R
Richard Heathfield
¬a\/b said:
size_t is well-defined.
size_t is well-defined.
S
santosh
¬a/b said:
How come then dynamically typed programming languages like Python and
Common Lisp are so portable and popular?
That's certainly true, but that's irrelevant to our discussion, since
size_t is well defined by the C Standard. What problems do you
specifically face when you use size_t?
¬
¬a\\/b
portable in my country means: i write a X language program;
that program run the same way in all machines
in the world that have a X language conform compiler
then you can argue how this program is portable
in the standard C language
#include <stdio.h>
#include <stdlib.h>
int main(void)
{size_t z=0x2FFFF, h=0xFFFFFFFF;
z=z*z;
printf("Bits(size_t) > 32 ?\n");
if(h<=0xFFFF||z<=h)
printf("No\n" );
else printf("Yes\n");
return 0;
}
because in each machine it could answer in a different way.
So what do you mean for the word "portable"? it is a meaningless word
in each machine where there are definitions like "size_t=number"
or where there are operations with size_t type variable => they are
not portable by definition (in each machine could be a different
result)
the problem is: size_t has different size each machine
but let it be size_t has 64 bits for all machine in the world
(or it is an memory only dipendent data type like a bignumber)
the problem could be for "*" function: can "*" function is the same in
all the machine and have the same result for the same operands?
the same for all other operators
the same for all UB and machine dipendent results
the same for all other "fixed all different size" data types
R
Richard Heathfield
¬a\/b said:
No, this isn't portable, because C doesn't guarantee size_t can store
values as high as 0x2FFFF.
The fact that you can write a non-portable program using size_t does not
mean size_t is not portable.
I mean that the program will achieve the same computational objective,
regardless of the implementation used to translate it.
To you, maybe, but not to me.
Two levers can be of different lengths, yet both can provide leverage,
and you can use either to shift a rock. Just as the concept of
"leverage" is portable across levers, so the concept of object size is
portable across implementations - and size_t is the type with which we
measure object sizes.
No, this isn't portable, because C doesn't guarantee size_t can store
values as high as 0x2FFFF.
The fact that you can write a non-portable program using size_t does not
mean size_t is not portable.
I mean that the program will achieve the same computational objective,
regardless of the implementation used to translate it.
To you, maybe, but not to me.
Two levers can be of different lengths, yet both can provide leverage,
and you can use either to shift a rock. Just as the concept of
"leverage" is portable across levers, so the concept of object size is
portable across implementations - and size_t is the type with which we
measure object sizes.
W
Walter Roberson
"running the same way" does not mean the same as "will
produce the same answer". For example, a program to print
out the current calendar time might have the same code
on all the systems, but it is going to produce a different
answer when run on each one of them.
S
santosh
¬a/b said:
You can't expect to portably store arbitrarily large values. size_t
can store values in the range of 0 ... SIZE_MAX. What's ill-defined
about this?
Here you're performing an arithmetic calculation without checking for
the possibility of wrap-around. Again results might vary across
implementations, but this is not exclusive to size_t types.
You're comparing objects which might not hold the values intended for
them.
And in what way is this exclusive to size_t. This is true for all of
C's numeric types. Each type's size and range are implementation
dependant except that certain minimum values are guaranteed by the
Standard. That's the price you'll have to pay for using an efficient,
statically typed language.
If you want a language with dynamically sized types, there're plenty
of them floating around. C was not defined to be such a language. On
the other hand, if you stick to what's guaranteed by the Standard, you
_can_ achieve a very high level of source code portability. The
problem is, you want guarantees the Standard is not providing.
<snip>
C
CBFalconer
Richard said:
Hint: ¬a\/b is a known troll.
C
CBFalconer
Guru said:
Please ensure you snip at least the sigs (the portion following the
"-- " marker). To reply to your query, try the URLs below as a
start.
--
Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://www.eskimo.com/~scs/C-faq/top.html> (C-faq)
<http://benpfaff.org/writings/clc/off-topic.html>
<http://anubis.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/> (C99 std)
<http://www.dinkumware.com/refxc.html> (C-library}
<http://gcc.gnu.org/onlinedocs/> (GNU docs)
<http://clc-wiki.net/wiki/C_community:comp.lang.c:Introduction>
B
Barry Schwarz
snip
Well then, you must not use int either since there are a plethora of
16-bit and 32-bit implementations. You probably don't use char either
since we know sizeof(char) is 1 but we don't know anything about
CHAR_BIT other than it is at least 8.
Remove del for email
Well then, you must not use int either since there are a plethora of
16-bit and 32-bit implementations. You probably don't use char either
since we know sizeof(char) is 1 but we don't know anything about
CHAR_BIT other than it is at least 8.
Remove del for email
G
Guru Jois
Thanks Santhosh
G
Guru Jois
Thanks to Richard too.
R
Richard
Richard Heathfield said:
Where are the portable "maximums" documented? Do you have a link?
S
santosh
Richard said:
I believe size_t is guaranteed to be able to represent values in the
range of 0x0 to 0xffff. This implies that it must at least be 16 bits
in size.
R
Richard Heathfield
Richard said:
They're documented in the Standard, which is available from the ANSI
Webstore for a few bucks. There's a link on Jack Klein's site IIRC.
Alternatively, do a Web search for n1124.pdf, which is C99 plus some
TCs.
An object of type size_t must be sufficiently large to be able to store
the size of any object that the implementation can construct. In C90,
the implementation must be able to construct an object at least 32767
bytes in size, so in C90 size_t must be at least 15 bits (and someone
once reasoned that it must be at least as wide as int, but I can't
remember the details - if that were true, it would have to be at least
16 bits wide in C90). In C99, the implementation must be able to
construct an object at least 65535 bytes in size, so in C99 size_t must
certainly be at least 16 bits wide.
0x2FFFF requires 18 bits to represent.
They're documented in the Standard, which is available from the ANSI
Webstore for a few bucks. There's a link on Jack Klein's site IIRC.
Alternatively, do a Web search for n1124.pdf, which is C99 plus some
TCs.
An object of type size_t must be sufficiently large to be able to store
the size of any object that the implementation can construct. In C90,
the implementation must be able to construct an object at least 32767
bytes in size, so in C90 size_t must be at least 15 bits (and someone
once reasoned that it must be at least as wide as int, but I can't
remember the details - if that were true, it would have to be at least
16 bits wide in C90). In C99, the implementation must be able to
construct an object at least 65535 bytes in size, so in C99 size_t must
certainly be at least 16 bits wide.
0x2FFFF requires 18 bits to represent.
F
Flash Gordon
Richard Heathfield wrote, On 10/07/07 15:52:
In C99 there is an even easier way to work out the minimum range
allowed. Section 7.18.3 para 2 explicitly says SIZE_MAX is at least 65535.
Or compare against the minimum allowed value of SIZE_MAX
In C99 there is an even easier way to work out the minimum range
allowed. Section 7.18.3 para 2 explicitly says SIZE_MAX is at least 65535.
Or compare against the minimum allowed value of SIZE_MAX