This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
GNU libc / libiconv iconv()'s EILSEQ behaviour seems standards-compliant
- From: Alexander Shopov <ash at contact dot bg>
- To: libc-alpha at sourceware dot org
- Cc: Bruno Haible <bruno at clisp dot org>, Paul Eggert <eggert at CS dot UCLA dot EDU>, Ulrich Drepper <drepper at redhat dot com>
- Date: Fri, 19 May 2006 18:57:28 +0300
- Subject: GNU libc / libiconv iconv()'s EILSEQ behaviour seems standards-compliant
Greetings glibc hackers,
Just to inform you:
It seems that GNU libc / libiconv iconv()'s behavior is standards
compliant. (The Open Group Base Specifications Issue 6, IEEE Std 1003.1,
2004 Edition)
I wrote to the OpenGroup' Austin group[1].
I got an answer from Geoff Clare[2].
The deciding factor is here:
http://www.opengroup.org/onlinepubs/000095399/functions/xsh_chap02_03.html
The Open Group Base Specifications Issue 6
IEEE Std 1003.1, 2004 Edition
2.3 Error Numbers
6th paragraph:
Implementations may support additional errors not included in this list,
may generate errors included in this list under circumstances other than
those described here, or may contain extensions or limitations that
prevent some errors from occurring. The ERRORS section on each reference
page specifies whether an error shall be returned, or whether it may be
returned. Implementations shall not generate a different error number
from the ones described here for error conditions described in this
volume of IEEE Std 1003.1-2001, but may generate additional errors
unless explicitly disallowed for a particular function.
Heh - standards, plentiful and lax as laxatives ;-)
Kind regards:
al_shopov
[1]
https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=show_archive.tpl&source=L&listname=austin-group-l&id=9501
[2]
https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=show_archive.tpl&source=L&listname=austin-group-l&id=9502