Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

size_t

3 views
Skip to first unread message

George

unread,
Oct 10, 2008, 4:07:00 AM10/10/08
to
Hello everyone,


1.

I am developing for both x86 and x64. I stop mouse on size_t in the code,
and "typedef unsigned int size_t" is always displayed. I think it is not
correct for x64. Since x64 size_t is 64-bit and unsigned int on x64 is
32-bit. So, the first question is how to let mouse display the correct
typedef?

2.

But when I select size_t and click go to Definition/Declaration, but always
failed. Where are they defined?


thanks in advance,
George

Doug Harrison [MVP]

unread,
Oct 10, 2008, 11:19:54 AM10/10/08
to
On Fri, 10 Oct 2008 01:07:00 -0700, George
<Geo...@discussions.microsoft.com> wrote:

>Hello everyone,
>
>
>1.
>
>I am developing for both x86 and x64. I stop mouse on size_t in the code,
>and "typedef unsigned int size_t" is always displayed. I think it is not
>correct for x64. Since x64 size_t is 64-bit and unsigned int on x64 is
>32-bit. So, the first question is how to let mouse display the correct
>typedef?

You're not going to find some IDE setting called "Display correct typedefs
in tooltips." If you want to report the bug, you can do so here:

http://connect.microsoft.com/feedback/default.aspx?SiteID=210

>2.
>
>But when I select size_t and click go to Definition/Declaration, but always
>failed. Where are they defined?

Try to compile this fragment:

size_t x;

Last time I checked, it will compile, because VC makes size_t an intrinsic
type. This is a (minor) deviation from the standard, which requires size_t
to be a typedef defined in various header files.

--
Doug Harrison
Visual C++ MVP

Bo Persson

unread,
Oct 10, 2008, 12:03:40 PM10/10/08
to

It is defined in the required headers (which George perhaps forgot to
include? :-), but as it is also the return type of the sizeof
operator, the compiler will have to know about it anyway. That's a
quirk of the language!


Bo Persson


Tim Roberts

unread,
Oct 11, 2008, 12:42:27 AM10/11/08
to

Windows comes with an excellent search tool
You must learn to use the search tools yourself.
findstr typedef.*size_t *.h

You'll find this in crtdefs.h:

#ifndef _SIZE_T_DEFINED
#ifdef _WIN64
typedef unsigned __int64 size_t;
#else
typedef _W64 unsigned int size_t;
#endif
#define _SIZE_T_DEFINED
#endif
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

George

unread,
Oct 11, 2008, 5:11:01 AM10/11/08
to
Thanks Doug,


1. Do you think it is an IDE bug to prevent mouse to show the correct
definition and also go to the wrong definition of 32-bit when developing
64-bit application?

2. I have tried without any header files, size_t x will compile. It proves
size_t is a built-in type? But I searched MSDN never mentions this and never
describes size_t is for 32-bit for x86 and 64-bit for x64.


regards,
George

George

unread,
Oct 11, 2008, 5:14:00 AM10/11/08
to
Hi Tim,


How do you prove size_t is using definitions in crtdefs.h? I have tried
without any header files included, size_t x could compile. Any comments?


regards,
George

George

unread,
Oct 11, 2008, 5:25:01 AM10/11/08
to
Hi Bo Persson,


I am confused about your comments. Do you mean we need include some header
file to use size_t or not? From testing, seems we do not need to include any
header file in order to use size_t.

My test environment, VC 2008.


regards,
George

Bo Persson

unread,
Oct 11, 2008, 5:34:18 AM10/11/08
to
George wrote:
> Hi Bo Persson,
>
>
> I am confused about your comments. Do you mean we need include some
> header file to use size_t or not? From testing, seems we do not
> need to include any header file in order to use size_t.

We need to include a header to get access to size_t, because it is a
typedef.

>
> My test environment, VC 2008.

VC2008 knows about size_t even without a header, because the compiler
uses the type itself. When you use it, you should include the
appropriate header.


Bo Persson

George

unread,
Oct 11, 2008, 6:21:00 AM10/11/08
to
Thanks Bo Persson,


I understand your point is size_t is actually defined in some header, not
built in type, correct?

