Re: [PATCH] Use explicit pointers for execl...() sentinels.

Jeff King [off-list ref] wrote:

On Sun, Mar 12, 2006 at 08:08:12PM +0200, Timo Hirvonen wrote:

quoted

NULL pointer does not point to any data, it just says it's 'empty'.  So
it doesn't need to be same type pointer as specified in the function
prototype.  Pointers are just addresses, it doesn't matter from to code
generation point of view whether it is (char *)0 or (void *)0.

Sorry, but I think you're wrong according to the C standard. Pointers of 
different types do NOT have to share the same representation (e.g.,
there have been some platforms where char* and int* were different
sizes). A void pointer must be capable of representing any type of
pointer (for example, holding the largest possible type). However, if
sizeof(void *) == 8 and sizeof(char *) == 4,

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.

                                             you have a problem with
variadic functions which are expecting to pull 4 byte off the stack. 

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

In a non-variadic function, the compiler would do the right implicit
casting. In a variadic function, it can't. 

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

The real question is, does git want to care about portability to such
platforms.

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

If you remain unconvinced, I can try to find chapter and verse of the
standard.

Please do.

quoted

sizeof(unsigned long) is sizeof(void *) in real world.

Are you saying that because it encompasses all of the platforms you've
worked on, or do you have some evidence that it is largely the case? It
certainly isn't guaranteed by the C standard.

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...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

On Mon, Mar 13, 2006 at 12:12:31AM -0400, Horst von Brand 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.

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.

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

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.

quoted

If you remain unconvinced, I can try to find chapter and verse of the
standard.

Please do.

See above.

-Peff