Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > defining the size_t type

Reply
Thread Tools

defining the size_t type

 
 
lubomir dobsik
Guest
Posts: n/a
 
      10-29-2007
On Oct 25, 3:42 pm, lubomir dobsik <(E-Mail Removed)> 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?
>
> cheers, lubos



thanks all for the reactions. the snippet comes from the stddef.h of a
particular compiler. i admit that under these circumstances my
original question doesnt make much sense. anyway, i posted this
because i was curious to see your comments on this rather than getting
a yes/no answer. thanks again, lubos

 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      10-29-2007
lubomir dobsik <(E-Mail Removed)> writes:
> On Oct 25, 3:42 pm, lubomir dobsik <(E-Mail Removed)> wrote:
>> #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?

>
> thanks all for the reactions. the snippet comes from the stddef.h of a
> particular compiler. i admit that under these circumstances my
> original question doesnt make much sense. anyway, i posted this
> because i was curious to see your comments on this rather than getting
> a yes/no answer. thanks again, lubos


Interesting. Which compiler is it? I wonder whether the compiler
actually recognizes "sizeof" in preprocessor directives, or perhaps
the author of stddef.h just *thought* it did.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <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"
 
Reply With Quote
 
 
 
 
lubomir dobsik
Guest
Posts: n/a
 
      12-04-2007
On Oct 29, 7:48 pm, Keith Thompson <(E-Mail Removed)> wrote:
> lubomir dobsik <(E-Mail Removed)> writes:
> > On Oct 25, 3:42 pm, lubomir dobsik <(E-Mail Removed)> wrote:
> >> #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?

>
> > thanks all for the reactions. the snippet comes from the stddef.h of a
> > particular compiler. i admit that under these circumstances my
> > original question doesnt make much sense. anyway, i posted this
> > because i was curious to see your comments on this rather than getting
> > a yes/no answer. thanks again, lubos

>
> Interesting. Which compiler is it? I wonder whether the compiler
> actually recognizes "sizeof" in preprocessor directives, or perhaps
> the author of stddef.h just *thought* it did.
>
> --
> Keith Thompson (The_Other_Keith) (E-Mail Removed) <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"


it was IAR, and no, it doesn't recognize the sizof during
preprocessing - the #if directive with the expression containing
sizeof is nested inside of another #if directive whose expression
apparently always evaluates to false.
 
Reply With Quote
 
somenath
Guest
Posts: n/a
 
      12-05-2007
On Oct 28, 12:05 am, Chris Torek <(E-Mail Removed)> wrote:
> In article <(E-Mail Removed)>
> Keith Thompson <(E-Mail Removed)> wrote:
>
> >If you are writing an implementation, you don't need a portable
> >definition [for size_t]. 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 ...

>
> It is "allowed to" in certain circumstances.
>
> 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. Hence:
>
> /* do not #define XYZ */
>
> #define FOUR 4
> #if FOUR == XYZ
> # error "this #error must not fire"
> #endif
>
> #if XYZ == 0
> # error "this #error must fire"
> #endif
>
> Because of this rule, the line:
>
> #if sizeof(int) == 2
>
> must be treated as if it read:
>
> #if 0(0) == 2
>


Sorry if I have misunderstood what you are trying to convey.
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 '('


> (assuming, of course, you have not "#define"d sizeof and/or int).
> Because this is syntactically invalid, the compiler is required
> to emit "at least one diagnostic".
>
> Once the "at least one diagnostic" has been produced, however, the
> compiler can then "look back" at the original text, discover the
> sizeof and int, and compute the size of an int. So you might get
> the "diagnostic":
>
> foo.c:12: congratulations on your commitment to the Frobozz compiler!
>
> which thanks you for making sure your code will not port to other
> C compilers, so that you will have to continue paying the $10,000-
> per-hour fee to use the Frobozz-branded compiler.
>
> >The only context where the above would make sense is if you're writing
> >a <stddef.h> to 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.

>
> Indeed -- for instance, the compiler can pre-"#define" various
> names that live in the implementor's name space (i.e., the one you,
> the implementor, are allowed to use because your customer, the C
> programmer, is *not* allowed to use it). Thus:
>
> #if __int_size == 2
> ... code that depends on sizeof(int) == 2 ...
> #elif __int__size == 4
> ... code that depends on sizeof(int) == 4 ...
> #else
> #error "oops: internal implementation error with __int_size"
> #endif
>
> Note that we can construct cases where the "sizeof" keyword must
> be replaced, during "#if" arithmetic, with the integer constant
> zero, and the result is still syntactically valid:
>
> #if sizeof + 0 != 0
> # error "this compiler is broken"
> #endif
>
> This makes implementing Frobozz C correctly quite tricky.


 
Reply With Quote
 
Chris Torek
Guest
Posts: n/a
 
      12-05-2007
>On Oct 28, 12:05 am, Chris Torek <(E-Mail Removed)> wrote:
>>... 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 <(E-Mail Removed)>,
somenath <(E-Mail Removed)> wrote:
>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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Defining iterator type through container object type Urs Thuermann C++ 6 11-04-2011 02:10 PM
reinterpret_cast<std::size_t>(p) and reinterpret_cast<std::size_t&>() Alex Vinokur C++ 1 02-06-2011 07:48 AM
Casting from const pair<const unsigned char*, size_t>* to constpair<unsigned char*, size_t>* Alex Vinokur C++ 9 10-13-2008 05:05 PM
defining or not defining destructors johny smith C++ 8 07-02-2004 08:51 AM
How to use maximum size of size_t type ? javadesigner C Programming 11 01-22-2004 05:03 PM



Advertisments