If so, which header file defines it? I actually find a couple of definitions
when do a search for size_t typedef.


regards,
George

Bo Persson

unread,
Oct 11, 2008, 7:31:04 AM10/11/08
to

That's a remnant from the C language. In C, one library header is not
allowed to include any other, so some things like size_t and NULL are
defined several times.

Just pick one!


Bo Persson


George

unread,
Oct 11, 2008, 8:01:01 AM10/11/08
to
Thanks Bo Persson,


1.

> That's a remnant from the C language. In C, one library header is not
> allowed to include any other, so some things like size_t and NULL are
> defined several times.

I am not quite sure what do you mean library header? .h file or? Could you
show me a sample which means "one library header is not allowed to include
any other" please?

2.

It is fine if there is multiple definitions because of the limitation of C
itself as you mentioned, but how to find which definition is the one I am
currently using?


regards,
George

Bo Persson

unread,
Oct 11, 2008, 10:04:41 AM10/11/08
to
George wrote:
> Thanks Bo Persson,
>
>
> 1.
>
>> That's a remnant from the C language. In C, one library header is
>> not allowed to include any other, so some things like size_t and
>> NULL are defined several times.
>
> I am not quite sure what do you mean library header? .h file or?

Yes, standard .h files provided with the C compiler.


> Could you show me a sample which means "one library header is not
> allowed to include any other" please?
>
> 2.
>
> It is fine if there is multiple definitions because of the
> limitation of C itself as you mentioned, but how to find which
> definition is the one I am currently using?

They are required to be identical, so you have to worry. In C
"stddef.h" is a good choice to standard typedefs, like size_t or NULL.
In C++ you could use <cstddef> instead.

If you use Visual Studio, just type size_t and press F1. The help page
will tell you.


Bo Persson


Bo Persson

unread,
Oct 11, 2008, 3:48:08 PM10/11/08
to
Bo Persson wrote:
> George wrote:
>> Thanks Bo Persson,
>>
>>
>> 1.
>>
>>> That's a remnant from the C language. In C, one library header is
>>> not allowed to include any other, so some things like size_t and
>>> NULL are defined several times.
>>
>> I am not quite sure what do you mean library header? .h file or?
>
> Yes, standard .h files provided with the C compiler.
>
>
>> Could you show me a sample which means "one library header is not
>> allowed to include any other" please?
>>
>> 2.
>>
>> It is fine if there is multiple definitions because of the
>> limitation of C itself as you mentioned, but how to find which
>> definition is the one I am currently using?
>
> They are required to be identical, so you have to worry. In C

or you rather *don't* have to worry. :-)

Doug Harrison [MVP]

unread,
Oct 12, 2008, 1:53:07 PM10/12/08
to
On Sat, 11 Oct 2008 02:11:01 -0700, George
<Geo...@discussions.microsoft.com> wrote:

>Thanks Doug,
>
>
>1. Do you think it is an IDE bug to prevent mouse to show the correct
>definition and also go to the wrong definition of 32-bit when developing
>64-bit application?

Yeah, I think it's a bug. A good hint was contained in what I originally
told you, namely, "If you want to report the bug..."

>>You're not going to find some IDE setting called "Display correct typedefs
>>in tooltips." If you want to report the bug, you can do so here:

>>http://connect.microsoft.com/feedback/default.aspx?SiteID=210

>2. I have tried without any header files, size_t x will compile. It proves

>size_t is a built-in type?

Again, the answer to your question may be found in what I originally told
you, namely:

>>Try to compile this fragment:
>>
>>size_t x;
>>
>>Last time I checked, it will compile, because VC makes size_t an intrinsic
>>type. This is a (minor) deviation from the standard, which requires size_t
>>to be a typedef defined in various header files.
>

>But I searched MSDN never mentions this

MSDN doesn't mention a lot of things.

>and never describes size_t is for 32-bit for x86 and 64-bit for x64.

But I'm pretty sure it describes size_t WRT x86 and x64. If it doesn't,
well, you can report the documentation bug using the link I gave you in my
first message.

Tim Roberts

