EOF is not a character • Hacker News Board

Re: EOF is not a character

#21

Post by wongarsu » Sat, Mar 14, 2020, 2:58 AM UTC

fennecfoxen wrote: post #12

reidacdc wrote: post #5

Seems like the confusion arises because getchar() (or its equivalent in langauges other than c) can produce an out-of-band result, EOF, which is not a character. Procedural programmers don't generally have a problem with this -- getchar() returns an int, after all, so of course it can return non-characters, and did you know that IEEE-754 floating point can represent a "negative zero" that you can use for an error cod…

I taught myself C on MS-DOS in middle school, decades ago. Could have sworn that ASCII 26 was named “EOF” even if modern text files don’t include it. This is a supplementary source of confusion.

Wikipedia supports this:

> Character 26 was used to mark "End of file" even if the ASCII calls it Substitute, and has other characters for this. Number 28 which is called "File Separator" has also been used for similar purposes. [1]

I think today we would think of character 4 (End of Transmission, Ctrl-D) as the end of file/input marker, but historically Character 26/Ctrl-Z was used, even on disk.

1: https://en.wikipedia.org/wiki/Substitute_character

Re: EOF is not a character

#22

Post by 1996 » Sat, Mar 14, 2020, 3:01 AM UTC

nixpulvis wrote: post #3

schoen wrote: post #2

Recently (though mine was the only comment): https://news.ycombinator.com/item?id=22461647

Well then try explaining ctrl+c vs ctrl+d to someone who's never touched a terminal at all. Starts off so easily... "see one tells the program to stop" the other, well, if you're in a shell... or some programs... oh god. IDK anymore, just assume it works. What was the question?"

it all depends on your stty settings.

since I am more used to Windows where ctrl-c is copy, I followed other people's suggestion and mapped ctrl-x to do what ctrl-c usually does, with:

stty intr ^X -ixon

This is because X and C are very close, and I couldn't sacrifice ctrl-v (paste) or ctrl-z (background) while I seldom use ctrl-c

I'm sure you could do the same with ctrl-d if you really wanted to.

Re: EOF is not a character

#23

Post by [deleted] » Sat, Mar 14, 2020, 3:05 AM UTC

ChristianBundy wrote: post #14

nixpulvis wrote: post #3

Earlier quoted context omitted.

Well then try explaining ctrl+c vs ctrl+d to someone who's never touched a terminal at all. Starts off so easily... "see one tells the program to stop" the other, well, if you're in a shell... or some programs... oh god. IDK anymore, just assume it works. What was the question?"

Maybe you can correct me if I'm wrong, but I've always considered Ctrl+C and Ctrl+D to be signals that you can send a process rather than explicit characters. You might also get some stdout for those key combinations because ???, but they should be thought of as signals rather than as characters you're sending via stdin. Hoping Cunningham's Law comes into play with this comment. :)

[deleted]

Re: EOF is not a character

#24

Post by jes5199 » Sat, Mar 14, 2020, 3:08 AM UTC

yeah, this author doesn’t know the history. Unix I/O was defined in opposition to practices in other OSes, that no longer exist

Re: EOF is not a character

#25

Post by nixpulvis » Sat, Mar 14, 2020, 3:09 AM UTC

taeric wrote: post #17

nixpulvis wrote: post #3

Earlier quoted context omitted.

Well then try explaining ctrl+c vs ctrl+d to someone who's never touched a terminal at all. Starts off so easily... "see one tells the program to stop" the other, well, if you're in a shell... or some programs... oh god. IDK anymore, just assume it works. What was the question?"

This actually doesn't seem that hard. In both, you are telling the computer, not the target program, something. One is to signal the running program you want to interrupt it. The other is to close the input to the program, as you are done giving it data.

You're making a lot of assumptions about the setup. Granted they are all mostly standard.

Re: EOF is not a character

#26

Post by samatman » Sat, Mar 14, 2020, 3:10 AM UTC

nixpulvis wrote: post #11

chrisseaton wrote: post #9

Earlier quoted context omitted.

> If by procedural you mean, nonsense, then sure Why are you being snarky? They clearly mean the issue of modelling partial functions which would normally be done by a side-effect in a procedural language but can’t in a functional language.

No, they imply that the handling is done by returning a negative number. I'm being snarky, as is my nature, to highlight the madness of a function called `getchar` returning anything but a `char`.

It's not a great snark given that the C standard considers the signedness of char to be implementation defined, making -1 a valid option, sometimes.

Re: EOF is not a character

#27

Post by taeric » Sat, Mar 14, 2020, 3:10 AM UTC

nixpulvis wrote: post #25

taeric wrote: post #17

Earlier quoted context omitted.

This actually doesn't seem that hard. In both, you are telling the computer, not the target program, something. One is to signal the running program you want to interrupt it. The other is to close the input to the program, as you are done giving it data.

You're making a lot of assumptions about the setup. Granted they are all mostly standard.

Assumptions help the world go around. :)

Re: EOF is not a character

#28

Post by [deleted] » Sat, Mar 14, 2020, 3:12 AM UTC

nixpulvis wrote: post #25

taeric wrote: post #17

Earlier quoted context omitted.

This actually doesn't seem that hard. In both, you are telling the computer, not the target program, something. One is to signal the running program you want to interrupt it. The other is to close the input to the program, as you are done giving it data.

You're making a lot of assumptions about the setup. Granted they are all mostly standard.

[deleted]

Re: EOF is not a character

#29

Post by nixpulvis » Sat, Mar 14, 2020, 3:12 AM UTC

taeric wrote: post #27

nixpulvis wrote: post #25

Earlier quoted context omitted.

You're making a lot of assumptions about the setup. Granted they are all mostly standard.

Assumptions help the world go around. :)

And... the Devil's in the details.

Re: EOF is not a character

#30

Post by nixpulvis » Sat, Mar 14, 2020, 3:16 AM UTC

samatman wrote: post #26

nixpulvis wrote: post #11

Earlier quoted context omitted.

No, they imply that the handling is done by returning a negative number. I'm being snarky, as is my nature, to highlight the madness of a function called `getchar` returning anything but a `char`.

It's not a great snark given that the C standard considers the signedness of char to be implementation defined, making -1 a valid option, sometimes.

I'm sorry you don't find it great (I still do). Integers are not characters.

Integers are numbers like -1337, 0, and 42.

Characters are things that compose strings of text.

These are not the same kind of thing at all. Just because APIs may be leaky, and some of these APIs are held in very high regard doesn't change that fact.