On Fri, 17 Jun 2005, Christos Zoulas wrote:
> I don't think so either, but when you ask the compiler to call printf(),
> and it calls puts() because it `knows' it is better, what else are you
> left with?

In my opinion, the compiler should decide whether or not it is
allowed to convert printf("%s",foo) to puts(foo) [and similarly with
fprintf/fputs] depending on what standards you told the compiler that
the code was intended to conform to.

For example, if you tell the compiler that the code conforms to the
hosted environment defined in ANSI/ISO 9899:1989, then the compiler
can know that printf("%s",NULL) invokes undefined behaviour, and the
programmer shouldn't care whether the undefined behaviour results in a
core dump or in the string "(null)" being printed.

I suggest the following actions:

  1. Accept the fact that programs that expect printf("%s", NULL)
     to print "(null)" are relying on a particular historical
     interpretation of behaviour that is undefined by recent standards.

  2. As a temporary hack, change gcc to never perform the printf/puts
     conversion that is causing trouble for the programs identified in
     (1).  Alternatively, change gcc to perform the conversion only if
     it can prove to itself that the string will not be null.
  
  3. Fix gcc to make it perform or not perform the printf/puts
     conversion depending on what combination of "-std=<standard>",
     "-ansi", "-pedantic", "-ffreestanding" and similar options were
     specified.  Possibly also add a "-fno-convert-printf-to-puts" or
     similar option.

  4. Make the programs identified in (1) pass appropriate flags to the
     compiler fixed in (2) so that they do get the historical "(null)"
     behaviour.

  5. Once (4) has been done, the temporary hack in (2) can be removed.

  6. In the long term, change the programs identified in (1) so that
     they do not attempt to invoke undefined behaviour from printf.
 
--apb (Alan Barrett)