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?

[Michel Rouzic]

Flash Gordon wrote:

Michel Rouzic wrote:

Eric Sosman wrote:

Other observations: `int' should probably be `size_t'

as for the size_t thing, well i could cast it for realloc, like this :
mystring=reallo c(mystring, (size_t) i+1);

Why on earth would you think that? You *really* need to start working
through a decent text book.

> other than that, I think i
should leave it to int, unless it is ok to do iterations and refer to
some element of an array by a size_t, which i doubt

Again, what on earth makes you think that? Of course you can use a
size_t variable for indexing in to an array.

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?

[pete]

Michel Rouzic wrote:

Flash Gordon wrote:

Michel Rouzic wrote:

Eric Sosman wrote:
> Other observations: `int' should probably be `size_t'

as for the size_t thing,
well i could cast it for realloc, like this :
mystring=reallo c(mystring, (size_t) i+1);

Why on earth would you think that?
You *really* need to start working
through a decent text book.

other than that, I think i
should leave it to int,
unless it is ok to do iterations and refer to
some element of an array by a size_t, which i doubt

Again, what on earth makes you think that? Of course you can use a
size_t variable for indexing in to an array.

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?

The integer parameter type of realloc is size_t,
so casting an int argument to type size_t, does nothing.

void *realloc(void *ptr, size_t size);

Do you have some resources available to learn about size_t?

--
pete

[websnarf]

Michel Rouzic wrote:

I know it must sound like a newbie question, but I never really had to
bother with that before,
Its not. Even experienced programmers seem not to know the proper
answer to this question (hint:fgets() is hardly adequate.)
[....] and I didn't even find an answer in the c.l.c FAQ
Not much of a surprise there.
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.
You have to understand, this is a foreign concept to many if not most
of the readers of this newsgroup. Every string container must have a
size, and "the C way" is to declare that size up front. You can search
the archives of this newsgroup to endless examples of this. The C
library is almost completely useless on this issue as well.
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?

You can read my solution to this problem here:

http://www.pobox.com/~qed/userInput.html

The key point is that the C standard library does not provide
provisions for reading a line of dynamically sized string. 1) gets()
is a deterministic overflow and 2) fgets() is inadequate. So no matter
what, for a really correct and useful solution you have to roll your
own algorithm (but it is doable as the link above demonstrates.)

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Keith Thompson]

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

Flash Gordon wrote:

Michel Rouzic wrote:

> Eric Sosman wrote:
>> Other observations: `int' should probably be `size_t'
>
> as for the size_t thing, well i could cast it for realloc, like this :
> mystring=reallo c(mystring, (size_t) i+1);

Why on earth would you think that? You *really* need to start working
through a decent text book.

> other than that, I think i
> should leave it to int, unless it is ok to do iterations and refer to
> some element of an array by a size_t, which i doubt

Again, what on earth makes you think that? Of course you can use a
size_t variable for indexing in to an array.

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?

Why *should* you use an int?

The second argument of realloc() is of type size_t. You can use an
int if like (it will be implicitly converted if you have a proper
"#include <stdlib.h>"), but there's no good reason to do so.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Maineline News]

sl*******@yahoo .com wrote:

Michel Rouzic wrote:

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?

From stdin is a bit of a problem. The usual answer is to use a
buffer to temporarily store the string:

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

.... snip code ...

Or you can get my ggets routine at:
<http://cbfalconer.home .att.net/download/ggets.zip>

--
"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

[Richard Heathfield]

we******@gmail. com said:

Michel Rouzic wrote:

I know it must sound like a newbie question, but I never really had to
bother with that before,
Its not. Even experienced programmers seem not to know the proper
answer to this question (hint:fgets() is hardly adequate.)

In my experience, you're wrong; how to do this is common knowledge amongst
experienced programmers.

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.

You have to understand, this is a foreign concept to many if not most
of the readers of this newsgroup. Every string container must have a
size, and "the C way" is to declare that size up front. You can search
the archives of this newsgroup to endless examples of this.

