20.6.2005 kello 21:38, der Mouse kirjoitti:

>> And when the semantics is undefined, one undefined behaviour i a good
>> a another.
>
> Except in the case at issue the semantics weren't undefined; we defined
> them very definitely.  (The problem was, the gcc people either didn't
> know or chose to ignore that.)

No, the semantics are still undefined from the point of view of compiler
that is compiling C code. The compiler knows what printf() is supposed
to do, and can act on that as it best sees fit. Now, if an 
implementation
implements specific behaviour for cases the standard leaves or states
that are undefined then that is OK too (because they are undefined).

(Hmm. Consider this: would it be ok for GCC shipped with NetBSD
to be modified to optimize printf("%s", NULL) -> fputs("(null)", 
stdout)?

In my opinion, if an application decides to invoke this undefined
behaviour through a standard specified interface, the application
deserves to be burned. If it really needs to rely on this, a wrapper
function or anything can be provided. And in NetBSD libc: "nbprintf()".

> You seem to be falling into much the same trap thorpej did: of thinking
> that NetBSD is - or should be - written in pure Standard-conforming C,
> not depending in any way on semantics not defined by the Standard.

No, of course NetBSD can and needs to be do things undefined by
standard C. However, it should not be necessary to abuse that what
is defined by the standard. "nbprintf()", again...

> As I remarked to someone (offlist, I think), if I were writing code
> that depended on nothing but what the Standard promised, I'd not be an
> OS hacker; I'd be doing applications, and fairly boring applications at
> that.  I do a lot of things that the Standard does not define semantics
> for, such as #including files with < > when the files in question are
> not standardized, such as "calling" "functions" which are not defined
> in my program but which the standard is silent on

The functions you are calling may not be defined by
your program nor the standard, but from the point of view of the
compiler they are defined in the application being composed as a whole,
assuming of course that they are defined somewhere. So this is in no
way contradictory to the standard, nor is it defined to be undefined
behaviour by the standard.

What you are talking about in the above paragraph is about using things
not defined by the standard. This printf() argument is about using a
thing defined by the standard as undefined behaviour.

>> It seems many people have some warped idea of the C semantics based
>> on historical precedence. :)
>
> Not so much of C-qua-C semantics, but of C-on-NetBSD semantics.  As I
> remarked above, very little of our code does not depend in some way on
> behaviour not promised by the C standard.

I'd like to point out that NetBSD code that depends on printf("%s", 
NULL)
working on NetBSD is on quite thin ground. As far as I can see, the 
manual
page for NetBSD printf() in no way tells that it is OK for argument for
%s to be NULL. It could be said that that is just as undefined on NetBSD
as in the C standard.