Header include order

[Derrick Coetzee]

It seems like, in every C source file I've ever seen, there has been a
very definite include order, as follows:

- include system headers
- include application headers
- include the header associated with this source file

For example, in a file hello.c:

#include <stdio.h>
#include "utils.h"
#include "hello.h"

(Incidentally I think that a source file which doesn't include the header
file which exports its symbols is _very_ bad, as this is a good way to
check for inconsistencies for free.)

I would argue that the standard order of header including is wrong,
and that the correct order is the reverse. Consider this scenario:

hello.c:
#include <stdlib.h>
#include "hello.h"

hello.h:
struct blah {
size_t size;
};

hello2.c
#include "hello.h"

Inexplicably (from the perspective of the person doing the including)
the file hello.h will cause compiler errors in hello2.c but not in hello.c.
If hello.c were written first, and then the include file used elsewhere,
the error would appear to be "new", and not be caught by those who wrote
hello.c, implementing the functionality exported by hello.h.

If this include order is used, this problem is averted:

- include the header associated with this source file
- include application headers
- include system headers

This is good for two reasons:
1. All headers must now include any system headers they need, and will
fail immediately if they don't.
2. Every header will be included in at least ONE source file before
anything else (the source file associated with that header), allowing
any intra-application dependencies to be caught.

Does anyone have a reasonable justification for the standard include
order that I haven't thought of? Thanks.

--
Derrick Coetzee

[Alex]

E. Robert Tisdale <E.**************@jpl.nasa.gov> wrote:

Alex wrote:

E. Robert Tisdale wrote:

Alex wrote:

$ cat test.c
#define _SIZE_T
#include <stdlib.h>

size_t size = 32;

$ gcc -W -Wall -ansi -pedantic test.c

Evidently, this is *not* the Sun C compiler for Solaris 2.6
but some version of the GNU C compiler.

No, but the headers being used, to the best of my knowledge,
*are* from the Sun C compiler:

/*
* Copyright (c) 1996, by Sun Microsystems, Inc.
* All Rights reserved.
*/ Perhaps, but not likely. Type gcc -v -W -Wall -ansi -pedantic test.c
I don't need to. From the output I posted earlier

/usr/include/stdlib.h:106: warning: parameter names <...>

....you can clearly see the path. This is indeed the file
with the Sun copyright you see above.
The stdlib.h distributed with gcc version 3.2
includes stddef.h to define size_t. I get
That's nice. It doesn't have to. Did I say differently?
Yes. I said:

Where is the definition for size_t?
You said:
In a header file included by stdlib.h

It doesn't have to be. It *could* be defined in stdlib.h.
Which, I thought, was pretty obvious. However, you went
out on a tangent, trying to make me prove that there is
indeed an implementation where size_t is defined in
stdlib.h. Such proof is inherently irrelevant!

For a change of pace. Please prove that all past, present,
and future implementations have/do/will always include another
header within stdlib.h in order to define size_t.

I *never* claimed that all past or future implementations
must include another header file in stdlib.h to define size_t.
All I asked you to do is show us *one* implementation that does not.
If you are aware of the fact that there *can* be an
implementation where size_t is defined in stdlib.h, why
are you arguing? Are you going to write code to depend
on that fact (I wonder how...) until I find you an
implementation where it would fail? Which I did.

Until such time, if you are interested in specific implementations,
please refer to the appropriate newsgroups.
As far as this newsgroup is concerned, your assertion is baseless.

You're the one who claims that your implementation defines size_t
in stdlib.h itself.
You claimed that stdlib.h includes another header to
define size_t. I pointed out that it was speculation
on your part, since the standard does not define it.
The point is that the ANSI/ISO C standards are very carefully written
to avoid specifying any unnecessary details about the implementation.
You need to be very careful when making statements about implementations
based upon your interpretation of the standards.

That is *my* point. Again, you said that stdlib.h
includes a header to define size_t. I pointed out
that it doesn't have to, according to the standard.

Can it be any simpler than that? Are you trolling?

Alex

[E. Robert Tisdale]

Alex wrote:

E. Robert Tisdale wrote:

Alex wrote:

E. Robert Tisdale wrote:

Alex wrote:

