questions about size_t

[edware]

Hello,
I have some questions about the size_t type.
First, what do we know about size_t? From what I have
read I believe that it is an unsigned integer,
but not necessarily an int. Am I correct?

Does this mean that if I need to compare two variables,
one of the size_t type, should the other also be a size_t
variable? There could be problems if I compare it with an
int, if those have different sizes, right?

Most of the time when I make for loops, I use an int variable
as index, like for (int i = 0; ...)
Should I change that to size_t if I need to compare the i
variable with the return value of strlen(), for example?

I think that just adds more things to think about,
wouldn't it be easier to just use an unsigned int, instead
of the size_t variable for strlen, sizeof, etc. ?

Whats the benefit of size_t?
Is there advantage using it for your own stuff, like
struct {
size_t size;
void *stuff;
};
or
make_balloon(size_t balloonsize);

or should it only be used for the standard functions?

[void * clvrmnky()]

edware wrote:

Hello,
I have some questions about the size_t type.
First, what do we know about size_t? From what I have
read I believe that it is an unsigned integer,
but not necessarily an int. Am I correct?
size_t is an unsigned integer type large enough to hold the value
returned from sizeof. The actual int types that correspond to size_t
can vary.
Does this mean that if I need to compare two variables,
one of the size_t type, should the other also be a size_t
variable? There could be problems if I compare it with an
int, if those have different sizes, right?

Most of the time when I make for loops, I use an int variable
as index, like for (int i = 0; ...)
Should I change that to size_t if I need to compare the i
variable with the return value of strlen(), for example?
Since size_t is defined as being unsigned, as long as you are sure your
int is not negative, the implicit casting (and I'm fuzzy on that) during
the compare should be ok.
I think that just adds more things to think about,
wouldn't it be easier to just use an unsigned int, instead
of the size_t variable for strlen, sizeof, etc. ?
Well, since size_t will always fit whatever sizeof can return, I'm
thinking that an int type holds an integer value and a size_t type
definitions hold some sort of size representation. Indeed, these are
closely related, but the size of an object is certainly different than
the value of it.

So, those functions that depend on sizes would be more correct in using
one of the type definitions (e.g., wchar_t, size_t).
Whats the benefit of size_t?
Is there advantage using it for your own stuff, like
struct {
size_t size;
void *stuff;
};
or
make_balloon(size_t balloonsize);

or should it only be used for the standard functions?

A good question. I pretty much use integer types interchangeably,
though I'm sure I'm missing something.

[Walter Roberson]

In article <Gl*******************@newsb.telia.net>,
edware <er***@hotmail.com> wrote:

I have some questions about the size_t type.
First, what do we know about size_t? From what I have
read I believe that it is an unsigned integer,
but not necessarily an int. Am I correct?
Right -- for example it might be unsigned long long .
Does this mean that if I need to compare two variables,
one of the size_t type, should the other also be a size_t
variable? There could be problems if I compare it with an
int, if those have different sizes, right?
The int would be promoted to the appropriate size and converted to
unsigned before the comparison. If the int happens to be negative,
you had better know what you are doing...

Most of the time when I make for loops, I use an int variable
as index, like for (int i = 0; ...)
Should I change that to size_t if I need to compare the i
variable with the return value of strlen(), for example?
As long as the int values are non-negative, the compiler will take
care of the details in the way you would expect.
I think that just adds more things to think about,
wouldn't it be easier to just use an unsigned int, instead
of the size_t variable for strlen, sizeof, etc. ? Whats the benefit of size_t?
Is there advantage using it for your own stuff, like
struct {
size_t size;
void *stuff;
};
or
make_balloon(size_t balloonsize); or should it only be used for the standard functions?

size_t measures the size (in bytes) of an object. You might happen
to be compiling and executing on a system in which the maximum allocatable
memory was (say) 32 terabytes, but for which the standard unsigned int only
goes to (say) 65535 or [more commonly these days] 4294967296 (4 gigabytes).

int is more or less the "natural" computation size for "most" problems,
not too big and not too small -- but there are times when you need
a lot more range, even if the extended range is slower to compute with.
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest

[pete]

edware wrote:

Hello,
I have some questions about the size_t type.
First, what do we know about size_t? From what I have
read I believe that it is an unsigned integer,
but not necessarily an int. Am I correct?
Yes.
Does this mean that if I need to compare two variables,
one of the size_t type, should the other also be a size_t
variable?
There could be problems if I compare it with an
int, if those have different sizes, right?
Don't worry about comparing different size types.
I do make it a point however,
to compare signed types to signed types
and unsigned types to unsigned types.
Most of the time when I make for loops, I use an int variable
as index, like for (int i = 0; ...)
Should I change that to size_t if I need to compare the i
variable with the return value of strlen(), for example?
I probably would.
Whats the benefit of size_t?

unsigned, might not be large enough to do the job of size_t.
unsigned long, might be slow.
size_t has the ability to be the fastest type,
that is also big enough to do the job.

--
pete

[Ben Pfaff]

pete <pf*****@mindspring.com> writes:

edware wrote:

Hello,
I have some questions about the size_t type.
First, what do we know about size_t? From what I have
read I believe that it is an unsigned integer,
but not necessarily an int. Am I correct?

Yes.

*Definitely* not an int, because that's not an unsigned integer
type.
--
"Some people *are* arrogant, and others read the FAQ."
--Chris Dollin

[edware]

Ben Pfaff wrote:

pete <pf*****@mindspring.com> writes:

edware wrote:

Hello,
I have some questions about the size_t type.
First, what do we know about size_t? From what I have
read I believe that it is an unsigned integer,
but not necessarily an int. Am I correct?

Yes.

*Definitely* not an int, because that's not an unsigned integer
type.

I meant a unsigned int.