standard include files

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

ram@zedat.fu-berlin.de (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-u@mib.org <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"

Stefan Ram <ram@zedat.fu-berlin.de> 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. As you
become more adept at this it becomes less of a burden, and reinforces your
comprehension. If it seems burdensome to do it this way, it means you have
much to learn. Taking shortcuts would be foolhardy.

This is even more important for something like POSIX, where often people
rely more on rumour and superstition than a proper grounding in the
standard. But once you learn the general structure of things (per the
standard), it becomes easier to learn and remember new interfaces, to
identify bugs in usage, etc.

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
esosman@ieee-dot-org.invalid

In article <includes-20120223013325@ram.dialup.fu-berlin.de>,
ram@zedat.fu-berlin.de (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.

Because once upon a time that would kill the compiler (when it had to fit in
65536 bytes of memory. MacOSX, at least, now does provide a lot of include all
headers.

--
My name Indigo Montoya. | R'lyeh 38o57'6.5''S 102o51'16''E.
You flamed my father. | I'm whoever you want me to be.
Prepare to be spanked. | Annoying Usenet one post at a time.
Stop posting that! | At least I can stay in character.

On 2012-02-23, Stefan Ram <ram@zedat.fu-berlin.de> 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 <ram@zedat.fu-berlin.de> 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-u@mib.org> 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 <william@wilbur.25thandClement.com> wrote:
> Stefan Ram <ram@zedat.fu-berlin.de> 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).

Kaz Kylheku <kaz@kylheku.com> wrote:
> On 2012-02-23, William Ahern <william@wilbur.25thandClement.com> wrote:
> > Stefan Ram <ram@zedat.fu-berlin.de> 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).

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.

If that's all that's holding you back you may as well include the whole lot.

On 02/23/12 05:19 PM, William Ahern wrote:
> Kaz Kylheku<kaz@kylheku.com> wrote:
>> On 2012-02-23, William Ahern<william@wilbur.25thandClement.com> 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 <kaz@kylheku.com> 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

On 2/22/2012 10:39 PM, Ian Collins wrote:
> On 02/23/12 05:19 PM, William Ahern wrote:
>> Kaz Kylheku<kaz@kylheku.com> wrote:
>>> On 2012-02-23, William Ahern<william@wilbur.25thandClement.com> 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.
>

and is ultimately a large part of the relatively long compile times of C
and C++ ("gotta churn through this big pile of crap the preprocessor
brought in").

and there is no "ideal" way to fix it (precompiled header mechanisms
tend to be more of a non-standardized finicky kludge, ...).

On Feb 23, 6:29*am, BGB <cr88...@hotmail.com> wrote:
>
> and there is no "ideal" way to fix it (precompiled header mechanisms
> tend to be more of a non-standardized finicky kludge, ...).- Hide quoted text -
>
My evil MS Visual Studio insists on adding the line #include
"stdafx.h" to everything, including the standard C core logic files.

--
MiniBasic - how to write a script interpreter
http://www.malcolmmclean.site11.com/www