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

[Morris Dovey]

Derrick Coetzee wrote:

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
You have a good eye.
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.)
Hmm. Ok. I think that it depends on the situation; but if you
don't do what you think is bad, you probably won't be wrong.
I would argue that the standard order of header including is wrong,
and that the correct order is the reverse. Consider this scenario:
Let me break in here to suggest that it isn't unusual for my
headers to need definitions provided by the system headers...
hello.c:
#include <stdlib.h>
#include "hello.h"

hello.h:
struct blah {
size_t size;
};
/This/ is bad practice. Structures, unions, arrays, and variables
should only be declared - not defined - in header files. Placing
definitions in header files, while not strictly illegal, is
asking for trouble.
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.
<snip>
Does anyone have a reasonable justification for the standard include
order that I haven't thought of?

Already answered.

HTH
--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Read my lips: The apple doesn't fall far from the tree.

[Rouben Rostamian]

In article <Pi**************************************@semaphor e.moonflare.com>,
Derrick Coetzee <dc****@moonflare.com> wrote:

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
[description of pitfalls snipped]
If this include order is used, this problem is averted:

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

I completely agree with your reasons for suggesting this.
They make good sense and enforce good code design.

But old habits die hard. I just can't bring myself to
reverse the order of header, despite reason and logic.

Old dog, new tricks...

--
Rouben Rostamian

[Morris Dovey]

Morris Dovey wrote:

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

/This/ is bad practice. Structures, unions, arrays, and variables should
only be declared - not defined - in header files. Placing definitions in
header files, while not strictly illegal, is asking for trouble.

Please ignore the comment about bad practice. Due to faulty
wiring I read that as a definition, which it obviously isn't.

If you ignore that, then the remainder is valid ( but not much
called-for )-:

--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Read my lips: The apple doesn't fall far from the tree.

[Richard Heathfield]

[This is a rather interesting idea, which probably won't get the attention
it deserves because it proposes a change to the way code is laid out, and
many clc-ers don't seem to like such changes.]

Derrick Coetzee wrote:

If this include order is used, this [idempotency failure] 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.
Not quite true. All headers must either include any system headers they
need, or follow another such header in the batting order. You have reduced
the scale of the problem (and I think that's a good thing in itself), but
not eliminated it.
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.
Interesting point.
Does anyone have a reasonable justification for the standard include
order that I haven't thought of? Thanks.

Only a philosophical one, which hadn't really occurred to me until you
raised the subject. I think the existing order is as it is because it gives
a constant narrowing of focus. "Right, let's have some big old headers, our
good friends stdio, stdlib, string... Okay, now let's pull in some local
stuff that we used on XFoo... xfoo.h, xbar.h... now, for /this/ program
we'll need ybaz.h, which we'll write in a minute... okay, let's write
ybaz".

In other words, I think it's pure habit.

--
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

[Moosebumps]

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

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

It's a coding standard at my company (not widely followed) to do this.
Always #include Foo.h as the first line of Foo.c. That way you're assured
that whenever you #include Foo.h from any other file, it will compile.
There is no messing with the orders of headers to fix compile errors, and
conversely organizing headers for aesthetics will not cause any compile
errors.

[Jarno A Wuolijoki]

On Tue, 18 Nov 2003, Derrick Coetzee wrote:

I would argue that the standard order of header including is wrong,
and that the correct order is the reverse.
If this include order is used, this problem is averted:

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

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

You may forget to include stdlib in hello.c and
then when you change hello.h to use stddef instead
it breaks?

[Dan Pop]

In <kp*****************@news.uswest.net> Morris Dovey <mr*****@iedu.com> writes:

Derrick Coetzee wrote:

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

You have a good eye.

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.)

Hmm. Ok. I think that it depends on the situation; but if you
don't do what you think is bad, you probably won't be wrong.

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

Let me break in here to suggest that it isn't unusual for my
headers to need definitions provided by the system headers...

Then, your headers should include the system headers they need.
I couldn't agree more with the OP on this point.

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

/This/ is bad practice. Structures, unions, arrays, and variables
should only be declared - not defined - in header files. Placing
definitions in header files, while not strictly illegal, is
asking for trouble.

Sheer nonsense, as far as structure and union definitions are concerned.
When I need a struct tm, I use the definition provided by <time.h> and
that never caused my any trouble. Using my own definition, OTOH, would
be a sure recipe for headaches.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <Pi**************************************@semaphor e.moonflare.com> Derrick Coetzee <dc****@moonflare.com> writes:

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.)
Obviously.
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.
It's not inexplicable. If hello.h is written this way, then including
<stddef.h> must be documented as a prerequisite. I agree that this is
not the right way of defining hello.h, *these days*.
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.
This is a general rule, *these days*. The system headers are not included
first so that other headers no longer have to include them.
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.
This is a valid point.
Does anyone have a reasonable justification for the standard include
order that I haven't thought of? Thanks.

Yes, from a historical perspective. Back when disks were much slower
than they are today (especially on micros and low end minis, whose
fastest mass storage devices were floppy disks), you didn't want to
have to open and read any more header files than strictly necessary.
Therefore, headers didn't include other headers, they merely documented
their dependencies. Using the traditional include order, each header file
had to be opened and read exactly once, speeding up the compilation
process, at the expense of some extra care on the programmer's side.

But there is another reason, that still applies. It is very easy to
inadvertently declare an identifier already declared in a system header.
Especially if your implementation provides many C99 functions as
extensions, along with its own specific extensions. If you include
the application headers first, the compiler will report the problem
as being generated by a system header. I've seen more than one
programmer completely baffled when that happened and suspecting his
implementation to be broken, because including a system header must,
"by definition", cause no problems. Imagine the following scenario:
one of your headers, say "appmath.h", declares:

long round(double);

and everything works fine, until someone else tries to compile your
program on a platform declaring

double round(double);

as a C99 extension in <math.h> (or even having C99 conforming libraries).
Since <math.h> was included after the application header, the error
will be reported in <math.h>, resulting in a maximum of confusion
(especially if the compiler was not kind enough to indicate the
actual location of the other declaration). Now, if that happened in
"appmath.h", nobody would expect the system headers to be broken, because
the problem is correctly reported as belonging to "appmath.h".

So, going from more general to more specific still has its merits...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Morris Dovey]

Dan Pop wrote:

Morris Dovey wrote:

Let me break in here to suggest that it isn't unusual for my
headers to need definitions provided by the system headers...
Then, your headers should include the system headers they need.
I couldn't agree more with the OP on this point.

Me too. It /does/ look as if I'd have done better to turn off the
computer and get some sleep. Apologies to Derrick.

/This/ is bad practice. Structures, unions, arrays, and variables
should only be declared - not defined - in header files. Placing
definitions in header files, while not strictly illegal, is
asking for trouble.

Sheer nonsense, as far as structure and union definitions are concerned.
When I need a struct tm, I use the definition provided by <time.h> and
that never caused my any trouble. Using my own definition, OTOH, would
be a sure recipe for headaches.

More of the same. This bit of stupidity I /did/ catch last night.
Now I find myself wondering what I could have been thinking. I
swear I was only drinking coffee...
--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Read my lips: The apple doesn't fall far from the tree.

[Alan Balmer]

On 19 Nov 2003 12:53:29 GMT, Da*****@cern.ch (Dan Pop) wrote:

Let me break in here to suggest that it isn't unusual for my
headers to need definitions provided by the system headers...

Then, your headers should include the system headers they need.
I couldn't agree more with the OP on this point.

Me, too :-) The standard headers, particularly, are guaranteed to work
in any order and even if included more than once.

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

/This/ is bad practice. Structures, unions, arrays, and variables
should only be declared - not defined - in header files. Placing
definitions in header files, while not strictly illegal, is
asking for trouble.

Sheer nonsense, as far as structure and union definitions are concerned.
When I need a struct tm, I use the definition provided by <time.h> and
that never caused my any trouble. Using my own definition, OTOH, would
be a sure recipe for headaches.

Definition vs. declaration?

I prefer that nothing in a header file reserve storage.

The above is OK, but a header file containing

struct blah {
size_t size;
} xyz;

is bad practice, imo.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Dan Pop]

In <jr********************************@4ax.com> Alan Balmer <al******@att.net> writes:

On 19 Nov 2003 12:53:29 GMT, Da*****@cern.ch (Dan Pop) wrote:

Let me break in here to suggest that it isn't unusual for my
headers to need definitions provided by the system headers...
Then, your headers should include the system headers they need.
I couldn't agree more with the OP on this point.

Me, too :-) The standard headers, particularly, are guaranteed to work
in any order and even if included more than once.

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

/This/ is bad practice. Structures, unions, arrays, and variables
should only be declared - not defined - in header files. Placing
definitions in header files, while not strictly illegal, is
asking for trouble.

Sheer nonsense, as far as structure and union definitions are concerned.
When I need a struct tm, I use the definition provided by <time.h> and
that never caused my any trouble. Using my own definition, OTOH, would
be a sure recipe for headaches.

Definition vs. declaration?

When it comes to structures and unions (as types, not as objects), I
consider:

struct foo;

to be a declaration and:

struct foo { int bar, baz; };

to be a definition.
I prefer that nothing in a header file reserve storage.

It's more than a simple preference in my case :-)

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Arthur J. O'Dwyer]

On Thu, 20 Nov 2003, CBFalconer wrote:

"E. Robert Tisdale" wrote:

You are confused.
A file included by the C preprocessor directive
is *not* necessarily a header file.
A file with *.h extension is *not* necessarily a header file.
Neither the C preprocessor or the C programming language
specify file name extensions for header files.

We should take especial notice now. That omniscient expert, ERT,
has made his pronouncement. Since he specifies his organization
as "Jet Propulsion Laboratory", and his return address as
@jpl.nasa.gov, he carries very imposing credentials. After all,
his abilities and careful standards adherence and understanding
are obviously protecting the entire US space program. The utter
drivel posted in c.l.c under his name is obviously a concerted
plot by the evil (left/right/center) to undermine his shining
reputation.

Chuck, as much as ERT has trolled and misinformed before, I
must say that your post looks uncalled-for here. I think he's
right -- a "header file," as the term is commonly used, refers
to a file that is included at the top of another file, and
contains declarations and macros and suchlike.
A file included in the middle of another file, containing
data or code templates, is *not* a "header file" -- it's a
"data file" or a "code template file."
FWIW, the Standard explicitly mentions that

[an] #include preprocessing
directive causes the named header or source file to be
^^^^^^^^^^^^^^
processed from phase 1 through phase 4, recursively.

by which I gather that the committee had something of the
same idea in mind. Makes sense to me, anyway.

So, let's leave the name-calling for the defenses of 'void
main' and 'malloc' casting, announcements of 'obvious trolls',
and indictments of 'indigenous plonkers', huh? :-) IMHO
Tisdale is right for once.

-Arthur

[Richard Heathfield]

EventHelix.com wrote:

For header file includes

a.c file should always include a.h as the first file. That way
a.h will always be self sufficient and header file include order
will not matter.

The following article should help:

http://www.eventhelix.com/RealtimeMa...dePatterns.htm

I doubt it. It's chock-full of syntax errors and undefined behaviour. Quite
a trick for a header file.

#ifndef _a_h_included_
#define _a_h_included_

It's a bad idea to use leading underscores.

#include "abase.h"
#include "b.h"

No source, no comment.

// Forward Declarations

Syntax error in C90.

class C;

Presumably class is typedef'd in abase.h or b.h?

class D;

class A : public ABase

And that's a syntax error.

Not a great page, IMHO.

--
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

[Moosebumps]

Good article, that's exactly what I do... took a while to pick that pattern
up, since I haven't seen it mentioned in a lot of C/C++ books. Some of my
coworkers still don't know when to use forward declarations.

"EventHelix.com" <ev********@hotmail.com> wrote in message
news:56**************************@posting.google.c om...

For header file includes

a.c file should always include a.h as the first file. That way
a.h will always be self sufficient and header file include order
will not matter.

The following article should help:

http://www.eventhelix.com/RealtimeMa...dePatterns.htm

Sandeep
--
http://www.EventHelix.com/EventStudio
EventStudio 2.0 - Generate Message Sequence Charts in PDF

[Dan Pop]

In <e0********************************@4ax.com> Alan Balmer <al******@att.net> writes:

On 19 Nov 2003 18:56:33 GMT, Da*****@cern.ch (Dan Pop) wrote:

In <jr********************************@4ax.com> Alan Balmer <al******@att.net> writes:

On 19 Nov 2003 12:53:29 GMT, Da*****@cern.ch (Dan Pop) wrote:
Definition vs. declaration?

