By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,276 Members | 2,137 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,276 IT Pros & Developers. It's quick & easy.

What's the deal with size_t?

P: n/a
Hello, World!

Reading this group for some time I came to the conclusion that
people here are split into several fractions regarding size_t,
including, but not limited to,

* size_t is the right thing to use for every var that holds the
number of or size in bytes of things.

* size_t should only be used when dealing with library functions.

* size_t should really be a signed type (less warnings)

* size_t is unnecessary (size of object in memory never exceeds
what can be held in an integer).

* size_t is visually unpleasant.

* size_t clutters up / is an uglification of the language
(solving only a theoretical problem).

* size_t usage may be non-portable because it won't be around
anymore in 100 years.

Sooo... what's the real deal with size_t? Where should it be
used/avoided (examples?)

Nov 6 '07 #1
Share this Question
Share on Google+
89 Replies


P: n/a
Tubular Technician said:
Sooo... what's the real deal with size_t? Where should it be
used/avoided (examples?)
Observe where, how, and why the standard library uses size_t. Then go thou
and do likewise. The standard library is very often (although by no means
always) a reasonable guide to good practice in your own code.

A great many standard library functions use size_t, not only to specify the
size of an object, but also to enumerate objects.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Nov 6 '07 #2

P: n/a
Tubular Technician wrote:
Hello, World!

Reading this group for some time I came to the conclusion that
people here are split into several fractions regarding size_t,
including, but not limited to,

* size_t is the right thing to use for every var that holds the
number of or size in bytes of things.
as far as I'm aware, all of the c-library I/O functions (as well as many
that take "number of items" arguments) all use size_t, so it is best to
match types.
>
* size_t should only be used when dealing with library functions.
That's a lot of library functions ;-)
>
* size_t should really be a signed type (less warnings)
except that size_t is often used to hold values that may be larger than
a signed integer can hold.

there is an ssize_t which is signed
>
* size_t is unnecessary (size of object in memory never exceeds
what can be held in an integer).
size_t is often used to refer to sizes of objects on disk, which can
easily exceed what can be held in a signed integer.

Max size_t is 4GB on 32bit architectures, I'm not entirely sure if that
changes on 64bit architectures, but Linux file sizes can range up to at
least 4GB and I believe that Linux also supports at least 4GB of memory,
so using a signed integer is not sufficient if you want your software to
be portable.
>
* size_t is visually unpleasant.
that's in the eye of the beholder and isn't a technical reason to
use/not use size_t
>
* size_t clutters up / is an uglification of the language
(solving only a theoretical problem).
Again, not a very technical argument.
* size_t usage may be non-portable because it won't be around
anymore in 100 years.
I won't be around in 100 years, so I'm not terribly worried whether it
will or won't be around by then.

I suspect, however, that size_t will not be going away.
>
Sooo... what's the real deal with size_t? Where should it be
used/avoided (examples?)
It should be used whenever you make a call to a library functions which
uses it and, likely, whenever you want to express the size of an object
in bytes.

Jeff
Nov 6 '07 #3

P: n/a
Tubular Technician <no@spam.invalidwrites:
* size_t is the right thing to use for every var that holds the
number of or size in bytes of things.
Only the size of an object held in memory, or a number or size
that can be no greater than the maximum size of an object held in
memory. Thus, size_t is not appropriate for holding the size of
disk file because a disk file can be larger than memory (use
off_t instead).
--
Ben Pfaff
http://benpfaff.org
Nov 6 '07 #4

P: n/a
Tubular Technician <n...@spam.invalidwrote:
Hello, World!

Reading this group for some time I came to the conclusion
that people here are split into several fractions regarding
size_t, including, but not limited to,

* size_t is the right thing to use for every var that holds
the number of or size in bytes of things.
For memory objects, it's hard to escape that fact.
* size_t should only be used when dealing with library
functions.
Sounds more like a phobia than sense.
* size_t should really be a signed type (less warnings)
How big is -1 bytes?

People get warnings for 2 reasons: bad code and mother hen
clucking compilers. Both are easy to rectify. The later
is easy to ignore.
* size_t is unnecessary (size of object in memory never
exceeds what can be held in an integer).
False for a number of 16-bit int systems that can address
more than 64K of memory. As 64-bit systems accessing more
than 4G of RAM become prevalent, you'll see more
implementations in the same boat because the many will
keep int at 32-bits for backwards compatibility with
programs written by programmers who failed to learn from
their mistakes when 32-bit systems took over 16-bit ones.
* size_t is visually unpleasant.
C is visually unpleasant.

[But size_t is a lot more appealing to me than FILE!]
* size_t clutters up / is an uglification of the language
(solving only a theoretical problem).
No, that's ptrdiff_t.
* size_t usage may be non-portable because it won't be
around anymore in 100 years.
If size_t won't be around, then it'll be because C won't
be around.
Sooo... what's the real deal with size_t? Where should
it be used/avoided (examples?)
Use it where you need to use it. Typical usage is as a size,
count or index of memory objects.

Fact is, it doesn't really matter whether you use size_t
or int. You still have to be conscious of memory limitations
and going beyond the limits of whatever integer you're using.

It's simpler to use size_t in most cases because detecting
wrap around is easy and, unlike int, it _is_ guaranteed to
be able to index any object allocated through normal means.

The only problem with size_t, AFAICS, is that it is not
required to have a rank of unsigned int or above.

--
Peter

Nov 6 '07 #5

P: n/a

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:05******************************@bt.com...
Tubular Technician said:
>Sooo... what's the real deal with size_t? Where should it be
used/avoided (examples?)

Observe where, how, and why the standard library uses size_t. Then go thou
and do likewise. The standard library is very often (although by no means
always) a reasonable guide to good practice in your own code.
just, be careful of adopting their naming conventions. otherwise, you may
run into, clashes...

my naming conventions often go like this:
<lib>_<name smaller libs or externally usable names.
<part>_<name rarer, usually for older code or if I may at some
point split the code into another lib
<lib>_<part>_<name a general convention.

in the above, lib is usually all caps, part is is often mixed case
(FirstLettersAreCaps), and name is often similar to part.

another convention used in some of my libs (for front-end API functions in
cases where I 'formally' specify the external API, rather than just making a
lib and just using whatever code the lib contains):
<prefix><name>

where prefix is all lower case (usually the lower-case equivalent of lib),
and name is as before (though, in a few cases, I have used all lower case
names, but this has mostly been for 'core' functions intended almost as
extensions or alternatives to the standard library).

usually, only a few front-end functions use these interfaces, with nearly
everything else (internal to the lib) using the previous conventions.
my rules are far more lax for front-end code, but usually this is only a
minor part of my projects.

A great many standard library functions use size_t, not only to specify
the
size of an object, but also to enumerate objects.
yes.

size_t is good, albeit in the past I have traditionally not used it much...

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Nov 6 '07 #6

