Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #58638 > unrolled thread

multiple header includes

Back to article view | Back to comp.lang.c

Contents

  multiple header includes jeff <nospam@nospam.com> - 2015-03-22 10:02 +0000
    Re: multiple header includes Lőrinczy Zsigmond <nospam@for.me> - 2015-03-22 11:14 +0100
    Re: multiple header includes Richard Heathfield <rjh@cpax.org.uk> - 2015-03-22 13:10 +0000
    Re: multiple header includes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 08:12 -0700
    Re: multiple header includes Robbie Hatley <see.my.sig@for.my.address> - 2015-03-27 02:46 -0700
      Re: multiple header includes James Kuyper <jameskuyper@verizon.net> - 2015-03-27 09:32 -0400
        Re: multiple header includes Robbie Hatley <see.my.sig@for.my.address> - 2015-04-11 14:08 -0700
          Re: multiple header includes Keith Thompson <kst-u@mib.org> - 2015-04-11 19:49 -0700
      Re: multiple header includes Keith Thompson <kst-u@mib.org> - 2015-03-27 08:32 -0700
    Re: multiple header includes fir <profesor.fir@gmail.com> - 2015-04-12 11:35 -0700
      Re: multiple header includes fir <profesor.fir@gmail.com> - 2015-04-12 11:45 -0700
        Re: multiple header includes fir <profesor.fir@gmail.com> - 2015-04-12 11:58 -0700

#58638 — multiple header includes

although in most cases we see the good practises of Header Guards, is 
there a risk for some architectures, that code like this,
#include<stdio.h>
#include<stdio.h>
(eg same header included twice), will invoke an Undefined Behavior?

thank you.

[toc] | [next] | [standalone]

#58641

On 2015.03.22. 11:02, jeff wrote:
> although in most cases we see the good practises of Header Guards, is
> there a risk for some architectures, that code like this,
> #include<stdio.h>
> #include<stdio.h>
> (eg same header included twice), will invoke an Undefined Behavior?

Unlikely, but the world is full of broken programs (compilers included),
so I cannot *promise* anything.

[toc] | [prev] | [next] | [standalone]

#58664

On 22/03/15 10:02, jeff wrote:
> although in most cases we see the good practises of Header Guards, is
> there a risk for some architectures, that code like this,
> #include<stdio.h>
> #include<stdio.h>
> (eg same header included twice), will invoke an Undefined Behavior?

The Standard requires that multiple inclusion of standard headers will 
be fine. "Standard headers may be included in any order; each may be 
included more than once in a given scope, with no effect different from 
being included only once, except that the effect of including <assert.h> 
depends on the definition of NDEBUG" - clear enough, I think.

I suppose implementors make this possible in the usual way - i.e. be 
careful what you define in a header, and use inclusion guards:

#ifndef H_MYHEADER_H
#define H_MYHEADER_H 1
header stuff goes here
#endif

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#58675

On Sunday, March 22, 2015 at 10:02:47 AM UTC, jeff wrote:
> although in most cases we see the good practises of Header Guards, is 
> there a risk for some architectures, that code like this,
> #include<stdio.h>
> #include<stdio.h>
> (eg same header included twice), will invoke an Undefined Behavior?
> 
I'm sure it's possible to construct a header such that if it is
included one a program is well-behaved, if included twice it shows
undefined behaviour. But it would have to be written in a weird and
wonderful way, or there would have to be some odd coincidence.

Generally multiple inclusion of headers leads to symbols being 
redefined, which creates compile-time errors. Not the same as
undefined behaviour, which is a runtime error.

[toc] | [prev] | [next] | [standalone]

#59076

On 3/22/2015 3:02 AM, jeff wrote:

> although in most cases we see the good practises of Header Guards, is
> there a risk for some architectures, that code like this,
> #include<stdio.h>
> #include<stdio.h>
> (eg same header included twice), will invoke an Undefined Behavior?

No.

Have you ever actually *looked* at stdio.h?  What are the first two
lines you see, other than comments?

