«

There was a discussion once about why people do not simply
include all possible standard headers, so that they do not
have to be so careful when choosing the needed ones.

Someone said that not including all possible standard
headers does reduce the possibility of standard names
defined in them colliding with user names. (Also including
future C versions, where a name might be defined by the
standard that is not defined now.)

But aren't all standard identifiers reserved anyway,
independently of whether the corresponding header is
included or not?

On 02/23/12 01:38 PM, Stefan Ram wrote:
> There was a discussion once about why people do not simply
> include all possible standard headers, so that they do not
> have to be so careful when choosing the needed ones.
>
> Someone said that not including all possible standard
> headers does reduce the possibility of standard names
> defined in them colliding with user names. (Also including
> future C versions, where a name might be defined by the
> standard that is not defined now.)
>
> But aren't all standard identifiers reserved anyway,
> independently of whether the corresponding header is
> included or not?

They may be reserved, but that reservation isn't enforced.

--
Ian Collins

(Stefan Ram) writes:
> There was a discussion once about why people do not simply
> include all possible standard headers, so that they do not
> have to be so careful when choosing the needed ones.
>
> Someone said that not including all possible standard
> headers does reduce the possibility of standard names
> defined in them colliding with user names. (Also including
> future C versions, where a name might be defined by the
> standard that is not defined now.)
>
> But aren't all standard identifiers reserved anyway,
> independently of whether the corresponding header is
> included or not?

N1570 7.1.3:

All identifiers with external linkage in any of the following
subclauses (including the future library directions) and errnoare
always reserved for use as identifiers with external linkage.

That covers all the functions declared in standard headers. So you can
define your own "sin" as long as it doesn't have external linkage.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 2/22/2012 7:38 PM, Stefan Ram wrote:
> There was a discussion once about why people do not simply
> include all possible standard headers, so that they do not
> have to be so careful when choosing the needed ones.
>
> Someone said that not including all possible standard
> headers does reduce the possibility of standard names
> defined in them colliding with user names. (Also including
> future C versions, where a name might be defined by the
> standard that is not defined now.)
>
> But aren't all standard identifiers reserved anyway,
> independently of whether the corresponding header is
> included or not?

Reservations come in different scopes and contexts.

For example, `FILE' is not reserved if <stdio.h> is not
included: You are free to write `int FILE;' at file scope in
one module and `extern int FILE;' in another, and the two names
will both refer to the same `int' variable.

But then, you are *not* free to write `int fopen;' at file
scope in any module, with or without <stdio.h>. The name is of
a different "class," and the rules are different.

7.1.3p1 lists the different realms of "reserved" for different
kinds of names. You will note that the rules in the sub-paragraphs
are not all the same.

--
Eric Sosman
d

On 2012-02-23, Stefan Ram <> wrote:
> But aren't all standard identifiers reserved anyway,
> independently of whether the corresponding header is
> included or not?

What if a header that you /need/ to include starts to clash with a name in your
program. Implementations should provide a way by which you can select the
precise standard conformance. E.g. what if someone needs to build a C90
program? It's simpler to have a switch for that in the implmentation than
to update the program.

On 2012-02-23, Stefan Ram <> wrote:
> There was a discussion once about why people do not simply
> include all possible standard headers, so that they do not
> have to be so careful when choosing the needed ones.
>
> Someone said that not including all possible standard
> headers does reduce the possibility of standard names
> defined in them colliding with user names. (Also including
> future C versions, where a name might be defined by the
> standard that is not defined now.)

This seems backwards, in fact. The external names exist whether you include the
header or not. So it is actually safer to include the header: you want the
clash to be detected at compile time.

In some environments you can write, say, your own malloc function:

double malloc(char *) { ... }

This is not diagnosed at linkage because it's something that is allowed
as an extension (overriding malloc). The internal C library uses of malloc
go to the right one, but those of the programs and any third party libs
go to the overridden one.

If a declaration were in scope (in spite of <stdlib.h> not being included),
this would be diagnosed as having the wrong type signature.

> But aren't all standard identifiers reserved anyway,
> independently of whether the corresponding header is
> included or not?

Exactly. Some identifiers are not, like typedef names or macro names.
But anything that has linkage is reserved anyway.

Even for names that are not reserved unless a given header is included,
it's usually a bad idea to invade that space.

If a translation unit includes no standard headers at all, should it be
defining ptrdiff_t, et cetera?

There is a case to be made for hosted implementations being free to define all
the standard material even if no header is included at all.

On 2012-02-23, Keith Thompson <kst-> wrote:
> That covers all the functions declared in standard headers. So you can
> define your own "sin" as long as it doesn't have external linkage.

But this is not necessarily a good idea, so there is a case to be made for
having this diagnosed as if the header were included.

On 2012-02-23, William Ahern <> wrote:
> Stefan Ram <> wrote:
>> There was a discussion once about why people do not simply
>> include all possible standard headers, so that they do not
>> have to be so careful when choosing the needed ones.
>
>> Someone said that not including all possible standard
>> headers does reduce the possibility of standard names
>> defined in them colliding with user names. (Also including
>> future C versions, where a name might be defined by the
>> standard that is not defined now.)
>
>> But aren't all standard identifiers reserved anyway,
>> independently of whether the corresponding header is
>> included or not?
>
> I can't speak for others, but _practicing_ is _learning_. When you include
> only what's needed, you learn how the standard library is organized.

This is not knowledge, but useless trivia.

Including what is needed is done for the sake of faster compilation times,
when headers are implemented vi textual substitution (which is basically
still the "state of the art" in C today).

On 02/23/12 05:19 PM, William Ahern wrote:
> Kaz Kylheku<> wrote:
>> On 2012-02-23, William Ahern<> wrote:
>>>
>>> I can't speak for others, but _practicing_ is _learning_. When you include
>>> only what's needed, you learn how the standard library is organized.
>
>> This is not knowledge, but useless trivia.
>
>> Including what is needed is done for the sake of faster compilation times,
>> when headers are implemented vi textual substitution (which is basically
>> still the "state of the art" in C today).
>
> I doubt including all the standard C headers would noticebly slow
> compilation, even for small compilation units. The simple textual
> substitution is a performance benefit compared to C++ or Java.

The C++ include mechanism is unfortunately still the same a C.

--
Ian Collins

Kaz Kylheku <> wrote:
> This is not knowledge, but useless trivia.

Knowledge is useless trivia.

--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org