unread,
Oct 13, 2008, 12:19:41 AM10/13/08
to
"Bo Persson" <b...@gmb.dk> wrote:
>
>That's a remnant from the C language. In C, one library header is not
>allowed to include any other,

What? You are one of the people whose posts I hesitate to challenge, but I
don't understand where that sentence came from. To my knowledge, that
restriction has NEVER been part of the C language, and I have never seen
that sentence in writing before. Are you suggesting this was a policy goal
in the ISO standard?

Tim Roberts

unread,
Oct 13, 2008, 12:22:31 AM10/13/08
to
George <Geo...@discussions.microsoft.com> wrote:
>
>How do you prove size_t is using definitions in crtdefs.h? I have tried
>without any header files included, size_t x could compile. Any comments?

I don't need to prove it. Doug and Bo gave you an excellent analysis of
why this happens. However, IF the crtdefs.h definition was different from
what the compiler had built-in, there would be a compile-time error.

Bo Persson

unread,
Oct 13, 2008, 1:33:04 PM10/13/08
to
Tim Roberts wrote:
> "Bo Persson" <b...@gmb.dk> wrote:
>>
>> That's a remnant from the C language. In C, one library header is
>> not allowed to include any other,
>
> What? You are one of the people whose posts I hesitate to
> challenge, but I don't understand where that sentence came from.
> To my knowledge, that restriction has NEVER been part of the C
> language, and I have never seen that sentence in writing before.
> Are you suggesting this was a policy goal in the ISO standard?

From what I understand, this follows from the requirements of "7.1.3
Reserved identifiers" of the C standard (C99).

One of the bullets says:

"Each identifier with file scope listed in any of the following
subclauses (including the future library directions) is reserved for
use as a macro name and as an identifier with file scope in the same
name space if any of its associated headers is included."

So if you don't include a header, its names are not reserved. This
would break if standard headers included each other.

Bo Persson


George

unread,
Oct 14, 2008, 9:25:01 AM10/14/08
to
Thanks Bo Persson,


1.

> >> That's a remnant from the C language. In C, one library header is
> >> not allowed to include any other, so some things like size_t and
> >> NULL are defined several times.
> >
> > I am not quite sure what do you mean library header? .h file or?
>
> Yes, standard .h files provided with the C compiler.

Confused. Do you mean in C standard header file design, like memory.h, it
does not include any other files? If yes, I doubt it since I found it
memory.h, it includes other files. If my understanding is wrong, could you
clarify what do you mean please? :-)

2.



> If you use Visual Studio, just type size_t and press F1. The help page
> will tell you.

Thanks. I find it out.


regards,
George

George

unread,
Oct 14, 2008, 9:27:01 AM10/14/08
to
Thanks Bo Persson!


Today, I have made more experiment, which is, enable the "Generate
Preprocessed Files" of VC, but the output is quite surprising. Any ideas?

#line 1 "d:\\visual studio 2008\\projects\\testsizet1\\testsizet1\\main.cpp"

#include <wnidows.h>

int main()
{
size_t x;

return 0;
}


regards,
George

George

unread,
Oct 14, 2008, 9:29:02 AM10/14/08
to
Hi Bo Persson,


"Each identifier with file scope listed in any of the following
subclauses (including the future library directions) is reserved for
use as a macro name and as an identifier with file scope in the same

name space if any of its associated headers is included." -- I read it a
couple of time, but very confused. Could you provide a sample to show what
does it mean or point me to some samples please? :-)


regards,
George

George

unread,
Oct 14, 2008, 9:31:01 AM10/14/08
to
Hi Tim,


> What? You are one of the people whose posts I hesitate to challenge, but I
> don't understand where that sentence came from. To my knowledge, that
> restriction has NEVER been part of the C language, and I have never seen
> that sentence in writing before. Are you suggesting this was a policy goal
> in the ISO standard?

I have checked C standard library header file, like memory.h, it does
include other header files. So, I doubt the above points. Any comments?


regards,
George

George

unread,
Oct 14, 2008, 9:33:01 AM10/14/08
to
Thanks Doug,


> But I'm pretty sure it describes size_t WRT x86 and x64. If it doesn't,
> well, you can report the documentation bug using the link I gave you in my
> first message.