When it comes to structures and unions (as types, not as objects), I ^^^^^^^^^^^^^^^^^^^^^^^^consider:

struct foo;

to be a declaration and:

struct foo { int bar, baz; };

to be a definition.

What do you call

struct foo foo_thing;

?

An object definition. Are you sure you've read the parenthetical note
in my previous post?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <3F***************@sun.com> Eric Sosman <Er*********@sun.com> writes:

I agree with Dan and Alan for the proverbial 99.44% of
all uses of header files, but there *are* cases where it
can be useful to put definitions in headers. A few I've
run across:

- When part of the code is generated by a "helper"
program, it's often convenient to have the helper
write a header. This is often seen in connection
with static initializations, where the main file
contains something like

static const struct thingummy big_table[] = {
#include "generated.h"
};

There's a quibble about whether the header in this
case "reserves storage" or not -- but at any rate,
it certainly doesn't contain declarations!
That file is NOT a header and using the .h extension doesn't make it one.
A more appropriate name for that file is generated.c.

The name "header" was not chosen at random for this type of files.
- Headers are a good place for widely-used `inline'
functions. Again, there's a quibble about whether
defining such a function "reserves storage," but
again it's clear that such a header contains more
than mere declarations.

We were clearly discussing about *object* definitions. Macro definitions,
type definitions and even inline and static function definitions do
belong to headers.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Alan Balmer]

On Wed, 19 Nov 2003 15:02:48 -0800, "E. Robert Tisdale"
<E.**************@jpl.nasa.gov> wrote:

That's *not* a header file.
A header file is #included at the *head* of another file.

The standard defines the standard headers. It does not specify that
they can only be included at the "head" of another file.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Alan Balmer]

On 20 Nov 2003 12:02:08 GMT, Da*****@cern.ch (Dan Pop) wrote:

What do you call

struct foo foo_thing;

?

An object definition. Are you sure you've read the parenthetical note
in my previous post?

That's why I asked the question. You said that your naming there
applied to types, not objects, but did not specify your convention for
describing object declarations/definitions.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Alan Balmer]

On Wed, 19 Nov 2003 14:17:57 -0800, "E. Robert Tisdale"
<E.**************@jpl.nasa.gov> wrote:

Where is the definition for size_t?

In a header file included by stdlib.h

You'd have been right with either stddef.h or stdio.h.

The standard does not specify that stdlib.h includes any other files.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Eric Sosman]

Alan Balmer wrote:

On Wed, 19 Nov 2003 14:17:57 -0800, "E. Robert Tisdale"
<E.**************@jpl.nasa.gov> wrote:

Where is the definition for size_t?

In a header file included by stdlib.h

You'd have been right with either stddef.h or stdio.h.

The standard does not specify that stdlib.h includes any other files.

... but the Standard *does* specify that <stdlib.h>
defines `size_t'. 7.20, paragraph 2.

--
Er*********@sun.com

[Alan Balmer]

On Thu, 20 Nov 2003 11:01:48 -0500, Eric Sosman <Er*********@sun.com>
wrote:

Alan Balmer wrote:

On Wed, 19 Nov 2003 14:17:57 -0800, "E. Robert Tisdale"
<E.**************@jpl.nasa.gov> wrote:

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

You'd have been right with either stddef.h or stdio.h.

The standard does not specify that stdlib.h includes any other files.

... but the Standard *does* specify that <stdlib.h>
defines `size_t'. 7.20, paragraph 2.

You're right, of course. I thought I remembered only three places
(above plus wchar.h). Should have double-checked.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Dan Pop]

In <1a********************************@4ax.com> Alan Balmer <al******@att.net> writes:

On 20 Nov 2003 12:02:08 GMT, Da*****@cern.ch (Dan Pop) wrote:

What do you call

struct foo foo_thing;

?

An object definition. Are you sure you've read the parenthetical note
in my previous post?

That's why I asked the question. You said that your naming there
applied to types, not objects, but did not specify your convention for
describing object declarations/definitions.

I'm using the standard terminology, no point in inventing my own: if it
reserves space, it's an object definition, otherwise it's a mere
declaration.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[CBFalconer]

"Arthur J. O'Dwyer" wrote:

On Thu, 20 Nov 2003, CBFalconer wrote:

"E. Robert Tisdale" wrote:

You are confused.
A file included by the C preprocessor directive
is *not* necessarily a header file.
A file with *.h extension is *not* necessarily a header file.
Neither the C preprocessor or the C programming language
specify file name extensions for header files.
We should take especial notice now. That omniscient expert, ERT,
has made his pronouncement. Since he specifies his organization
as "Jet Propulsion Laboratory", and his return address as
@jpl.nasa.gov, he carries very imposing credentials. After all,
his abilities and careful standards adherence and understanding
are obviously protecting the entire US space program. The utter
drivel posted in c.l.c under his name is obviously a concerted
plot by the evil (left/right/center) to undermine his shining
reputation.

.... snip ...
So, let's leave the name-calling for the defenses of 'void
main' and 'malloc' casting, announcements of 'obvious trolls',
and indictments of 'indigenous plonkers', huh? :-) IMHO
Tisdale is right for once.

Where did I call him names? I referred to him as an "omniscient
expert". I attributed any misinformation posted (allegedly) by
him to a plot by evil fringe groups? However I should probably
have stripped all of his post apart from the "you are confused"
portion.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Eric Sosman]

Alan Balmer wrote:

On Thu, 20 Nov 2003 11:01:48 -0500, Eric Sosman <Er*********@sun.com>
wrote:

Alan Balmer wrote:

On Wed, 19 Nov 2003 14:17:57 -0800, "E. Robert Tisdale"
<E.**************@jpl.nasa.gov> wrote:

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

You'd have been right with either stddef.h or stdio.h.

The standard does not specify that stdlib.h includes any other files.

... but the Standard *does* specify that <stdlib.h>
defines `size_t'. 7.20, paragraph 2.

You're right, of course. I thought I remembered only three places
(above plus wchar.h). Should have double-checked.

Also <string.h>. The Standard's practice seems to be
that any header defines all the types used in its function
declarations. There are a few exceptions (e.g., <stdio.h>
doesn't define va_list even though vfprintf() et al. use
it), but they are rare.

