
Dissecting Linux Kernel Code - fao_
https://finnoleary.net/kernel-code.html
======
comex
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/](https://lwn.net/Articles/657341/)

------
chris_wot
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!

~~~
jdsully
You brought back memories of my time working on render code for MS Office.

~~~
chris_wot
Is it as ancient as LibreOffice (35+ years old)?

~~~
jdsully
I actually thought LibreOffice/OpenOffice/etc was a bit newer but it seems the
timeframes are very similar to MS Office around 1985ish. Excel which is the
product I worked on dated to 1987 but Word is older being first launched in
1983.

------
segfaultbuserr

        #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](http://www.open-
std.org/jtc1/sc22/WG14/www/docs/n1256.pdf)

[1]
[https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/er...](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html)

[3]
[https://github.com/torvalds/linux/blob/0d7614f09c1ebdbaa1599...](https://github.com/torvalds/linux/blob/0d7614f09c1ebdbaa1599a5aba7593f147bf96ee/include/asm-
generic/errno-base.h)

~~~
fao_
Indeed! I was indeed aware of this specific use of ERANGE (although imo
there's almost always a better error code that can be chosen to better
communicate what has happened).

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

