Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Something Rotten in the Core

codersnotes.com

Post reply on HN
Print view View original

11–20 of 21 posts

Re: Something Rotten in the Core

#11

Post by alexandercrohde »

jitl wrote: post #7

It seems like commenters here on HN are caught on the point that GDB does provide a reasonable machine interface. That's not the author's point; responding specifically to that fact is missing the forest for one mis-labeled non-tree. Here's two paragraphs from later on that sum much better: > We've seen it hundreds of times in all kinds of software. Functions that return bool instead of an error code. Where did the p…

I agree that GDB isn't substantive to the author's point, it's merely an example and validity of the argument as a whole isn't contingent on that one example.

However, I guess I'm not clear about the argument as a whole. The author is essentially claiming, "We write wrappers that are shoddy in that they don't consider failure cases."

That is true. What the author doesn't address is: what's the solution?

If the answer is "Code better," or "Think more," I feel like that's a straw-man.

I think the real question is how can we make a wrapper (e.g. a complex setup script) provide visibility into its problems (permissions issue, harddrive space, network issue, etc) without doubling the work involved?

Re: Something Rotten in the Core

#12

Post by AstralStorm »

jitl wrote: post #7

It seems like commenters here on HN are caught on the point that GDB does provide a reasonable machine interface. That's not the author's point; responding specifically to that fact is missing the forest for one mis-labeled non-tree. Here's two paragraphs from later on that sum much better: > We've seen it hundreds of times in all kinds of software. Functions that return bool instead of an error code. Where did the p…

Calling the systems glued on is generous. It presumes they are actually holding together. It is often not even duct tape level, but the connectors are machined with micrometric precision.

Likewise most errors are not checked or deemed impossible instead of proven to be impossible.

Re: Something Rotten in the Core

#13

Post by AstralStorm »

jepler wrote: post #5
jepler wrote: post #3

I couldn't tell whether the author was making a good point, because their facts were badly askew. Historically, there were multiple UNIX debuggers. It's true, gdb largely exterminated them (and anyway, when people say UNIX they often mean linux+freebsd+macos, where gdb was the defacto standard). However, there is now a second common UNIX debugger from the llvm/clang alternate universe (lldb). In the very bad old days…

"The LLDB debugger APIs are exposed as a C++ object oriented interface in a shared library. The lldb command line tool links to, and uses this public API… The entire API is also then exposed through Python script bindings which allow the API to be used within the LLDB embedded script interpreter, and also in any python script that loads the lldb.py module in standard python script files. See the Python Reference page…

And therefore three is no stable ABI because C++ lacks one. Maybe in the future...

Re: Something Rotten in the Core

#14

Post by AstralStorm »

candiodari wrote: post #10
klodolph wrote: post #8

> We've seen it hundreds of times in all kinds of software. Functions that return bool instead of an error code. Where did the precise error vanish to? Poof, it's gone! A thousand times yes. Earlier this year, two of us spent a full day debugging a problem with some of our automation. Our team has pretty good automation, for the most part, but this particular problem was in kind of a dark corner. A shell script in th…

