Comment by jdxcode
1 year ago
I totally see the point of this, but still, you have to admit this is pretty funny:
> Developers sometimes experience trouble debugging the quarter-million line amalgamation source file because some debuggers are only able to handle source code line numbers less than 32,768 [...] To circumvent this limitation, the amalgamation is also available in a split form, consisting of files "sqlite3-1.c", "sqlite3-2.c", and so forth, where each file is less than 32,768 lines in length
That would imply that such debuggers are storing line numbers as not just 16-bit numbers (which is probably sensible, considering that source files longer than that are uncommon), but as signed 16-bit numbers. I can't fathom a situation where line numbers would ever be negative.
Cue C or C++ should-I-prefer-signed-or-unsigned-integers debate
It's not that uncommon of a convention to strictly use signed numbers unless doing bit manipulation, eg the Google C++ Style Guide.
Notably, unsigned integers also have defined behavior for overflow. This means compilers can do less optimization on unsigned integers. For example, they can't assume that. x + 1 > x for unsigned ints, but are free to assume that for standard ints.
That is just another reason to stick with signed ints unless there is a very specific behavior you rely on.
3 replies →
Maybe somewhere some line offset is stored as i16? (I don't understand why anyway but..)
The __LINE__ macro defaults to "int". That then gets handed to the debugger.
The __LINE__ macro, like all other macros, is expanded during the preprocessing of the source code and is not handed to the debugger in any way.
2 replies →