puts() vs printf()

[jmcgill]

A modern compiler will notice when a single argument to printf()
contains no format specifiers

I think that would bother me because I consider the compiler knowing
this much about a parameter to a library function to be pathological
binding. I realize it's a very standard library function with
well-defined parameters, but still, this feels like a violation of some
boundary that shouldn't be crossed. What a nasty surprise if someone
implements his own standard IO library and discovers the compiler has
different ideas about format strings?

 

[CBFalconer]

I think that would bother me because I consider the compiler knowing
this much about a parameter to a library function to be pathological
binding. I realize it's a very standard library function with
well-defined parameters, but still, this feels like a violation of some
boundary that shouldn't be crossed. What a nasty surprise if someone
implements his own standard IO library and discovers the compiler has
different ideas about format strings?

Doing so at the user level is expressly forbidden by the standard.

 

[jmcgill]

Doing so at the user level is expressly forbidden by the standard.

Fair enough. But still would not appreciate the idea of the compiler
snooping into my function arguments and deciding for me if they are needed.

Does GCC do this?

 

[Andrew Poelstra]

Fair enough. But still would not appreciate the idea of the compiler
snooping into my function arguments and deciding for me if they are needed.

Does GCC do this?

1) Yes it does, but that's off-topic.
2) Your compiler needs to see your paramaters in order to compile. Unless
you're hiding drugs in them, there's no reason for you not to want the
compiler searching them.

 

[jmcgill]

1) Yes it does, but that's off-topic.

I figured.

2) Your compiler needs to see your paramaters in order to compile. Unless
you're hiding drugs in them, there's no reason for you not to want the
compiler searching them.

Still bothers me. I don't mind the preprocessor seeing this, and maybe
having it feed the compiler what it wants. But what we are talking
about here is the compiler itself evaluating string literals and making
arbitrary changes to them. It bugs me in a philosophical way, even
though I don't care in any practical sense.

 

[Eric Sosman]

jmcgill wrote On 08/25/06 11:12,:

[... about substitution of Standard functions based on arguments ...]

Fair enough. But still would not appreciate the idea of the compiler
snooping into my function arguments and deciding for me if they are needed.

If I write pow(x,5) it does not bother me in the least if
the compiler generates a call to _intpow(x,5), a hypothetical
optimized-for-integer-powers version.

If I write strlen("Hello, world!") I am delighted if the
compiler just generates (size_t)13.

If I write memcpy(p, q, sizeof *p) I applaud the compiler
that generates a block-move instruction instead of a function
call. For div(num, den) I would be disappointed if the compiler
did *not* generate an in-line division. I *want* sqrt() to
turn into an FSQRT instruction when it can.

Why should printf() be any different?

 

[Charles Richmond]

It is. BullSchildt is normally error infested. In this particular
case he is right. This is analagous to undefined behaviour -
sometimes you get the expected result.

And newbie folks need to understand: Undefined Behavior means
that you can get *any* result, including sometimes the result
that you expected. Just don't count on getting the result that
you expected...

 

[jmcgill]

Undefined Behavior means
that you can get *any* result, including sometimes the result
that you expected. Just don't count on getting the result that
you expected...

Would you say that undefined behavior also entitles an implementor to
define the behavior as appropriate for a given implementation, or would
you say that undefined behavior should remain *expressly* undefined, and
should *not* be defined by any given implementation?

 

[Flash Gordon]

Charles Richmond wrote:

And newbie folks need to understand: Undefined Behavior means
that you can get *any* result, including sometimes the result
that you expected. Just don't count on getting the result that
you expected...

Don't count on not getting the result you expect either. I.e. don't
assume that just because your program gave the correct result it is
necessarily correct. It could still contain undefined behaviour and only
fail when it is most important to you that it works, for example when
you are doing a demonstration to win that multi-million pound bid.

 

[Eric Sosman]

jmcgill wrote On 08/25/06 13:12,:

Would you say that undefined behavior also entitles an implementor to
define the behavior as appropriate for a given implementation, or would
you say that undefined behavior should remain *expressly* undefined, and
should *not* be defined by any given implementation?

The former.

