> As I had virtually no understanding of the TCP code, I liberally sprinkled it with printf()s And people say it's a stupid way to debug!
What people say that?
A fifteen year old TCP bug?
41–50 of 61 posts
Re: A fifteen year old TCP bug?
#42The response to the bug report was by Bruce Evans, who is listed as the "Style Police-Meister" for FreeBSD. Apparently his job is to enforce standards & code style. Seems like he was doing his job. http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committe... Edit: edited for clarity. Thanks, pinko!
[deleted]
Re: A fifteen year old TCP bug?
#43Earlier quoted context omitted.
a better fix to use the lmin macro. libkern.h. http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/sys/sys...
Not really. The line is this: long adv = min(recwin, (long)TCP_MAXWIN rcv_scale) - (tp->rcv_adv - tp->rcv_nxt); So it's really: long = uint(long, (long)uint32) - (uint32-uint32) Here's the problem on x64: you're converting a 64-bit long to a uint, then doing a subtraction with another uint, then placing that result into a 64-bit long. Since the compiler is just doing an assignment rather than a sign extension, which…
the lmin[1] macro will convert the uints to a long int and then do the arithmetic.
[1]static __inline long lmin(long a, long b) { return (a [2]static __inline u_int min(u_int a, u_int b) { return (a Edit: 6.3.1.8 Usualarithmetic conversions in the c-99 standard.
Re: A fifteen year old TCP bug?
#44Earlier quoted context omitted.
Care to elaborate? Unlike signed ones, unsigned integral types at least have well-defined behavior on shifting and overflow. (I'm speaking in terms C specifically here, of course.)
Signed ints are easier to range check at runtime. Given an unsigned int, it's difficult to detect an invalid result from combining or comparing signed and unsigned ints. Google's C++ Style Guide discourages using unsigned ints to represent nonnegative numbers (like sizes or counts). It recommends using runtime checks or assertions instead. http://google-styleguide.googlecode.com/svn/trunk/cppguide.x... Unsigned ints…
The "always use signed" rule is a source of endless debate in C circles. I personally like almost everything in the Google C++ Style Guide, but this is one place where I think they got it wrong.
The problem is that the riskiest place for a signed/unsigned mismatch is when calling an unsigned API with a signed value. Simply deciding to not use unsigned at all doesn't fix this because ANSI C and STL use unsigned types throughout (f.e. memcpy)
if (size There will still be spots where you'll need to compare signed and unsigned values, but the compiler will warn you about these. You'll have to cast one side or the other but that's a GOOD thing. Since neither a signed-compare nor an unsigned-compare is always what you want you want to be explicit about it.
There are other advantages to using unsigned types. For instance, it gives an explicit hint to the person reading the code about the range of the value. I think this makes interfaces clearer. For instance if you see a function signature of "void foo(const uint8_t *, size_t)" you'll immediately guess that you're dealing with a memory buffer and its explicit size without even seeing the names of the parameters.
Actually, if I had my way "int" would default to being unsigned and you'd have to specifically request "signed" if that's what you want. I find that I probably use unsigned types 5x as often as signed ones.
Re: A fifteen year old TCP bug?
#45> As I had virtually no understanding of the TCP code, I liberally sprinkled it with printf()s And people say it's a stupid way to debug!
What people say that?
Pick any "how do you debug?" submission anywhere, and you'll see a lot of people claiming that using printf, etc, is retarded in the age of good debuggers.
Maybe they're just a noisy minority.
Re: A fifteen year old TCP bug?
#46Is Stevens vol. 2 in the public domain now? If not, that's pretty poor form, linking to a scanned pdf of the book.
Its not because if you are a FreeBSD developer it is already assumed that you own every copy of Steven's books next to the shrine of him in your basement. So linking to a digital scan is not infringement its just convenience.
Re: A fifteen year old TCP bug?
#47The response to the bug report looks depressingly typical. Rejects the working fix with a wall of text speculation on numerous other possibly better fixes (without deigning to actually choose one). Nirvana fallacy in action!
What he's doing seems useful to the project. There's no better time to get it right. I'm just surprised he's willing to expend so much effort communicating instead of just fixing the patch. I noticed that C programmers tend to use macros for things where (possibly non-exported) inline functions would make more sense. Why is that? Are they in the habit of building the OS with all optimizations off? Or is it that they'…
I think it's mostly inertia and culture. Inline functions weren't in the standard till C99.
Re: A fifteen year old TCP bug?
#48Earlier quoted context omitted.
What people say that?
Pick any "how do you debug?" submission anywhere, and you'll see a lot of people claiming that using printf, etc, is retarded in the age of good debuggers. Maybe they're just a noisy minority.
Using printf to debug when you could use a good debugger is...well, I wouldn't say stupid, just highly unproductive.
The problem is there are a lot of problems that aren't debugger friendly, especially if you are new to a particular domain. The kernel, timing-related problems, remote systems, production systems (you have intelligent logging, right?), etc., all have extremely valid reasons for using printf debugging.
Re: A fifteen year old TCP bug?
#49Earlier quoted context omitted.
What people say that?
Pick any "how do you debug?" submission anywhere, and you'll see a lot of people claiming that using printf, etc, is retarded in the age of good debuggers. Maybe they're just a noisy minority.
printf debugging is too simple and intuitive to justify an entire blog post. ;)
Re: A fifteen year old TCP bug?
#50Earlier quoted context omitted.
What he's doing seems useful to the project. There's no better time to get it right. I'm just surprised he's willing to expend so much effort communicating instead of just fixing the patch. I noticed that C programmers tend to use macros for things where (possibly non-exported) inline functions would make more sense. Why is that? Are they in the habit of building the OS with all optimizations off? Or is it that they'…
The inline keyword is best thought of as a hint to the compiler, not a command. The compiler is free to ignore the meatbag telling it to inline functions if it chooses to. Macros are substituted in before the compiler, so they are always inlined. EDIT: Hint, not suggestion.
That is true, but the idea that programmers can use macros to force the compiler to emit optimal code is wrong, too. In the early days of C, that was (almost) true, but those days are over.
In theory, a compiler could uninline common code blocks, including macro calls, into functions to decrease object code size and/or working set size, thus speeding up the program (example: functions f and g with inlined function h each take 2 cache lines; without inlining, each of f, g and h fit a single cache line)
In practice, using an inline function will give the compiler the opportunity to weigh different objectives (code size, execution speed, debuggability, etc) against each other, and do the better thing.