Excess buffer using fgets

This is a discussion on Excess buffer using fgets within the C Programming forums, part of the General Programming Boards category; Hi to all... I checked the FAQ and some tutorials over the net regarding not use
scanf or gets just ...

Excess buffer using fgets

Hi to all... I checked the FAQ and some tutorials over the net regarding not use
scanf or gets just use fgets to control buffer. I created this code for a test but it seems
like the excess buffer is not removed but the other fgets received it and it won't allow
me to input another value.

By associating with wise people you will become wise yourselfIt's fine to celebrate success but it is more important to heed the lessons of failureWe've got to put a lot of money into changing behavior

The size of the string is 22, if I entered more than 22 the age input will accept the excess buffer that was from the first input. So I can't input for the age at all and the age will print out the excess from the first input.

I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.

EDIT:
OK, so what I've found is that while it is in fact portable (standard-compliant), it isn't necessarily implemented correctly on all systems. But it should work on most. Also, you could probably compress it into a single fseek by specifying SEEK_END (and 0 for the offset, of course).

I learned from a thread one thing that returning strings might result in a pointer which might be pointing to the string which is not present there. So, wouldn't this declaration be more safe than yours.

By associating with wise people you will become wise yourselfIt's fine to celebrate success but it is more important to heed the lessons of failureWe've got to put a lot of money into changing behavior

The problem with that, though, is that tries to read from the input even if there's none available.

I think that that would result in EOF being read. But I see what you mean: if this was keyboard input, there would be a problem, but we should be able to cater for keyboard input... I'll post later if this has not been addressed by the time I get back.

Originally Posted by BEN10

I learned from a thread one thing that returning strings might result in a pointer which might be pointing to the string which is not present there. So, wouldn't this declaration be more safe than yours.
Code:

The function returns a pointer that was passed to it, so if the pointer points to something that exists in the caller, the caller will receive a pointer to something that exists. There is no problem.

I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.

>> I learned from a thread one thing that returning strings might result in a pointer which might be pointing to the string which is not present there. So, wouldn't this declaration be more safe than yours.

It depends on the function, but fgets, specifically, is guaranteed to return a pointer to the buffer, unless an error occurs, in which case it returns NULL.