Mail Archives: djgpp/2000/05/18/09:00:50
Does that mean I need to put (int) and (size_t), if I want to assign a value
of int to size_t and vice virsa?
OK, if it's so important, how many bugs are caused by not caring about
size_t? I don't mean in my own programs. Let's say in M$'...
bye.
Alexei A. Frounze
-----------------------------------------
Homepage: http://alexfru.chat.ru
Mirror: http://members.xoom.com/alexfru
"A. Sinan Unur" wrote:
>
> > > > Eli Zaretskii wrote:
> > > > > You need it for portability.
> > > > >
> > > > > size_t is not equal to int. Its precise definition depends on
> > > > > the implementation.
> ...
> > > > > You seem to be missing the point that you shouldn't rely on
> > > > > size_t and int being the same size (also: size_t is unsigned,
> > > > > ssize_t is signed).
>
> "Alexei A. Frounze" <alex DOT fru AT mtu-net DOT ru> wrote in message
> news:39236A55 DOT 78749ABD AT mtu-net DOT ru...
>
> > I've never said I _rely_. I don't use size_t in my sources. Only
> > standard types: char, short, int, long int, long long,... ;)
>
> i am sorry but this statement makes no sense. size_t is no less standard
> than int, but afaik long long is not in the standard at all.
>
> eli's warning is extremely appropriate: size_t has a well defined meaning
> that "it is the safest type that can represent the size of the largest data
> object you can create" (P.J. Plauger's "The Standard C Library", p.219.)
>
> for example, the following code is not safe
>
> int main(int argc, char *argv[]) {
> unsigned len = strlen(argv[0]);
> }
>
> because unsigned int is not guaranteed to be able to hold a size_t even
> though it may seem to work for now.
>
> --
> mailto:Sinan_Unur AT mail DOT com
> http://unur.com/
- Raw text -