trying to work out some problem points
Posted Dec 7, 2011 11:07 UTC (Wed) by khim
In reply to: trying to work out some problem points
Parent article: Fedora security update to nginx
> Have you tried to look on the whole ngx_resolver_copy function?
Not until now.
So you want not just understand the code easily but to understand some random piece of it out of context. This is tall order: I'm not sure anything is written to this ideal. If you pull some random passage from the book then you'll hit the same problem even if book is obviously written to be read...
First adding the same comment you just gave here, would help the reader to understand which algorithm exactly the code is trying to implement.
Are you sure? This is change in file ngx_resolver.c and it fixes compression pointer processing. This either gives you enough background or sends you to google which gives you enough context...
Second one classic programming sin is to use uncommented, not symbolic magic numbers. Instead the reader should be supported with some kind of hint about what those "0xc0" and "0x3f" constants mean.
Did you meant to say "reader should be confused with some kind of define" ? Take a look on original code: it compares n to "0xc0" and of n is equal to "0xc0" then it takes low 6 bits out of it and... does something. These bits are quite obviously zeros so the whole thing makes no sense. Replacement code looks quote obviously correct: you check top two bits with "n & 0xc0" and is they are set it checks the low six bits. Well, this feels kind of suspicious: there are four possibilities and we lump three of them together. This was the only strange and suspicious part of code but then if you've read the RFC and know that these three possibilities usually considered equal (which you should probably do before you'll try to understand what goes on here), then it's obvious, too.
Be that a previous commented #define or a comment/explanation on the right of the code or something other.
Well, I sure will appreciate comment "01 and 10 are reserved and should not be used but we'll treat them as 11 for now" near if, but I'm not sure it's all that big of a deal.
I think it's the same thing as what was already discussed: if writer assumes fluency in C (and C is better IMO when you describe bit manipulations) and reader is not fluent in C (so it looks like hexdump to him) then it's really hard to reconcile these POVs.
I think we just live in different worlds. When I want to understand what goes on in code like this one but peppered with tons of defines the first thing I do is "gcc -E" to strip out all that scrap away: this gives me easy-to-understand (if sometimes overly verbose) code to read (does not work with C++ and it's inline functions, grrr). I doubt you ever do that...
Can you see the problem I'm trying to point to?
Well, sure: you are no fluent enough in C. Got that. But try to understand the other side, too! This code is obviously written by person who's VERY fluent in C and not all that fluent in English (this does not follow, but I knew the author personally so know it's true). Of course he'll try to write clean C code which requires as few English comments as possible. IMNSHO he more-or-less succeeded here so I don't see what's your problem.
to post comments)