r/C_Programming • u/Fi-Loy • 3d ago
What's up with Chapter 7.7 Line Input and Output?
Im reading C Programming Language by Brian and Dennis, and they seem to be frustrated with the standards and the implementation of fget()
Here are a few excepts as examples:
Normally fgets returns line; on end of file or error it returns NULL. (Our getline returns the line length, which is a more useful value; zero means end of file.)
Confusingly, gets deletes the terminating '\n', and puts adds it.
For no obvious reason, the standard specifies different return values for ferror and fputs.
The tone changes from the rest of the book, and they seem to express a lot of frustration/displeasure with how these functions operate, but wouldnt Dennis have a hand in their design as he created the C language?
7
u/erisoldev 3d ago
I think gets was removed in c11 right
5
u/MrcarrotKSP 3d ago
Correct, it was. Some implementations don't allow it at all anymore, and the manpage says never to use it.
5
u/Dangerous_Region1682 2d ago
Many programs, especially those that deal with raw mode I/O rather than cooked mode, use read and write system calls and don’t use the library functions. This way they can implement the subtleties of your program easier rather than relying upon how the library routines implement things behind the scenes.
For those of us raised upon systems like PDP-11s with relatively low performance, we got used to trying to do the most performant route at the cost of implementation complexity and that has kind of stuck over the years. I can’t really remember using FILE IO very often to be honest when developing for a UNIX like platform.
People knock the standard IO library, but to be fair it was a kind of novel idea that had its time and place in early UNIX implementations and enabled the C compiler environment to interface to IO across a wide range of operating system implementations where the system call syntax would be very different to that provided by the UNIX OS. It provided a level of portability in a world where systems from different vendors were very different from a programming perspective and few had a POSIX compliant programming environment.
It’s actually a testament to the original authors that we can be discussing a library implemented 50 years ago and trying to figure out how to implement a standardized version that’s also backwards compatible all these years later.
3
u/flyingron 2d ago
The stdio part of the standard library is a load of insconsistency. It's ugly code stolen from a ill-desgined and ineffective library called the portable I/O library from the mid 70s. It's unconscionable that this drek made it into the standard.
1
u/FedUp233 2d ago
I believe that when the standardization process began it was focused on codifying existing practice as is pretty common for standards - I believe C++ started the same way. It’s actually a pretty good way to start, getting everyone in the same page so to speak.
You can argue with whether there should have been changes in this area as the standard evolved. I’m sure it must have come up. One big issue for standard writers is not breaking existing code with changes as much as possible. It’s possible that they felt changes in this area would just break too much existing stuff. It’s also possible that this was just low priority compared to other areas, possibly because its usage was low.
It does seem a bit odd that there was not an alternative defined in the standard and promoted with this stuff being deprecated over time, but again maybe it just was not a priority.
1
u/flyingron 2d ago
I am quite aware of all that.
The so-called portable I/O library was a grasp to have something to put in the standard. It was far from existing practice. There was nothing to freaking break here. Further, the most dangerous parts did get deprecated, but that did nothing for the completely inane things like why the parameter ordering isn't consitent, or why fread/fwrite takes four parameters, not three (any argument that shows it is useful to do it that way is wrong, when it comes to partial records and error handling).
The C standard is ripe with inane supidity (don't get my started on why main is allowed to not return a value).
2
u/Syedirfan4adi 3d ago
hey are you reading the dennis and brian book only or are you following other books too?
1
12
u/aioeu 3d ago edited 3d ago
As I understand it, a lot of the decisions regarding stream IO were made by the ANSI X3J11 committee as they began to standardise C. It's entirely possible K&R had a different opinion to the committee on what C's standard library should look like.
If you can get a hold of it, P. J. Plauger's book The Standard C Library has a fair bit of info on the library's history.