Re: printf("%p\n", (void *)0);

From: Brian Inglis (Brian.Inglis_at_SystematicSW.Invalid)
Date: 03/09/05 

Date: Wed, 09 Mar 2005 00:41:42 GMT

On Tue, 08 Mar 2005 20:18:22 GMT in comp.std.c, Keith Thompson
<kst-u@mib.org> wrote:

>"Douglas A. Gwyn" <DAGwyn@null.net> writes:

>> aegis wrote:

>>> > p The argument shall be a pointer to void. The value of the
>>> > pointer is converted to a sequence of printing characters, in
>>> > an implementation-defined manner.
>>
>> (void*)0 is a valid value of the type "pointer to void".
>> Thus printf is required to accept it in this context.
>
>But part of the standard can be read to imply that (void*)0 is not a
>valid value of type "pointer to void".

>But I'm not comfortable depending on "common sense" to determine what
>the standard means.
>
>I can imagine a stubborn implementer creating a version of printf()
>that depends on the pointer value being non-null (perhaps it shows it
>as a base address and offset, or perhaps it attempts to show a few
>bytes of what it points to). If I filed a bug report, I'm not sure
>what chapter and verse I could cite to convince the implementer that
>this is a bug. This probably isn't a realistic situation (I doubt
>that any actual printf() implementation blows up on null pointers),
>but it's still the kind of thing the standard should address.

Isn't undefined behaviour any behaviour not explicitly defined in the
standard for the abstract machine or the library implementation?
So is the above (undefined) case not then undefined behaviour, as is
the case with strlen()?
The behaviour of printf() with format specifier "%p" is implementation
defined, but ISTM that leaves it open to each implementation whether
they define that part of the implementation to work will null
pointers.
If it could be undefined behaviour, we have no option but to treat it
as undefined behaviour in portable code. 

-- 
Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada
Brian.Inglis@CSi.com 	(Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
    fake address		use address above to reply