<zmatt>
just the simplest error handling function possible (print error message and exit)
<set_>
Yep.
<set_>
That one.
<set_>
Oh.
<zmatt>
obviously can be replaced by any other form of error handling if you prefer
<set_>
Okay.
<set_>
Can it be called something else outside of die?
<set_>
For instance, mos?
<zmatt>
if you also rename all uses of it you can call it whatever you fancy... why?
<set_>
Oh. Okay. I was asking b/c die seems a bit morbid.
<zmatt>
I mean, it kills the program
<set_>
I was just reviewing the source. Oh! Now, I understand.
<set_>
I thought it was for the readers.
<set_>
Ha.
<set_>
Well, now I know.
<set_>
Is it like EOF and NULL?
<zmatt>
none of these things are even remotely related?
<set_>
Okay. You are right.
<set_>
Sorry.
<set_>
I keep reading that NULL in Linux is a black hole. It just gets erased for good.
<set_>
And EOF, quits the program too, i.e. like the die() usage.
<set_>
Just wondering. That is all.
<zmatt>
it's just a simple form of handling errors that really shouldn't happen, in a way that's more useful than returning some error code that the caller is probably going to ignore because they don't know what to do with it either... as the old klingon proverb says, it's better to die() than to return() in failure ;-)
<set_>
Aw!
<zmatt>
you're confusing NULL (the pointer constant) with /dev/null (the device that discards anything written to it)
<set_>
Aw. Yes.
<set_>
You are right.
<zmatt>
and EOF is just an abbreviation for "end of file", it does not imply any sort of behaviour
<set_>
Oh. Okay.
<zmatt>
and none of these things still anything to do with each other
<zmatt>
*still have
<set_>
Okay.
<set_>
Hey @zmatt: none of those things have anything to do w/ one another. You are right.
<set_>
But, they all are endings.
<zmatt>
no they're not
<set_>
Oh.
<set_>
the /dev/null is the end of the file on the output unless specificity is called in the program.
<zmatt>
?????
<set_>
For instance, if I was making atoi or atof work.
<zmatt>
that sentence was really just a word-salad
<set_>
in .c files...here. Sheesh.
<set_>
So anyway.
<set_>
Back to what I was saying.
<set_>
Forget it.
<set_>
atoi is ascii to int.
<set_>
atof is ascii to float as in a double.
<set_>
I have been goofin' around w/ stderr, stdin, stdout on the console.
<set_>
I was learnin' about dprintf too!
<set_>
Are using fd's a thing of the past?
<zmatt>
that's a function you're very unlkely to have any use for
<zmatt>
no
<set_>
Okay. Good.
<set_>
oh.
<set_>
Why would I not use the dprintf function?
<zmatt>
but normally you don't use the underlying file descriptors for stdin/stdout/stderr directly except in very specific circumstances
<set_>
Aw. Okay. What are two "specific circumstances?"
<zmatt>
because all other code uses printf()/fprintf(), and mixing that with dprintf will result in problems
<set_>
Oh. Okay.
<set_>
Hmm. I guess I better be careful.
<zmatt>
basically, if there's an open FILE* for a file descriptor, you almost certainly want to use that instead of using the file descriptor directly (unless you know exactly what you're doing)
<zmatt>
hence, use stdin/stdout/stderr instead of using the underlying file descriptors (0, 1, and 2 respectively) directly