So what you mean to say is that the problem is not so much that there isn't any error reporting, but that, in C, it's being ignored ? Never do printf("here's a number: %d", 11); Always do: int attempts = 0 int ret = printf("here's a number: %d", 11); while (attempts++ Needless to say, you should do this on EVERY printf statement. There. Isn't explicit erroring great ? NO IT ISN'T. Needless to say, this has an almost…

By "most of C++" you mean stuff written as C with classes right? Or perhaps the fact that exceptions are not more specific which is a general problem everywhere?

Re: Something Rotten in the Core

#15

Post by tekjenitalor »

klodolph wrote: post #8

> We've seen it hundreds of times in all kinds of software. Functions that return bool instead of an error code. Where did the precise error vanish to? Poof, it's gone! A thousand times yes. Earlier this year, two of us spent a full day debugging a problem with some of our automation. Our team has pretty good automation, for the most part, but this particular problem was in kind of a dark corner. A shell script in th…

To be honest it doesn't sound like you have any business writing shell scripts intended for anything in production.

You want to lament a unix shells inability to introspect across problem domains the way a glue language can|does you are going to be talking to a relatively inexperienced audience for sympathy.

Re: Something Rotten in the Core

#16

Post by klodolph »

candiodari wrote: post #10
klodolph wrote: post #8

> We've seen it hundreds of times in all kinds of software. Functions that return bool instead of an error code. Where did the precise error vanish to? Poof, it's gone! A thousand times yes. Earlier this year, two of us spent a full day debugging a problem with some of our automation. Our team has pretty good automation, for the most part, but this particular problem was in kind of a dark corner. A shell script in th…

So what you mean to say is that the problem is not so much that there isn't any error reporting, but that, in C, it's being ignored ? Never do printf("here's a number: %d", 11); Always do: int attempts = 0 int ret = printf("here's a number: %d", 11); while (attempts++ Needless to say, you should do this on EVERY printf statement. There. Isn't explicit erroring great ? NO IT ISN'T. Needless to say, this has an almost…

> So what you mean to say is that the problem is not so much that there isn't any error reporting, but that, in C, it's being ignored ?

...huh? No, I'm not saying that. I'm saying that if you write a shell script there's a risk of not detecting errors that you care about. I also said that I like to rewrite these overgrown shell scripts in Go, which is apparently a Wrong Opinion and some bad C code will somehow convince me of this.

First, the nitpicks: EAGAIN should not be handled here. EAGAIN shouldn't be retried in a loop, that will just spin the CPU for no good reason. If printf() returns EAGAIN it means that you made stdout non-blocking and hopefully you would know if you did that, but that's unusual except in language runtimes. There's also a missing break; in the switch.

Beyond that, I don't really care about error handling for printf() when I'm logging output or running interactive programs.

Compare this with the behavior for C++:

    #include 
    #include 
    #include 
    int main() {
        close(STDOUT_FILENO);
        std::cout
Try it yourself.

As an example of the errors we see in our logs, they often look like this:

    some_file.go:399: could not realign warp core coupling b502:
      plasmaManifold.PhaseInterplex(): host not found: m19d.eng.ncc1701d
The "ignored errors in the Go standard library" aren't really ignored errors. Look at the bufio code a little bit more closely, you'll see that those errors are properly returned.

Re: Something Rotten in the Core

#17

Post by hossbeast »

Animats wrote: post #9

This is a classic problem with open-source GUIs - they're a wrapper around a command-line program. Such programs typically have no clue what happened at the command line level - they just present whatever the command line program prints to the user. A few days ago, there was a UI designer on here who was looking for an open source program to work on. I suggested "git gui". Git's default GUI is a Tk wrapper around the…

They also write a descriptive message (and nothing else) on stderr as a convention.

Re: Something Rotten in the Core

#18

Post by Animats »

hossbeast wrote: post #17
Animats wrote: post #9

This is a classic problem with open-source GUIs - they're a wrapper around a command-line program. Such programs typically have no clue what happened at the command line level - they just present whatever the command line program prints to the user. A few days ago, there was a UI designer on here who was looking for an open source program to work on. I suggested "git gui". Git's default GUI is a Tk wrapper around the…

They also write a descriptive message (and nothing else) on stderr as a convention.

Which is usually useless to a GUI or a script.

Re: Something Rotten in the Core

#19

Post by candiodari »

klodolph wrote: post #16
candiodari wrote: post #10

Earlier quoted context omitted.

So what you mean to say is that the problem is not so much that there isn't any error reporting, but that, in C, it's being ignored ? Never do printf("here's a number: %d", 11); Always do: int attempts = 0 int ret = printf("here's a number: %d", 11); while (attempts++ Needless to say, you should do this on EVERY printf statement. There. Isn't explicit erroring great ? NO IT ISN'T. Needless to say, this has an almost…

> So what you mean to say is that the problem is not so much that there isn't any error reporting, but that, in C, it's being ignored ? ...huh? No, I'm not saying that. I'm saying that if you write a shell script there's a risk of not detecting errors that you care about. I also said that I like to rewrite these overgrown shell scripts in Go, which is apparently a Wrong Opinion and some bad C code will somehow convin…

> First, the nitpicks: EAGAIN should not be handled here. EAGAIN shouldn't be retried in a loop, that will just spin the CPU for no good reason. If printf() returns EAGAIN

Manpage seems to imply that's not the only reason:

http://man7.org/linux/man-pages/man3/errno.3.html

And I'm pretty sure that the manpage is right : with creative redirects you can make that happen for other reasons too. You can redirect stdout to a file on NFS, or to a tcp socket that may have a full buffer, lots of evil ideas come to mind.

I'll take another good look at the bufio error. Thing is, I'm also pretty sure that I'd want bufio to correctly handle EINTR and EAGAIN and it seems to me very unlikely that this golang runtime code is correct for those cases. But I'll spend some time trying to make it fail. Maybe I'll learn something.

Re: Something Rotten in the Core

#20

Post by citrin_ru »

> So much user-facing network software is built on top of other programs, like ssh or rsync, and when those things fail they just don't know what to do. And so much of the problem is precisely because they're not using them as libraries, they're using them as command-line utilities.

Unix CLI utilities have well defined way to return an error - non zero exit code. It is even possible to return different errors as different exit codes, though it is rarely done.

Post reply on HN