Request

[Richard Heathfield]

av said:

possible i'm the only one in think that standard C is wrong on
definition of size_t?

That's unlikely. There are plenty of people who don't understand C.

 

[Chris Dollin]

possible i'm the only one in think that standard C is wrong on
definition of size_t?

Yes.

 

[Richard Tobin]

possible i'm the only one in think that standard C is wrong on
definition of size_t?

Certainly the modular arithmetic used for unsigned types is usually
inappropriate for sizes, but so are signed types. And presumably the
standards committee would not be willing to invent a new kind of
integer for this purpose.

-- Richard

 

[Richard Heathfield]

Richard Tobin said:

Certainly the modular arithmetic used for unsigned types is usually
inappropriate for sizes,
Why?

but so are signed types. And presumably the
standards committee would not be willing to invent a new kind of
integer for this purpose.

And it's easy to see why not, if you try doing so for yourself. What
characteristics should such an integer type have?

 

[Richard Tobin]

Certainly the modular arithmetic used for unsigned types is usually
inappropriate for sizes,

[/QUOTE]

Why?

Because the space required for A bytes and B bytes is A+B bytes, not
(A+B) mod (SIZE_MAX+1).

And it's easy to see why not

Yes.

-- Richard

 

[av]

possible i'm the only one in think that standard C is wrong on
definition of size_t?

because i have some time to troll, here it is the right model for your
"beloved" ssize_t and size_t
------------------------------------------
Signed
int32_t a,b;
/ INT32_MIN, if a or b or both are INT32_MIN
/ INT32_MIN, if the result is not the usual mathematic result
a@b=v{
\ mathematical correct result

where @ is in { +, -, *, /, %}
If i want to see if the computatiton that use +-*/%
is correct is enought to prove
result is in [INT32_MIN+1..INT32_MAX]
------------------------------------------
unsigned
uns32_t a, b;
/ UNS32_MAX, if a or b or both are UNS32_MAX
/ UNS32_MAX, if the result is not the usual mathematic result
a@b=v{
\ mathematical correct result

where @ is in { +, -, *, /, %, <<, >>, &, |, ~}
If i want to see if the computatiton that use +-*/%<<>>&|~
is correct is enought to prove
result is in [0..UNS32_MAX-1]

 

[Richard Heathfield]

Richard Tobin said:

Why?

Because the space required for A bytes and B bytes is A+B bytes, not
(A+B) mod (SIZE_MAX+1).[/QUOTE]

Sure, but at some point you have to accept that A+B doesn't make sense. It
may well be that implementations need to supply a wider size_t than they do
at present, but when all's said and done, there are (according to
Schneier's "Applied Cryptography", 2nd edition) only 2^265 atoms in the
Universe (not including dark matter). If we could store a megabyte of data
in each atom (ha! why not?), that would be 2^285 bytes, right? So if we had
a 285-bit size_t, it would be able to store the sum total of the sizes of
all the objects it is possible to create in a Universe-sized computer, so
there is simply no point in having a size_t wider than that (unless you're
into parallel universes). If we confine ourselves to the Earth, we have a
mere 2^170 atoms to play with, so - even given that rather optimistic
megabyte per atom - a 190-bit size_t would do the trick nicely, and modular
arithmetic would become rather irrelevant.

We live in a real world with real limits, and it's high time that computer
programmers got used to the fact.

 

[Ben Pfaff]

We live in a real world with real limits, and it's high time that computer
programmers got used to the fact.

But integers are *so* much easier!

 

[Richard Tobin]

Because the space required for A bytes and B bytes is A+B bytes, not
(A+B) mod (SIZE_MAX+1).

[/QUOTE]

Sure, but at some point you have to accept that A+B doesn't make sense.

I'm not really arguing that size_t ought to be a different type, just
agreeing with someone that it has a problem. And we've seen that this
problem is not illusory, because several implementations have a bug in
calloc() because of it.

There are various ways it could be improved, some more and some less
C-like:

- use an arbitrary-precision type. Handy, but not really C.
- use a larger but fixed-size integer type. This is happening anyway
with 64-bit systems, but is still susceptible to the calloc() mistake.
- use an integer type that is required to signal overflow. This
seems like a plausible extension.

The overflow-signalling solution seems like a good idea to me; I imagine
the main problem is that it is not efficient to implement on all systems.

We live in a real world with real limits, and it's high time that computer
programmers got used to the fact.

Having programming languages check these limits has advantages.

-- Richard