>$ cat test.c
>#define _SIZE_T
>#include <stdlib.h>
>
>size_t size = 32;
>
>$ gcc -W -Wall -ansi -pedantic test.c

Evidently, this is *not* the Sun C compiler for Solaris 2.6
but some version of the GNU C compiler.

No, but the headers being used, to the best of my knowledge,
*are* from the Sun C compiler:

/*
* Copyright (c) 1996, by Sun Microsystems, Inc.
* All Rights reserved.
*/

Perhaps, but not likely. Type

gcc -v -W -Wall -ansi -pedantic test.c

I don't need to. From the output I posted earlier

/usr/include/stdlib.h:106: warning: parameter names <...>

...you can clearly see the path.
This is indeed the file with the Sun copyright you see above.

I found this same copyright notice in 88 header files
in the implementation distributed with version 3.2 of gcc.
Regardless of origin, your stdlib.h header file
is almost certainly part of the GNU C implementation
distributed with gcc.

The stdlib.h distributed with gcc version 3.2
includes stddef.h to define size_t. I get

That's nice. It doesn't have to.

Did I say differently?
Yes. I said:
Where is the definition for size_t?
You said:
In a header file included by stdlib.h
It doesn't have to be. It *could* be defined in stdlib.h.

I never said differently.
But the fact that size_t *could* be defined in stdlib.h itself
does *not* mean that size_t *is* defined in stdlib.h itself.
Which, I thought, was pretty obvious. However,
you went out on a tangent, trying to make me prove that
there is indeed an implementation
where size_t is defined in stdlib.h.
Such proof is inherently irrelevant!
It is *not* irrelevant to your claim
that you have found an implementation
where size_t is actually defined in stdlib.h itself.
Are you prepared to concede that you were wrong?

For a change of pace. Please prove that all past, present,
and future implementations have/do/will always include another
header within stdlib.h in order to define size_t.

I *never* claimed that all past or future implementations
must include another header file in stdlib.h to define size_t.
All I asked you to do is show us *one* implementation that does not.

If you are aware of the fact that there *can* be an implementation
where size_t is defined in stdlib.h, why are you arguing?

I assume that you agree that since the ANSI/ISO C standards
do not specify that size_t is defined in stdlib.h itself
and not in any included header file, all implementations
*could* define size_t in a header file included by stdlib.h.
My assertion is simply that, in fact, all implementations
*do* define size_t in a header file included by stdlib.h.
All you need to do to disprove my assertion is to provide
one example of an implementation that actually defines size_t
in stdlib.h itself.
Are you going to write code to depend on that fact (I wonder how...)
until I find you an implementation where it would fail? Which I did.

No. You haven't demonstrated that
size_t is actually defined in stdlib.h itself.

Until such time, if you are interested in specific implementations,
please refer to the appropriate newsgroups.
As far as this newsgroup is concerned, your assertion is baseless.

You're the one who claims that your implementation defines size_t
in stdlib.h itself.

You claimed that stdlib.h includes another header to define size_t.
I pointed out that it was speculation on your part
since the standard does not define it.

And I have pointed out that the ANSI/ISO C standards are irrelevant
to the question of whether or not size_t is defined in a header file
included by stdlib.h.
You are just ignorant of all the other considerations,
besides the standard, that go into an implementation.
For example, size_t is useful at a much lower level than stdlib.h
in most implementations so it is *always* defined
in a lower level header file included in stdlib.h.
The point is that the ANSI/ISO C standards are very carefully written
to avoid specifying any unnecessary details about the implementation.
You need to be very careful when making statements about implementations
based upon your interpretation of the standards.

That is *my* point. Again, you said that stdlib.h
includes a header to define size_t. I pointed out
that it doesn't have to, according to the standard.

And I never argued this point. I only asserted that
size_t was actually defined in a header file included by stdlib.h.
The absence of even one contradictory example supports my assertion.

[Alex]

E. Robert Tisdale <E.**************@jpl.nasa.gov> wrote:

Alex wrote:

E. Robert Tisdale wrote:

The point is that the ANSI/ISO C standards are very carefully written
to avoid specifying any unnecessary details about the implementation.
You need to be very careful when making statements about implementations
based upon your interpretation of the standards.
That is *my* point. Again, you said that stdlib.h
includes a header to define size_t. I pointed out
that it doesn't have to, according to the standard.

