EOF is not a character • Hacker News Board

Re: EOF is not a character

#31

Post by rgoulter » Sat, Mar 14, 2020, 3:18 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. :)

I liked this explanation. https://www.linusakesson.net/programming/tty/

When the TTY device takes (by default) Ctrl+C or Ctrl+D, it sends the signals to the program. The TTY's 'line discipline' (the policy for when the program's STDIN can read from a line of input) can be changed from a default 'cooked' to a 'raw mode'. In with raw mode line discipline the Ctrl+C doesn't send the signal. Presumably that's why e.g. vi or emacs don't just close on Ctrl+C.

Re: EOF is not a character

#32

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

rectang wrote: post #19

Like NULL, confusion over EOF is a problem which can be eliminated via algebraic types. What if instead of a char, getchar() returned an Option ? Then you can pattern match, something like this Rust/C mashup: match getchar() { Some(c) => putchar(c), None => break, } Magical sentinels crammed into return values — like EOF returned by getchar() or -1 returned by ftell() or NULL returned by malloc() — are one of C's dra…

So `read`'s `Ok(0)` result, is akin to `getchar`'s `None` result here. A different API causes a little more to consider, but generally makes sense.

Re: EOF is not a character

#33

Post by snek » Sat, Mar 14, 2020, 3:22 AM UTC

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…

> and did you know that IEEE-754 floating point can represent a "negative zero" that you can use for an error code in functions that return float or double?

I am begging, please never ever do this. NaN literally exists for this reason. NaN even allows you to encode additional error context and details into the value.

Re: EOF is not a character

#34

Post by guerrilla » Sat, Mar 14, 2020, 3:29 AM UTC

jes5199 wrote: post #24

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

Clearly, since they barely know the system they are talking about but could you elaborate instead of leaving it vague? Which systems?

Re: EOF is not a character

#35

Post by Thorrez » Sat, Mar 14, 2020, 3:29 AM UTC

Another weird thing is that sometimes you can read an EOF, then keep reading more real bytes. So EOF doesn't necessarily mean the permanent end.

Re: EOF is not a character

#36

Post by _8j50 » Sat, Mar 14, 2020, 3:31 AM UTC

Banged my head against the wall once after trying to figure out why Ctrl+D generates some character in bash but I can't send that character in a pipe to simulate termination.

Re: EOF is not a character

#37

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

rgoulter wrote: post #31

ChristianBundy wrote: post #14

Earlier quoted context omitted.

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. :)

I liked this explanation. https://www.linusakesson.net/programming/tty/ When the TTY device takes (by default) Ctrl+C or Ctrl+D, it sends the signals to the program. The TTY's 'line discipline' (the policy for when the program's STDIN can read from a line of input) can be changed from a default 'cooked' to a 'raw mode'. In with raw mode line discipline the Ctrl+C doesn't send the signal. Presumably that's why e.g. vi…

> Now you press ^Z. Since the line discipline has been configured to intercept this character (^Z is a single byte, with ASCII code 26), you don't have to wait for the editor to complete its task and start reading from the TTY device. Instead, the line discipline subsystem instantly sends SIGTSTP to the foreground process group.

This helps me, thanks for pointing me back at this great write-up.

Re: EOF is not a character

#38

Post by mark-r » Sat, Mar 14, 2020, 3:37 AM UTC

chrisseaton wrote: post #8

So what is CP/M-style character 26? Isn’t that documented as end-of-file?

It's just a convention, it isn't enforced by the OS. The C runtime for example will check for character 26 if you're reading a file opened in text mode but not in binary mode. The underlying OS call to read a file makes no distinction between text and binary.

Re: EOF is not a character

#39

Post by eyegor » Sat, Mar 14, 2020, 3:38 AM UTC

nixpulvis wrote: post #7

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…

What does "Procedural" vs "Functional" have to do with this? It's a choice in data type. If by procedural you mean, nonsense, then sure... I agree that a function named `getchar` returning an `int` is procedural. :P

What they mean to say is: when I was working with a language that enforced pure functions, I had to actually consider purity. It's rare to see a way to enforce purity in procedural languages, whereas most fp langs support it.

Re: EOF is not a character

#40

Post by mark-r » Sat, Mar 14, 2020, 3:39 AM UTC

jcrawfordor wrote: post #13

chrisseaton wrote: post #8

So what is CP/M-style character 26? Isn’t that documented as end-of-file?

Perhaps a marginally better title would be "EOF is not a character [on Unix]". There are some OS that have an explicit EOF character, but it seems to have been the less common approach historically. CP/M featured an explicit end of file marker because the file system didn't bother to handle the problem of files which were not block-aligned, so the application layer needed to detect where the actual end of the file wa…

I think CP/M copied that convention from an even older OS but I can't remember which one.