[v3] system_error, round one

[Ulrich Drepper]

Benjamin Kosnik wrote:
>> - if such a locale is added as for many other classes, then use 
>> strerror_l() which is available in glibc and will be available in all 
>> future POSIX systems.
> 
> Yes. There seems to be some intent to use locale bits, but no actual 
> thought as to what the interface should look like.

That has to change before anything is standardized then.  Just like 
ordinary messages, error messages are translated.


>> - you shouldn't hardcode the highest error number.  If you really need 
>> that information use the _sys_nerr variable which most Unix systems 
>> provide.
> 
> OK, thanks. I see sys_nerr, _sys_nerr in bits/sys_errlist.h, but no way 
> to get at this info via a functional interface. Is this correct? I guess 
> I can just deal with this at configure time.

Ideally you code doesn't have to know about the highest error number. 
strerror() et.al will produce output for all error values and this might 
be useful.  Systems always introduce new error values and using an old 
runtime on a new kernel shouldn't fail.  It should just show it doesn't 
know the error code and generate a useful string.  strerror() generates 
"Unknown error %d" or so.

If for whatever non-existing reason the C++ decide that this is no 
acceptable and the invented "other" error value has to be used, then 
you'll have to use _sys_nerr.  It is a variable and there is no alternative.


> One of the things I was wondering (besides all the XXX comments in the 
> posted source...) was if I would have to create this as a GNU/generic 
> type of thing, like the rest of locale. It seems like this is where this 
> is all heading.

Well, "GNU" variants can be POSIX variants in few years.  All the 
thread-local locale stuff is in the next POSIX revision.  But until then 
you have to introduce a locale facet and use the strerror_l function 
just for glibc.


> I am wondering if it may make more sense to just implement a revised 
> version of this spec, since it seems pretty weak at the moment, and then 
>  shoot back those implementation differences in paper form to the LWG 
> pre-Toronto.

You in any case have to address the locale issue.  And I would 
definitely do away the "other" thing.  As I wrote, new error codes are 
not an exception which must be flagged, they are introduced pretty 
regularly.  The C++ runtime cannot be written to flip out when t his 
happens or drop the information.  Fold all additional error codes into 
"other" drop information.  Programmers won't be able to determine what 
really happened.

Really, all you need is a wrapper around strerror_l().

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