6 ms·

Will stdio outlive us?

5 points by parenthesis 18y ago

Allocator2008 18y ago
For my money it is the only IO API one need ever learn. Good point on signed/unsigned. I think in most cases char is unisgned, i.e., in most environments, so this is not a problem. But can't you do something like: char c while( (c = getchar() & 0xff) != EOF) { //Do something } if you are in a signed environment? I think really stdio is rather like my experience with mexican food. I live in Austin, Texas now, and I love mexican food, the hotter the better, but as a kid I lived in eldritch New England, not far from the Miskatonic river, and felt I didn't "like" spicey food, being more used to lobster, clam chowder, and so forth. Now they can't put enough jalepenos in a burger for my liking. Similarly, being 27, and thus living in the "java age", I first taught myself to program with the Java SDK, which spares one from alot of these "pitfalls". But now I like the control, and also the relative simplicity of the API, that stdio gives one, arguably more intuitive and easier to remember than in Java, and given a choice between Java and C, I would go with the later. It is an acquired taste. To paraphrase Charleton Heston: "They will take my [stdio] away out my cold, dead hands!" :-)
- mooism2 18y ago
  The correct way is int ch; while ((ch = getchar()) != EOF) { // ... } If ch is declared as a char, it's buggy regardless of whether it's signed or not, it's just the failure modes are different.
- jpd 18y ago
  From K&R: We also declare 'c' to be an int, not a char, so it can hold the value which getchar returns. As we shall see in Chapter 2, this value is actually an int, since it must be capable of representing EOF in addition to all possible 'char's.
allenbrunson 18y ago
some of these are legitimate complaints. but i'm having trouble working up any outrage, because i like the stdio interface. personally, i paper over the defects by not using stdio directly. i write wrappers around it, then write tests, neither of which has to be revisited very often. i guess the most pressing issue is shaky support for anything but ascii. that's dealt with in the short term via utf8, and in the long term by expanding the size of 'char' to 32 bits, i hope.
tsally 18y ago
If you learn C from a text that is worth anything (K&R comes to mind) you learn how to address this so called 'EOF error' from the beginning. If I remember right, K&R does not even introduce the character primitive until after it introduces getchar(). All of the examples use an int.

5 points by parenthesis 18y ago

Allocator2008 18y ago

For my money it is the only IO API one need ever learn. Good point on signed/unsigned. I think in most cases char is unisgned, i.e., in most environments, so this is not a problem. But can't you do something like: char c while( (c = getchar() & 0xff) != EOF) { //Do something } if you are in a signed environment? I think really stdio is rather like my experience with mexican food. I live in Austin, Texas now, and I love mexican food, the hotter the better, but as a kid I lived in eldritch New England, not far from the Miskatonic river, and felt I didn't "like" spicey food, being more used to lobster, clam chowder, and so forth. Now they can't put enough jalepenos in a burger for my liking. Similarly, being 27, and thus living in the "java age", I first taught myself to program with the Java SDK, which spares one from alot of these "pitfalls". But now I like the control, and also the relative simplicity of the API, that stdio gives one, arguably more intuitive and easier to remember than in Java, and given a choice between Java and C, I would go with the later. It is an acquired taste. To paraphrase Charleton Heston: "They will take my [stdio] away out my cold, dead hands!" :-)

mooism2 18y ago
The correct way is int ch; while ((ch = getchar()) != EOF) { // ... } If ch is declared as a char, it's buggy regardless of whether it's signed or not, it's just the failure modes are different.
jpd 18y ago
From K&R: We also declare 'c' to be an int, not a char, so it can hold the value which getchar returns. As we shall see in Chapter 2, this value is actually an int, since it must be capable of representing EOF in addition to all possible 'char's.

allenbrunson 18y ago

some of these are legitimate complaints. but i'm having trouble working up any outrage, because i like the stdio interface. personally, i paper over the defects by not using stdio directly. i write wrappers around it, then write tests, neither of which has to be revisited very often. i guess the most pressing issue is shaky support for anything but ascii. that's dealt with in the short term via utf8, and in the long term by expanding the size of 'char' to 32 bits, i hope.

tsally 18y ago

If you learn C from a text that is worth anything (K&R comes to mind) you learn how to address this so called 'EOF error' from the beginning. If I remember right, K&R does not even introduce the character primitive until after it introduces getchar(). All of the examples use an int.