«

Jack Klein wrote:
> Jordan Abel <> wrote in comp.lang.c:
>> On 2006-01-15, Chris Torek <> wrote:
>>> OzBob <> wrote:
>>>
.... snip ...
>>>
>>> Actually, your immediate problem is with the line:
>>>
>>> printf("some text ... %s ...", (char *), NULL);
>>>
>>> which is not a valid operation: the effect of providing NULL
>>> to the "%s" directive is undefined. On the HP-UX machine,
>>> the actual effect turns out to be a no-op, and on the SPARC,
>>> it turns out to be "Segmentation Fault - core dumped".
>>
>> more data points: On glibc, freebsd, and 7th edition UNIX,
>> it's "(null)" - i'm surprised this wasn't codified into the
>> standard, given its age.
>
> I'd be very surprised if it had been. What arguments can you
> provide that this would be a Good Thing(tm)?

I am repeating my argument from another thread here. Here it
doesn't require a subject change

You are looking at it solely from a debugging viewpoint. On the
other hand, it is highly preferable to save volatile data than to
crash because some meaningless display had no data with which to
update. The "(null)" display can also serve as a debugging aid.

I am firmly in the camp that believes functions should interpret
illegal parameters in a sensible way if possible. Treating NULL as
an empty source string certainly qualifies.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

On 2006-01-16, pemo <> wrote:
>
> "Richard Heathfield" <> wrote in message
> news:dqeo0l$i11$...
>> Keith Thompson said:
>>
>>> Michael Mair <> writes:
>>>> OzBob wrote:
>>> [...]
>>>>> # gcc -std=c99 -pedantic -W -Wall -O test.c
>>>>> test.c:25: warning: return type of `main' is not `int'
>>>>
>>>> Note: This is not to be taken lightly -- in principle, all
>>>> bets are off for a "void main" main().
>>>
>>> In principle, yes. But in fact, I've never seen a C compiler that
>>> misbehaves really badly given a "void main" declaration.
>>
>> If you're prepared to generalise this to "given a declaration of main that
>> returns something other than int", I can vouch for the fact that I once
>> managed to crash Windows NT in a most colourful way by experimenting with
>> double main(void)!
>
> Ah - the '!' invokes undefined behaviour.

Actually, that'd be a syntax error.

On 2006-01-16, Jack Klein <> wrote:
> On 16 Jan 2006 01:02:31 GMT, Jordan Abel <> wrote
> in comp.lang.c:
>
>> On 2006-01-15, Chris Torek <> wrote:
>> > In article <dqdgi7$ctk$>
>> > OzBob <> wrote:
>> >>I am developing some basic string / file manipulation C progams at home
>> >>(Sparcstation running Solaris 9 and gcc) for my work environment (PA-RISC
>> >>running HP-UX 11.11 and c99 compatible compiler). However I seem to have
>> >>encountered problems performing the most basic of manipulations and
>> >>comparisons.
>> >
>> > Actually, your immediate problem is with the line:
>> >
>> > printf("some text including the %s directive\n", (char *)NULL);
>> >
>> > which is not a valid operation: the effect of providing NULL to
>> > the "%s" directive is undefined. On the HP-UX machine, the actual
>> > effect turns out to be a no-op, and on the SPARC, it turns out to
>> > be "Segmentation Fault - core dumped".
>>
>> more data points: On glibc, freebsd, and 7th edition UNIX, it's
>> "(null)" - i'm surprised this wasn't codified into the standard, given
>> its age.
>
> I'd be very surprised if it had been. What arguments can you provide
> that this would be a Good Thing(tm)?

That it's how things were done in the original implementation [absent
some real reason to change it] isn't good enough? How about an easy way
to make a debug printf for a variable that may either point at a
null-terminated string or be NULL?

Jordan Abel <> writes:
> On 2006-01-16, Jack Klein <> wrote:
>> On 16 Jan 2006 01:02:31 GMT, Jordan Abel <> wrote
>> in comp.lang.c:
[...]
>>> more data points: On glibc, freebsd, and 7th edition UNIX, it's
>>> "(null)" - i'm surprised this wasn't codified into the standard, given
>>> its age.
>>
>> I'd be very surprised if it had been. What arguments can you provide
>> that this would be a Good Thing(tm)?
>
> That it's how things were done in the original implementation [absent
> some real reason to change it] isn't good enough? How about an easy way
> to make a debug printf for a variable that may either point at a
> null-terminated string or be NULL?

printf("s = %s\n", s ? s : "(null)");

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.