[SOLVED] Gets() behaving like fgets()?


#42

As for the way things output, that’s all in how the print formatting ends up. Did the input include the ‘\n’? Did it have a ‘\0’? If so(if not), where did they end up? How did it affect the output? See where I’m going with this?


#43

I think the extra overflow characters you question at one point are a demonstration of how memory is allocated and the way printf works. Until the program exits that memory that is still recently allocated to the program is still accessible. So if the input provided to printf didn’t have a terminating ‘\0’ it would continue reading the bytes of memory until one is found, another means of termination comes along, or it runs out of allotted memory to read.


#44

Ahhhhhhhhhhhhhh, because Unix isn’t about prompting the user for input. It’s about chaining stdout to stdin, and if fgets flushed the input it’d drop piece of the input. Imagine you’re making a copy of the cut command and it has to work like this:

ls | cut -d ' ' -f 1

Now, if fgets by default cleared the input buffer the your cut would read one line of the ls command, clear the rest, and miss lines. Instead fgets buffers the ls input for you so that you can work on it without losing any.


#46

My final solution for ex24 after all the extra credit provided the most reliable string input scan I’ve come up with so far. Essentially I scanned ALL the input the user provided up til, but not including, the ‘\n’ (when enter is pressed). It only retains up to the max number of characters and it always ends the final result with ‘\0’. The checks are catching the /dev/urandom input too. The program exits at the checks (in the main function) instead of a system error. Overall I’d say I did alright and the underlying input feed issue in this thread is handled.

ex24.c:Scan_chars()
int Scan_chars(char *dest, size_t max)
{
    int n = -1; int count = 0;
    char ch = -1;
    while (ch != '\n') {
        n = scanf("%c", &ch);
        if (n == 0 || ch == 0) break;
        if (count < max && ch != '\n') {
            dest[count] = ch;
            count++;
        }
    }
    if (count == 0) { 
        return -1;
    } else if (count == max) {
        dest[max - 1] = '\0';
    } else {
        dest[count] = '\0'; 
    }

    return 0;
}

#47

Nice! Always remember though that you are only reducing the probability of a bug when you code C. There are so many undefined behaviors in C that you have no idea if you’ve really made it secure or not.


#48

Not perfect of course. I’m really starting to understand how C’s roots created it’s unpredictable nature and how undefined behavior was uncharted waters until we learned how to navigate them. Your course is a perfect example of how we have to be very definitive in our code and despite our best efforts there’s always undefined behavior to consider. Thankfully there’s a lot of experienced developers who have shared a wealth of knowledge over the years. It’s nice that C continues to improve and it’s still a widely used & well supported language. Plus there’s a lot of bad code out there to fix so we have plenty of work cut out for us lol.