I always get tripped up by `offsetof'. For some insane
reason I expect <stdlib.h> to provide it, but of course it's
found only in <stddef.h>. Evidence of a warped childhood,
I guess.

--
Er*********@sun.com

[Alex]

Alan Balmer <al******@att.net> wrote:

On Wed, 19 Nov 2003 14:17:57 -0800, "E. Robert Tisdale"
<E.**************@jpl.nasa.gov> wrote:

Where is the definition for size_t?

In a header file included by stdlib.h

You'd have been right with either stddef.h or stdio.h. The standard does not specify that stdlib.h includes any other files.

Turns out I was incorrect.

A.3.11 GENERAL UTILITIES <stdlib.h>

EXIT_FAILURE
EXIT_SUCCESS
<...>
size_t

However, the fact that this is accomplished by the
inclusion of another header file, within stdlib.h,
is a speculation. It is not mandated by the standard.

Alex

[Chris Torek]

>"Arthur J. O'Dwyer" wrote:

So, let's leave the name-calling for the defenses of 'void
main' and 'malloc' casting, announcements of 'obvious trolls',
and indictments of 'indigenous plonkers', huh? :-) IMHO
Tisdale is right for once.

In article news:3F***************@yahoo.com
CBFalconer <cb********@worldnet.att.net> writes:Where did I call him names? I referred to him as an "omniscient
expert". I attributed any misinformation posted (allegedly) by
him to a plot by evil fringe groups?
I imagine Arthur interpreted this as sarcasm. (I certainly did. :-) )
However I should probably have stripped all of his post apart from
the "you are confused" portion.

Whenever I see that line, I am reminded of the old "rogue" game.
I imagine my "@" character wandering about the dungeon, looking
for the Amulet of Yendor, and encountering a "T":

The Trollsdale hits! -more-

You are confused.

:-) (Of course, in rogue, it was a different monster that caused
the "confusion", after which one's attempts to move or hit caused
a random direction to be chosen. Trolls merely hit very hard, and
had good built-in armor.)

(At the U of MD, we once managed to get hold of the source to an
older version of rogue, and someone "customized" it to put in the
names of various professors and other characters: "The Zelkowitz
hits! Your PhD is denied!" And so on.)

(Seriously, though, I do think he uses it more as a command than
a statement.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.

[E. Robert Tisdale]

Alex wrote:

Alan Balmer <al******@att.net> wrote:

E. Robert Tisdale wrote:

Where is the definition for size_t?

In a header file included by stdlib.h

You'd have been right with either stddef.h or stdio.h.

The standard does not specify that stdlib.h includes any other files.

Turns out I was incorrect.

A.3.11 GENERAL UTILITIES <stdlib.h>

EXIT_FAILURE
EXIT_SUCCESS
<...>
size_t

However, the fact that this is accomplished by the
inclusion of another header file, within stdlib.h,
is a speculation. It is not mandated by the standard.

That's irrelevant.
All you need to do to prove my assertion false
is to present *one* example of an implementation
where size_t is defined in stdlib.h and *not*
in some included header file.

[Alex]

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

Alex wrote:

Alan Balmer <al******@att.net> wrote:

E. Robert Tisdale wrote:

>Where is the definition for size_t?

In a header file included by stdlib.h

You'd have been right with either stddef.h or stdio.h.

The standard does not specify that stdlib.h includes any other files.

Turns out I was incorrect.

A.3.11 GENERAL UTILITIES <stdlib.h>

EXIT_FAILURE
EXIT_SUCCESS
<...>
size_t

However, the fact that this is accomplished by the
inclusion of another header file, within stdlib.h,
is a speculation. It is not mandated by the standard.

That's irrelevant.
All you need to do to prove my assertion false
is to present *one* example of an implementation
where size_t is defined in stdlib.h and *not*
in some included header file.

If you insist. Solaris 2.6:

/usr/include/stdlib.h:

<...>

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

<...>

Alex

[Richard Bos]

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

Alex wrote:

Alan Balmer <al******@att.net> wrote:

E. Robert Tisdale wrote:

>Where is the definition for size_t?

In a header file included by stdlib.h

The standard does not specify that stdlib.h includes any other files.

A.3.11 GENERAL UTILITIES <stdlib.h>

size_t

However, the fact that this is accomplished by the
inclusion of another header file, within stdlib.h,
is a speculation. It is not mandated by the standard.

That's irrelevant.
All you need to do to prove my assertion false
is to present *one* example of an implementation
where size_t is defined in stdlib.h and *not*
in some included header file.

Nope. All we need to do to prove your assertion false is to note that
the Standard doesn't demand that <stdlib.h> includes any header files,
but does demand that it define size_t.

Richard

[Dan Pop]

In <3F***************@sun.com> Eric Sosman <Er*********@sun.com> writes:

I always get tripped up by `offsetof'. For some insane
reason I expect <stdlib.h> to provide it, but of course it's
found only in <stddef.h>.

In practice, offsetof is the only reason for including <stddef.h>.
The other thing defined only by <stddef.h> is ptrdiff_t, which is
seldom used explicitly.

Code needing NULL or size_t is extremely likely to include another
header defining them (<stdio.h>, <string.h> or <stdlib.h>, usually).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[E. Robert Tisdale]

Alex wrote:

E. Robert Tisdale wrote:

All you need to do to prove my assertion false
is to present *one* example of an implementation
where size_t is defined in stdlib.h and *not*
in some included header file.

If you insist. Solaris 2.6:

I suppose you mean the Sun C compiler
that you got bundled with Solaris 2.6?

/usr/include/stdlib.h:

<...>

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

<...>

I don't mean to quibble but
you haven't actually shown that size_t gets defined in stdlib.h
Try to compile

#define _SIZE_T
#include <stdlib.h>

size_t size = 32;

with your Sun C compiler and show us the diagnostic message
that it issues.

[Alan Balmer]

On Fri, 21 Nov 2003 10:35:03 -0800, "E. Robert Tisdale"
<E.**************@jpl.nasa.gov> wrote:

Alex wrote:

E. Robert Tisdale wrote:

All you need to do to prove my assertion false
is to present *one* example of an implementation
where size_t is defined in stdlib.h and *not*
in some included header file.

If you insist. Solaris 2.6:

I suppose you mean the Sun C compiler
that you got bundled with Solaris 2.6?

/usr/include/stdlib.h:

<...>

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

<...>

I don't mean to quibble

Yes, you do. You just aren't very good at it.
but
you haven't actually shown that size_t gets defined in stdlib.h
Try to compile

#define _SIZE_T
#include <stdlib.h>