WRT is short for?


regards,
George

George

unread,
Oct 14, 2008, 9:34:15 AM10/14/08
to
Thanks Tim,


> why this happens. However, IF the crtdefs.h definition was different from
> what the compiler had built-in

Your above statement makes me confused. Do you mean size_t is defined in
crtdefs.h or a built-in type? Could you clarify your point please? :-)


regards,
George

Bo Persson

unread,
Oct 14, 2008, 12:40:41 PM10/14/08
to
George wrote:
> Thanks Bo Persson,
>
>
> 1.
>
>>>> That's a remnant from the C language. In C, one library header is
>>>> not allowed to include any other, so some things like size_t and
>>>> NULL are defined several times.
>>>
>>> I am not quite sure what do you mean library header? .h file or?
>>
>> Yes, standard .h files provided with the C compiler.
>
> Confused. Do you mean in C standard header file design, like
> memory.h, it does not include any other files? If yes, I doubt it
> since I found it memory.h, it includes other files. If my
> understanding is wrong, could you clarify what do you mean please?
> :-)

I didn't say that it cannot include other files, I said that it cannot
include other standard headers. :-)


For example, if this is legal in a .c file:


#include <memory.h>

void printf()
{ int x = 5; }


because printf isn't reserved until I include <stdio.h>. This means
that <memory.h> cannot include <stdio.h>, or vice versa.

That <memory.h> includes a file <crtdefs.h> is an implementation
detail. It is not a standard header, and it only contains names
starting with underscore+uppercase or a double underscore. These names
are always reserved to the implementation, so I cannot use these
anyway.


The rules about reserved names goes all the way back to the earliest
C, that didn't always use headers, and didn't require function
protoypes either. The dark ages!

If you want the language to be backwards compatible, you cannot change
these rules.


Bo Persson

Bo Persson

unread,
Oct 14, 2008, 12:43:24 PM10/14/08
to
Bo Persson wrote:
> George wrote:
>> Thanks Bo Persson,
>>
>>
>> 1.
>>
>>>>> That's a remnant from the C language. In C, one library header
>>>>> is not allowed to include any other, so some things like size_t
>>>>> and NULL are defined several times.
>>>>
>>>> I am not quite sure what do you mean library header? .h file or?
>>>
>>> Yes, standard .h files provided with the C compiler.
>>
>> Confused. Do you mean in C standard header file design, like
>> memory.h, it does not include any other files? If yes, I doubt it
>> since I found it memory.h, it includes other files. If my
>> understanding is wrong, could you clarify what do you mean please?
>> :-)
>
> I didn't say that it cannot include other files, I said that it
> cannot include other standard headers. :-)
>
>
> For example, if this is legal in a .c file:

Sorry, skip the 'if' here. This IS legal in a .c file!

Doug Harrison [MVP]

unread,
Oct 14, 2008, 1:51:37 PM10/14/08
to
On Tue, 14 Oct 2008 06:33:01 -0700, George
<Geo...@discussions.microsoft.com> wrote:

>WRT is short for?

Try googling "define WRT" (minus the quotes).

Tim Roberts

unread,
Oct 15, 2008, 1:10:34 AM10/15/08
to
George <Geo...@discussions.microsoft.com> wrote:
>
>Today, I have made more experiment, which is, enable the "Generate
>Preprocessed Files" of VC, but the output is quite surprising. Any ideas?
>
>#line 1 "d:\\visual studio 2008\\projects\\testsizet1\\testsizet1\\main.cpp"
>
>#include <wnidows.h>
>
>int main()
>{
> size_t x;
>
> return 0;
>}

Why is this surprising? You have specified an include file that does not
exist, so it cannot be expanded (NB: the name is misspelled).

The real <windows.h> expands to about a quarter million lines of code.

Tim Roberts

unread,
Oct 15, 2008, 1:18:45 AM10/15/08
to

The paragraph Bo quoted is from the 1999 C Standard. Microsoft currently
implements the 1990 C Standard.

I'm not yet convinced I truly believe that interpretation. I have to go do
some more research.