And I never argued this point. I only asserted that
size_t was actually defined in a header file included by stdlib.h.
The absence of even one contradictory example supports my assertion.

You are obviously trolling. I resign from this discussion.

Alex

[E. Robert Tisdale]

Alex wrote:

I have lost this argument so you're a troll.

[Mark Gordon]

On Mon, 24 Nov 2003 14:13:56 -0800
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote:

Alex wrote:

E. Robert Tisdale wrote:

Alex wrote:

E. Robert Tisdale wrote:

>Alex wrote:
>
>>$ cat test.c
>>#define _SIZE_T
>>#include <stdlib.h>
>>
>>size_t size = 32;
>>
>>$ gcc -W -Wall -ansi -pedantic test.c
>
>Evidently, this is *not* the Sun C compiler for Solaris 2.6
>but some version of the GNU C compiler.

No, but the headers being used, to the best of my knowledge,
*are* from the Sun C compiler:

/*
* Copyright (c) 1996, by Sun Microsystems, Inc.
* All Rights reserved.
*/

Perhaps, but not likely. Type

gcc -v -W -Wall -ansi -pedantic test.c

I don't need to. From the output I posted earlier

/usr/include/stdlib.h:106: warning: parameter names <...>

...you can clearly see the path.
This is indeed the file with the Sun copyright you see above.

I found this same copyright notice in 88 header files
in the implementation distributed with version 3.2 of gcc.
Regardless of origin, your stdlib.h header file
is almost certainly part of the GNU C implementation
distributed with gcc.

Since according to you the GCC headers are copyright Sun, perhaps you
will accept a header copyright IBM that was distributed with either AIC
or the AIX compiler?

/* IBM_PROLOG_BEGIN_TAG */
/* This is an automatically generated prolog. */
/* */
/* bos43V src/bos/usr/include/stdlib.h 1.31.6.2 */
/* */
/* Licensed Materials - Property of IBM */
/* */
/* (C) COPYRIGHT International Business Machines Corp. 1985,1995 */

....
#ifndef _H_STANDARDS
#include <standards.h>
#endif

The above is the only file included by this header, and is does not
define SIZE_T not does it include anything else

#ifndef _SIZE_T
#define _SIZE_T
typedef unsigned long size_t;
#endif

So with the version of CC and headers that IBM provide size_t IS defined
in stdlib.h and NOT in a file included by it.

Obviously I can't post the include files in there entirety since they
are copyright, so you can either believe me, buy a copy of AIX and it's
development system, or call me a lier.

>The stdlib.h distributed with gcc version 3.2
>includes stddef.h to define size_t. I get

That's nice. It doesn't have to.

Did I say differently?

Yes. I said:

>>Where is the definition for size_t?

You said:

>In a header file included by stdlib.h

It doesn't have to be. It *could* be defined in stdlib.h.

I never said differently.
But the fact that size_t *could* be defined in stdlib.h itself
does *not* mean that size_t *is* defined in stdlib.h itself.

You said "In a header included by stdlib.h" not "Possibly in a header
included by stdlib.h" so you have definitely been proved wrong. since on
AIX 4.3 it IS defined in stdlib.h and NOT in any headers included by
stdlib.h.

Which, I thought, was pretty obvious. However,
you went out on a tangent, trying to make me prove that
there is indeed an implementation
where size_t is defined in stdlib.h.
Such proof is inherently irrelevant!

It is *not* irrelevant to your claim
that you have found an implementation
where size_t is actually defined in stdlib.h itself.
Are you prepared to concede that you were wrong?

Why should he when he is correct?

For a change of pace. Please prove that all past, present,
and future implementations have/do/will always include another
header within stdlib.h in order to define size_t.

I *never* claimed that all past or future implementations
must include another header file in stdlib.h to define size_t.
All I asked you to do is show us *one* implementation that does not.

If you are aware of the fact that there *can* be an implementation
where size_t is defined in stdlib.h, why are you arguing?

I assume that you agree that since the ANSI/ISO C standards
do not specify that size_t is defined in stdlib.h itself
and not in any included header file, all implementations
*could* define size_t in a header file included by stdlib.h.
My assertion is simply that, in fact, all implementations
*do* define size_t in a header file included by stdlib.h.