size_t size = 32;

with your Sun C compiler and show us the diagnostic message
that it issues.

Proving that's it's possible to write code which produces errors.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Alex]

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

Alex wrote:

E. Robert Tisdale wrote:

All you need to do to prove my assertion false
is to present *one* example of an implementation
where size_t is defined in stdlib.h and *not*
in some included header file.

If you insist. Solaris 2.6: I suppose you mean the Sun C compiler
that you got bundled with Solaris 2.6?
Indeed.

/usr/include/stdlib.h:

<...>

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

<...>

I don't mean to quibble but
you haven't actually shown that size_t gets defined in stdlib.h
Try to compile #define _SIZE_T
#include <stdlib.h> size_t size = 32; with your Sun C compiler and show us the diagnostic message
that it issues.

Unfortunately, I am not at liberty to define constants with leading
underscores in their names. That naming convention is reserved for
the implementation.

What is your point, exactly?

Alex

[Eric Sosman]

"E. Robert Tisdale" wrote:

I don't mean to quibble but
you haven't actually shown that size_t gets defined in stdlib.h
Try to compile

#define _SIZE_T
#include <stdlib.h>

size_t size = 32;

with your Sun C compiler and show us the diagnostic message
that it issues.

The compiler is within its rights to do anything at all
(or nothing at all) with this code, since the mis-use of a
reserved identifier invokes undefined behavior. Section 7.1,
paragraph 1, first bullet.

--
Er*********@sun.com

[E. Robert Tisdale]

Alex wrote:

E. Robert Tisdale wrote:

Alex wrote:

E. Robert Tisdale wrote:

All you need to do to prove my assertion false
is to present *one* example of an implementation
where size_t is defined in stdlib.h and *not*
in some included header file.

If you insist. Solaris 2.6:

I suppose you mean the Sun C compiler
that you got bundled with Solaris 2.6?

Indeed.
/usr/include/stdlib.h:

<...>

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

<...>

I don't mean to quibble but
you haven't actually shown that size_t gets defined in stdlib.h
Try to compile

#define _SIZE_T
#include <stdlib.h>

size_t size = 32;

with your Sun C compiler and show us the diagnostic message
that it issues.

Unfortunately, I am not at liberty
to define constants with leading underscores in their names.
That naming convention is reserved for the implementation.

What is your point, exactly?

That you are confused.
That you haven't shown that size_t is defined in stdlib.h
instead of in another header file included by stdlib.h.
That your remarks about the ANSI/ISO standard
are irrelevant to my assertion that
"size_t is defined in a header file included by stdlib.h".
That you refusal to publish the diagnostic messages
from you compiler for the above code leads me to suspect
that you already know that size_t is *not* defined in stdlib.h
but in another header file included by stdlib.h

Why are you so dissembling?
Why are you afraid of this simple experiment?

[E. Robert Tisdale]

Eric Sosman wrote:

E. Robert Tisdale wrote:

I don't mean to quibble but
you haven't actually shown that size_t gets defined in stdlib.h
Try to compile

#define _SIZE_T
#include <stdlib.h>

size_t size = 32;

with your Sun C compiler and show us the diagnostic message
that it issues.

The compiler is within its rights to do anything at all
(or nothing at all) with this code, since the mis-use of a
reserved identifier invokes undefined behavior.
Section 7.1, paragraph 1, first bullet.

True but irrelevant.

[Alan Balmer]

On Fri, 21 Nov 2003 12:13:14 -0800, "E. Robert Tisdale"
<E.**************@jpl.nasa.gov> wrote:

Section 7.1, paragraph 1, first bullet.

True but irrelevant.

At long last, I have reluctantly come to the conclusion that you are
irrelevant, and that time reading your posts is wasted. You have the
honor of being only the second person I have ever filtered from this
newsgroup. Bye, now.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Eric Sosman]

"E. Robert Tisdale" wrote:

Eric Sosman wrote:

E. Robert Tisdale wrote:

I don't mean to quibble but
you haven't actually shown that size_t gets defined in stdlib.h
Try to compile

#define _SIZE_T
#include <stdlib.h>

size_t size = 32;

with your Sun C compiler and show us the diagnostic message
that it issues.

The compiler is within its rights to do anything at all
(or nothing at all) with this code, since the mis-use of a
reserved identifier invokes undefined behavior.
Section 7.1, paragraph 1, first bullet.

True but irrelevant.

Which part of "undefined behavior" are you having trouble
understanding? If the code produces U.B. (as the sample does),
the implementation's response is no longer describable in terms
of the Standard. The code is not "C code" because the language
definition assigns it no meaning; it is at best "C with extras."

Back to your original assertion (here re-quoted because
it has long since disappeared in snippage):

Alex>>Where is the definition for size_t?

Tisdale>In a header file included by stdlib.h

This assertion is false in general (although it could be true
for some particular C implementation). The Standard requires
that `#include <stdlib.h>' must define `size_t' (Section 7.20,
paragraph 2), but does not dictate the mechanism by which the
definition is provided. In particular, it does not require
<stdlib.h> to include some other header file, unmentioned in
the Standard. It does not even require that the inclusion of
<stdlib.h> read a file at all; the compiler can simply "know"
what is supposed to happen, and cause it to happen "magically."

--
Er*********@sun.com

[Alex]

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

Alex wrote:

E. Robert Tisdale wrote:
<snip>

you haven't actually shown that size_t gets defined in stdlib.h
Try to compile

#define _SIZE_T
#include <stdlib.h>

size_t size = 32;

with your Sun C compiler and show us the diagnostic message
that it issues.

Unfortunately, I am not at liberty
to define constants with leading underscores in their names.
That naming convention is reserved for the implementation.

What is your point, exactly?

That you are confused.
That you haven't shown that size_t is defined in stdlib.h
instead of in another header file included by stdlib.h.
That your remarks about the ANSI/ISO standard
are irrelevant to my assertion that
"size_t is defined in a header file included by stdlib.h".
That you refusal to publish the diagnostic messages
from you compiler for the above code leads me to suspect
that you already know that size_t is *not* defined in stdlib.h
but in another header file included by stdlib.h Why are you so dissembling?
Why are you afraid of this simple experiment?

Your reasoning is inane. However, I'll oblige:

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

size_t size = 32;