However, George, please allow me to give you a little advice. This is a
very picky point that is of interest only to people who are writing the
standards and building compilers. It has no implications for the ordinary
programmer, and I suggest you move on to another topic.

Tim Roberts

unread,
Oct 15, 2008, 1:20:28 AM10/15/08
to

It shouldn't make you confused. I'm merely summarizing what was said
earlier in the thread. size_t is defined in <crtdefs.h>, as the standard
requires. However, for somewhat picky technical reasons, it is also a
built-in type.

Nothing more complicated than that.

George

unread,
Oct 17, 2008, 10:55:02 AM10/17/08
to

George

unread,
Oct 17, 2008, 11:01:01 AM10/17/08
to
Thanks Bo Persson,


1.

Do you know why standard C header file can not include other standard C
header file? What is the root reason behind this rule, e.g. this rule could
help us to achieve some benefits?

2.

For a header file, in which rule could you decide whether it is standard
header file or not?


regards,
George

George

unread,
Oct 17, 2008, 11:15:01 AM10/17/08
to
Thanks for your advice, Tim!


My point is, I think the people who writes the standard is the people who is
most experienced. The decision and reason they made must be of good reason
for us to learn.

So, I am looking forward to your reply why standard header file is not
allowed to include other standard files. I am also looking forward to seeing
your analysis for the ideas behind the decision, and to see whether such
great ideas could improve our daily coding work. :-)


regards,
George

George

unread,
Oct 17, 2008, 11:17:01 AM10/17/08
to
Hi Doug,


There are various definitions. Have you tried to search "define WRT" from
Google? :-)


have a good weekend,
George

George

unread,
Oct 17, 2008, 11:20:01 AM10/17/08
to
Thanks Tim,


Looks like size_t is quite special thing and in our current theory we can
not explain gracefully. Right? :-)

I mean our theory is,

- built-in type does not need to include any files;
- we trust MSDN document which mentioned size_t is defined in crtdef.h.


regards,
George

Bo Persson

unread,
Oct 17, 2008, 12:01:09 PM10/17/08
to
George wrote:
> Thanks Bo Persson,
>
>
> 1.
>
> Do you know why standard C header file can not include other
> standard C header file? What is the root reason behind this rule,
> e.g. this rule could help us to achieve some benefits?

There is no benefit except backward compatibility with ancient,
pre-standard C. Initially there was no library and no headers, so you
could use any names in your program.

>
> 2.
>
> For a header file, in which rule could you decide whether it is
> standard header file or not?

I look in the standard. :-)

Right after the quote I gave from chapter 7.1, there are lots of 7.x
sections each describing one header file and the names declared in it.


Bo Persson


Doug Harrison [MVP]

unread,
Oct 17, 2008, 3:30:51 PM10/17/08
to
On Fri, 17 Oct 2008 08:17:01 -0700, George
<Geo...@discussions.microsoft.com> wrote:

>There are various definitions. Have you tried to search "define WRT" from
>Google? :-)

When in doubt, go with the first one, taking into account the context in
which the acronym was used. It isn't hard to figure out.

Doug Harrison [MVP]

unread,
Oct 17, 2008, 3:32:45 PM10/17/08
to

Listen, I gave you the correct explanation in my first post to you. Why are
you still talking about it? Here it is again, and I hope this thread will
cease and desist:

<q>


Try to compile this fragment:

size_t x;

Last time I checked, it will compile, because VC makes size_t an intrinsic
type. This is a (minor) deviation from the standard, which requires size_t
to be a typedef defined in various header files.

</q>

It ain't some profound mystery of the universe. :)

Tim Roberts

unread,
Oct 19, 2008, 12:07:35 AM10/19/08
to

Well, *I* am not going to be the one to tell you why, because I remain
unconvinced that the requirement follows from that paragraph. In Visual
C++ 8.0, for example, <stdio.h> includes <crtdefs.h>, and <stdlib.h>
includes both <crtdefs.h> and <limits.h>.

Now, I fully grant that, just because that Visual C++ does it does NOT
automatically mean that the standard allows it. Also, as I said, the
section Bo quoted was from the 1999 standard, whereas Microsoft implements
the 1990 standard.

0 new messages