Most people who ask questions here are newbies, which is why they're asking
questions; that's why we tend to give them simple answers. Nevertheless,
the "how do I get an entire line of input" thing has been asked and
satisfactorily answered many times here.
The C
library is almost completely useless on this issue as well.

That's like saying the toolkit you get with a new bicycle is useless. Well,
yes, it's not brilliant - but it's probably enough to get you up and
rolling on Christmas Day. Serious users will want better in due course, and
quite a few solutions to this problem have been presented in this newsgroup
in the past.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Mark McIntyre]

On 9 Dec 2005 19:20:43 -0800, in comp.lang.c , we******@gmail. com
wrote:

Michel Rouzic wrote:

I know it must sound like a newbie question, but I never really had to
bother with that before,

Its not. Even experienced programmers seem not to know the proper
answer to this question

Don't be silly.

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];

You have to understand, this is a foreign concept to many if not most
of the readers of this newsgroup.

Absolute rubbish. Of course, I do realise you're trolling. But you
really are a chump.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[slebetman]

Michel Rouzic wrote:

Flash Gordon wrote:

Again, what on earth makes you think that? Of course you can use a
size_t variable for indexing in to an array.
ok cool, so why shouldn't I use an int for the size in a realloc,

Apart from the obvious fact that realloc is defined to accept size_t
instead of int, you should consider size_t to be self documenting. That
is, it is immediately obvious what the variable means:

int len;

Oh it's a number of how long something is.

size_t len;

Oh it is how long/large something is in memory.

or why again shouldn't I cast it to size_t?

Because, for very large arrays (I myself haven't seen arrays larger
than 2GB, but it is possible) on 64bit (or 128bit? someday...)
platforms, size_t may or may not be the same size as int. You don't
know, I don't know. But your compiler knows. Using size_t causes your
compiler to treat it properly. On 32bit platforms size_t may end up
being the same as an unsigned int anyway so don't worry about it
generating different code. Leave it to your compiler to decide.

[slebetman]

Michel Rouzic wrote:

Flash Gordon wrote:

Michel Rouzic wrote:

Keith Thompson wrote:

<snip>

> The speed of that code while reading input probably isn't going to be
> much of an issue, but the multiple calls to realloc() might cause
> excessive heap fragmentation, which could cause problems elsewhere in
> your program. (The standard does use the term "heap", but you get the
> idea.)

does it mean that the elements of my array won't be contigous?

No, it means the free space in your heap will be fragmented. Any memory
block returned by *alloc is always contiguous.

oh, thats what I thought. But, what are the consequences, I mean, I'll
have some memory occupied, some free space, and then my string, so, as
for the free space, does it mean it could only be used for something
smll enough to fit it, or otherwise it will just be wasted space?

The consequences is that sooner or later malloc/realloc will fail
because it can't find a contigous area of memory as large as the one
you requested. Coupled with your refusal to handle realloc failures,
this will result in a program crash.

[Flash Gordon]

Michel Rouzic wrote:

Flash Gordon wrote:

Michel Rouzic wrote:
<snip>
It might not cause a segmentation violation. It might overwrite critical
data instead.
um... i dont think you know what i'm refering to.

I do and you are WRONG.
The example I took is
the one of my program that reads .wav files to deal with them, without
checking that it actually is a .wav file. basically, it will just look
at a precise place in a file for a 32-bit integer telling how many
bytes are to be read in the file. If you try to input a non .wav file
instead, the 32-bit integer read will be bogus, and is likely to have a
value much higher than the number of bytes left in the file, so the
program will try to read even after the it has read the whole file,
thus causing a segmentation fault.
There is absolutely NO guarantee that is will cause a segmentation
fault. For a start that is a term that is not defined in the C standard,
secondly it is a term not applicable to all systems, thirdly almost any
action that could cause a segmentation fault could *also* overwrite some
critical data used by your application, such the FILE structures,
possibly causeing corruption of files on disk.
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)

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.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.