Header include order

[E. Robert Tisdale]

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]

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


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.

 

[Alex]

Alex wrote:

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

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]

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.

 

[E. Robert Tisdale]

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]

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]

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.

 

[E. Robert Tisdale]

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.

 

[Eric Sosman]

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

 

[Alex]

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

 

[Noah Roberts]

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

The undefined part of course

NR

 

[E. Robert Tisdale]

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]

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]

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______)
/\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
==============================================================

 

[Richard Heathfield]

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.

 

[Dan Pop]

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


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

 

[Alex]

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

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.

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

 

[E. Robert Tisdale]

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



$ gcc --version
egcs-2.91.60



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

Did I say differently?

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/skeptic/arguments.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]

_____________________
/| /| | |
||__|| | 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/skeptic/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?

 

[Alex]

Alex wrote:

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.

Did I say differently?

Yes. I said:

You said:

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!

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.

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