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 |
Who maintains dpkg?
Who maintains dpkg?
Posted Mar 18, 2008 19:30 UTC (Tue) by dw (subscriber, #12017)Parent article: Who maintains dpkg?
The (char*)0 -> NULL varargs change is pretty amateurish and introduces a real, undeniable bug, as void* is not guaranteed to be the same size as char*, only that it must be the same size or larger. I recently had to fix several bugs in a certain open source communications toolkit that took exactly this form; building on a new architecture caused all manner of weird looking problems to appear that wasted quite a few hours to figure out. One of the hardest things I've had to swallow since starting to write code for money is *not* making cosmetic changes in *obviously ugly* code, because My Style is Obviously Better than This Piece Of Crap. It's hard, but a professional should understand that the same ego device that causes him to feel this superiority is the exact same thing that he is trampling all over in someone else when making stylistic changes of no technical merit to their code. To me this seems small-mindedly rude, and on several lines of the diffs that Ian highlighted, more than a little concerning for such a core Debian maintainer to be making this sort of trivial mistake. I know who I won't be blaming the next time dpkg swallows my hard disk. ;)
(Log in to post comments)
Who maintains dpkg?
Posted Mar 18, 2008 19:42 UTC (Tue) by dw (subscriber, #12017) [Link]
Just to point out that the zero thing is a language feature, this is taken from this C99 draft (PDF):6.3.2.3 3. An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant. If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function.Bjarne Stroustrup argues in the C++ FAQ for the direct use of 0 as opposed to NULL. I think the point he makes is that as something defined in the spec ("null pointer constant"), the semantic meaning of the literal 0 should be known and understood by every C programmer.
Who maintains dpkg?
Posted Mar 18, 2008 20:17 UTC (Tue) by elanthis (subscriber, #6227) [Link]
They're also adding a specific null pointer constant, nullptr, to the next version of C++ to make all the "but 0 isn't a pointer" weenies happy.
Who maintains dpkg?
Posted Mar 18, 2008 21:07 UTC (Tue) by nix (subscriber, #2304) [Link]
That's just bowing to the inevitable: virtually every vendor already has such a constant, under some name or other (including GCC). You need it for non-confusing overload resolution anyway. (Plus, to be honest, the overloading of the integer 0 with a specific pointer meaning, with the unique stipulation that it need not be all-bits-zero, with the corresponding `pointer context' stuff, was a big mistake from the start.)
Who maintains dpkg?
Posted Mar 18, 2008 21:19 UTC (Tue) by roelofs (subscriber, #2599) [Link]
They're also adding a specific null pointer constant, nullptr, to the next version of C++ to make all the "but 0 isn't a pointer" weenies happy.g++ has had something like that for quite some time now.
Greg
Buggifying critical core modules
Posted Mar 18, 2008 20:24 UTC (Tue) by ncm (subscriber, #165) [Link]
To be very precise about it: to pass 0, literally, to a varargs function in a position where it expects a pointer value is an error. To pass NULL is the same error. The only correct way is to pass either a variable of exactly the right type, or 0 cast to exactly the right type. Anything else is wrong, and buggy. Changing 0 to NULL just changes one bug to another. Changing (e.g.) "(char*)0" to NULL introduces a gratuitous bug into correct code.A maintainer who introduces gratuitous bugs into correct code should not be a maintainer. A maintainer who introduces gratuitous bugs into critical, core modules should be physically ejected from the project, preferably on a ballistic trajectory, with rotation.
Buggifying critical core modules
Posted Mar 18, 2008 21:09 UTC (Tue) by nix (subscriber, #2304) [Link]
To be honest, though, I've introduced this particular bug myself without noticing, and so has everyone else I know. The real problem here is C and C++ being deeply counterintuitive (even more than usual).
Buggifying critical core modules
Posted Mar 19, 2008 2:20 UTC (Wed) by ncm (subscriber, #165) [Link]
Which part of "don't break code that works, for no reason" is counterintuitive? (I ask merely for information.)
Buggifying critical core modules
Posted Mar 19, 2008 8:31 UTC (Wed) by nix (subscriber, #2304) [Link]
The counterintuitive part is NULL not always being the thing to use if you want a null pointer. Breaking code that works, well, I've done *that*, too, but generally when refactoring old and tangled messes. I didn't think dpkg would count (and random stylistic cleanups into a *different style than the rest of the code*, well, ick.)
null pointers
Posted Mar 19, 2008 9:54 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
In what scenario does NULL not work if you want a null pointer? Specifically, when doesn't GCC's __null (or equivalent in other modern compilers) do what you expected a null pointer to do ?
null pointers
Posted Mar 19, 2008 10:01 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
Ah, I think I get it now. So the concern is that on some (now obscure) platforms, there are a variety of pointer sizes available, and someone might actually be stupid enough to use one narrower (and thus less general) than void * in a vararg function. At which point NULL (being void *) will be the wrong size and cause unexplained problems. It seems to me that (type *) NULL is still a perfectly good choice of value for such a parameter and that we have modern vararg type checking for exactly this sort of reason, although admittedly that probably won't warn you about the portability problem if you're testing on platforms where pointers are always the size of the machine word.
null pointers
Posted Mar 19, 2008 10:13 UTC (Wed) by cortana (subscriber, #24596) [Link]
I wonder... is that a -W option to GCC that enables a warning if you try to pass NULL or 0 to a varargs function where a pointer to some data is expected?
null pointers
Posted Mar 20, 2008 10:22 UTC (Thu) by msmeissn (subscriber, #13641) [Link]
If you mark up the function with __attribute__((sentinel)) then
it will warn.
All common functions are marked up already.
$ cat xx.c
#include <unistd.h>
void f() {
execl("hello","world","!",0);
}
$ gcc -Wall -O2 -c xx.c
xx.c: In function ‘f’:
xx.c:4: warning: missing sentinel in function call
$
I personally marked up X, GLIB and GTK for instance... :/
Ciao, Marcus
null pointers
Posted Mar 22, 2008 17:03 UTC (Sat) by spitzak (subscriber, #4593) [Link]
Aha! So that's what that damn warning means! It would really help if the warning said "missing cast of 0 to varargs function" rather than "missing sentinal"!
null pointers
Posted Mar 19, 2008 15:54 UTC (Wed) by vmole (subscriber, #111) [Link]
Actually, that's still not it. A varargs function that specifies a "(type *)" argument requires a "(type *)" argument, not something else, not even "(void *)". The problem with the modification made to dpkg was not the replacement of "0" with "NULL", but the removal of the "(char *)" cast.
null pointers
Posted Mar 19, 2008 17:18 UTC (Wed) by quotemstr (subscriber, #45331) [Link]
Name a POSIX system, or better yet, a platform on which dpkg runs, where code and data pointers are not the same size. Using NULL for function pointers is fine given certain assumptions, and these days, IMO, one can safely make these assumptions.
null pointers
Posted Mar 19, 2008 17:54 UTC (Wed) by vmole (subscriber, #111) [Link]
Once upon a time, people assumed that sizeof(int) == sizeof(_ptr_).
Once upon a time, people assumed that sizeof(int) == sizeof(long).
Once upon a time, people assumed that sizeof(int) == 2 and sizeof(long) == 4.
Once upon a time, people assumed you could dereference NULL (or 0), and its value was 0.
Once upon a time, people assumed that all the world was ASCII.
Times change, and your "safe assumptions" are not so safe anymore.
null pointers
Posted Mar 19, 2008 18:05 UTC (Wed) by quotemstr (subscriber, #45331) [Link]
Assumptions are necessarily for practicality. You assume that cars will stop at red lights when you cross the street, don't you? You assume that a char has eight bits, don't you? Standards are simply sets of assumptions we allow programs to make. POSIX implies that using NULL, with a sensible definition, is okay for every kind of pointer. Some assumptions are warranted and others not. It's not warranted to assume little-endian byte ordering, for example, because the choice is arbitrary and still not uniform. OTOH, it is warranted to assume that pointer types are the same size because they're uniform ally so, and because there's a strong reason to think that the assumption will hold into the future.
null pointers
Posted Mar 19, 2008 20:20 UTC (Wed) by vmole (subscriber, #111) [Link]
You assume that cars will stop at red lights when you cross the street, don't you?
You obviously don't live in Houston. I'd be dead if I was that careless. (No smiley.)
You assume that a char has eight bits, don't you?
No, why would I? Sure, that's the most common situation, but if I'm actually coding something that requires that (unusual), then I check. Now, I admit that I probably would just error-out, rather than spend the time coding for the unusual situation until I actually needed it.
Sure, we all make assumptions when we have to. But why make an assumption when you can just as easily follow the standard? If you're coding to POSIX, and POSIX really does imply that null-pointer types are all interchangeable, then fine. But the code isn't C standard compliant, and I've spent way too much of my life fixing code full of assumptions about platforms and compilers to have much positive to say about code that doesn't follow appropriate standards.
null pointers
Posted Mar 19, 2008 21:39 UTC (Wed) by quotemstr (subscriber, #45331) [Link]
If you've represented a UTF-8 encoded string with some kind of char array, you've relied on 'char' having at least eight bits. There is a tradeoff involved in not making assumptions. Say you're writing a portable program and you don't want to assume AF_UNIX support. You can either use some other IPC mechanism, likely to be less efficient, or code two versions, one that uses unix-domain sockets and another that uses something else. Either way, there is an overhead for not assuming AF_UNIX support, either in runtime overhead or maintenance. You can add build-time checks of your assumptions, true, but some assumptions hold true so often that it's often not worth even bothering to check. All I'm arguing is that for non-embedded systems, all pointers being the same size is the case often enough that it's not worth it to litter the code with strange casts. Checking whether the assumption held would be simple enough with something like autoconf, but there's no reason to clutter the code itself.
null pointers
Posted Mar 19, 2008 22:39 UTC (Wed) by vmole (subscriber, #111) [Link]
Whose talking about littering the code with strange casts? Do you really find:
somevarargfunc("these", "are", "some", "strings", (char *) NULL);
strange or confusing? Because that's all we're talking about. Any non-varargs function will have a prototype that will take care of this. (At this point someone will pipe-up with the comment that C89 doesn't require prototypes. That's true. But then you have to cast a lot of things, and my argument becomes stronger, not weaker.)
And of course there's a tradeoff in not making assumptions. But the kind of thing you're talking about, such as OS features available, is a whole different level, and no, I don't see anything wrong with assuming (for example) that a program is unix-like specific, and coding it as such, when the cost of doing otherwise is non-trivial. But why this desire to willfully violate a basic standard to save a few characters, when the (not-likely, but could happen) downside is obscure failures and tedious debugging?
Oh, and there's a big difference between "assume char is 8 bits" and "assume char is at *least* 8 bits". The first is an assumption that will eventually bite you, the second is not an assumption at all, but is guaranteed by the C89 standard.
null pointers
Posted Mar 20, 2008 10:19 UTC (Thu) by tfheen (subscriber, #17598) [Link]
Whether C89 requires prototypes or not is irrelevant to dpkg though, as dpkg is using C99. (--std=gnu99, to be precise.)
null pointers
Posted Mar 19, 2008 21:03 UTC (Wed) by nix (subscriber, #2304) [Link]
It doesn't even hold into the present :(
null pointers
Posted Mar 19, 2008 21:11 UTC (Wed) by quotemstr (subscriber, #45331) [Link]
Can you name an example of a POSIX system for which the assumption does not hold?
null pointers
Posted Mar 19, 2008 21:47 UTC (Wed) by nix (subscriber, #2304) [Link]
Any IA64 or PPC64-based systems. I think HPPA too but can't remember. (On both these platforms it so happens that data pointers are all the same size: but function pointers are larger... and yes this has exposed bugs in free software.)
null pointers
Posted Mar 19, 2008 21:57 UTC (Wed) by quotemstr (subscriber, #45331) [Link]
I don't think that's true. See the downthread comments on the same topic. I'd be interested in knowing what the specific bugs were.
null pointers
Posted Mar 19, 2008 22:18 UTC (Wed) by nix (subscriber, #2304) [Link]
If I could remember, I'd say. I'll have a dig.
null pointers
Posted Mar 28, 2008 22:33 UTC (Fri) by anton (guest, #25547) [Link]
On [PPC64 and IA64] it so happens that data pointers are all the same size: but function pointers are larger.Not on Linux-PPC64 (and probably not on Linux-IA64, either):
#include <stdio.h>
int main()
{
printf("%ld %ld\n", sizeof(void *), sizeof(int(*)()));
return 0;
}
prints
8 8
null pointers
Posted Mar 29, 2008 1:08 UTC (Sat) by nix (subscriber, #2304) [Link]
Oh. My memory is failing me and I can't read simulator source code, it seems. (I was *sure* they were examples of arches using a descriptor consisting of a data pointer combined with other stuff.)
null pointers
Posted Mar 20, 2008 15:07 UTC (Thu) by lysse (subscriber, #3190) [Link]
> Assumptions are necessarily for practicality... You assume that a char has eight bits, don't you? I think that's called "disproving your own argument by contradiction".
null pointers
Posted Mar 19, 2008 20:54 UTC (Wed) by nix (subscriber, #2304) [Link]
Have two, IA64 and PPC64. Code and data pointers being different sizes is not uncommon: generally, in that situation, the data pointer is a plain pointer and the code pointer is some sort of descriptor.
null pointers
Posted Mar 19, 2008 21:22 UTC (Wed) by quotemstr (subscriber, #45331) [Link]
No go. How would dlsym() work if that were true? Also, an IA64 function pointer is a pointer to a function descriptor, which is a pair of values -- a pointer to the start of the code and the global pointer to use for that function. The pointer to the descriptor is a normal data pointer, and is what corresponds to the C-level function pointer.
null pointers
Posted Mar 19, 2008 21:48 UTC (Wed) by nix (subscriber, #2304) [Link]
Ah, oops. Forgot about that. (It's tripped me up before, too.) (I still have memories of pointer sizing bugs in the area of dlsym(), but I can't remember what they were.)
null pointers
Posted Mar 20, 2008 3:52 UTC (Thu) by rganesan (subscriber, #1182) [Link]
> Name a POSIX system, or better yet, a platform on which dpkg runs, where > code and data pointers are not the same size. Using NULL for function > pointers is fine given certain assumptions, and these days, IMO, one can > safely make these assumptions. I think you guys are missing the point. The issue is not code vs data pointers. The issue is ptr vs data. A varargs function being passed a NULL pointer needs to be passed (void *) 0 or (char *) 0 or some pointer. Passing just a 0 which is legal representation for a NULL pointer in C does not work for 64-bit systems. 0 is a 32-bit quantity, (void *) 0 is a 64-bit quantity for LP64 (Unix/Linux) as well as P64 (Windows) 64-bit platforms.
null pointers
Posted Mar 19, 2008 20:44 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
How is what I said "still not it" when it's exactly the same as your explanation ?
null pointers
Posted Mar 19, 2008 21:11 UTC (Wed) by vmole (subscriber, #111) [Link]
Because it's not a matter of narrow vs. wide, or using something "narrower than (void *)". If the function specification says "This vararg list is terminated by null character pointer", then, by the standard, you have to pass something equivalent to "(char *) 0", and "(void *) 0" isn't. The idea of a "void *" being generic is that variables of type "void *" can store pointers of any type, and pointers can be cast to void and then back to the original type without information loss. But they are a distinct type, and not necessarily interchangeable with other pointer types.
Does this matter the vast majority of the time? No. Is it C standard lawyer nitpickery of the most annoying kind? Yes, of course. But the C89 standard is this way precisely because there were some systems for which this kind of nitpicking *did* matter.
But yes, where you wrote: "It seems to me that (type *) NULL is still a perfectly good choice of value for such a parameter." is correct. I should have distinguished that in my original reply.
A small nit-pick...
Posted Mar 19, 2008 22:27 UTC (Wed) by dw (subscriber, #12017) [Link]
"The idea of a "void *" being generic is that variables of type "void *" can store pointers of any type, and pointers can be cast to void and then back to the original type without information loss." As far as I remember it is illegal to convert between void* and any function pointer type in ANSI C; POSIX' specification of dlsym() actually relies on what is essentially a vendor extension to work for function pointers.
A small nit-pick...
Posted Mar 19, 2008 22:52 UTC (Wed) by vmole (subscriber, #111) [Link]
Oops, you're correct about that. I just looked in Plauger and Brodie's "Standard C" (which is not the standard, but I think we can trust them), and they agree: it's *object* pointers that can be intraconverted with void pointers.
But the hilarious thing is this:
The types _pointer_to_char_, _pointer_to_signed_char_, _pointer_to_unsigned_char_, and _pointer_to_void_ all share the same representation.So "(void *) 0" is interchangeable with "(char *) 0", but not "0" or "(int *) 0".
A small nit-pick...
Posted Mar 19, 2008 23:15 UTC (Wed) by nix (subscriber, #2304) [Link]
This is surely related to the aliasing rules, which also have a similar special hole allowing aliasing of of void * and char *, but not of pointers of any other distinct types.
Buggifying critical core modules
Posted Mar 19, 2008 14:14 UTC (Wed) by quotemstr (subscriber, #45331) [Link]
Is there one real-world POSIX-compliant platform that cares about the distinction?
Buggifying critical core modules
Posted Mar 19, 2008 14:33 UTC (Wed) by dw (subscriber, #12017) [Link]
$ cat -n a.c ; ./a ; uname -sp
1 #include <stdio.h>
2
3 int main(void) {
4 printf("%d %d\n", sizeof(int), sizeof(void *));
5 return 0;
6 }
4 8
NetBSD x86_64
Same for Linux amd64.
Buggifying critical core modules
Posted Mar 19, 2008 14:44 UTC (Wed) by quotemstr (subscriber, #45331) [Link]
No. sizeof(int) and sizeof(void*) are likely to be different, but sizeof(void*) and sizeof(any_other_t*) are the same on every POSIX platform I know about. That's the distinction without a difference the OP mentioned. You don't need to pass "exactly the right type" because, AFAICS, the bit pattern of the pointer is going to be same no matter what -- provided you pass an actual pointer.
Buggifying critical core modules
Posted Mar 19, 2008 15:15 UTC (Wed) by dw (subscriber, #12017) [Link]
Oh, whups :) In that case I do not know the answer.
Buggifying critical core modules
Posted Mar 19, 2008 15:19 UTC (Wed) by tjc (subscriber, #137) [Link]
> the bit pattern of the pointer is going to be same no matter what --
> provided you pass an actual pointer.
This took me by surprise:
int main(void)
{
int n;
void *p = &n;
printf("%p\n", p);
p++;
printf("%p\n", p);
return 0;
}
I thought incrementing a void pointer would cause a compiler error (or at least a warning),
but it seems to treat it as a char pointer and increment it by one byte on my system (gcc
4.1.2 on Solaris).
Buggifying critical core modules
Posted Mar 19, 2008 15:26 UTC (Wed) by dw (subscriber, #12017) [Link]
A GCCism:
-Wpointer-arith
Warn about anything that depends on the ``size of'' a
function type or of "void". GNU C assigns these types a
size of 1, for convenience in calculations with "void *"
pointers and pointers to functions.
Buggifying critical core modules
Posted Mar 20, 2008 18:34 UTC (Thu) by dododge (subscriber, #2870) [Link]
The lesson being: when you run "gcc" with no options, it does not compile the C language, but rather the "GNU C" language. GNU C bears a strong resemblance to C but has many additional and alternate semantics. If you're trying to write portable code and you want gcc to follow Standard C rules, you have to explicitly request it. I normally use, at a minimum: -std=c99 -pedantic -Wall -Wextra
Buggifying critical core modules
Posted Mar 19, 2008 16:47 UTC (Wed) by jengelh (subscriber, #33263) [Link]
#include <stdio.h>
#define E(t) printf(#t " = %u\n", sizeof(t));
int main(void)
{
E(void *);
E(void far *);
E(void near *);
E(void (*)(void));
}
near pointers are always 2, and far are always 4. But it is interesting to see that untagged pointers vary in size, depending on the compiler model. Turbo C++ 1.x for DOS says:
/* “Tiny” and “Small” model */ void * = 2 void (*)(void) = 2 /* “Medium” model */ void * = 2 void (*)(void) = 4 /* “Compact” model */ void * = 4 void (*)(void) = 2 /* “Large” and “Huge” model */ void * = 4 void (*)(void) = 4 /* For your information about this compiler, in all models: */ int = 2 long = 4
nonfunctionpointertype * is always the same width as void *, though.
Buggifying critical core modules
Posted Mar 19, 2008 17:07 UTC (Wed) by quotemstr (subscriber, #45331) [Link]
Not applicable. DOS isn't a POSIX system.
Buggifying critical core modules
Posted Apr 7, 2008 8:00 UTC (Mon) by jengelh (subscriber, #33263) [Link]
So what? You do not need DOS to make a compiler output far/near-based pointers. What it requires is — I think — that the CPU is in real mode because that's where far/near pointers make most sense.
Buggifying critical core modules
Posted Mar 19, 2008 16:53 UTC (Wed) by zlynx (subscriber, #2285) [Link]
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.
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.
Buggifying critical core modules
Posted Mar 20, 2008 8:58 UTC (Thu) by filipjoelsson (subscriber, #2622) [Link]
But isn't 0 an integer? In which case it would be necessary to cast that 0 to a ptr. Ok, so there's not much point arguing about which pointer to cast it to - but removing the cast would still be a subtle error.
Buggifying critical core modules
Posted Mar 20, 2008 11:14 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]
Another varargs type problem: sizeof() returns size_t, but %d expects an int. You should use %zu to format values of type size_t.
Buggifying critical core modules
Posted Mar 20, 2008 11:58 UTC (Thu) by dw (subscriber, #12017) [Link]
Hah, I was waiting for that. :) Seems you can't complain about type widths and then go write an invalid printf!
Buggifying critical core modules
Posted Mar 20, 2008 23:54 UTC (Thu) by nix (subscriber, #2304) [Link]
... unless you want your program to be portable to any of the large number of extant systems that don't support %z in printf(). (Linux/glibc systems have supported it for ages, of course, but it's the only system I'm writing code for right now that does.)
Buggifying critical core modules
Posted Mar 20, 2008 15:12 UTC (Thu) by lysse (subscriber, #3190) [Link]
Ah, so it's OK to sin if it doesn't cause any immediately identifiable short term problems?
Buggifying critical core modules
Posted Mar 19, 2008 15:43 UTC (Wed) by paulj (subscriber, #341) [Link]
Changing (e.g.) "(char*)0" to NULL introduces a gratuitous bug into correct code.
On any platforms that matter though?
Buggifying critical core modules
Posted Mar 19, 2008 19:52 UTC (Wed) by ncm (subscriber, #165) [Link]
What does "that matter" mean? Usually it seems to mean "that I have". We've learned painfully, again and again, that choosing that definition leads to pain. It's easy to follow the correct rule: "in a varargs call, always pass the correct type." Doing what you know is incorrect just because it happens to work on your own hardware is little different from sabotage.
Buggifying critical core modules
Posted Mar 22, 2008 10:19 UTC (Sat) by sandmann (subscriber, #473) [Link]
Fine, let's define "matter" as "exist". Which platforms are we worrying about?
Buggifying critical core modules
Posted Mar 20, 2008 16:16 UTC (Thu) by liljencrantz (subscriber, #28458) [Link]
All 64-bit x86 CPUs. That's only the second most common platform to run Linux on.
Who maintains dpkg?
Posted Mar 18, 2008 19:48 UTC (Tue) by nix (subscriber, #2304) [Link]
Also, (void *)0 is a null pointer, even in a stdargs function: as Ian pointed out, NULL-the-macro may be defined as '0', which is not a pointer in a stdargs context and may have a different bit value.
Who maintains dpkg?
Posted Mar 21, 2008 4:22 UTC (Fri) by mikov (subscriber, #33179) [Link]
It took me by surprise that most people here expect NULL to be (void)0. My impression from the C and C++ standards (which admittedly I haven't looked at recently) is that 0 is the preferable definition for NULL. Not 0L and not (void)0. (I know that GCC's headers define it as (void)0. However if it was changed to plain 0, all correct ANSI C programs should continue to work!) So, the only clearly correct, portable and even stylistically preferable solution in this case is ((char*)0). I am surprised that there is discussion about it at all.
Who maintains dpkg?
Posted Mar 18, 2008 20:04 UTC (Tue) by tzafrir (subscriber, #11501) [Link]
I just wonder what exactly will generate a larger discussion here: the development of dpkg (with the semi-hijack and all) or the merits of NULL pointers.
NULL vs. 0 discussion
Posted Mar 18, 2008 21:49 UTC (Tue) by pr1268 (subscriber, #24648) [Link]
> I just wonder what exactly will generate a larger discussion here: the development of dpkg (with the semi-hijack and all) or the merits of NULL pointers.
Lively discussions on NULL vs. 0 have occurred on lwn.net before. And they'll probably occur again here in the future.
Our discussions here show how easily code micromanagement issues can permeate to all areas of software engineering and computers, and its staunch support from either side of the style debate.
Artificially-imposed code standards (those which exist outside of the formal grammar/syntax of a programming language, and which usually focus on boundary character placement, white space, identifier names, etc.) are among the most annoying and contentious, but they're also the most hotly defended. Even the white space requirements of COBOL and Python can be abused (and subsequently debated) over differing styles.
NULL vs. 0 discussion
Posted Mar 18, 2008 22:42 UTC (Tue) by zlynx (subscriber, #2285) [Link]
Indeed, style is an annoying problem. Sometimes I wish language authors would just define the space and brace layout in the language spec and make the compiler enforce it. :) Python made a big mistake in this area by allowing both tabs and spaces.
A fault of modern source editors?
Posted Mar 18, 2008 23:07 UTC (Tue) by dw (subscriber, #12017) [Link]
Just a side note, but Python treats tabs as 8 spaces. My main point is, I don't understand why we don't have "text" editors advanced enough to preserve original whitespace style while presenting source code in the user's preferred style. Given that source code is actually just a big data structure. I've mentioned the idea of a "structured editor" to a few people before, and they generally just look at me like I'm insane (which is not unusual), but other times I wonder if we had more general purpose libraries with something like DOM APIs, would merging and source code editing not be all the more pleasurable an experience? Merge conflict -> "aah, statements are semantically identical" Merge conflict -> "aah, expressions evaluate to the same type" Merge conflict -> "aah, extra array initialiser added" etc. I also appreciate the idea of typing "for" and having a text editor display some sort of widget that meant you didn't have to type the semicolons, and so on. If it was done nicely it might greatly reduce the possibility of introducing logic errors due to typos. In a world where source text is treated like the data structure it is by editing and merging components, arguments about style largely disappear (although I guess naming schemes will always come up :). I find the concept of hand-editing a large data structure in what is basically a glorified hex editor a little more repulsive than using a GUI to do the same job.
Refactoring browsers
Posted Mar 18, 2008 23:26 UTC (Tue) by dark (subscriber, #8483) [Link]
This is an idea that "Refactoring Browsers" try to address, but I haven't heard of anyone trying to hook one up to a version control system to resolve conflicts. They are usually designed the other way around: user hits the "add parameter to function" button and the browser changes the function and all its callers to match.It's incredibly hard to do for C, though, because of the preprocessor.
A fault of modern source editors?
Posted Mar 18, 2008 23:55 UTC (Tue) by zlynx (subscriber, #2285) [Link]
I agree with you. I'd love to have structured editor, grep, diff and patch tools. Anything with a well-made definition should be doable, like C's BNF. Perl need not apply. :) I would handle the preprocessor by having the editor (and other tools) handle the preprocessed code and then replacing it with the macro in the display while retaining the macro definition in the background. It could be expanded or contracted in the display by a double-click, or right-click, or a little plus icon.
A fault of modern source editors?
Posted Mar 19, 2008 1:32 UTC (Wed) by nix (subscriber, #2304) [Link]
A lot of your points have merit, but one thing you mentioned is less useful than it might at first appear: the `code template' stuff, where you type 'for ' and the editor types in (;;) and sticks you after the opening bracket. This is problematical for several reasons: Firstly, the editor is making your cursor jump around without your having commanded it to move, and both the point it left and the place it moved to is essentially arbitrary (does your editor's template matcher fire after space? Bracket? Which section of the for does it move you to? Perhaps it moves you to the loop body...) Secondly, once you're there, there's no way the editor can automatically tell that you've finished typing in one section and want to move to the next, so you'll have to tell it. Had the template not been there, you could have indicated this by pressing the semicolon; but with the template in place, you have to hit the right cursor key some number of times, or have a right-one-language-token key -- which is still no more convenient than hitting ; would have been! Everyone always uses for loops as an example of where syntactically-aware editing would be useful, but to be honest I've never found anything more elaborate than autoindenting and automatic closing brace/bracket insertion to be any help at all. Those identifier autocompletion dialogs are even worse, because unless you have a hyper-high-end system they make the editor stall for an instant, they tend to dump a dialog box up on top of your typing (why not open a pane at the bottom of the screen and fill it up?) and they invariably don't contain the identifier I'm actually *looking* for anyway. So the result is a juddery, flickery, annoying mess, like browing an advert-laden site with animation enabled and flash installed. :)
A fault of modern source editors?
Posted Mar 22, 2008 4:32 UTC (Sat) by kevinbsmith (subscriber, #4778) [Link]
Actually, the Java editor in eclipse has solved this pretty nicely. Type in "for" and hit
Ctrl-Space (their auto-complete trigger). Choose which kind of for loop you want, and it
creates a skeleton. It's even smart enough to look at what arrays are in scope and guess which
one you wanted to iterate over.
It places your cursor in the first "field", which is the iterator variable name ("i"). If you
modify it, all other references to i are updated to your new name. Hit tab to advance to the
second field, which is the terminating condition. Tab again gets you to the body of the if,
inside the curly braces.
Or at any point you can bail out by hitting an arrow key or mouse-clicking elsewhere. You're
not locked into just editing those fields. It takes a bit of practice, but is really quite
effective. More so for iterating collections classes and other Java-isms.
I don't really like Java, and eclipse is bloated and has a clumsy UI. But it is a really
powerful tool that manages to make programming faster and less error-prone in many ways. I
miss it when coding in other languages.
A fault of modern source editors?
Posted Mar 19, 2008 22:12 UTC (Wed) by quotemstr (subscriber, #45331) [Link]
Try paredit-mode for Emacs when editing Lisp. It's a structured editing mode with commands that work on whole sexps instead of characters per se. For example, with the cursor represented by |:(xyzzy (g|)) + DEL -> (xyzzy (|))
(xyzzy (|)) + DEL -> (xyzzy |)
(xyzzy |foo) + M-x paredit-forward-barf-sexp (normally C-left) -> (xyzzy) |foo
It takes a little getting used to, but it's very handle, with lots of useful shortcuts; plus, when using it, the resulting code is always well-formed.
Who maintains dpkg?
Posted Mar 18, 2008 21:08 UTC (Tue) by wblew (subscriber, #39088) [Link]
The C language standard specifies that the constant 0 in the context of a given pointer type is taken to mean the null value for that pointer type. As a result the notion of a universal NULL was brain damage right from the start. The fact that the K&R book uses the NULL notation is no excuse to tolerate that brain damage in perpetuity. As a personal guideline, I consider it cleaner and more correct to just use 0 instead of NULL or whatever. If nothing else you avoid a conversion from T* to void* and in some contexts that might involve a runtime cost and/or have other effects. I prefer this commonly used idiom: char *p = /* some value */ if (p) /* p is not the null pointer, just like p!=0, but shorter */ if (!p) /* p is the null pointer, just like p==0, but shorter */ All style discussions aside, two points: 1) The GPLv2 speaks very clearly on the parties' rights. As a receiver of a GPLv2 licensed software work, I have the *same* rights to change that work as the original author, so long as I retain that work's GPLv2 license. I do not have to ask "permission" of that original author to modify and then distribute his work in that modified form. What moral rights? Hogwash... 2) When somebody is using "moral arguments" in a technical context its time to *carefully* analyze their arguments. IMO it usually comes down to this: I don't like what you are doing, but I have no technical or legal basis for my opinion, so I am invoking my moral rights in this matter. PS: IMO they are both wrong on the merits, I'd use 0, and not NULL, nor (char*)0. That is because the compiler already considers 0 to be the null value for the pointer type "char*". No casts needed, cruft is cruft, making it harder to grok. cheers,
Who maintains dpkg?
Posted Mar 18, 2008 21:35 UTC (Tue) by mgb (subscriber, #3226) [Link]
"I'd use 0". Which would be a bug. We're talking about a varargs function. The compiler does not know to convert 0 to (char *)0. This is a bug in many architectures, including the once-popular i386 "compact" and "medium" memory models.
Quite the thread :-)
Posted Mar 21, 2008 2:18 UTC (Fri) by Max.Hyre (subscriber, #1054) [Link]
19 PgDn's worth of discussion of whether NULL == 0 == (char *)0, and mostly politely conducted.This is an observation, not an objection, you understand. Having been a language lawyer in another life, it was very interesting. LWN readers rock! :-)
Quite the thread :-)
Posted Mar 21, 2008 2:24 UTC (Fri) by Max.Hyre (subscriber, #1054) [Link]
My bad. 40 PgDns. Either I miscounted, or 20 were added while I was off writing the comment. I wouldn't want to bet either way.
Quite the thread :-)
Posted Mar 21, 2008 5:01 UTC (Fri) by pr1268 (subscriber, #24648) [Link]
Agreed - This is exactly the kind of content worth paying for a LWN subscription. I can't even quantify how much I've learned by reading the discussion comments on LWN - especially including this one (where data and function pointers could be of different sizes, thus the debate about NULL vs. 0 actually transcending coding style).
Impressive. And, thanks to all those above the 40 PgDns (and below) who contributed to the discussion!