Hacker News Reader

Comment by OskarS | Hacker News Reader

All that is certainly true, but we're talking about a function that dates back to the 70s here. It predates all of those nice error handling concepts (exceptions, Result<T>, multiple return values), so it's pretty sensible from that perspective to have -1 be the error value.

But yes, don't do this today, obviously.

View on HN

We're still dealing with this today as so many of us deploy and develop software for POSIX that exposes us to these edge cases.

So, yes, while working in Rust and using better APIs designed around these interfaces, we won't do the wrong thing, but there's still a lot of people that are going to end up getting cut by these old 70's interfaces. It would be nice if we didn't have to work with these, but many of us still do.

I wonder how a rust compiler implementation would fare on a PDP-11/20

They do have easily accessible PSW so using, say, a carry flag to implement Option<i16>/Result<i16, i16> is a possibility.

I don't think it's possible to fit even the type inference in 64k.

> All that is certainly true, but we're talking about a function that dates back to the 70s here. It predates all of those nice error handling concepts (exceptions, Result<T>, multiple return values), so it's pretty sensible from that perspective to have -1 be the error value.

It doesn't predate creating a struct which tells you exactly whether thing went wrong and how.

It predates C functions being able to return a struct.

In fact, it predates C itself. See https://github.com/DoctorWkt/pdp7-unix/blob/9947fbf42bbb3c94...

Reply on news.ycombinator.com