> Who says C has to be implemented with function calls at all?
> Noone, as far as I know.

Of course.

> As a compiler writer I'll make the compiler do any transformations I
> like as long as it doesn't change the semantics.

Which would be fine, except that the transformation in question _was_
changing the semantics.

> 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.)

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.

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, occasionally even
casting between pointers and integers and "knowing" the resulting
semantics of the resulting conversion.

The transformation that started this off is a fine thing to do when
either (a) the code is known to be strictly conforming or (b) you don't
care what happens in cases where the Standard specifies undefined
behaviour or is silent.  Neither one is true of any significant
fraction of NetBSD's code, so the transformation cannot be assumed to
be correct; it must be tested against the rest of the system to
determine its appropriateness.  Of the two transformations discussed in
this thread (inlining memcpy and printf->fputs), the former passes the
test of appropriateness when tested against the rest of the system; the
latter fails it.

That's why I think this new gcc calls for a patch to revert that
behaviour, or a backout of the import.

Not that I really think either is likely to happen. :(

> 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.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B