| |||||||||||||
Making EPERM friendlierMaking EPERM friendlierPosted Jan 20, 2013 6:17 UTC (Sun) by wahern (subscriber, #37304)Parent article: Making EPERM friendlier
This isn't about making error messages more friendly, this is about providing a hack because most software is broken. If software reported and recorded errors precisely when they happened, this wouldn't be an issue. The application making the request has much more relevant contextual information than the operating system does. And context that is inaccessible to the application is usually supposed to be that way for security. You're not supposed to know which policy blocked your request. (Things may be different if you're a sysadmin, but you want a separate, protected channel for that information.)
Yes, it's tedious to deal with errors early, but everything is tedious in C. It's the nature of the language. C isn't a RAD environment.
Let's not pretend that this proposal is a better errno. It's a work-around for broken software. It's equivalent to wrapping every error in an exception, and pretending that exceptions fix the tedium, instead of what they usually do--kick the bucket down the road.
Now, that doesn't make it a bad proposal, per se, just not what it's advertised as.
As for dealing with errno munging, the simplest answer is to not use errno. Capture the errno value immediately after a system call fails. And stop writing library APIs which write through errno; instead, return a friggin' int directly. Why people use kernel error reporting semantics as a prototype, I'll never understand. When I see application routines which return -1 to signal an error, I want to tear my hair out.
(Log in to post comments)
Making EPERM friendlier Posted Jan 20, 2013 6:34 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
you are complaining about a completely different problem.
The problem that's being addressed here is that a well written application that is going to tell the user what went wrong only knows that permisison was denied.
The application cannot provide any more information to the user, because it doesn't have the information.
And there is no sane way for the admin/support person to figure out _why_ the permission was denied.
In the 'old days', this was fairly simple, there was only one place to check (the rwx permissions).
However today, it's much harder.
When you don't give admins sane ways to figure out the cause of the permission problems within the context of the more complex security model, the result is going to be that admins disable the more complex security model, a secure system that doesn't get the job done is worthless.
Making EPERM friendlier Posted Jan 20, 2013 9:40 UTC (Sun) by alankila (subscriber, #47141) [Link]
I know this take on the issue isn't going to be popular here, but I like exceptions as error-reporting system. It is imho hell of a lot better than single integer. The information contained in the stack trace allows me to infer the state of the system and generally determine the point of failure, or the offending piece of code I wrote.
If only C, or the userspace-kernel API could have something like that...
Making EPERM friendlier Posted Jan 21, 2013 8:40 UTC (Mon) by epa (subscriber, #39769) [Link]
An exception is essentially an alternative return value from the function. (The *implementation* of exception handling in languages such as C++ is something quite different, but that is not relevant here). I agree that it is great to have a structured object giving details on the error. However that may be a little ambitious - and in 20 years we might be having arguments about how the error details don't fit into the C structure defined way back in 2013. I suggest that a string, such as Plan 9's errstr, is a reasonable compromise between a single int (clearly inadequate) and a complex structured exception object (too complex to be widely adopted at the kernel level).
|
|||||||||||||