... 25 lines of comments ...
#ifndef _STDIO_H_
#define	_STDIO_H_
... about 700 more lines of code ...
#endif

So if the header has already been included, _STDIO_H_ is defined,
so the second and all subsequent attempts to #include it will
cause the preprocessor to include only the first 25 lines of comments,
which the compiler ignores.

> thank you.

You're welcome.


-- 
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
http://www.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley

[toc] | [prev] | [next] | [standalone]

#59085

On 03/27/2015 05:46 AM, Robbie Hatley wrote:
> 
> On 3/22/2015 3:02 AM, jeff wrote:
> 
>> although in most cases we see the good practises of Header Guards, is
>> there a risk for some architectures, that code like this,
>> #include<stdio.h>
>> #include<stdio.h>
>> (eg same header included twice), will invoke an Undefined Behavior?
> 
> No.
> 
> Have you ever actually *looked* at stdio.h?  What are the first two
> lines you see, other than comments?
> 
> ... 25 lines of comments ...
> #ifndef _STDIO_H_
> #define	_STDIO_H_
> ... about 700 more lines of code ...
> #endif

Note: there is no unique stdio.h - each implementation of the C standard
library provides it's own, and while there will be substantial
similarities between them, there can also be substantial differences.
Any particular implementation's standard headers may contain constructs
that only work as intended when compiled using that particular
implementation. It's even entirely feasible for an implementation of C
to correctly implement "#include <stdio.h>" without even having a file
named "stdio.h" stored anywhere.
Therefore, looking at any particular implementation's stdio.h can lead
you to reach conclusions which won't apply when using the stdio.h
provided with some other implementation.

The important thing is that the standard mandates:
"Standard headers .. may be included more than once in a given scope,
with no effect different from being included only once, except that the
effect of including <assert.h> depends on the definition of NDEBUG (see
7.2)." (7.1.2p4)

Header guards are merely one way (certainly the most obvious way) of
meeting that requirement. It's the requirement that matters, not the
details about how it's implemented.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#59917

On 3/27/2015 6:32 AM, James Kuyper wrote:

> ... looking at any particular implementation's stdio.h can lead
> you to reach conclusions which won't apply when using the stdio.h
> provided with some other implementation.

Yes, that is true.