P: n/a
Jeffrey Stedfast <st******@comcast.netwrote:
Tubular Technician wrote:
Reading this group for some time I came to the conclusion that
people here are split into several fractions regarding size_t,
including, but not limited to,
Hardly. There are most people, who vary from option one to option two,
and then there's Malcolm, who is scared of underlines.
* size_t should really be a signed type (less warnings)

except that size_t is often used to hold values that may be larger than
a signed integer can hold.

there is an ssize_t which is signed
Not in C, there isn't. Maybe in C++.
* size_t is unnecessary (size of object in memory never exceeds
what can be held in an integer).

size_t is often used to refer to sizes of objects on disk,
More likely in memory...
which can easily exceed what can be held in a signed integer.
....for which this is just as true. For the sizes of disk objects, size_t
may not even be enough.
Max size_t is 4GB on 32bit architectures,
Nonsense. size_t may be any unsigned integer type; what's there to stop
an implementation on a "32bit architecture", whatever that means in this
case (and it could mean several things), from making a size_t 64 bits?
After all, if it's a C99 implementation, it already _has_ to make long
long at least that large.
Sooo... what's the real deal with size_t? Where should it be
used/avoided (examples?)

It should be used whenever you make a call to a library functions which
uses it and, likely, whenever you want to express the size of an object
in bytes.
Quite. And it should be avoided if you're a scaredycat who doesn't want
to face up to any other integer types than int and char.

Richard
Nov 6 '07 #7

P: n/a
Richard Bos wrote:
Jeffrey Stedfast <st******@comcast.netwrote:
>>
there is an ssize_t which is signed

Not in C, there isn't. Maybe in C++.
I think it's Posix.

--
Ian Collins.
Nov 6 '07 #8

P: n/a
On Tuesday 06 Nov 2007 6:46 am Tubular Technician <no@spam.invalid>
wrote in article <lg************@foo.example.com>:
Hello, World!

Reading this group for some time I came to the conclusion that
people here are split into several fractions regarding size_t,
including, but not limited to,

* size_t is the right thing to use for every var that holds the
number of or size in bytes of things.
Yes.
* size_t should only be used when dealing with library functions.
Why? That's daft.
* size_t should really be a signed type (less warnings)
Not worth it.
* size_t is unnecessary (size of object in memory never exceeds
what can be held in an integer).
There is no such requirement. It is provably false.
* size_t is visually unpleasant.
Weakest of all arguments against it.
* size_t usage may be non-portable because it won't be around
anymore in 100 years.
Why is that?
Sooo... what's the real deal with size_t? Where should it be
used/avoided (examples?)
It's appropriate to hold the sizes of objects, arrays and often to hold
indexes as well. If you really need a signed value then it's, of
course, not appropriate. If you don't mind skirting portability there
is POSIX's ssize_t.

Nov 6 '07 #9

P: n/a
Richard Bos wrote:
Jeffrey Stedfast <st******@comcast.netwrote:
>Tubular Technician wrote:
>>Reading this group for some time I came to the conclusion that
people here are split into several fractions regarding size_t,
including, but not limited to,

Hardly. There are most people, who vary from option one to option two,
and then there's Malcolm, who is scared of underlines.
>>* size_t should really be a signed type (less warnings)
except that size_t is often used to hold values that may be larger than
a signed integer can hold.

there is an ssize_t which is signed