You are wrong, see above.
All you need to do to disprove my assertion is to provide
one example of an implementation that actually defines size_t
in stdlib.h itself.
Done. Although it looks to me like you already had an example.

Are you going to write code to depend on that fact (I wonder how...)
until I find you an implementation where it would fail? Which I
did.

No. You haven't demonstrated that
size_t is actually defined in stdlib.h itself.

It looked like it was defined there to me, it just had protection
against duplicate definitions so you could include all the headers that
define it which the standard allows you to do.

Until such time, if you are interested in specific implementations,
please refer to the appropriate newsgroups.
As far as this newsgroup is concerned, your assertion is baseless.

You're the one who claims that your implementation defines size_t
in stdlib.h itself.

You claimed that stdlib.h includes another header to define size_t.
I pointed out that it was speculation on your part
since the standard does not define it.

And I have pointed out that the ANSI/ISO C standards are irrelevant
to the question of whether or not size_t is defined in a header file
included by stdlib.h.
You are just ignorant of all the other considerations,
besides the standard, that go into an implementation.
For example, size_t is useful at a much lower level than stdlib.h
in most implementations so it is *always* defined
in a lower level header file included in stdlib.h.

WRONG

The point is that the ANSI/ISO C standards are very carefully
written to avoid specifying any unnecessary details about the
implementation. You need to be very careful when making statements
about implementations based upon your interpretation of the
standards.

That is *my* point. Again, you said that stdlib.h
includes a header to define size_t. I pointed out
that it doesn't have to, according to the standard.

And I never argued this point. I only asserted that
size_t was actually defined in a header file included by stdlib.h.

You actually stated that it IS defined in a header included by stdlib.h
and you have done so even more clearly and explicitly in the post.
The absence of even one contradictory example supports my assertion.

Absence of proof is not proof of absence. Anyway, your original
assertion and fallacious statement of fact are disproved by the IBM
implementation.
--
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.

[E. Robert Tisdale]

Mark Gordon wrote:

On Mon, 24 Nov 2003 14:13:56 -0800
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote:

Alex wrote:

E. Robert Tisdale wrote:
Alex wrote:

>E. Robert Tisdale wrote:
>
>
>>Alex wrote:
>>
>>
>>>$ cat test.c
>>>#define _SIZE_T
>>>#include <stdlib.h>
>>>
>>>size_t size = 32;
>>>
>>>$ gcc -W -Wall -ansi -pedantic test.c
>>
>>Evidently, this is *not* the Sun C compiler for Solaris 2.6
>>but some version of the GNU C compiler.
>
>No, but the headers being used, to the best of my knowledge,
>*are* from the Sun C compiler:
>
> /*
> * Copyright (c) 1996, by Sun Microsystems, Inc.
> * All Rights reserved.
> */

Perhaps, but not likely. Type

gcc -v -W -Wall -ansi -pedantic test.c

I don't need to. From the output I posted earlier

/usr/include/stdlib.h:106: warning: parameter names <...>

...you can clearly see the path.
This is indeed the file with the Sun copyright you see above.

I found this same copyright notice in 88 header files
in the implementation distributed with version 3.2 of gcc.
Regardless of origin, your stdlib.h header file
is almost certainly part of the GNU C implementation
distributed with gcc.

Since according to you the GCC headers are copyright Sun, perhaps you
will accept a header copyright IBM that was distributed with either AIC
or the AIX compiler?

/* IBM_PROLOG_BEGIN_TAG */
/* This is an automatically generated prolog. */
/* */
/* bos43V src/bos/usr/include/stdlib.h 1.31.6.2 */
/* */
/* Licensed Materials - Property of IBM */
/* */
/* (C) COPYRIGHT International Business Machines Corp. 1985,1995 */

...
#ifndef _H_STANDARDS
#include <standards.h>
#endif

The above is the only file included by this header, and is does not
define SIZE_T not does it include anything else

#ifndef _SIZE_T
#define _SIZE_T
typedef unsigned long size_t;
#endif

So with the version of CC and headers that IBM provide size_t IS defined
in stdlib.h and NOT in a file included by it.

Obviously I can't post the include files in there entirety since they
are copyright, so you can either believe me, buy a copy of AIX and it's
development system, or call me a lier.