However, most implementations of C on PCs *do* involve a folder
called "include" with a file called "stdio.h", and looking at that
file *will* remove all doubt about whether including it multiple times
will cause harm. (It won't).

> The important thing is that the standard mandates:
> "Standard headers .. may be included more than once in a given scope,
> with no effect different from being included only once, except that the
> effect of including <assert.h> depends on the definition of NDEBUG (see
> 7.2)." (7.1.2p4)
>
> Header guards are merely one way (certainly the most obvious way) of
> meeting that requirement. It's the requirement that matters, not the
> details about how it's implemented.

Yes, that is true.

However, looking at headers (if one's implementation uses them)
can be illuminating, and hence can be an "important" step towards
understanding what's going on, esp if one doesn't happen to have
a copy of the standard lying around at the moment.

I should also point out that not all C implementations include
the whole C library. Implementations for embedded systems often
don't have stdio functionality at all; I/O has to be done by
other means. In the very first programming project I ever worked on
professionally, there was no stdio; inputs were by pushbuttons and
outputs were by LEDs. And while the code was mostly in C, some was
in assembly, and some was in machine language. No keyboard, no
monitor, no hard disk, a few K of RAM, a few K of Flash, and only
a very rudimentary OS. People on desktop PCs are spoiled.

(That was just as Spirit and Opportunity were landing on Mars.
And when their systems froze up, I immediately thought "did they
remember to collect their garbage? I think they need to reset
their RAM. Perhaps I should call up JPL?" Because I'd just had
a similar failure on the system I was working on, which from a
computer standpoint was very similar to Spirit & Opportunity.)


-- 
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
http://www.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley

[toc] | [prev] | [next] | [standalone]

#59925

Robbie Hatley <see.my.sig@for.my.address> writes:
[...]
> I should also point out that not all C implementations include
> the whole C library. Implementations for embedded systems often
> don't have stdio functionality at all; I/O has to be done by
> other means.
[...]

Freestanding implementations aren't required to provide a library (other
than a few headers that don't define any functions).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#59089

Robbie Hatley <see.my.sig@for.my.address> writes:
[...]
> ... 25 lines of comments ...
> #ifndef _STDIO_H_
> #define	_STDIO_H_
> ... about 700 more lines of code ...
> #endif
[...]

My newsreader rendered that identifier as just STDIO_H.  It probably
tried to put it in italics, but my terminal emulator doesn't do italics.
I was about to reply that, since <stdio.h> is part of the
implementation, it needs to use a reserved identifier -- but of course
it already does.

I'll have to figure out how to turn off that behavior.  (If anyone knows
how to do that for Gnus, drop me an e-mail.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#59934

W dniu niedziela, 22 marca 2015 11:02:47 UTC+1 użytkownik jeff napisał:
> although in most cases we see the good practises of Header Guards, is 
> there a risk for some architectures, that code like this,
> #include<stdio.h>
> #include<stdio.h>
> (eg same header included twice), will invoke an Undefined Behavior?
> 
> thank you.

I dont use header quards i just include headers in those .c which needs them and
it works, co header guards needed

(though i must say i am not much experienced here as i am not working with many libs in my life im doing mostly pure winapi progs and my own libs)

do i need header guards? i dont know

[toc] | [prev] | [next] | [standalone]

#59935

W dniu niedziela, 12 kwietnia 2015 20:35:26 UTC+2 użytkownik fir napisał:
> W dniu niedziela, 22 marca 2015 11:02:47 UTC+1 użytkownik jeff napisał:
> > although in most cases we see the good practises of Header Guards, is 
> > there a risk for some architectures, that code like this,
> > #include<stdio.h>
> > #include<stdio.h>
> > (eg same header included twice), will invoke an Undefined Behavior?
> > 
> > thank you.
> 
> I dont use header quards i just include headers in those .c which needs them and
> it works, co header guards needed
> 
> (though i must say i am not much experienced here as i am not working with many libs in my life im doing mostly pure winapi progs and my own libs)
> 
> do i need header guards? i dont know

ps in general i do not need to include headers in headers (and thats good, headers ale pure, not dependant) - though as far as i remember vaguelly there may be some pathology imposed when i want to write a header that uses winapi 
type in it  -i consider this as a minor patology maybe as it seems that in such case i need to include header in header (?) (or maybe not?) if so such header may be patologically included more than once (though im not sure as to this)

[toc] | [prev] | [next] | [standalone]

#59936

W dniu niedziela, 12 kwietnia 2015 20:45:36 UTC+2 użytkownik fir napisał:
> W dniu niedziela, 12 kwietnia 2015 20:35:26 UTC+2 użytkownik fir napisał:
> > W dniu niedziela, 22 marca 2015 11:02:47 UTC+1 użytkownik jeff napisał:
> > > although in most cases we see the good practises of Header Guards, is 
> > > there a risk for some architectures, that code like this,
> > > #include<stdio.h>
> > > #include<stdio.h>
> > > (eg same header included twice), will invoke an Undefined Behavior?
> > > 
> > > thank you.
> > 
> > I dont use header quards i just include headers in those .c which needs them and
> > it works, co header guards needed
> > 
> > (though i must say i am not much experienced here as i am not working with many libs in my life im doing mostly pure winapi progs and my own libs)
> > 
> > do i need header guards? i dont know
> 
> ps in general i do not need to include headers in headers (and thats good, headers ale pure, not dependant) - though as far as i remember vaguelly there may be some pathology imposed when i want to write a header that uses winapi 
> type in it  -i consider this as a minor patology maybe as it seems that in such case i need to include header in header (?) (or maybe not?) if so such header may be patologically included more than once (though im not sure as to this)

ps 
probably in such case i also do not need to put header in header too,  but i just need to 
put winapi header before winapi-dependant 
header in each .c that needs winapi dependant
header

so header guards seem still not needed here
9maybe in some other case)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web