Not in C, there isn't. Maybe in C++.
Ah, this could be an GNUism (I wouldn't be surprised) :)
>
>>* size_t is unnecessary (size of object in memory never exceeds
what can be held in an integer).
size_t is often used to refer to sizes of objects on disk,

More likely in memory...
>which can easily exceed what can be held in a signed integer.

...for which this is just as true. For the sizes of disk objects, size_t
may not even be enough.
true enough, my mistake.
>
>Max size_t is 4GB on 32bit architectures,

Nonsense. size_t may be any unsigned integer type; what's there to stop
an implementation on a "32bit architecture", whatever that means in this
case (and it could mean several things), from making a size_t 64 bits?
sorry, I meant to say "at least", as in, "Max size_t is at least 4GB on
32bit" because it has to be able to at least hold values that large.
After all, if it's a C99 implementation, it already _has_ to make long
long at least that large.
Agreed.
>
>>Sooo... what's the real deal with size_t? Where should it be
used/avoided (examples?)
It should be used whenever you make a call to a library functions which
uses it and, likely, whenever you want to express the size of an object
in bytes.

Quite. And it should be avoided if you're a scaredycat who doesn't want
to face up to any other integer types than int and char.

Richard
Jeff
Nov 6 '07 #10

P: n/a
Tubular Technician wrote On 11/05/07 20:16,:
Hello, World!

Reading this group for some time I came to the conclusion that
people here are split into several fractions regarding size_t,
including, but not limited to,

* size_t is the right thing to use for every var that holds the
number of or size in bytes of things.
I've never seen this claim made.
* size_t should only be used when dealing with library functions.
Nor this one.
* size_t should really be a signed type (less warnings)
Nor this one.
* size_t is unnecessary (size of object in memory never exceeds
what can be held in an integer).
This claim has been made, and also refuted with actual
examples of real contemporary machines.
* size_t is visually unpleasant.
Big deal. I'm sure some of the people who post here
are visually unpleasant, too.
* size_t clutters up / is an uglification of the language
(solving only a theoretical problem).
This claim has been made, and made, and made, and made,
and made, by one person who never tires of making it, and
making it, and making it, and making it, and making it. You
have probably awakened him, and now we'll get to see him do
it all over again, again, again, again, again. Thanks a lot.
* size_t usage may be non-portable because it won't be around
anymore in 100 years.
Neither will C.
Sooo... what's the real deal with size_t? Where should it be
used/avoided (examples?)
See Richard Heathfield's reply.

--
Er*********@sun.com
Nov 6 '07 #11

P: n/a
Tubular Technician wrote:
...
* size_t is the right thing to use for every var that holds the
number of or size in bytes of things.
The first part ("number of things") is incorrect. 'size_t' should not be
used for that purpose (with some exceptions, see below). The second part
("size in bytes of things") is correct - that's exactly what 'size_t' is
there to be used for.
* size_t should only be used when dealing with library functions.
No, if by "library functions" you mean "standard library functions". See
above: 'size_t' should be used whenever there's a need to store or pass
a generic "size in bytes of things".
* size_t should really be a signed type (less warnings)
False.
* size_t is unnecessary (size of object in memory never exceeds
what can be held in an integer).
What "integer"? '[unsigned] int'? That's false. Note, BTW, that 'size_t'
is an "integer" itself.
* size_t is visually unpleasant.
It is consistent with the other legacy naming conventions used in
C89/90. Consistency is immeasurably more important than visual
pleasantry. Moreover, consistency begets visual pleasantry, once you get
used to it.
* size_t clutters up / is an uglification of the language
(solving only a theoretical problem).
False.
* size_t usage may be non-portable because it won't be around
anymore in 100 years.
Hm... I just don't know what to say about it. Doesn't make much sense.
Sooo... what's the real deal with size_t? Where should it be
used/avoided (examples?)
As it says above, 'size_t' should be used whenever there's a need to
store or pass a generic "size in bytes of things". I.e it should be used
for absolute sizes of objects in bytes (see 'malloc' for example).

Note, that it is also limitedly acceptable to use 'size_t' to express
array sizes and indexes (i.e. element counts), but only in contexts that
are specifically targeted at _arrays_ (as opposed to _containers_ in
general) and _generic_ arrays at that (as opposed to
_application-specific_ arrays, which should use application-specific
types for that purpose) (see 'calloc' for example or string manipulation
functions).

--
Best regards,
Andrey Tarasevich
Nov 6 '07 #12

P: n/a
Eric Sosman <Er*********@sun.comwrites:
Tubular Technician wrote On 11/05/07 20:16,:
[...]
>* size_t is unnecessary (size of object in memory never exceeds
what can be held in an integer).

This claim has been made, and also refuted with actual
examples of real contemporary machines.
[...]

The claim *as stated* is correct. The size of any object in memory
can never exceed what can be held in an integer (ignoring a nitpicking
controversy about how big an object calloc() can create); size_t is,
after all, an integer type.

Blurring the distinction between "int" and "integer" is one of the
worst errors I see here. There are a number of integer types in C,
ranging from char to long long (and perhaps more if the implementation
provides one or more extended integer types). "int" is just one of
those types (it's also a keyword that can be used in the names of
several other integer types).

(The standard might use the term "integral types" rather than "integer
types"; I'm not sure, it doesn't make much difference to the point,
and my copy of the standard isn't handy at the moment.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Nov 6 '07 #13

P: n/a
On Nov 5, 7:16 pm, Tubular Technician <n...@spam.invalidwrote:
Hello, World!

Reading this group for some time I came to the conclusion that
people here are split into several fractions regarding size_t,
including, but not limited to,

* size_t is the right thing to use for every var that holds the
number of or size in bytes of things.
Generally I agree, although if you know your upper bound isn't going
to exceed one of the other integral types, they should work just as
well.
* size_t should only be used when dealing with library functions.
Disagree; I'll use it when it makes sense.
* size_t should really be a signed type (less warnings)
Nonsensical. How many objects in memory take up < 0 bytes?
* size_t is unnecessary (size of object in memory never exceeds
what can be held in an integer).
As others have pointed out, this isn't necessarily true.
* size_t is visually unpleasant.
Just about the entire C language is visually unpleasant.
* size_t clutters up / is an uglification of the language
(solving only a theoretical problem).
The problem is far from theoretical -- depending on the architecture,
the regular integral types may not be wide enough to represent the
size of an object in memory.
* size_t usage may be non-portable because it won't be around
anymore in 100 years.
If anyone is seriously making that argument, then they are in need of
a beating with a copy of Schildt. That's retarded.
Sooo... what's the real deal with size_t? Where should it be
used/avoided (examples?)
I use size_t types anytime I'm dealing with arrays or allocating
memory.

Nov 7 '07 #14

P: n/a

"Andrey Tarasevich" <an**************@hotmail.comwrote in message
>
As it says above, 'size_t' should be used whenever there's a need to
store or pass a generic "size in bytes of things". I.e it should be used
for absolute sizes of objects in bytes (see 'malloc' for example).

Note, that it is also limitedly acceptable to use 'size_t' to express
array sizes and indexes (i.e. element counts), but only in contexts that
are specifically targeted at _arrays_ (as opposed to _containers_ in
general) and _generic_ arrays at that (as opposed to
_application-specific_ arrays, which should use application-specific
types for that purpose) (see 'calloc' for example or string manipulation
functions).
The problem is that, in C, the array is by far the most common data
structure. So size_t needs to be used whenever the maximum dimensions of the
array cannot be specified by the programmer.
That creates another problem. Frequently we know that the array will be
relatively small, but it doesn't make much sense to specify a limit. For
instance the number of children in a class must, in Britain, be thirty or
less by law. However that law is often breached. But not so flagrantly that
you have classes of hundreds.
So should the class count be an int or a size_t? If we want to pass a class
to qsort() to rank the children by mark, the function will take a size_t.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Nov 7 '07 #15

P: n/a
>>>>"MMcL" == Malcolm McLean <re*******@btinternet.comwrites:

MMcLThe problem is that, in C, the array is by far the most
MMcLcommon data structure. So size_t needs to be used whenever
MMcLthe maximum dimensions of the array cannot be specified by
MMcLthe programmer.

The dialect of C I use most often *requires* the maximum dimension of
the array to be specified by the programmer, either by providing a
constant size at compile-time or by calling a memory allocation
function with a size at run-time.

MMcLFrequently we know that the array will be relatively small,
MMcLbut it doesn't make much sense to specify a limit. For
MMcLinstance the number of children in a class must, in Britain,
MMcLbe thirty or less by law. However that law is often
MMcLbreached. But not so flagrantly that you have classes of
MMcLhundreds. So should the class count be an int or a size_t?
MMcLIf we want to pass a class to qsort() to rank the children
MMcLby mark, the function will take a size_t.

Yes, and the dialect of C I use most often will implicitly cast an int
to a size_t as necessary. Does your compiler not support that feature?

Charlton

--
Charlton Wilbur
cw*****@chromatico.net
Nov 7 '07 #16

P: n/a
"Charlton Wilbur" <cw*****@chromatico.netwrote in message
>>>>>"MMcL" == Malcolm McLean <re*******@btinternet.comwrites:

MMcLThe problem is that, in C, the array is by far the most
MMcLcommon data structure. So size_t needs to be used whenever
MMcLthe maximum dimensions of the array cannot be specified by
MMcLthe programmer.

The dialect of C I use most often *requires* the maximum dimension of
the array to be specified by the programmer, either by providing a
constant size at compile-time or by calling a memory allocation
function with a size at run-time.

MMcLFrequently we know that the array will be relatively small,
MMcLbut it doesn't make much sense to specify a limit. For
MMcLinstance the number of children in a class must, in Britain,
MMcLbe thirty or less by law. However that law is often
MMcLbreached. But not so flagrantly that you have classes of
MMcLhundreds. So should the class count be an int or a size_t?
MMcLIf we want to pass a class to qsort() to rank the children
MMcLby mark, the function will take a size_t.

Yes, and the dialect of C I use most often will implicitly cast an int
to a size_t as necessary. Does your compiler not support that feature?
You need to explicitly cast, or it will warn.

Whilst quite often arrays are in fact fixed at compile time, this is often
at quite a high level or late stage. You might have three thousand "rooms"
in an adventure game, however the "seach rooms for named object" function
will be written long before this limit is fixed. So the number of rooms
really needs to be a size_t. The programmer of the search function cannot
dictate how big the final game will be. That's if we go down the size_t
route.

Also, a lot of variables are in fact passed by indirection. If you've got
more than one class in the school, sizes might well be stored in an array.
Index numbers giving a key for each pupil probably will be as well.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Nov 7 '07 #17

P: n/a
"Malcolm McLean" <re*******@btinternet.comwrites:
>Yes, and the dialect of C I use most often will implicitly cast an int
to a size_t as necessary. Does your compiler not support that feature?
You need to explicitly cast, or it will warn.
That is a QOI issue, not a language issue, surely. With gcc I can
choose.

--
Ben.
Nov 7 '07 #18

P: n/a
Malcolm McLean wrote, On 07/11/07 22:10:
"Charlton Wilbur" <cw*****@chromatico.netwrote in message
>>>>>>"MMcL" == Malcolm McLean <re*******@btinternet.comwrites:

MMcLThe problem is that, in C, the array is by far the most
MMcLcommon data structure. So size_t needs to be used whenever
MMcLthe maximum dimensions of the array cannot be specified by
MMcLthe programmer.

The dialect of C I use most often *requires* the maximum dimension of
the array to be specified by the programmer, either by providing a
constant size at compile-time or by calling a memory allocation
function with a size at run-time.

MMcLFrequently we know that the array will be relatively small,
MMcLbut it doesn't make much sense to specify a limit. For
MMcLinstance the number of children in a class must, in Britain,
MMcLbe thirty or less by law. However that law is often
MMcLbreached. But not so flagrantly that you have classes of
MMcLhundreds. So should the class count be an int or a size_t?
MMcLIf we want to pass a class to qsort() to rank the children
MMcLby mark, the function will take a size_t.

Yes, and the dialect of C I use most often will implicitly cast an int
to a size_t as necessary. Does your compiler not support that feature?
You need to explicitly cast, or it will warn.
The C standard does not require that and its not a problem I have.
Whilst quite often arrays are in fact fixed at compile time, this is
often at quite a high level or late stage. You might have three thousand
"rooms" in an adventure game, however the "seach rooms for named object"
function will be written long before this limit is fixed. So the number
of rooms really needs to be a size_t. The programmer of the search
function cannot dictate how big the final game will be. That's if we go
down the size_t route.
However, if in your scenario the programmer of the search function uses
the type int you can have an infinite game? Don't be an idiot. Of
course, if they have decided to leave the decision until later or think
there may be reason to change there is another useful language feature
called typedef.

typedef room_size_t whatever;
Also, a lot of variables are in fact passed by indirection.
In my experience most variables are not passed by indirection (or, in C
terms, most of the time I do not pass a pointer to the variable).
If you've
got more than one class in the school, sizes might well be stored in an
array. Index numbers giving a key for each pupil probably will be as well.
See suggestion above.

Of course, in the example of class sizes you know it is guaranteed to be
less than 32767 so using int is safe if that is the choice you want to make.
--
Flash Gordon
Nov 8 '07 #19

P: n/a
Andrey Tarasevich wrote:
Tubular Technician wrote:
>...
* size_t is the right thing to use for every var that holds the
number of or size in bytes of things.

The first part ("number of things") is incorrect. 'size_t' should not be
used for that purpose (with some exceptions, see below). The second part
("size in bytes of things") is correct - that's exactly what 'size_t' is
there to be used for.
I was thinking of

struct foo {
/* ... */
};
struct foo Foo[X];
#define FOOSIZE (sizeof Foo / sizeof Foo[0])
>* size_t should only be used when dealing with library functions.

No, if by "library functions" you mean "standard library functions". See
above: 'size_t' should be used whenever there's a need to store or pass
a generic "size in bytes of things".
I think the above claim may come from the fact that size_t is not built
into the language like char, int, long, etc. For example (I know there
are probably better examples), if <stdio.his included, it makes
available both function prototypes dealing with FILE objects as well
as the FILE type itself.

In case of size_t, it is made available when including headers that use
it, but is not available by the bare language, that is, the compiler
knows by itself the max. size of memory that can be addressed, it knows
by itself about sizeof and the (unnamed) type it yields, but to create an
object of said type inclusion of a header is needed.

(BTW, what is the exact rational behind this? Was there a fear at the
time size_t was added to the language that making it available
unconditionally may conflict with preexisting code, somewhat like with
C99 when bool was added?)
>* size_t usage may be non-portable because it won't be around
anymore in 100 years.

Hm... I just don't know what to say about it. Doesn't make much sense.
IIRC, this claim was made in the big book discussion thread some time
ago and was given as a reason why the example code in said book does
not use size_t.
Nov 8 '07 #20

P: n/a
Flash Gordon wrote:
Malcolm McLean wrote, On 07/11/07 22:10:
>Whilst quite often arrays are in fact fixed at compile time, this is
often at quite a high level or late stage. You might have three
thousand "rooms" in an adventure game, however the "seach rooms for
named object" function will be written long before this limit is
fixed. So the number of rooms really needs to be a size_t. The
programmer of the search function cannot dictate how big the final
game will be. That's if we go down the size_t route.

However, if in your scenario the programmer of the search function uses
the type int you can have an infinite game? Don't be an idiot. Of
course, if they have decided to leave the decision until later or think
there may be reason to change there is another useful language feature
called typedef.

typedef room_size_t whatever;
ITYM
typedef whatever room_size_t;

--
Philip Potter pgp <atdoc.ic.ac.uk
Nov 8 '07 #21

P: n/a
Philip Potter wrote, On 08/11/07 09:58:
Flash Gordon wrote:
>Malcolm McLean wrote, On 07/11/07 22:10:
>>Whilst quite often arrays are in fact fixed at compile time, this is
often at quite a high level or late stage. You might have three
thousand "rooms" in an adventure game, however the "seach rooms for
named object" function will be written long before this limit is
fixed. So the number of rooms really needs to be a size_t. The
programmer of the search function cannot dictate how big the final
game will be. That's if we go down the size_t route.

However, if in your scenario the programmer of the search function
uses the type int you can have an infinite game? Don't be an idiot. Of
course, if they have decided to leave the decision until later or
think there may be reason to change there is another useful language
feature called typedef.

typedef room_size_t whatever;

ITYM
typedef whatever room_size_t;
I do indeed. Thanks.
--
Flash Gordon
Nov 8 '07 #22

P: n/a
Jeffrey Stedfast <st******@comcast.netwrote:
Richard Bos wrote:
Jeffrey Stedfast <st******@comcast.netwrote:
Max size_t is 4GB on 32bit architectures,
Nonsense. size_t may be any unsigned integer type; what's there to stop
an implementation on a "32bit architecture", whatever that means in this
case (and it could mean several things), from making a size_t 64 bits?

sorry, I meant to say "at least", as in, "Max size_t is at least 4GB on
32bit" because it has to be able to at least hold values that large.
Not even that. It is quite possible for a system (probably embedded) to
have 32-bit or even 64-bit ints, but very few of them. If your
implementation targets a chip which has only 256 4-octet words, it is
possible to limit size_t to one octet.
Two things need to be noted here, though. One: whether the above
approach makes practical sense is quite another question; all I'm saying
here is that it's allowed. And two: this is for C89; C99 has SIZE_MAX,
which C89 didn't have, and it demands that SIZE_MAX be at least 65535.
Still not 4 GB, though.

Richard
Nov 8 '07 #23

P: n/a
Charlton Wilbur wrote On 11/07/07 16:25,:
[...]
Yes, and the dialect of C I use most often will implicitly cast an int
to a size_t as necessary. Does your compiler not support that feature?
How can a cast be "implicit?"

In other words, what are you talking about? Can
you give an example?

--
Er*********@sun.com
Nov 8 '07 #24

P: n/a
>>>>"ES" == Eric Sosman <Er*********@sun.comwrites:

ESCharlton Wilbur wrote On 11/07/07 16:25,:
>[...] Yes, and the dialect of C I use most often will
implicitly cast an int to a size_t as necessary. Does your
compiler not support that feature?
ES How can a cast be "implicit?"

Sorry, implicit type conversion, not implicit cast.

ES In other words, what are you talking about? Can you give
ESan example?

Given the following declarations:

struct foo **foolist;
int i;
int num_foo;
int compare_foo (void *foo_one, void *foo_two);

and a prototype for qsort in scope, the following code:

qsort (foolist, last_foo, sizeof struct foo *, compare_foo);

may cause a warning at compile time because num_foo (an int) is used
when the prototype of qsort calls for a size_t, but the type
conversion from int to size_t is nonetheless performed.

Charlton

--
Charlton Wilbur
cw*****@chromatico.net
Nov 8 '07 #25

P: n/a
Charlton Wilbur wrote On 11/08/07 14:48,:
>>>>>>"ES" == Eric Sosman <Er*********@sun.comwrites:

ESCharlton Wilbur wrote On 11/07/07 16:25,:
>[...] Yes, and the dialect of C I use most often will
>implicitly cast an int to a size_t as necessary. Does your
>compiler not support that feature?
[...]
ES In other words, what are you talking about? Can you give
ESan example?

Given the following declarations:

struct foo **foolist;
int i;
int num_foo;
int compare_foo (void *foo_one, void *foo_two);

and a prototype for qsort in scope, the following code:

qsort (foolist, last_foo, sizeof struct foo *, compare_foo);

may cause a warning at compile time because num_foo (an int) is used
when the prototype of qsort calls for a size_t, but the type
conversion from int to size_t is nonetheless performed.
Thanks; that makes sense (assuming last_foo is really
num_foo). The conversion is performed because that's what
C requires. C does not require the diagnostic, but the
compiler is always allowed to emit diagnostics that C
doesn't require.

--
Er*********@sun.com
Nov 8 '07 #26

P: n/a
>>>>"ES" == Eric Sosman <Er*********@sun.comwrites:

ESCharlton Wilbur wrote On 11/08/07 14:48,:
>>>>>>"ES" == Eric Sosman <Er*********@sun.comwrites:
ESCharlton Wilbur wrote On 11/07/07 16:25,:
>[...] Yes, and the dialect of C I use most often will >>
implicitly cast an int to a size_t as necessary. Does your >>
compiler not support that feature? [...]
ESIn other words, what are you talking about? Can you give an
ESexample?
> Given the following declarations:

struct foo **foolist; int i; int num_foo; int compare_foo (void
*foo_one, void *foo_two);

and a prototype for qsort in scope, the following code:

qsort (foolist, last_foo, sizeof struct foo *, compare_foo);

may cause a warning at compile time because num_foo (an int) is
used when the prototype of qsort calls for a size_t, but the
type conversion from int to size_t is nonetheless performed.
ES Thanks; that makes sense (assuming last_foo is really
ESnum_foo).

Yes; though I write code and posts in the same editor, the compiler
only checks my code.

ESThe conversion is performed because that's what C requires. C
ESdoes not require the diagnostic, but the compiler is always
ESallowed to emit diagnostics that C doesn't require.

Right. I was answering one of Malcolm's incorrect objections to
size_t, even though by now I should know better.

Charlton

--
Charlton Wilbur
cw*****@chromatico.net
Nov 8 '07 #27

P: n/a
"Charlton Wilbur" <cw*****@chromatico.neta écrit dans le message de news:
87************@mithril.chromatico.net...
>>>>>"ES" == Eric Sosman <Er*********@sun.comwrites:

ESCharlton Wilbur wrote On 11/07/07 16:25,:
>[...] Yes, and the dialect of C I use most often will
>implicitly cast an int to a size_t as necessary. Does your
>compiler not support that feature?

ES How can a cast be "implicit?"

Sorry, implicit type conversion, not implicit cast.

ES In other words, what are you talking about? Can you give
ESan example?

Given the following declarations:

struct foo **foolist;
int i;
int num_foo;
int compare_foo (void *foo_one, void *foo_two);

and a prototype for qsort in scope, the following code:

qsort (foolist, last_foo, sizeof struct foo *, compare_foo);

may cause a warning at compile time because num_foo (an int) is used
when the prototype of qsort calls for a size_t, but the type
conversion from int to size_t is nonetheless performed.
Actually, the code above fails to compile because sizeof requires
parentheses for a type argument. You probably meant to write sizeof
*foolist. Beware also that the comparison function compare_foo is a little
tricky: its arguments will need to be converted to struct foo **, not struct
foo *.

--
Chqrlie
Nov 8 '07 #28

P: n/a

"Tubular Technician" <no@spam.invalidwrote in message
news:36************@no.spam.invalid...
Andrey Tarasevich wrote:
>Tubular Technician wrote:
>>* size_t usage may be non-portable because it won't be around
anymore in 100 years.

Hm... I just don't know what to say about it. Doesn't make much sense.

IIRC, this claim was made in the big book discussion thread some time
ago and was given as a reason why the example code in said book does
not use size_t.
The vast majority of the functions in the book work on arrays whose
dimensions are unknown at the time of writing. However most will be small -
tan image could be of any dimensions, for instance, but in practise it is
most unlikely that any dimension would exceed a few thousand pixels.

The question is whether to got the size_t route. Which means that almost
every integer becomes a size_t. Most integers are ultimately used to index
arrays. Even a type field is often used as an index. There are exceptions,
for instance amounts of money, but not many.

My decision was no. I don't see a language that insists on

size_t N;
size_t i;

for(i=0;i<N;i++)
/* typical loop code */

catching on. People are going to want a more meaningful type name for a
standard, defualt index variable, which doesn't hold a size. Either the ANSI
committee will take down C, or the rule will be changed.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
Nov 8 '07 #29

P: n/a

"Charlton Wilbur" <cw*****@chromatico.netwrote in message
ESThe conversion is performed because that's what C requires. C
ESdoes not require the diagnostic, but the compiler is always
ESallowed to emit diagnostics that C doesn't require.

Right. I was answering one of Malcolm's incorrect objections to
size_t, even though by now I should know better.
If you convert from an int to a size_t the compiler is quite justifed in
warning about a signed to unsigned conversion. If you convert from a size_t
to an int it is quite justified in warning about the reverse, or maybe a
size truncation.

You can get round this problem by littering your code with casts. The
alternative of messing with warning levels isn't a route you can go down to
solve this problem, because you might need a higher warning level for other
purposes.

However it is tolerable.

The real fun starts when you start passing about integers by indirection, or
printing them out, or saving them to files. You can of course make code
work, though it is very easy to write something that will in fact break if a
size is greater than the range of an int, or sizeof(size_t) doesn't equal
sizeof(int). Array operations are so common that by introducing size_t you
have made a fundamental change to the language.

The real answer is to deprecate size_t, make int big enough to address any
array except huge char arrays (we can live with this little inconsistency),
and then introduce smaller types on 64 bit machines to aid the
micro-optimiser, who might want a fast but small integer. 64 bit int will be
reasonably fast on any practical 64 bit architecture, we are talking about
shaving off cache usage and cycles to squeeze out the last drop of
efficiency.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Nov 9 '07 #30

P: n/a

"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
news:as************@news.flash-gordon.me.uk...
Philip Potter wrote, On 08/11/07 09:58:
>Flash Gordon wrote:
>>typedef room_size_t whatever;

ITYM
typedef whatever room_size_t;

I do indeed. Thanks.
You want to declare a special symbol for the type that holds the number of
rooms in an adventure game?

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Nov 9 '07 #31

P: n/a

"Ben Bacarisse" <be********@bsb.me.ukwrote in message
>
At the time, size_t was a huge relief. Every project had decided how
to represent size_t things in its own way and this was very bad for
portability. Mandating int as the type for sizes would have meant
that millions of lines of code would have to be at least checked to
make sure that it would not break (either because of the performance
or because of pre-standards assumptions about the sizes of types).
size_t was good, and for those of up it helped, it has very few
negative connotations.

Now that we have it, we have to compare the costs and benefits of (a)
continuing to use it; (b) going the Malcolm McLean route. This is
where I get stuck on your argument. Used properly, size_t has almost
no costs. You can re-name it if you don't like the name and you can
reserve a few values for error returns if you like to play such tricks
(I raise these two because ugliness and negative error returns have
been cited as advantages of the MM way). What is the "size_t problem"
that your proposal tries to "solve"?
If everyone used size_t consistently there would be only two objections, the
ugliness of the name and the fact that it is unsigned. These are relatively
trivial. The fact is that they won't.
For instance one person complains with squeals of indignation when I suggest
making int 64 bit. That would slow down his code. Can you imagine that this
individual uses size_t consistently for an index variable? The real killer,
hower is the force of

size_t i;

when i is not a memory size, it is an index.

Renaming size_t yourself is a bad option. It's the bool problem writ large.
No one can call you unless they either adopt the same convention, or
decorate their fucntions with ugly hacks. A new fundamental type is a job
for a standards body.

The snag with inconsistent use of size_t is that you don't get the benefit
of it - the code will, in practise break if arrays overflow the size of an
int. You get the drawbacks - there are plenty of ugly underscores. And you
get an even worse drawback, because you've got more and more types swilling
around. The number of interconversion is N^2, by adding just one type we
have double the number of potential problems. They really hit when you start
passing variables about by indirection. That's when you find yourself
calling malloc() and writing a little conversion function, just to get the
list of indices into size_t format from int. Worse, it's probably a no-op.
So someone somewhere will just cast to an int *.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Nov 9 '07 #32

P: n/a
Malcolm McLean said:
"Ben Bacarisse" <be********@bsb.me.ukwrote in message
<snip>
>What is the "size_t problem" that your proposal tries to "solve"?
If everyone used size_t consistently there would be only two objections,
the ugliness of the name
No big deal. I never liked "int" either. I'd have preferred "integer". But
c'est la vie, n'est-ce-pas?
and the fact that it is unsigned.
No, that's an advantage.
These are relatively trivial. The fact is that they won't.
For instance one person complains with squeals of indignation when I
suggest making int 64 bit.
I have a better idea. Make int as big as you like, provided only that it's
*at least* 16 bits. Oh, but wait - that's what we have already.

If you want a 64-bit type, by all means make int 64 bits in *your* compiler
- but don't force that choice on the rest of us, please.

<snip>
The snag with inconsistent use of size_t is that you don't get the
benefit of it
Fine - so use it consistently. End of problem.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Nov 9 '07 #33

P: n/a
Malcolm McLean wrote:
underscores. And you get an even worse drawback, because you've got more
and more types swilling around. The number of interconversion is N^2, by
adding just one type we have double the number of potential problems.
No, by adding one type we increase the number of possible type
conversions by 2N - one from each type to the new type, and one the
other way. If it doubled, the number would be 2^N, not N^2.

Philip

--
Philip Potter pgp <atdoc.ic.ac.uk
Nov 9 '07 #34

P: n/a
Richard Heathfield wrote:
No big deal. I never liked "int" either. I'd have preferred "integer". But
c'est la vie, n'est-ce-pas?
But using 'int' keeps the word 'integer' free to talk about integer
types in general. I think this is an advatage.

--
Philip Potter pgp <atdoc.ic.ac.uk
Nov 9 '07 #35

P: n/a

"Philip Potter" <pg*@see.sig.invalidwrote in message
news:fh**********@aioe.org...
Malcolm McLean wrote:
>underscores. And you get an even worse drawback, because you've got more
and more types swilling around. The number of interconversion is N^2, by
adding just one type we have double the number of potential problems.

No, by adding one type we increase the number of possible type conversions
by 2N - one from each type to the new type, and one the other way. If it
doubled, the number would be 2^N, not N^2.
You are right of course.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Nov 9 '07 #36

P: n/a
Malcolm McLean wrote, On 09/11/07 10:06:
>
"Charlton Wilbur" <cw*****@chromatico.netwrote in message
> ESThe conversion is performed because that's what C requires. C
ESdoes not require the diagnostic, but the compiler is always
ESallowed to emit diagnostics that C doesn't require.

Right. I was answering one of Malcolm's incorrect objections to
size_t, even though by now I should know better.
If you convert from an int to a size_t the compiler is quite justifed in
warning about a signed to unsigned conversion. If you convert from a
size_t to an int it is quite justified in warning about the reverse, or
maybe a size truncation.
It is allowed to, but then it can warn about anything it likes.
You can get round this problem by littering your code with casts. The
alternative of messing with warning levels isn't a route you can go down
to solve this problem, because you might need a higher warning level for
other purposes.
Just disable the one warning. Most compilers support this.
However it is tolerable.

The real fun starts when you start passing about integers by
indirection,
Not a problem if if you are consistent.
or printing them out,
Not a problem in C99 since you need to know the type anyway.
or saving them to files.
Saving any integer type in its native binary format means the file won't
be portable anyway, that is nothing to do with size_t itself.
You can of
course make code work,
Yes, very easily.
though it is very easy to write something that
will in fact break if a size is greater than the range of an int, or
sizeof(size_t) doesn't equal sizeof(int).
Yes, and it is just as easy to write code that will break if int is not
32 bits.
Array operations are so common
that by introducing size_t you have made a fundamental change to the
language.
Well, it was introduced back in the late 80s and did not stop the
popularity of C. So now it is REMOVING it that would be a fundamental
change.
The real answer is to deprecate size_t, make int big enough to address
any array except huge char arrays (we can live with this little
inconsistency),
What give you the right to speak for everybody?
and then introduce smaller types on 64 bit machines to
aid the micro-optimiser, who might want a fast but small integer. 64 bit
int will be reasonably fast on any practical 64 bit architecture, we are
talking about shaving off cache usage and cycles to squeeze out the last
drop of efficiency.
Alternatively the minority of people who object to size_t can move to a
language without it or create their own language. Then the majority of
people won't have to put up with you ignoring the major problems your
proposed change would mean.
--
Flash Gordon
Nov 9 '07 #37

P: n/a
Malcolm McLean wrote, On 09/11/07 10:08:
>
"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
news:as************@news.flash-gordon.me.uk...
>Philip Potter wrote, On 08/11/07 09:58:
>>Flash Gordon wrote:
>>>typedef room_size_t whatever;

ITYM
typedef whatever room_size_t;

I do indeed. Thanks.
You want to declare a special symbol for the type that holds the number
of rooms in an adventure game?
If it's type might change, yes, and you were the one who suggested its
type might change.

I note you failed to answer the other points I raised.
--
Flash Gordon
Nov 9 '07 #38

P: n/a
Malcolm McLean wrote:
>
"Tubular Technician" <no@spam.invalidwrote in message
news:36************@no.spam.invalid...
>Andrey Tarasevich wrote:
>>Tubular Technician wrote:
>>>* size_t usage may be non-portable because it won't be around
anymore in 100 years.

Hm... I just don't know what to say about it. Doesn't make much sense.

IIRC, this claim was made in the big book discussion thread some time
ago and was given as a reason why the example code in said book does
not use size_t.
The vast majority of the functions in the book work on arrays whose
dimensions are unknown at the time of writing.
Array sizes need to be known at compile time; furthermore according
to ISO/IEC 9899:1999 5.2.4.1 a single object is not guaranteed to be
able to be larger than 65535 bytes, which according to 5.2.4.2.1 also
happens to be the guaranteed range of an unsigned int (UINT_MAX).
So an index type of unsigned int ("natural" int size?) seems perfectly
fine to me.

If you're talking about address (as obtained by malloc()) + offset,
size_t is already known due to inclusion of <stdlib.h>, and since
allocation size is of type size_t and offset may range from 0 to
(allocation_size-1), to me it always seemed natural to use size_t
for offsets as well.

The only inconsistency I can see is if using the sizeof operator in
a translation unit that does not include of any of the standard
headers providing the definition of size_t.
[why does the compiler know about sizeof but not about size_t? Or
rather, why is sizeof a keyword but size_t is not?]

However most will be small
- tan image could be of any dimensions, for instance, but in practise it
is most unlikely that any dimension would exceed a few thousand pixels.
It is quite common in interface functions to allow negative image
dimensions to indicate mirroring along that particular axis, which
means size_t may not be the best choice. When indexing into the
image's actual pixel values, however... see above.
The question is whether to got the size_t route. Which means that almost
every integer becomes a size_t.
How does that follow?
Most integers are ultimately used to index arrays.
Never heard of that theory.
Even a type field is often used as an index. There are exceptions,
for instance amounts of money, but not many.
?
My decision was no. I don't see a language that insists on

size_t N;
size_t i;
What if N is the result of sizeof? Then i needs to be able to represent
all values from 0 .. N-1. If not, why make them size_t in the first place?
for(i=0;i<N;i++)
/* typical loop code */

catching on. People are going to want a more meaningful type name for a
standard, defualt index variable, which doesn't hold a size.
If it doesn't hold a size, then why should it have some "standard" type?

What I was wondering in my original post is, if an object *does*
represent a size/index, but said value is neither the result of either
sizeof nor does it involve any of the standard library functions taking
or returning a size_t, how common is it to make it a size_t nonetheless?

Either the ANSI committee will take down C, or the rule will be changed.
?

Nov 11 '07 #39

P: n/a
Flash Gordon <sp**@flash-gordon.me.ukwrites:
typedef index_t size_t;
<nit>typedef size_t index_t;</nit>

.... and you saved me from having to reply to Malcolm. The anti-size_t
FUD needs to be refuted.

--
Ben.
Nov 11 '07 #40

P: n/a
Ben Bacarisse wrote, On 11/11/07 12:35:
Flash Gordon <sp**@flash-gordon.me.ukwrites:
>typedef index_t size_t;

<nit>typedef size_t index_t;</nit>
I'm doing well at that at the moment. I thought it the correct way
around, but typed it backwards.
... and you saved me from having to reply to Malcolm. The anti-size_t
FUD needs to be refuted.
Indeed. At least, for those without the experience and knowledge to spot
it for the stupidity it is or who might assume that there is actually
some basis to his claims beyond his own bias.
--
Flash Gordon
Nov 11 '07 #41

P: n/a

"Ben Bacarisse" <be********@bsb.me.ukwrote in message
Flash Gordon <sp**@flash-gordon.me.ukwrites:
>typedef index_t size_t;

<nit>typedef size_t index_t;</nit>

... and you saved me from having to reply to Malcolm. The anti-size_t
FUD needs to be refuted.
No good. Why not.

stringsup.h

typedef size-t index_t;

index_t charat(char *str, char ch);
The poor user

#include strsup.h /* I need charat, right */
void complex_parser(char *stuff)
{
index_t quote;

quote = charat(stuff, '\"');
/* wait a minute, index_t is now runnignt hrough all my code
Just so that I can use malcolm's charat() function. */
}
You do not define bool, string, or any other fundamental type in user code.
Because you then force everyone to either adopt your convention, or to
create a kludgy mess. You also do not define your own alias for size_t.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm


Nov 11 '07 #42

P: n/a
"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
>
Indeed. At least, for those without the experience and knowledge to spot
it for the stupidity it is or who might assume that there is actually some
basis to his claims beyond his own bias.
The claims have been justified time after time on this ng. Obviously not at
sufficient length to persuade those who are rather slow.

For instance a statistical analysis of some Java byte code was posted a
while back to convince you that most integers are used for index variables.
Remember that? Actually it something that any programmer with any
sensitivity know instinctively. However you didn't have the insight to
appreciate the relevance. Now you've decided that, because the great Flash
has managed to venture some criticism, however inane, there is "no basis" to
my ideas.

What arrogance.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Nov 11 '07 #43

P: n/a
"Malcolm McLean" <re*******@btinternet.comwrites:
"Ben Bacarisse" <be********@bsb.me.ukwrote in message
>Flash Gordon <sp**@flash-gordon.me.ukwrites:
>>typedef index_t size_t;

<nit>typedef size_t index_t;</nit>

... and you saved me from having to reply to Malcolm. The anti-size_t
FUD needs to be refuted.
No good. Why not.
If people don't learn how and when to use size_t then a real problem
does emerge.
stringsup.h

typedef size-t index_t;

index_t charat(char *str, char ch);
The poor user

#include strsup.h /* I need charat, right */
void complex_parser(char *stuff)
{
index_t quote;

quote = charat(stuff, '\"');
/* wait a minute, index_t is now runnignt hrough all my code
Just so that I can use malcolm's charat() function. */
}
No. It is almost as if we are talking about a different language.
You have not persuaded me in the past that the "poisoning" you think
happens is inevitable and I have failed to persuade you that it is not
a problem. We have both stated our cases (in other threads) and the
best thing is simply for others to decide for themselves. I don't see
any point in going over it again.

However, someone needs to cry "foul" (or at least "not agreed") if you
keep telling beginners that size_t will mess up their programs.

--
Ben.
Nov 11 '07 #44

P: n/a
"Malcolm McLean" <re*******@btinternet.comwrites:
The claims have been justified time after time on this ng. Obviously
not at sufficient length to persuade those who are rather slow.
I'd prefer to keep the debate as polite as possible. Both sides of
this debate (and as far as I can see you are alone on your side[1])
are having trouble getting through but calling me "slow" won't help.

[1] I don't mean people who find the underscore infelicitous. I mean
people who agree that it needs to be removed from the language to
ensure the survival of C.

--
Ben.
Nov 11 '07 #45

P: n/a

"Ben Bacarisse" <be********@bsb.me.ukwrote in message
However, someone needs to cry "foul" (or at least "not agreed") if you
keep telling beginners that size_t will mess up their programs.
I don't jump on every use of size_t in newbie code and say "aha, that will
be deprecated within ten years. Better take it out now".

However if someone starts a thread "what's the deal with size_t" naturally
I'll give my opinion, without claiming that it is the only one that can be
held.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Nov 11 '07 #46

P: n/a
Ben Bacarisse <be********@bsb.me.ukwrites:
"Malcolm McLean" <re*******@btinternet.comwrites:
>The claims have been justified time after time on this ng. Obviously
not at sufficient length to persuade those who are rather slow.

I'd prefer to keep the debate as polite as possible. Both sides of
this debate (and as far as I can see you are alone on your side[1])
are having trouble getting through but calling me "slow" won't help.
He didn't. He was referring to the more aloof arguing tactics of Flash
Gordon.
>
[1] I don't mean people who find the underscore infelicitous. I mean
people who agree that it needs to be removed from the language to
ensure the survival of C.
I certainly seem to have lost track of this ongoing saga. I thought most
of it was about people being anal in insisting size_t be used as an
index in a controlled program where the programmer knows full well that
a typical int/unsigned int is sufficient[1].

[1] And if he doesn't he should question whether he should be a
programmer of anything likely to perform.

Nov 11 '07 #47

P: n/a
Malcolm McLean wrote, On 11/11/07 18:10:
>
"Ben Bacarisse" <be********@bsb.me.ukwrote in message
>However, someone needs to cry "foul" (or at least "not agreed") if you
keep telling beginners that size_t will mess up their programs.
I don't jump on every use of size_t in newbie code and say "aha, that
will be deprecated within ten years. Better take it out now".

However if someone starts a thread "what's the deal with size_t"
naturally I'll give my opinion, without claiming that it is the only one
that can be held.
No, you claim it as absolute fact and claim to have proved it, which you
have not.
--
Flash Gordon
Nov 11 '07 #48

P: n/a
Richard wrote, On 11/11/07 18:11:
Ben Bacarisse <be********@bsb.me.ukwrites:
>"Malcolm McLean" <re*******@btinternet.comwrites:
>>The claims have been justified time after time on this ng. Obviously
not at sufficient length to persuade those who are rather slow.
I'd prefer to keep the debate as polite as possible. Both sides of
this debate (and as far as I can see you are alone on your side[1])
are having trouble getting through but calling me "slow" won't help.

He didn't. He was referring to the more aloof arguing tactics of Flash
Gordon.
I agree that he was probably referring more to me than Ben, although the
way it is phased says that it applies to everyone who has read the
threads and still disagrees with Malcolm.
>[1] I don't mean people who find the underscore infelicitous. I mean
people who agree that it needs to be removed from the language to
ensure the survival of C.

I certainly seem to have lost track of this ongoing saga. I thought most
of it was about people being anal in insisting size_t be used as an
index in a controlled program where the programmer knows full well that
a typical int/unsigned int is sufficient[1].

[1] And if he doesn't he should question whether he should be a
programmer of anything likely to perform.
Most of it from my side is against Malcolm's premiss that most integers
are used for indexing and his conclusion that size_t should be removed
from the language and int should become 64 bit on modern "64 bit"
processors. Oh, and the claims my Malcolm that any evidence presented
against his case does not count because it is only "a few little
exceptions" (or something, I can't remember his exact words) or gets
ignored.

I'm mainly of the opinion that people like Intel, the C standards
committee, the Posix standard committee et al know rather more than me
OR Malcolm on this subject and yet they all seem to have reached the
opposite conclusions to Malcolm (I almost said they disagreed with him,
but of course they have probably never heard of him).
--
Flash Gordon
Nov 11 '07 #49

P: n/a
Malcolm McLean wrote, On 11/11/07 17:19:
"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
>>
Indeed. At least, for those without the experience and knowledge to
spot it for the stupidity it is or who might assume that there is
actually some basis to his claims beyond his own bias.
The claims have been justified time after time on this ng. Obviously not
at sufficient length to persuade those who are rather slow.

For instance a statistical analysis of some Java byte code was posted a
while back to convince you that most integers are used for index
variables. Remember that?
Yes, and you should remember the number of people who came up with good
reasons why that did not prove your point.
Actually it something that any programmer with
any sensitivity know instinctively.
Ah, so you are claiming that everyone else on this group who has
expressed an opinion has no sensitivity. Interesting and almost
certainly wrong.
However you didn't have the insight
to appreciate the relevance.
You seem not to have the ability to see why it did not prove your point
despite the reasons being pointed out.
Now you've decided that, because the great
Flash has managed to venture some criticism, however inane, there is "no
basis" to my ideas.
Since you came up with that study after forming your opinion you formed
your opinion based on your own bias. Since many very good reasons why
that study did not prove your point were pointed out to you it is still
true that you have no basis other than your own bias for these claims.
What arrogance.
Ah, so someone who disagrees with you with reasons that have been stated
is arrogant. Where as you who disagree with the majority including such
luminaries as Intel, the C standards committee, those on this group who
know more than me about C and all the evidence presented to counter your
claims are not arrogant.

By the way, people have presented evidence as to why your claims are
wrong and why your study did not prove your point. I am fairly sure that
most was presented as evidence rather than proof. However, you are of
the opinion that any evidence presented against you does not count where
as when you present something it is proof.
--
Flash Gordon
Nov 11 '07 #50

89 Replies

This discussion thread is closed

Replies have been disabled for this discussion.