469,927 Members | 1,904 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,927 developers. It's quick & easy.

defining the size_t type

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

Oct 25 '07 #1
8 1626
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.

Oct 25 '07 #2
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
Oct 25 '07 #3
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
Oct 25 '07 #4
In article <11**********************@57g2000hsv.googlegroups. 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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Oct 25 '07 #5
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_Keith) 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"
Oct 25 '07 #6
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
Oct 27 '07 #7
Eric Sosman <es*****@ieee-dot-org.invalidwrites:
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_Keith) 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"
Oct 27 '07 #8
>On Oct 28, 12:05 am, Chris Torek <nos...@torek.netwrote:
>>... 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**********************************@i12g2000prf. googlegroups.com>,
somenath <so*********@gmail.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 (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Dec 5 '07 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

16 posts views Thread by Raj Kotaru | last post: by
26 posts views Thread by Adam Warner | last post: by
17 posts views Thread by candy_init | last post: by
10 posts views Thread by nambissan.nisha | last post: by
5 posts views Thread by edware | last post: by
39 posts views Thread by Mark Odell | last post: by
6 posts views Thread by Wayne Shu | last post: by
5 posts views Thread by krzysztof.konopko | last post: by
89 posts views Thread by Tubular Technician | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.