Proper way to input a dynamically-allocated string

[Michel Rouzic]

I know it must sound like a newbie question, but I never really had to
bother with that before, and I didn't even find an answer in the c.l.c
FAQ

I'd like to know what's the really proper way for input a string in an
array of char that's dynamically allocated. I mean, I wish not to see
any such things as char mystring[100]; I don't want to see any number
(if possible) I just want to declare something like char *mystring; and
then I don't know how allocate it with just as many chars (with the
space for the \0 of course) as you get from stdin.

I'd really like to know once for all what's the smartest way of
inputing strings from stdin and storing them in a way so they take just
the needed space and I don't want to see any number such as 100 or
10,000 or even 4,294,967,296 in my code. Any way it can be done?

[slebetman]

Michel Rouzic wrote:

Flash Gordon wrote:

It might not cause a segmentation violation. It might overwrite critical
data instead.

<snip>

so basically, as I said, if the user wants to input an mp3 file instead
of a .wav, it's at his own risk. And if you want to input an EOF
character at some point, well, it's at your own risk too, maybe one day
i'll bother with making some stuff to check that kind of foolishness,
but so far i've got more prioritary things to do than this kinda of
stuff (like making sure my program does what it's supposed to do)

The program crashing due to memory allocation error is the programmer's
foolishness for not checking the return value of realloc. No need to
punish the user for your own faults.

Checking for errors is not foolishness. It is the responsibility of the
programmer, more so in fact than the other 'priority' things like
adding features. This is because unchecked errors will cause those
wonderful features you've developed to fail at the most unexpected
times - like when demoing your app to your client.

When you program in C error handling, memory allocation etc. is the
responsibility of the programmer. This is because C is really nothing
more than 'high level assembly'. If you find this uncomfortable, and if
you insist on not checking errors, then don't write in C. Languages
like Tcl or Perl is more suitable. All the low level errors are already
handled by the people who wrote the interpreters in C so you don't have
to. Errors in scripting languages don't have the serious consequences
like in C.

[Christian Bau]

In article <e4************ @news.flash-gordon.me.uk>,
Flash Gordon <sp**@flash-gordon.me.uk> wrote:

One of the *first* things to worry about is making sure that your input
data is correct. As well as the reasons I've also mentioned, i.e. risk
of doing nasty things to your system, which are REAL risks, although the
most likely problem is corrupting either output OR input file (yes, the
input file CAN be corrupted). There is also the risk that the format
gets extended and a wav file contains things you don't handle properly,
causing your program to corrupt things despite being given a real wav file.

If the application that is programmed in such a careless way is
important and widespread, then some attacker will figure out how to
construct a file that will not only crash the computer, but will make it
do exactly what the attacker wants it to do.

[slebetman]

Christian Bau wrote:

In article <e4************ @news.flash-gordon.me.uk>,
Flash Gordon <sp**@flash-gordon.me.uk> wrote:

One of the *first* things to worry about is making sure that your input
data is correct. As well as the reasons I've also mentioned, i.e. risk
of doing nasty things to your system, which are REAL risks, although the
most likely problem is corrupting either output OR input file (yes, the
input file CAN be corrupted). There is also the risk that the format
gets extended and a wav file contains things you don't handle properly,
causing your program to corrupt things despite being given a real wav file.

If the application that is programmed in such a careless way is
important and widespread, then some attacker will figure out how to
construct a file that will not only crash the computer, but will make it
do exactly what the attacker wants it to do.

Yes! The infamous "buffer overflow".

[Malcolm]

"Michel Rouzic" <Mi********@yah oo.fr> wrote

ok cool, so why shouldn't I use an int for the size in a realloc, or
why again shouldn't I cast it to size_t?

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. 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.

[Ben Pfaff]

"Malcolm" <re*******@btin ternet.com> writes:

"Michel Rouzic" <Mi********@yah oo.fr> wrote

ok cool, so why shouldn't I use an int for the size in a realloc, or
why again shouldn't I cast it to size_t?

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.

I don't see why that is a problem. Much of my own code is
written that way. size_t is simply the natural type in C for the
size of something.
--
"Given that computing power increases exponentially with time,
algorithms with exponential or better O-notations
are actually linear with a large constant."
--Mike Lee

[Malcolm]

"Ben Pfaff" <bl*@cs.stanfor d.edu> wrote

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.

I don't see why that is a problem. Much of my own code is
written that way. size_t is simply the natural type in C for the
size of something.

I'm going to do a thread on size_t sometime soon.

You have illustrated the problem however. Once you allow size_t, almost
every integer becomes a size_t, because most integers count something.

[pete]

Malcolm wrote:

"Ben Pfaff" <bl*@cs.stanfor d.edu> wrote

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.

I don't see why that is a problem. Much of my own code is
written that way. size_t is simply the natural type in C for the
size of something.

I'm going to do a thread on size_t sometime soon.

You have illustrated the problem however.
Once you allow size_t, almost
every integer becomes a size_t,
because most integers count something.

Type int is good for return error codes or status codes.
Functions that do comparing, return type int.
A lot of stdio functions, return type int.

The number of nodes in a list, isn't tied to size_t.
I use long unsigned for counting those.

--
pete

[Flash Gordon]

Malcolm wrote:

"Ben Pfaff" <bl*@cs.stanfor d.edu> wrote

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.

I don't see why that is a problem. Much of my own code is
written that way. size_t is simply the natural type in C for the
size of something.

I'm going to do a thread on size_t sometime soon.

You have illustrated the problem however. Once you allow size_t, almost
every integer becomes a size_t, because most integers count something.

What is the problem with that? In any case, a lot of integers in code I
write are not counting the size of C objects (they might be scaled costs
which can even be negative, for example).
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Joe Wright]

Ben Pfaff wrote:

"Malcolm" <re*******@btin ternet.com> writes:

"Michel Rouzic" <Mi********@yah oo.fr> wrote

ok cool, so why shouldn't I use an int for the size in a realloc, or
why again shouldn't I cast it to size_t?

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.

I don't see why that is a problem. Much of my own code is
written that way. size_t is simply the natural type in C for the
size of something.

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.

It is interesting to have functions prototyped with size_t parameters to
indicate positive values. Otherwise, int works perfectly well for me.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Malcolm]

"Joe Wright" <jw*****@comcas t.net> wrote

#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.

It is interesting to have functions prototyped with size_t parameters to
indicate positive values. Otherwise, int works perfectly well for me.

Take this function

/*
trivial function that counts number of occurrences of ch in str
*/
mystrcount(cons t 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