Dissecting Linux Kernel Code

I wonder what happened to that proposal from a few years ago [1] to let Linux communicate more detailed error info to userland. Integer error codes are good enough for the most common errors, but in obscure cases like that one, it's often unreasonably difficult to figure out where an error code came from or what exactly went wrong.

[1] https://lwn.net/Articles/657341/

Whilst in no way as complex as Linux kernel development, I felt I was going down multiple debugging rabbit holes whilst I was try it lying to figure out why LibreOffice wasn’t displaying a texture fill.

My first stage of diagnosis found that we weren’t reading in texture brushes correctly. So I figured out how to do this. Then I found this didn’t work, so after a lot of checking if the EMF+ spec I realised we only read in compressed image data (PNG, JOEG, etc) but not uncompressed DIBs. I think the original coder didn’t realise what the bit so data type values represented and used a previous implementation to guess at what it did (this is no criticism of them, incidentally).

So then I realise the existing VCL code could read a DIB, but relied on a valid DIB header, which the EMF image object doesn’t provide.

So my next step was to add a seem into the DIB data reader that injects its own DIBV5 header. I’m now reading it in.

Now I have read it in, I actually have to get it to draw. Here’s hoping this will be easier to implement!

    #define ERANGE 34 /* Math result not representable */

> Hold on. Math result? But we don't do any math in the call that triggers that. Do we?

If you "man errno", you'll open a man page from Linux Programmer's Manual which tells you that "ERANGE" means "result too large" and it was defined in POSIX.1 and C99 standard, using it for either math overflow or size in general is appropriate. Particularly, in C99 (page 214, page 311) [0] , ERANGE is often returned by math functions (but it was also used by strtol, strtoll, strtoul, and strtoull for indicating buffer overflow), and simply defines it as "ERANGE: Result too large" [1].

So the conclusion is, although abusing the errno in an ad-hoc basis is not uncommon, but clearly this is not the case here, it's perfectly in compliance and it's even documented. It was simply the case which the comment itself in <asm-generic/errno-base.h> was outdated and misleading.

I suspect "ERANGE" was originally introduced to <asm-generic/errno-base.h> for some math or softfloat code and/or it was a copy-and-paste of the C manual, but later it was picked up by other system calls, and the original comment was never updated. The fact that

    #define EDOM 33 /* Math argument out of domain of func */

was just above ERANGE is possibly my circumstantial evidence.

However, I just looked through "git log" but I couldn't confirm my hypothesis, since the code has been there since 2005 [3] in the first git release. The comment must be ancient, a real historical artifact.

[0] http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf

[1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/er...

[3] https://github.com/torvalds/linux/blob/0d7614f09c1ebdbaa1599...

Gdb won't watch errno, but will it watch the word at the address where the instance of errno for that thread lives?