$ gcc -W -Wall -ansi -pedantic test.c
In file included from test.c:2:
/usr/include/stdlib.h:106: warning: parameter names (without types) in function declaration
/usr/include/stdlib.h:108: warning: parameter names (without types) in function declaration
/usr/include/stdlib.h:109: parse error before `size_t'
/usr/include/stdlib.h:118: parse error before `size_t'
/usr/include/stdlib.h:119: parse error before `)'
/usr/include/stdlib.h:120: parse error before `size_t'
/usr/include/stdlib.h:121: parse error before `)'
/usr/include/stdlib.h:128: parse error before `size_t'
/usr/include/stdlib.h:129: parse error before `size_t'
/usr/include/stdlib.h:132: parse error before `mbstowcs'
/usr/include/stdlib.h:132: parse error before `size_t'
/usr/include/stdlib.h:132: ANSI C forbids data definition with no type or storage class
/usr/include/stdlib.h:133: parse error before `wcstombs'
/usr/include/stdlib.h:133: parse error before `size_t'
/usr/include/stdlib.h:133: ANSI C forbids data definition with no type or storage class
test.c:4: parse error before `size'
test.c:4: warning: type defaults to `int' in declaration of `size'
test.c:4: ANSI C forbids data definition with no type or storage class
$

Happy?

Alex

[E. Robert Tisdale]

Alan Balmer wrote:

E. Robert Tisdale wrote:

Section 7.1, paragraph 1, first bullet.
True but irrelevant.

At long last,
I have reluctantly come to the conclusion that you are irrelevant
and that time reading your posts is wasted.
You have the honor of being only the second person
I have ever filtered from this newsgroup.

I appreciate it.
You should have done so long ago.
I expect that I will soon have lots of company in your kill file.
Bye, now.

Remember,
you are promising *not* to respond to *any* of my articles.
We are all depending upon you to keep this promise.

[Noah Roberts]

Eric Sosman wrote:

Which part of "undefined behavior" are you having trouble
understanding?

The undefined part of course :P

NR

[E. Robert Tisdale]

Eric Sosman wrote:

"E. Robert Tisdale" wrote:

In a header file included by stdlib.h

This assertion is false in general (although it could be true
for some particular C implementation). The Standard requires
that `#include <stdlib.h>' must define `size_t' (Section 7.20,
paragraph 2), but does not dictate the mechanism by which the
definition is provided. In particular, it does not require
<stdlib.h> to include some other header file, unmentioned in
the Standard. It does not even require that the inclusion of
<stdlib.h> read a file at all; the compiler can simply "know"
what is supposed to happen, and cause it to happen "magically."

That's correct. The standard does *not* specify
whether size_t is defined in stdlib.h itself
or in another header file included by stdlib.h
so the standard is *irrelevant* to the question.
The only thing that may be relevant
is whether or not *any* implementation of the standard
actually defines size_t in stdlib.h itself.
Why is this simple fact so difficult for you to understand?

[E. Robert Tisdale]

Alex wrote:

E. Robert Tisdale wrote:

Alex wrote:

E. Robert Tisdale wrote:
<snip>
you haven't actually shown that size_t gets defined in stdlib.h
Try to compile

#define _SIZE_T
#include <stdlib.h>

size_t size = 32;

with your Sun C compiler and show us the diagnostic message
that it issues.

Unfortunately, I am not at liberty
to define constants with leading underscores in their names.
That naming convention is reserved for the implementation.

What is your point, exactly?

That you are confused.
That you haven't shown that size_t is defined in stdlib.h
instead of in another header file included by stdlib.h.
That your remarks about the ANSI/ISO standard
are irrelevant to my assertion that
"size_t is defined in a header file included by stdlib.h".
That you refusal to publish the diagnostic messages
from you compiler for the above code leads me to suspect
that you already know that size_t is *not* defined in stdlib.h
but in another header file included by stdlib.h

Why are you so dissembling?
Why are you afraid of this simple experiment?

Your reasoning is inane. However, I'll oblige:

$ 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.
Could you type

gcc --version

at the your Solaris prompt and tell us which version?
In file included from test.c:2:
/usr/include/stdlib.h:106: warning: parameter names (without types) in function declaration
/usr/include/stdlib.h:108: warning: parameter names (without types) in function declaration
/usr/include/stdlib.h:109: parse error before `size_t'
/usr/include/stdlib.h:118: parse error before `size_t'
/usr/include/stdlib.h:119: parse error before `)'
/usr/include/stdlib.h:120: parse error before `size_t'
/usr/include/stdlib.h:121: parse error before `)'
/usr/include/stdlib.h:128: parse error before `size_t'
/usr/include/stdlib.h:129: parse error before `size_t'
/usr/include/stdlib.h:132: parse error before `mbstowcs'
/usr/include/stdlib.h:132: parse error before `size_t'
/usr/include/stdlib.h:132: ANSI C forbids data definition with no type or storage class
/usr/include/stdlib.h:133: parse error before `wcstombs'
/usr/include/stdlib.h:133: parse error before `size_t'
/usr/include/stdlib.h:133: ANSI C forbids data definition with no type or storage class
test.c:4: parse error before `size'
test.c:4: warning: type defaults to `int' in declaration of `size'
test.c:4: ANSI C forbids data definition with no type or storage class
$
The stdlib.h distributed with gcc version 3.2
includes stddef.h to define size_t. I get
gcc -Wall -std=c99 -pedantic -c test.c

In file included from test.c:2:
/usr/include/stdlib.h:137: parse error before "__ctype_get_mb_cur_max"
/usr/include/stdlib.h:137: ISO C forbids data definition with no type or
storage class
/usr/include/stdlib.h:554: parse error before "__size"
/usr/include/stdlib.h:556: parse error before "__nmemb"
/usr/include/stdlib.h:565: parse error before "size_t"
/usr/include/stdlib.h:731: parse error before "size_t"
/usr/include/stdlib.h:735: parse error before "size_t"
/usr/include/stdlib.h:822: parse error before "size_t"
/usr/include/stdlib.h:826: parse error before "size_t"
/usr/include/stdlib.h:833: parse error before "mbstowcs"
/usr/include/stdlib.h:834: parse error before "size_t"
/usr/include/stdlib.h:834: ISO C forbids data definition with no type or
storage class
/usr/include/stdlib.h:836: parse error before "wcstombs"
/usr/include/stdlib.h:837: parse error before "size_t"
/usr/include/stdlib.h:838: ISO C forbids data definition with no type or
storage class
test.c:4: parse error before "size"
test.c:4: warning: type defaults to `int' in declaration of `size'
test.c:4: ISO C forbids data definition with no type or storage class

so my experiment doesn't prove that
*your* implementation defines size_t in stdlib.h itself either.

[CBFalconer]

Alex wrote:

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

Alex wrote:

E. Robert Tisdale wrote:

All you need to do to prove my assertion false
is to present *one* example of an implementation
where size_t is defined in stdlib.h and *not*
in some included header file.

If you insist. Solaris 2.6:

I suppose you mean the Sun C compiler
that you got bundled with Solaris 2.6?

Indeed.
/usr/include/stdlib.h:

<...>

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

<...>

I don't mean to quibble but
you haven't actually shown that size_t gets defined in stdlib.h
Try to compile

#define _SIZE_T
#include <stdlib.h>
size_t size = 32;

with your Sun C compiler and show us the diagnostic message
that it issues.

Unfortunately, I am not at liberty to define constants with leading
underscores in their names. That naming convention is reserved for
the implementation.

What is your point, exactly?

_____________________
/| /| | |
||__|| | Please do not |
/ O O\__ | feed the |
/ \ | Trolls |
/ \ \|_____________________|
/ _ \ \ ||
/ |\____\ \ ||
/ | | | |\____/ ||
/ \|_|_|/ | _||
/ / \ |____| ||
/ | | | --|
| | | |____ --|
* _ | |_|_|_| | \-/
*-- _--\ _ \ | ||
/ _ \\ | / `
* / \_ /- | | |
* ___ c_c_c_C/ \C_c_c_c____________

+-------------------+ .:\:\:/:/:.
| PLEASE DO NOT | :.:\:\:/:/:.:
| FEED THE TROLLS | :=.' - - '.=:
| | '=(\ 9 9 /)='
| Thank you, | ( (_) )
| Management | /`-vvv-'\
+-------------------+ / \
| | @@@ / /|,,,,,|\ \
| | @@@ /_// /^\ \\_\
@x@@x@ | | |/ WW( ( ) )WW
\||||/ | | \| __\,,\ /,,/__
\||/ | | | jgs (______Y______)
/\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
================================================== ============

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Richard Heathfield]

E. Robert Tisdale wrote:

The standard does *not* specify
whether size_t is defined in stdlib.h itself
or in another header file included by stdlib.h
so the standard is *irrelevant* to the question.
On the contrary - since the standard doesn't specify it, we should not write
code that relies on it.
The only thing that may be relevant
is whether or not *any* implementation of the standard
actually defines size_t in stdlib.h itself.

No, /that/ is entirely irrelevant.

--
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

[Alex]

E. Robert Tisdale <E.**************@jpl.nasa.gov> 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.
*/

I would use the Sun C compiler for this example if it weren't
for:

$ cc
/usr/ucb/cc: language optional software package not installed
Could you type gcc --version
$ gcc --version
egcs-2.91.60
<snip>
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.
> gcc -Wall -std=c99 -pedantic -c test.c

In file included from test.c:2:
/usr/include/stdlib.h:137: parse error before "__ctype_get_mb_cur_max"
/usr/include/stdlib.h:137: ISO C forbids data definition with no type or
storage class
/usr/include/stdlib.h:554: parse error before "__size"
/usr/include/stdlib.h:556: parse error before "__nmemb"
/usr/include/stdlib.h:565: parse error before "size_t"
/usr/include/stdlib.h:731: parse error before "size_t"
/usr/include/stdlib.h:735: parse error before "size_t"
/usr/include/stdlib.h:822: parse error before "size_t"
/usr/include/stdlib.h:826: parse error before "size_t"
/usr/include/stdlib.h:833: parse error before "mbstowcs"
/usr/include/stdlib.h:834: parse error before "size_t"
/usr/include/stdlib.h:834: ISO C forbids data definition with no type or
storage class
/usr/include/stdlib.h:836: parse error before "wcstombs"
/usr/include/stdlib.h:837: parse error before "size_t"
/usr/include/stdlib.h:838: ISO C forbids data definition with no type or
storage class
test.c:4: parse error before "size"
test.c:4: warning: type defaults to `int' in declaration of `size'
test.c:4: ISO C forbids data definition with no type or storage class

so my experiment doesn't prove that
*your* implementation defines size_t in stdlib.h itself either.

That doesn't surprise me. As I've pointed out before, your
reasoning is inane. What is to prevent the implementation
from defining size_t within stddef.h with a similar preprocessor
conditional block to what I have in my stdlib.h?

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. 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.

Alex

[Dan Pop]

In <3F**************@jpl.nasa.gov> "E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:

Alex wrote:

E. Robert Tisdale wrote:

All you need to do to prove my assertion false
is to present *one* example of an implementation
where size_t is defined in stdlib.h and *not*
in some included header file.

If you insist. Solaris 2.6:

I suppose you mean the Sun C compiler
that you got bundled with Solaris 2.6?

/usr/include/stdlib.h:

<...>

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

<...>

I don't mean to quibble but
you haven't actually shown that size_t gets defined in stdlib.h
Try to compile

#define _SIZE_T
#include <stdlib.h>

size_t size = 32;

with your Sun C compiler and show us the diagnostic message
that it issues. ^^^^^^^

Why did you use the singular?

znsun1:~/tmp 9> uname -a
SunOS znsun1 5.6 Generic_105181-23 sun4u sparc
znsun1:~/tmp 10> which cc
/opt/SUNWspro/bin/cc
znsun1:~/tmp 11> cat test.c
#define _SIZE_T
#include <stdlib.h>

size_t size = 32;
znsun1:~/tmp 12> cc test.c
"/usr/include/stdlib.h", line 106: parameter redeclared: size_t
"/usr/include/stdlib.h", line 106: warning: function prototype parameters must have types
"/usr/include/stdlib.h", line 108: warning: function prototype parameters must have types
"/usr/include/stdlib.h", line 109: syntax error before or at: size_t
"/usr/include/stdlib.h", line 109: warning: undefined or missing type for: size_t
"/usr/include/stdlib.h", line 118: syntax error before or at: size_t
"/usr/include/stdlib.h", line 118: warning: undefined or missing type for: size_t
"/usr/include/stdlib.h", line 119: syntax error before or at: int
"/usr/include/stdlib.h", line 119: warning: undefined or missing type for: int
"/usr/include/stdlib.h", line 119: function cannot return function or array
"/usr/include/stdlib.h", line 119: syntax error before or at: )
"/usr/include/stdlib.h", line 119: warning: syntax error: empty declaration
"/usr/include/stdlib.h", line 120: syntax error before or at: size_t
"/usr/include/stdlib.h", line 120: warning: undefined or missing type for: size_t
"/usr/include/stdlib.h", line 121: syntax error before or at: int
"/usr/include/stdlib.h", line 121: warning: undefined or missing type for: int
"/usr/include/stdlib.h", line 121: function cannot return function or array
"/usr/include/stdlib.h", line 121: syntax error before or at: )
"/usr/include/stdlib.h", line 121: warning: syntax error: empty declaration
"/usr/include/stdlib.h", line 128: syntax error before or at: size_t
"/usr/include/stdlib.h", line 128: warning: undefined or missing type for: size_t
"/usr/include/stdlib.h", line 129: syntax error before or at: size_t
"/usr/include/stdlib.h", line 129: warning: undefined or missing type for: size_t
"/usr/include/stdlib.h", line 132: syntax error before or at: mbstowcs
"/usr/include/stdlib.h", line 132: syntax error before or at: size_t
"/usr/include/stdlib.h", line 132: warning: undefined or missing type for: size_t
"/usr/include/stdlib.h", line 132: warning: old-style declaration or incorrect type for: mbstowcs
"/usr/include/stdlib.h", line 133: syntax error before or at: wcstombs
"/usr/include/stdlib.h", line 133: syntax error before or at: size_t
"/usr/include/stdlib.h", line 133: warning: undefined or missing type for: size_t
"/usr/include/stdlib.h", line 133: warning: old-style declaration or incorrect type for: wcstombs
"/usr/include/stdlib.h", line 175: syntax error before or at: size_t
"/usr/include/stdlib.h", line 175: warning: undefined or missing type for: size_t
"/usr/include/stdlib.h", line 185: warning: function prototype parameters must have types
"/usr/include/stdlib.h", line 194: syntax error before or at: size_t
"/usr/include/stdlib.h", line 194: warning: undefined or missing type for: size_t
"/usr/include/stdlib.h", line 204: parameter redeclared: size_t
"/usr/include/stdlib.h", line 204: warning: function prototype parameters must have types
"test.c", line 4: warning: old-style declaration or incorrect type for: size_t
"test.c", line 4: syntax error before or at: size
"test.c", line 4: warning: old-style declaration or incorrect type for: size
cc: acomp failed for test.c

Which was to be expected: you told <stdlib.h> (and any headers it might
include) that size_t is *already* defined, which was a lie. You know what
it happens when you lie to your implementation, right?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[E. Robert Tisdale]

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

at your Solaris prompt and gcc should show you
the paths that it searched for system header files.

I would use the Sun C compiler for this example if it weren't for:

$ cc
/usr/ucb/cc: language optional software package not installed

Could you type

gcc --version

$ gcc --version
egcs-2.91.60

<snip>

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?

> gcc -Wall -std=c99 -pedantic -c test.c

In file included from test.c:2:
/usr/include/stdlib.h:137: parse error before "__ctype_get_mb_cur_max"
/usr/include/stdlib.h:137: ISO C forbids data definition with no type or
storage class
/usr/include/stdlib.h:554: parse error before "__size"
/usr/include/stdlib.h:556: parse error before "__nmemb"
/usr/include/stdlib.h:565: parse error before "size_t"
/usr/include/stdlib.h:731: parse error before "size_t"
/usr/include/stdlib.h:735: parse error before "size_t"
/usr/include/stdlib.h:822: parse error before "size_t"
/usr/include/stdlib.h:826: parse error before "size_t"
/usr/include/stdlib.h:833: parse error before "mbstowcs"
/usr/include/stdlib.h:834: parse error before "size_t"
/usr/include/stdlib.h:834: ISO C forbids data definition with no type or
storage class
/usr/include/stdlib.h:836: parse error before "wcstombs"
/usr/include/stdlib.h:837: parse error before "size_t"
/usr/include/stdlib.h:838: ISO C forbids data definition with no type or
storage class
test.c:4: parse error before "size"
test.c:4: warning: type defaults to `int' in declaration of `size'
test.c:4: ISO C forbids data definition with no type or storage class

so my experiment doesn't prove that
*your* implementation defines size_t in stdlib.h itself either.

That doesn't surprise me. As I've pointed out before, your
reasoning is inane. What is to prevent the implementation
from defining size_t within stddef.h with a similar preprocessor
conditional block to what I have in my stdlib.h?

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.

This is a "straw man" argument.

http://www.don-lindsay-archive.org/s...nts.html#straw

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.
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. All I'm saying is that you haven't shown that yet.
I've been trying my best to help you but your evidence, so far,
is unconvincing.
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.

[E. Robert Tisdale]

CBFalconer wrote:

_____________________
/| /| | |
||__|| | Please do not |
/ O O\__ | feed the |
/ \ | Trolls |
/ \ \|_____________________|
/ _ \ \ ||
/ |\____\ \ ||
/ | | | |\____/ ||
/ \|_|_|/ | _||
/ / \ |____| ||
/ | | | --|
| | | |____ --|
* _ | |_|_|_| | \-/
*-- _--\ _ \ | ||
/ _ \\ | / `
* / \_ /- | | |
* ___ c_c_c_C/ \C_c_c_c____________

+-------------------+ .:\:\:/:/:.
| PLEASE DO NOT | :.:\:\:/:/:.:
| FEED THE TROLLS | :=.' - - '.=:
| | '=(\ 9 9 /)='
| Thank you, | ( (_) )
| Management | /`-vvv-'\
+-------------------+ / \
| | @@@ / /|,,,,,|\ \
| | @@@ /_// /^\ \\_\
@x@@x@ | | |/ WW( ( ) )WW
\||||/ | | \| __\,,\ /,,/__
\||/ | | | jgs (______Y______)
/\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
================================================== ============

Evidently, your definition of a troll is anyone who disagrees with you.
For you, it's just another epithet that you hurl at an opponent.
You resort to ad hominem attacks

http://www.don-lindsay-archive.org/s...arguments.html

when you have lost an argument
and have no valid argument to contribute to the discussion.
The use of such an obviously fallacious argument shows contempt
for subscribers if you really expect to sway them with it.
Or do you honestly believe that you are making a valid argument?