>>The stdlib.h distributed with gcc version 3.2
>>includes stddef.h to define size_t. I get
>
>That's nice. It doesn't have to.

Did I say differently?

Yes. I said:
>>>Where is the definition for size_t?
>>
You said:
>>In a header file included by stdlib.h
>
It doesn't have to be. It *could* be defined in stdlib.h.

I never said differently.
But the fact that size_t *could* be defined in stdlib.h itself
does *not* mean that size_t *is* defined in stdlib.h itself.

You said "In a header included by stdlib.h" not "Possibly in a header
included by stdlib.h" so you have definitely been proved wrong. since on
AIX 4.3 it IS defined in stdlib.h and NOT in any headers included by
stdlib.h.

I stand corrected. I ammend my assertion to
"size_t is defined in a header file included by stdlib.h
except for the IBM AIC or AIX compiler."

[Richard Heathfield]

E. Robert Tisdale wrote:

CBFalconer wrote:
<troll banners>
Evidently, your definition of a troll is anyone who disagrees with you.
No. I have disagreed with Chuck on many occasions, and yet he has never
called me a troll. Therefore, your statement is incorrect.
For you, it's just another epithet that you hurl at an opponent.
No. He just hurls it at trolls.
You resort to ad hominem attacks
Loads of people have tried reasoning with you. It never works, because you
blithely ignore almost every criticism people make. So in the end, lots of
people stopped bothering.

Now that we know you respond to cartoons, expect more cartoons.
when you have lost an argument
and have no valid argument to contribute to the discussion.
Oh, we have plenty of valid arguments, stretching back many years. When are
you planning to deal with those arguments?
The use of such an obviously fallacious argument shows contempt
for subscribers if you really expect to sway them with it.
It was a cartoon, not an argument. We've done the arguments already.
Or do you honestly believe that you are making a valid argument?

We've made loads. Google for almost any comp.lang.c thread containing the
word "Tisdale" for a whole bunch of reasons why you are wrong.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Mark Gordon]

On Mon, 24 Nov 2003 17:49:25 -0800
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote:

Mark Gordon wrote:
<snip>

Since according to you the GCC headers are copyright Sun, perhaps
you will accept a header copyright IBM that was distributed with
either AIC or the AIX compiler?

^^^ AIX

<snip>
I stand corrected. I ammend my assertion to
"size_t is defined in a header file included by stdlib.h
except for the IBM AIC or AIX compiler."

How do you know there is no other implementation where size_t is not
defined in stdlib.h?

Just accept that you were wrong in your assertion
and that you are wrong to claim to know what every single
implementation of C does.
--
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.

[E. Robert Tisdale]

Mark Gordon wrote:

How do you know that there is no other implementation
where size_t is not defined in stdlib.h?

How do you know that there *is* another implementation
where size_t is not defined in stdlib.h?

[Richard Heathfield]

E. Robert Tisdale wrote:

Mark Gordon wrote:

How do you know that there is no other implementation
where size_t is not defined in stdlib.h?

How do you know that there *is* another implementation
where size_t is not defined in stdlib.h?

And this kind of silly argument is /precisely/ why we go by What The
Standard Says.

The Standard, in this case, requires stdlib.h to declare the size_t type,
but neither forbids it from doing so, nor requires it to do so,
specifically by including some other header. Therefore, it is foolish for
us to write C code that relies either on the inclusion, or on the
non-inclusion, by stdlib.h of some other header for that declaration.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Randy Howard]

In article <3f********@news2.power.net.uk>, in*****@address.co.uk.invalid
says...
[In reference to ERT]...

Loads of people have tried reasoning with you. It never works, because you
blithely ignore almost every criticism people make. So in the end, lots of
people stopped bothering.

Now that we know you respond to cartoons, expect more cartoons.

Seems as if a new c.l.c convention is needed for the Uber-Troll (to still
a Tom St. Denis-ism). Perhaps something on the order of

<CARTOON>
Insert a response to one of ERT's inane postings...
</CARTOON>

This would allow everyone else to immediately grasp the intent of the
posting.

--
Randy Howard _o
2reply remove FOOBAR \<,
______________________()/ ()______________________________________________
SCO Spam-magnet: po********@sco.com