Proper way to input a dynamically-allocated string

[Joe Wright]

Take this function

/*
trivial function that counts number of occurrences of ch in str
*/
mystrcount(const char *str, int ch)

Now basically this function is alwaysgoing to return small integers.
However, technically, someone could pass it a massive string, all set to one
character. Then an int would overflow, if size_t were bigger than an int.

Size is not interesting. The maximum value of size_t and int are the
same (on my 32-bit Intel machine). There is no case (that I know of) for
an object representation to be larger than 2^31 bytes because the high
order 2 Gigs is reserved for the OS.

Thus the function must return a size_t.

If the value of size_t cannot exceed INT_MAX, what's the point?

 

[Ben Pfaff]

I have seldom defined a variable of type size_t. On DJGPP..

typedef long unsigned int size_t;

..is its declaration. In limits.h I find..

#define SSIZE_MAX 2147483647
#define INT_MAX 2147483647
#define LONG_MAX 2147483647L

..and so see no compelling reason to type anything size_t rather than int.

If you're only interested in your implementation, then that's a
reasonable point of view.

 

[Jordan Abel]

If you're only interested in your implementation, then that's a
reasonable point of view.

plus, that's SSIZE_MAX, which applies to the posix type ssize_t, not the
C type size_t. SIZE_MAX is probably twice that, being unsigned.

 

[Keith Thompson]

Take this function

/*
trivial function that counts number of occurrences of ch in str
*/
mystrcount(const char *str, int ch)

Now basically this function is alwaysgoing to return small integers.
However, technically, someone could pass it a massive string, all set to one
character. Then an int would overflow, if size_t were bigger than an int.

Thus the function must return a size_t.

That means that the higher-level logic which calls it must also be written
with size_t, and the ugliness propagates

I fail to see what's ugly about it. What's wrong with using size_t to
represent sizes? That's what it's for.

 

[Keith Thompson]

Size is not interesting. The maximum value of size_t and int are the
same (on my 32-bit Intel machine). There is no case (that I know of)
for an object representation to be larger than 2^31 bytes because the
high order 2 Gigs is reserved for the OS.

Yes, *on your 32-bit Intel machine*. That's fine if you don't care
about portability. (Personally, I like my code to be reasonably
portable even if it's only going to run on one platform.)

If the value of size_t cannot exceed INT_MAX, what's the point?

Clarity and portability.

 

[Jordan Abel]

That is not true. the macro you are looking at is not the one that
defines the maximum value for size_t.

Note teh extra "S". That is talking about the posix typedef "ssize_t".

 

[Michel Rouzic]

size_t is an uglification that will run through all your code, wrecking its
readability and elegance, as every memory size, and hence every array index,
and hence every count, has to be a size_t.

There are many subtle problems with the use of unsigned integers.

Yeah I know that. Once i performed a division by an unsigned int minus
another unsigned int, the problem was that the first one was always
smaller than the second, so my result was about one billion times as
small as it was expected to be. I tend to avoid using unsigned integers
since then, most of the time i'm not even ever getting close to 2
billions in my integer values..

Java
eliminated them, for very good reasons.
The problem with using integers, on the other hand, is largely theoretical.
The maximum memory size allowed by a compiler may exceed the size of an
integer.
It is perfectly plausible that a company may have more than 32767 employees.
It is also perfectly plausible that a C program may have to run on a machine
where int is 16 bits. It is not plausible that you will want to run the
payroll for a company with more that 30,000 employees on a machine with
16-bit integers. Hence we can happily use an int to hold the count of
employees, or a long if really paranoid.

I tend to write int32_t instead of int, and include stdint.h, so I know
I make sure that on every platform i'll be using 32 bit integers. some
people reported that it couldnt compile with their compiler tho, I
guess it's some C99 stuff.

 

[websnarf]

I tend to write int32_t instead of int, and include stdint.h, so I know
I make sure that on every platform i'll be using 32 bit integers. some
people reported that it couldnt compile with their compiler tho, I
guess it's some C99 stuff.

Yeah, there's no reason to do that. I've written a stdint.h
alternative called "pstdint.h" which you can obtain here:
http://www.pobox.com/~qed/pstdint.h . Its a plug-in replacement for
stdint.h (its just missing a few things like WINT_MAX which nobody
should care about anyways) that has a much higher chance of being
portable to most people's platforms.

 

[Stan Milam]

Yeah I know that. Once i performed a division by an unsigned int minus
another unsigned int, the problem was that the first one was always
smaller than the second, so my result was about one billion times as
small as it was expected to be. I tend to avoid using unsigned integers
since then, most of the time i'm not even ever getting close to 2
billions in my integer values..

Java is inferior