Thread: Maximum array size (char) to input a double

BUFSIZ would be my suggestion.

But then again, I would probably use BUFSIZ for reading ALL input, then validate whatever was typed in, just to minimise the problems of the user being a moron and typing excessively long lines of rubbish just to see if they can break your code.

For a double, you need about 15 decimal digits to fill the precision available.

myprog < myprog
is an extreme test of the input handling capabilities of your program

Originally Posted by Salem

BUFSIZ would be my suggestion.

But then again, I would probably use BUFSIZ for reading ALL input, then validate whatever was typed in, just to minimise the problems of the user being a moron and typing excessively long lines of rubbish just to see if they can break your code.

For a double, you need about 15 decimal digits to fill the precision available.

myprog < myprog
is an extreme test of the input handling capabilities of your program

Just bear in mind that floating point numbers can be expressed sub-optimally, e.g. using extra zero's at either end of the number, and easily reach into the 50's or 100's of digits and still be valid input for a double.

And if you do use a buffer that is shorter than bufsiz, at least make sure that the line you read through fgets() is complete - if it's not a complete line, ask the user to enter again [after clearing the buffer as per the FAQ]. Otherwise, you may find that you read something like this:

Code:

char buffer[20];
double d;
int x;
fgets(buffer, sizeof(buffer, stdin);
d = strtod(buffer, ...);
fgets(buffer, sizeof(buffer, stdin);
i = strtol(buffer, ...);
printf("i=%d, d = %f\n", i, d)

Feed that with
0.00000000000000000012345
4711
and you see the ouput of

Code:

0.00000
12345

--
Mats

> a double is 8 bytes. so
Which as nothing at all to do with it's representation as a string.

That would only accommodate 7 digits (excluding the dot), so up to around 99 999 999 or -9 999 999 or 0.999 99 or -0.9999.
Hmm. Not very long.

BUFSIZ is a standard constant for "the buffer inside a FILE struct".

--
Mats

Yes, a fputs() of a large block will take size/BUFSIZ number of actual write operations - if you don't want that behaviour, you need to use fwrite() or a lower level write operation - it is normally not a problem.

In the header file you are showing, it seems that PowerPC has a 4KB memory buffer, other architectures have 512 byte buffer. Why? Who knows - perhaps something in the PowerPC architecture makes it important that the buffer is 4KB...

--
Mats

> 1. Why should I use BUFSIZ ?
It exists to be used.

It may also signify to the reader that the buffer is only temporary and that any data read into the buffer is also temporary, and needs to be validated before being moved to the correct place in memory.

It also saves programmer decision time in trying to decide just how big to make the buffer. Excessive squeezing of a few bytes as in abachler's example leads to all sorts of other side effects like forgetting to count the newline AND the \0.

A couple of dozen "magic number" sizes all through the code may leave you wondering what's going on and what's safe to change. A consistent size may give you more confidence.

> Is BUFSIZ is stdin buffer size too ?
Yes, there's no problem using BUFSIZ for stdin.
Remember, stdin may be redirected from a file on some systems.

> Why BUFSIZ can be 4096 or 512 ?
It depends on the architecture (in your example). The system implementers have decided that on a PowerPC a size of 4096 is a better answer than 512.