I'm having some fun trying to imagine the documentation
if the latter were true. "If the program dereferences a
NULL pointer the system *may* nudge nudge raise a signal
that *might* wink wink be called SIGSEGV, but -- say no
more, say no more, you *didn't* hear that from *me*, eh?"

 

[CBFalconer]

Would you say that undefined behavior also entitles an implementor
to define the behavior as appropriate for a given implementation,
or would you say that undefined behavior should remain *expressly*
undefined, and should *not* be defined by any given implementation?

It's undefined from the point of view of the C standard. Just
because the implementor arranges for a particular response doesn't
mean that the same will occur on another system.

--
Some informative links:
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

 

[Stephen Sprunk]

I think that would bother me because I consider the compiler knowing
this much about a parameter to a library function to be pathological
binding. I realize it's a very standard library function with
well-defined parameters, but still, this feels like a violation of
some
boundary that shouldn't be crossed. What a nasty surprise if someone
implements his own standard IO library and discovers the compiler has
different ideas about format strings?

The compiler is allowed to "violate that boundary" because the standard
says so. Presumably there's some switch to turn off that optimization
if you don't like it, but why wouldn't you? It only happens in cases
it's proven to be safe, and it follows the as-if rule. There's lots of
scarier/cleverer things that compilers do these days; this is a minor
nit.

If the above offends you, so should GCC complaining if the arguments in
a call to printf() don't match the format string. How is pointing out
bugs a bad thing?

S

 

[Stephen Sprunk]

It can't. The output of the two statements is different.

The compiler should be able to convert this:

char *foo = "Hello world!\n";
printf(foo);

to this:

char *foo = "Hello world!";
puts(foo);

under the as-if rule, provided there's no other use of foo's contents.
However, proving the latter point may not be worth the effort, so only
things of the form printf("Hello world!\n"); or printf("%s\n",foo);
would be converted.

S

 

[jmcgill]

The compiler is allowed to "violate that boundary" because the standard
says so.

I buy it fine. I hadn't fully considered that we're only talking about
standard library calls in the first place.

 

[jmcgill]

It's undefined from the point of view of the C standard. Just
because the implementor arranges for a particular response doesn't
mean that the same will occur on another system.

My question is more along the lines of this, and I don't think I was
clear enough:

Does an undefined behavior, that is explicitly undefined in the spec (as
opposed to the infinite things being undefined by ommission), mean that
the spec is attempting to require that behavior to be undefined, or is
it open enough that an implementation that defines some specific
behavior for that case is not nonconforming as a result?

Maybe that's still not clear enough.

 

[robertwessel2]

I buy it fine. I hadn't fully considered that we're only talking about
standard library calls in the first place.

The copmiler is also free to do so for non-library functions, within
the bounds set by the as-if rule. So if the defintion of mystrlen() is
adequetely visible to the compiler (and assuming the obvious
implementation of that function), the compiler is free to reduce
"a=mystrlen("somestring")" to "a=9".

In fact, this sort of optimization is quite common with inlined
functions.

 

[Stephen Sprunk]

The copmiler is also free to do so for non-library functions, within
the bounds set by the as-if rule. So if the defintion of mystrlen()
is
adequetely visible to the compiler (and assuming the obvious
implementation of that function), the compiler is free to reduce
"a=mystrlen("somestring")" to "a=9".

In fact, this sort of optimization is quite common with inlined
functions.

With inlined functions, it's fair to _assume_ your compiler will do such
optimizations; if it doesn't, it's time to upgrade. Better compilers
have "inter-procedural optimization" or "whole-program optimization",
which allow them to do the same thing with non-inline functions within
the same translation unit or even across translation units -- provided,
of course, they can prove the "as if" rule applies.

<OT>The GCC folks have recently started playing with IPO within the same
translation unit, but it's still in it infancy and only seems to work on
inline and static functions so far; many commercial compilers have had
IPO for a while. A few have WPO, but typically that means the "compile"
stage emits some intermediate representation and actual compilation and
most optimization is delayed until the "link" stage. The GCC folks
haven't made any noises they're considering that route, but five years
from now I wouldn't be surprised to see it.</OT>

S