3 ms·

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 (exception

by OskarS 7y ago

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.

catblast 7y ago
I wonder how a rust compiler implementation would fare on a PDP-11/20
- Joker_vD 7y ago
  They do have easily accessible PSW so using, say, a carry flag to implement Option<i16>/Result<i16, i16> is a possibility.
- saati 7y ago
  I don't think it's possible to fit even the type inference in 64k.
bluejekyll 7y ago
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.
masklinn 7y ago
> 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.
- kps 7y ago
  It predates C functions being able to return a struct.
  - beefhash 7y ago
    In fact, it predates C itself. See https://github.com/DoctorWkt/pdp7-unix/blob/9947fbf42bbb3c9410c33ae9f12485d893542e3b/src/sys/s3.s#L58 https://github.com/DoctorWkt/pdp7-unix/blob/9947fbf42bbb3c94...