patchRe: [PATCH] Trivial warning fix for imap-send.c

Jeff King <peff@peff.net> wrote:

Very improbable, they'll be the same normally ("void *" is a way of getting rid of the overloading of the meaning of "char *" for this before ANSI C). Sure, sizeof(int *) might be 4, but I think that is pretty far off.

There are special rules for variadic functions, probably pointers would be cast to/from void * in such a case by the compiler.

It sure can. The rules where defined so that it works.

Broken platform, on which the compiler fails miserably in doing its job? No, it doesn't.

Please do.

More because a machine with pointers that are much larger than the largest "normal" integer would be pretty weird (sure, on intel 8086 they where 32 ("far" pointer, segment + offset) and 16 bits, but...

On Mon, Mar 13, 2006 at 12:12:31AM -0400, Horst von Brand wrote:

Let me clarify my position. The STANDARD doesn't guarantee such things. In PRACTICE, for modern machines you can assume that all pointers are the same size (and things like all-bits-zero is a null pointer) if it makes your code cleaner. In other words, I agree with Linus: git should follow what works in practice, but you should at least recognize that you're violating the standard.

That being said, you appear to be making the argument that passing a 'foo *' to a variadic function expecting a 'bar *' doesn't violate the standard. I believe it invokes undefined behavior.

The rules indicate that arguments matching the '...' follow "default
argument promotion".  See section 6.5.2.2, paragraph 7.  This default
promotion is the same as what would happen if there were no prototype
for the function, and is defined in paragraph 6:
  ...the integer promotions are performed on each argument, and arguments
  that have type float are promoted to double.
I don't see anything about promoting pointers to void.

Furthermore, when accessing the arguments using va_arg, the types must
match or the behavior is undefined, UNLESS (7.5.1.1, para 2):
  - one type is signed and the other is the matching unsigned type
  - one type is a pointer to void and the other is a pointer of
    character type
IOW, the standard does promise that void* and char* pointers are
represented the same, but nothing else.

See above.

-Peff

Jeff King <peff@peff.net> wrote:

[...]

Right.

It just passes 3 "void *"'s, and casts back. What is so strange?

On Mon, 13 Mar 2006, Horst von Brand wrote:

It doesn't actually pass 3 "void *".

Variadic functions pass their arguments as-is (apart from the normal integer promotion for small integer types: chars are passed as integers if "char" is smaller than "int").

So no actual casting takes place for the arguments, and

	execl("foo", "bar", my_struct_foo, NULL);

passes in four pointers: two of type "char *", one of whatever my_struct_foo is ("struct foo *") and finally hopefully one of "void *" (modulo broken compilers). They might - in theory - have different sizes and representations.

Now, the interesting effect of this is that simple things like

	printf("Pointer value %p\n", myfunction);

is actually NOT STRICTLY PORTABLE CODE! Why? Because "%p" wants a void pointer, but "myfunction" is of a different pointer type, which may actually have a different size and a different representation entirely, so you can get total garbage printed out.

So you have two choices:

 - be sane, and ignore insane architectures. In this case, the above is 
   perfectly fine C code.

 - be insane, and care about it. In this case, you really do have to add 
   the casts to be safe in theory.

The "%p" for printf() is actually a wonderful example of why you really really really should ignore language lawyers. According to language lawyers, you should add that "(void *)" cast. But look around for how many such casts you can find in real code, and realize that the language lawyers just don't matter. A C compiler environment that requires it is simply broken, and sane people will refuse to use it for anything than small embedded work, because it's simply not usable.

So while it's not true in theory, in _practice_ you should expect all pointers to be of the same size and use the same representation. Anything else is just too painful to be ever worth bothering with.

(Remember near and far pointers from 16-bit DOS/Windows? Those environments at least had _explicit_ pointer sizes, making the problem less horrible, but that was clearly a disaster nonetheless. Pointers that implicitly have different sizes because they point to different types are even _worse_).

			Linus

PS. Final words: while knowing that all pointer representations must be the same, and that NULL actually must be the bitwise binary "all zero" value (otherwise "memset(structptr, 0, structsize)" would break), it's equally important to know that the standard doesn't _guarantee_ it. Why?

Because that way, when somebody tries to tell you that your code isn't standards conformant and might be unportable, you can say "yeah, I know, but only a total loser would ever care". Instead of incorrectly trying to argue that your code is "correct".

Jeff King <peff@peff.net> wrote:

[...]

Problem is that nobody reads the manuals, next to nobody complains, and when it doesn't work out via road A you try plan B. A might have been exactly right, but it is blocked, and you'll never know if it is because of fundamental reasons or by decree.