Printable View
Hello everyone,
I have just started programming in Linux.I tried this basic program :
This gives a segmentation fault in Linux but it runs perfectly on Borland C++ in Windows.Code:#include<stdio.h>
int main()
{
char *buffer;
scanf("%s",buffer);
printf("\n%s\n",buffer);
return 0;
}
How can I avoid this problem?
buffer needs to be allocated some space.
Like
char buffer[100];
> This gives a segmentation fault in Linux but it runs perfectly on Borland C++ in Windows.
That's just dumb luck. Sometimes code just works despite all attempts to make a mess of it.
But just because it seems to produce the correct answer doesn't make the code correct.
On using char buffer[100],I am limited to only 100 characters.Suppose I have a string of say 1000 characters it causes an overflow.Though,I can use malloc() I need to know the number of bytes to be allocated to the string.Suppose I don't know this value what should I do?
What exactly I am trying to do is accept a string of unknown length i.e the length is known only after the user enters the string.
You can't input a string of unknown length directly. You have to read it in in fixed sized blocks (of known size), then keep extending the space allocated until you reach whatever it is that terminates the input.
In other words, fget() + malloc() + a loop of some sort.
fgets...Quote:
Originally Posted by Salem
fgets() is not as simple as it looks.Quote:
Originally Posted by vart
If the line is longer than the buffer size, then the result will be truncated. The only way to detect this is to check if the final character in the buffer is '\n'. If it's not, you still are not sure whether a truncation occurred, because it could merely be that the last line in the file did not have a newline at the end of it. So if there is no trailing '\n' you additionally have to check feof().
When you code all this up, you actually end up with something that looks pretty terrible, whereas the simpler implementation based on fgetc() and dynamically resizing the buffer is actually a lot easier to understand.
Thats something I had never realised. However considering that the OP is reading in data from the keyboard I would have thought that the input would be guaranteed to to end in a newline, which would mean means that in this case it would be possible to check for truncation.Quote:
fgets() is not as simple as it looks.
If the line is longer than the buffer size, then the result will be truncated. The only way to detect this is to check if the final character in the buffer is '\n'. If it's not, you still are not sure whether a truncation occurred, because it could merely be that the last line in the file did not have a newline at the end of it. So if there is no trailing '\n' you additionally have to check feof().
When you code all this up, you actually end up with something that looks pretty terrible, whereas the simpler implementation based on fgetc() and dynamically resizing the buffer is actually a lot easier to understand.
In theory, stdin could have been redirected from some other source, and could contain a final line with no trailing newline.Quote:
Originally Posted by mike_g
fgets() has other dangers, such as if the input contains '\0'. If you think about it, you realize that there is actually no way to determine how many characters were read by fgets(). And therefore, no way to actually check the last character to see if it's '\n' (because you have no way of knowing where the last character is, if '\0' is thrown into the mix).
Writing robust line getting functions is stupid-hard. The GNU C library has a non-standard function called getline() which does it for you. I was kind of shocked that it didn't make it into C99. So we're still left rolling our own implementations of a basic function that should have been part of the standard to begin with. It sucks.