A better and standard compliant way is to just write your own getline() equivalent and make sure it's rock solid and use it everywhere. Or to find a good library that does it for you and use that. You can also just be fine with the fact that you might have more of the line in the buffer than you've read and just skip what's left since that's very likely what most people will do anyway.

You're welcome!

Agreed: "I'd rather read in the whole shebang using fgets() and tokenize the whole bunch myself" As part of my training as a C beginner, I wrote all the string handling myself and getchar() would be my first try.

I know how you feel. When I first implemented my own libc I couldn't stand doing things in just the way the standard defined and wound up just writing a completely new definition of a library from scratch. I wound up adding data structures and algorithms and still use it to this day for all of my in-house projects.

I'm afraid this format only works with printf: printf("%.*s", 5, "Hello World!"); // Hello not scanf.

It is not supported anywhere. Precision specifier is only printf thing.

@@infastin3795 perhaps I mis-remembered then, oh well, I'm making a library that'll be a possible stand in replacementment of libc etc, not for the symbols like musl, but for cross platform stuff, it's called paw, everything is prefixed with paw as well so they can be used together, I'll post a link eventually once I'm satisfied the 1st version is reasonably feature complete, including threads, mutices, semaphores, graphics, ux, all that "fun" stuff that stdc chose to ignore at the start

@@zxuiji Good, everyone should do that at least once in their career, especially if they intend on seriously using C.

@@anon_y_mousse What, make a library? Make a custom printf/scanf? You weren't clear as to which of my comments you were replying. Side note, just yesterday I managed to finish my pseudo mutices, the main issue I always had with pthread_mutex_t etc is that it was never defined exactly what happens when a thread tries to delete the mutex at the same time another tries to lock it, after a number of re-thinks I finally arrived at an octal permissions based design. The mutex requires data to be attached to it during creation along with a type string & callback for what it should do when deleting said data (which can only be triggered when no thread is capable of attaching to the mutex), as a bonus I added a couple of prev/next pointers to create a linked list GC with, the only time the GC is ever searched is when a thread declares it is abandoning all mutices it has permission to attach to, the owning thread ends up in a blocked state but the rest just happily kill their own permissions and attachment count. It was a real task to create such a mutex but now I'm comfortable using it in a multi-threaded environment since I know exactly what will happen if one thread tries to delete the mutex while another is trying to lock it, the delete will just not happen because it will detect other threads still have permission to attach and just refuse to remove the owner's permissions when it tries, the owner's permissions have to be removed before deletion is triggered so the only way for something unexpected to happen is if the dev is being stupid by not clearing their pointer after revoking the permissions of their thread.

There is a width option "*" for scanf. You add an extra item in the parameter list for the width. Example: char name [20]; scanf ("%*s", sizeof name - 1, name); Works too if the size is not a literal, but a parameter to your function.

@@Hauketal it doesn't work. the `*` skips stuff. you're thinking of the `*` for `printf`.

True. I needed to do that myself - and in order to achieve that (portable across several very different platforms and compilers) I had to read it until EOF.

​@HansBezemer which should not work since stdin is never eof. The terminal just pauses your program and prompts when the buffer is empty.

@@5cover The stdin can have an EOF. try to run ./myprogram < test.txt The stdin will be the file "test.txt" and it will reach EOF.

This will result in bad values for anything entered before '0', like '+'.

@@Hauketal That's fine, you're supposed to check for that yourself if you want to support it, the ONLY purpose of this function is to read digits, that can then be used by wrapper functions that need it, like floating point number readers for instance

ungetc

Most formats including "%s" consume and discard leading whitespace characters. Only "%c", "%[...]" and "%n" don't.

You can read input into a buffer with fgets, then process that data with sscanf was something he said. Using scanf is OK in personal programs but not in general professionally. In general reading a file format, you analyse the input returning a token to say what type of input text you found and have the value available, converting a string of digits into a number. It's called lexical analysis and parsing for the grammar rules. That way you can detect errors and avoid buffer over runs and overflow.

It should now be available on my store

Because scanf was designed to read trusted data (such as formatted data in files), it needs not check for errors. The C standard library doesn't offer a way to read user input from the console because there was no need for it. I mean, have you ever performed console input in a "real" project? Apart from the usual (y/n) confirmation (which can trivially be implemented with getchar, as you only need to read a single character), you seldom see console user input as all the information necessary is specified in the command parameters. But it's easy to implement it using fgets and functions such as strtol.

Rust is no

@@sumofat4994 Rust is trust

@@sumofat4994 Rust at least "meh". Meh, enough for Linux to consider adding support for it.

@@0xDEAD-C0DE Rust is slow and bloated.

@@0xDEAD-C0DE You are delusional.

@@rustycherkas8229 Sorry, my mistake in the line scanf(tmp, &a); but the program will still work. I got lucky here 🤓 The address of an entire array has the same value as the address of the first element of the array.

@@CCoder-- I've deleted my comment. You're right about the array, and about "getting lucky"... Suggest you "tweak" the code to avoid pedantic comments from pedantic people like me... 😁

@@rustycherkas8229 no It's all right😀, pointers are a bit confusing. You can keep your previous comment to help others understand.

@@CCoder-- Kinda sorry I brought it up... @06:35 Jacob makes a point about dropping the "address of" from "&name"... imho, better that it is NOT present for those times when a block of code is factored out into a separate function... Easy to overlook an array becoming a pointer only (received as a parameter.) AND, it confuses the sh*t out of newbies, too! 🤣That's worth a LOT.... 🤣🤣🤣

Careful and defensive programming prevents almost all buffer overflows. Also very effective against memory leaks.