Sponsored link
Serve your customers, not your servers, with VERIO Linux VPS. Full-access test-drive here.
| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
Buggifying critical core modules
Buggifying critical core modules
Posted Mar 19, 2008 16:53 UTC (Wed) by zlynx (subscriber, #2285)In reply to: Buggifying critical core modules by quotemstr
Parent article: Who maintains dpkg?
It would be a perfectly valid POSIX system to have 32-bit function pointers and 64-bit data pointers, for example. In that case, void* would have to hold 64 bits, but a varargs function expecting a function pointer and passed a void* would pull 32 bits off, leaving 32 bits of junk for the next argument to pull. The reason this bug is so subtle is because systems like that are quite rare. Up until they aren't, and then the waste product hits the rotary impeller. When AMD64 became popular, I ran into *many* of these vararg bugs on my Gentoo system because developers had become used to passing 0 for NULL. To my shame, I patched many of these by passing NULL and only now realize it should have been (char*)0 or similar.
(Log in to post comments)
Buggifying critical core modules
Posted Mar 19, 2008 17:15 UTC (Wed) by quotemstr (subscriber, #45331) [Link]
I don't think your scenario is realistic. dlsym() returns a void*, not a function pointer type, implying that void* and function pointers are the same size. Plus, IIRC, POSIX explicitly guarantees that function pointers can be round-tripped through void*. I don't think we have to worry about different pointer sizes any more than we have to worry about bytes that aren't eight bits wide. Don't litter your code with casts; just use NULL.
Buggifying critical core modules
Posted Mar 19, 2008 17:41 UTC (Wed) by zlynx (subscriber, #2285) [Link]
C guarantees void* will be large enough to hold any pointer type and automatic type-casting handles most of the problems. The *only* places this causes problems is functions without prototypes, which no one does anymore, and vararg functions. Since the only place this makes bugs is vararg parameters, it is a very subtle problem indeed. Another thing that makes these bugs painful: When I was debugging my AMD64 Gentoo problems caused by passing 0 instead of NULL or (char*)0, the problems only showed up *sometimes* with -O2 compiles and *usually* with -O3, but never with -O0. It entirely depended on what junk happened to be on the stack after the terminating 0 integer and if the junk was 0 or not.
Buggifying critical core modules
Posted Mar 19, 2008 17:48 UTC (Wed) by quotemstr (subscriber, #45331) [Link]
I'm not saying that you should spell "null pointer" at "0", but that it is okay to use NULL (which should be 0L or ((void*)0) everywhere.
Buggifying critical core modules
Posted Mar 19, 2008 18:04 UTC (Wed) by zlynx (subscriber, #2285) [Link]
I should have kept my response simple. No, you cannot use NULL everywhere. If function pointers and data pointers are different sizes, a void pointer will be the largest size. This will cause problems with varargs when it expects a pointer of the smaller size. An example with 32-bit function and 64-bit data: After calling the vararg function *properly* the stack might look like: (char*)0xf00fdeadf00fdead int(*x)(int,int)0xdeadbeef (int)32 (int)64 But if you call it with NULL for the function pointer it will be: (char*)0xf00fdeadf00fdead (void*)0x0000000000000000 (int)32 (int)64 Now if the vararg function pulls the arguments like this: pull char* - 0xf00fdeadf00fdead pull int(*x)(int,int) - 0x00000000 pull int - 0 pull int - 32 See how the last two int arguments got the wrong data?
Buggifying critical core modules
Posted Mar 19, 2008 18:09 UTC (Wed) by quotemstr (subscriber, #45331) [Link]
Even in the highly unlikely scenario that function pointers someday become _smaller_ than data pointers (which would have no benefits and which would make dynamic loading exceedingly complicated and delicate), the vast majority of pointers are still data pointers, all of which will have the same size. My point is that in the real world on mainstream systems, you don't have to worry about contingencies like the kind you mentioned anymore. Embedded, special-purpose code is different, but then we're not talking about POSIX anymore, and lots of other assumptions go out the window too. I don't imagine dpkg is going to run on a microcontroller.
Buggifying critical core modules
Posted Mar 20, 2008 18:53 UTC (Thu) by dododge (subscriber, #2870) [Link]
> If function pointers and data pointers are different > sizes, a void pointer will be the largest size. No, as noted above C explicitly requires void* to have the same representation and alignment as char*. The guarantee that a pointer can be reliably converted to void* and back again applies only to pointers to object and incomplete types, not pointers to functions.