As title: is size_t always unsigned, i.e. for size_t x, is x always >= 0 ?
views:
1186answers:
8
+10
A:
Yes. It's usually defined as
typedef unsigned int size_t;
Reference:
C++ Standard Section 18.1 defines size_t is in <cstddef> which is described in C Standard as <stddef.h>.
C Standard Section 4.1.5 defines size_t as an unsigned integral type of the result of the sizeof operator
Mehrdad Afshari
2009-07-06 20:56:41
www.cplusplus.com is not the c++ standard
anon
2009-07-06 21:07:49
@Neil: I know. It was the first thing I found. I don't have C++ standard at hand so I'm downloading it (my connection is damn slow). In the meantime, I put something other than myself.
Mehrdad Afshari
2009-07-06 21:08:54
Well, I do have the C++ standard to hand, but can't find it, possibly because it's actually defined in the C (not C99) standard. I am hoping someone will track it down, because I think its an interesting question!
anon
2009-07-06 21:12:42
Be aware that cplusplus.com has some weird sites. Look at this, for example: http://www.cplusplus.com/reference/iostream/ostream/operator%3C%3C/ now that are fun signatures of operator<< :)
Johannes Schaub - litb
2009-07-06 21:13:42
@Neil: True. I'm hunting for C standard now.
Mehrdad Afshari
2009-07-06 21:14:51
@litb: Yeah. It's not reliable but for this specific case, I was pretty sure that `operator new` is defined using `size_t` as a parameter so it should be unsigned.
Mehrdad Afshari
2009-07-06 21:15:49
operator new is, and AFAICT size_t is not defined in the C++ standard.
David Thornley
2009-07-06 21:22:13
@Neil: Not the actual standard but pretty much explains it http://www.lysator.liu.se/c/rat/c3.html#3-3-3-4 : The Standard, like the Base Document, defines the result of the `sizeof` operator to be a constant of an unsigned integral type. *and also*: The type of `sizeof`, whatever it is, is published (in the library header `<stddef.h>`) as `size_t`
Mehrdad Afshari
2009-07-06 21:23:32
Thanks mehrdad for hunting down the reference
peterchen
2009-07-06 21:38:29
please note that `size_t` will normaly be 64 bit on 64 bit systems, whereas `int` might still be 32 bit; such things are highly compiler specific
Christoph
2009-07-06 23:27:24
Christoph: That's exactly why emphasis is added on the word *usually*. I wrote that line of code to demonstrate the idea, not to rely on.
Mehrdad Afshari
2009-07-06 23:39:04
David Rodríguez - dribeas
2009-07-07 05:24:55
It does not make sense for a size to be negative, but it might make sense to store it in a variable of signed type. What if you want the (signed) difference between two size_t values?
finnw
2009-07-06 23:32:28
+14
A:
According to the 1999 ISO C standard (C99), size_t is an unsigned integer type of at least 16 bit (see sections 7.17 and 7.18.3).
The standard also recommends that size_t shouldn't have an integer conversion rank greater than long if possible, ie casting size_t to unsigned long is unproblematic if the recommendation is followed.
The 1989 ANSI C standard (ANSI C) doesn't mention a minimal size or recommended conversion rank.
The 1998 ISO C++ standard (C++98) (as well as the current draft for C++0x) refers to the C standard. Section 18.1 reads:
The contents are the same as the Standard C library header
<stddef.h>[...]
According to section 1.2, this means the library as defined by the 1990 ISO C standard (C90), including its first amendment from 1995 (C95):
The library described in clause 7 of ISO/IEC 9899:1990 and clause 7 of ISO/IEC 9899/Amd.1:1995 is hereinafter called the Standard C Library.
The parts regarding size_t should be inherited from ANSI C: Frontmatter and section numbering aside, the standards for C90 and ANSI C are identical. I'd need a copy of the normative amendment to be sure that there weren't any relevant changes to stddef.h, but I doubt it. The minimal size seems to be introduced with stdint.h, ie C99.
Please also consider the following quote from section 1.2 of C++98:
All standards are subject to revision, and parties to agreements based on this International Standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below.
Christoph
2009-07-06 21:01:50
@Neil, well he has to take the C Standard, because the C++ Standard delegates to it :) It doesn't itself define size_t :)
Johannes Schaub - litb
2009-07-06 21:11:16
Somehow i believed the C89/C95 Standard required size_t to be at least 16 bit. But it looks like only C99 has that requirement and that it's at least 65535.
Johannes Schaub - litb
2009-07-06 21:41:42
@Neil: Actually, the C++ standard never mentions to which version of ISO C it refers; and ISO/IEC 9899:1990 is officially withdrawn
Christoph
2009-07-06 21:53:12
It says it references C99, but for the library, it refers to C90 and C95. In 1.2/2 it says "The library described in ... C90 and in ... C95 is here-inafter called 'The Standard C Library'". Thus when it specifies the content of cstddef, it refers to C89 (and the amendment C95, which is a TC to C89 afaik. As is C++03 to C++98 too) (another time specified by 17.4.1.2/4)
Johannes Schaub - litb
2009-07-06 22:50:11
@litb: you're right, thanks; I only did a quick search and somehow didn't find the normative references; will edit some more
Christoph
2009-07-06 22:59:38
+3
A:
According to the standard it is unsigned, however I recall that some older implementations used a signed type for the typedef.
From an older GCC doc:
There is a potential problem with the size_t type and versions of GCC prior to release 2.4. ANSI C requires that
size_talways be an unsigned type. For compatibility with existing systems' header files, GCC definessize_tinstddef.hto be whatever type the system'ssys/types.hdefines it to be. Most Unix systems that definesize_tinsys/types.h, define it to be a signed type. Some code in the library depends onsize_tbeing an unsigned type, and will not work correctly if it is signed
I'm not sure how important it would be to guard against that. My code assumes it's unsigned.
Michael Burr
2009-07-06 21:06:18
I think everyone knows it's probably unsigned - but unless someone can quote a relevant standards document, we'll never know for sure.
anon
2009-07-06 21:10:34
I don't have the standard document handy at the moment (though I'm confident that all the relevant standards, C90, C99 and C++98 and beyond require it to be unsigned). However, I just wanted to point out that regardless of the standard, there are potentially important exceptions where size_t is a signed type.
Michael Burr
2009-07-06 21:14:00
A:
On mature (?) reflection - quotes from the C99 Standard are probably sufficient. Despite some of the weirdo things C99 does, I don't believe they would change the type of size_t. So apologies to anyone who I may have forced to pore through ancient C standards documents!
anon
2009-07-06 21:18:43
One of the weird things C99 introduced are implementation defined extended integral types. So it happens an implementation may have a size_t that doesn't even fit into unsigned long long :)
Johannes Schaub - litb
2009-07-06 21:39:50
Neil: It was fun though ;) BTW, as *litb* pointed out in a comment C89 doesn't restrict the size of `size_t`. In fact, what I wrote in my answer is the *only* thing it says about `size_t` so your concern was completely relevant.
Mehrdad Afshari
2009-07-06 21:50:58
+1
A:
The size_t should follow the same definition as the C standard, and in several places in the C++ standard it implies it's unsigned natura (particularly in the allocator template argument definitions).
On the C++ Standard, section 18.1 (ISO/IEC 14882 - First edition 1998-01-01):
Table 15 lists as defined types: ptrdiff_t and size_t
3 The contents are the same as the Standard C library header , with the following changes: 4 The macro NULL is an implementation-defined C++ null pointer constant in this International Standard (4.10).
The macro offsetof accepts a restricted set of type arguments in this International Standard. type shall be a POD structure or a POD union (clause 9). The result of applying the offsetof macro to a field that is a static data member or a function member is undefined. SEE ALSO: subclause 5.3.3, Sizeof, subclause 5.7, Additive operators, subclause 12.5, Free store, and ISO C subclause 7.1.6.
njsf
2009-07-06 21:26:13