🚀 go-pugleaf

In <40s0eo$k8c@goanna.cs.rmit.edu.au> ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

>I mentioned
>    cc .... -Dgets=DONT_USE_GETS
>
>kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:
>>An excellent idea.  But wouldn't it be better if it gave the error
>>message at compile time (with a line number so you could find and
>>correct it easily)?  Say:
>
>>	-Dgets='DONT_USE_GETS!'
>
>No.  Reason:  a program that _doesn't_ use gets() may still #include <stdio.h>
>in order to correctly use fgets().  With your suggestion the prototype for
>gets() in <stdio.h> -- assuming of course a C implementation which uses text
>files for stdio.h, I know it needn't -- would be in error.
>
>Note that the definition is OUTSIDE the C sources.  It is not something that
>I would dream of including in C code that is supposed to be portable, because
>if you #include <stdio.h> you aren't supposed to mess with reserved names like
>gets.  This is done _outside_ the C code _for debugging_ only on systems where
>it is known (by experiment) to work.

Whether you include <stdio.h> or not is irrelevant.  gets() is in the
implementation namespace, and any attempt to redefine it invokes undefined
behaviour, whether <stdio.h> is included or not:

    ISO 7.1.3 Reserved Identifiers
    ...
    All identifiers with external linkage in any of the following clauses
    (including future library directions) are always reserved for use as
    identifiers with external linkage.

This should end this thread in comp.std.c.  Things which happen to work
on some implementations are better discussed elsewhere.

Dan
--
Dan Pop
CERN, CN Division
Email: Dan.Pop@mail.cern.ch 
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland