defining the size_t type

[lubomir dobsik]

hi, i have seen an interesting thing:

#if sizeof((char*)0 - (char*)0) == sizeof(unsigned int)
typedef unsigned int size_t;
#elif sizeof((char*)0 - (char*)0) == sizeof(unsigned long)
typedef unsigned long size_t;
#elif sizeof((char*)0 - (char*)0) == sizeof(unsigned long long)
typedef unsigned long long size_t;
#endif

is this way of defining the size_t portable?

cheers, lubos

[santosh]

lubomir dobsik wrote:

hi, i have seen an interesting thing:

#if sizeof((char*)0 - (char*)0) == sizeof(unsigned int)
typedef unsigned int size_t;
#elif sizeof((char*)0 - (char*)0) == sizeof(unsigned long)
typedef unsigned long size_t;
#elif sizeof((char*)0 - (char*)0) == sizeof(unsigned long long)
typedef unsigned long long size_t;
#endif

is this way of defining the size_t portable?

As far as I know sizeof cannot be used with the conditional compilation
directives. This may be a compiler specific extension.

[Eric Sosman]

lubomir dobsik wrote On 10/25/07 10:42,:

hi, i have seen an interesting thing:

#if sizeof((char*)0 - (char*)0) == sizeof(unsigned int)
typedef unsigned int size_t;
#elif sizeof((char*)0 - (char*)0) == sizeof(unsigned long)
typedef unsigned long size_t;
#elif sizeof((char*)0 - (char*)0) == sizeof(unsigned long long)
typedef unsigned long long size_t;
#endif

is this way of defining the size_t portable?

No.

One problem is that conditional compilation occurs
before types exist, so casts don't work and `sizeof'
cannot be evaluated. (At this stage of compilation,
`sizeof' and `char' and `unsigned' and `int' and `long'
are not even recognized as keywords.)

Another problem is that size_t might be something
other than the three types you test for.

Still another problem is that sizes do not determine
types. If `sizeof(size_t) == sizeof(unsigned int)' you
cannot conclude that `size_t' and `unsigned int' are the
same, just as you cannot conclude that `int' and `float'
are the same even if their sizes agree.

Even yet still another additional problem is that
you're trying to infer the type of `size_t' by examining
the size of `ptrdiff_t', a different type altogether.

Moreover still another additional accompanying extra
problem is that the attempt to define `size_t' is illegal
in any module that includes any of the several Standard
headers that define it for themselves.

But the biggest problem of all is that it's stupid.
Use a header; that's what they're for.

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

[Ben Pfaff]

lubomir dobsik <l.******@gmail .comwrites:

is this way of defining the size_t portable?

No.

Here is a portable way:
#include <stddef.h>
--
Ben Pfaff
http://benpfaff.org

[Richard Tobin]

In article <11************ **********@57g2 000hsv.googlegr oups.com>,
lubomir dobsik <l.******@gmail .comwrote:

>#if sizeof((char*)0 - (char*)0) == sizeof(unsigned int)

The difference between two pointers is of type ptrdiff_t, not size_t.
You could use sizeof(sizeof(0 )), if it weren't for the other problems
in your code.

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Keith Thompson]

lubomir dobsik <l.******@gmail .comwrites:

hi, i have seen an interesting thing:

#if sizeof((char*)0 - (char*)0) == sizeof(unsigned int)
typedef unsigned int size_t;
#elif sizeof((char*)0 - (char*)0) == sizeof(unsigned long)
typedef unsigned long size_t;
#elif sizeof((char*)0 - (char*)0) == sizeof(unsigned long long)
typedef unsigned long long size_t;
#endif

is this way of defining the size_t portable?

No, for all the reasons that have already been mentioned. Where did
you see it?

If you're not writing an implementation, then you don't need to define
size_t; the implementation will do it for you.

If you are writing an implementation, you don't need a portable
definition. You can use whatever compiler-specific magic you like, as
long as it produces the correct results. If you happen to know that
your preprocessor handles sizeof (it's not required to, and I'm not
certain it's allowed to), then you can take advantage of that, though
as Richard Tobin mentions, ``(sizeof sizeof 0)'' would make more
sense.

The only context where the above would make sense is if you're writing
a <stddef.hto be used with several different implementations (say,
the same compiler on several different platforms). But even then,
there are likely to be cleaner ways to do it.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Eric Sosman]

Chris Torek wrote:

[... concerning sizeof, etc., in #if directives ...]
At this point in translation, pp-tokens that are not otherwise
"special" -- by which I mean pp-tokens that will map to C keywords
or ordinary identifiers -- are to be treated as if they were the
integer constant zero. [...]

Are you sure pp-tokens that will eventually become keywords
are treated differently than others? It's my understanding that,
for example,

#if return == while

is equivalent to

#if 0 == 0

5.1.1.2 says that preprocessing directives are handled in phase 4
before pp-tokens become tokens in phase 7. 6.4 describes the
keywords as a subset of the tokens, and 6.4p3 includes "keywords"
in the list of possible tokens but not in the list of pp-tokens.

--
Eric Sosman
es*****@ieee-dot-org.invalid

[Keith Thompson]

Eric Sosman <es*****@ieee-dot-org.invalidwrit es:

Chris Torek wrote:

>[... concerning sizeof, etc., in #if directives ...]
At this point in translation, pp-tokens that are not otherwise
"special" -- by which I mean pp-tokens that will map to C keywords
or ordinary identifiers -- are to be treated as if they were the
integer constant zero. [...]

Are you sure pp-tokens that will eventually become keywords
are treated differently than others?

[...]

He didn't say they were. He referred to "pp-tokens that will map to C
keywords or ordinary identifiers".

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Chris Torek]

>On Oct 28, 12:05 am, Chris Torek <nos...@torek.n etwrote:

>>... the line:
#if sizeof(int) == 2
must be treated as if it read:
#if 0(0) == 2
... [so that] the compiler is required to emit "at least one diagnostic".

In article <f0************ *************** *******@i12g200 0prf.googlegrou ps.com>,
somenath <so*********@gm ail.comwrote:

>Sorry if I have misunderstood what you are trying to convey.

I think you have:

>But
#if sizeof(int) == 2
#endif
Will not be compiled.
I think because as it is converted to #if 0(0) == 2

The compiler is throwing eror
foo.c:1:11: missing binary operator before '('

This is your "at least one diagnostic".

If you have Frobozz C, *that* *particular* compiler -- which prints
a different diagnostic -- then goes on to "re-inspect" the original
line, and do something different.

No C compiler is *required* to work the way Frobozz C does, so if
you would ever like to use any *other* compiler, you should avoid
depending on the special features offered by Frobozz C.

This is true of other compilers as well. If you make use of various
gcc-specific features, you will be unable to use lcc-win32 to
compile your code; if you make use of certain lcc-win32-specific
features, you will be unable to use gcc to compile your code; and
so on. Thus, *any* time you make use of *any* compiler's special
features, you should be aware of the *cost* of your actions, as
well as the (presumed) benefit (i.e., getting the use of whatever
the "special feature" does for you).

In other words, I am not saying "do not use qfloat (lcc-win32) or
&&label (gcc) or &42 (VMS) or #pragma dwim (Frobozz)", but rather,
"be aware of BOTH the cost AND the benefit of your actions".
--
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://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.