 Notes |
(0007016)
geoffclare (manager)
2024-12-19 10:43
edited on: 2024-12-19 10:43
|
The RETURN VALUE section agrees with the second piece of text that a null pointer is returned:A call to the bind_textdomain_codeset() function with a non-empty domainname argument shall return one of the following:- The currently bound codeset name for that text domain if codeset is a null pointer
- The newly bound codeset if codeset is non-empty
- A null pointer without changing errno if no codeset has yet been bound for that text
domain
although this also has problems, as the last bullet item should say codeset is null (or be merged into the first bullet item).
|
|
(0007041)
bhaible (reporter)
2025-01-09 17:07
|
The value documented in the bulleted list is "the implementation-defined default codeset used by the gettext family of functions".
The value documented after the bulleted list is "a null pointer".
Which is it in practice? I ran the attached test program foo.c on all implementations (glibc, GNU libintl, musl libc, NetBSD 10, Solaris 11), and the return value is a null pointer in all cases.
So, it appears that the wording "the implementation-defined default codeset used by the gettext family of functions" was added for generality, in order not to disagree with any possible implementation. But since all implementations return a null pointer, this generality is not needed.
My suggestion therefore: Replace "the implementation-defined default codeset used by the gettext family of functions" with "a null pointer". |
|
(0007045)
geoffclare (manager)
2025-01-16 15:24
edited on: 2025-01-16 16:31
|
Interpretation response
------------------------
The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor.
Rationale:
-------------
There are three statements about the return value under these conditions, two of which say a null pointer is returned. The third (about a default codeset) contradicts those two and does not match the behavior of current implementations.
Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
On page 667 line 23399 section bindtextdomain(), change:
If domainname is not bound, the function shall return the implementation-defined default codeset used by the gettext family of functions.
to:
If domainname is not bound, the function shall return a null pointer without changing errno.
On page 557 line 23402 section bindtextdomain(), delete the redundant text:
If codeset is a null pointer and domainname is a non-empty string, bind_textdomain_codeset() shall return the current codeset for the named domain, or a null pointer if a codeset has not yet been set.
On page 668 line 23425 section bindtextdomain(), change:
A null pointer without changing errno if no codeset has yet been bound for that text domain
to:
A null pointer without changing errno if codeset is a null pointer and no codeset has yet been bound for that text domain
|
|
(0007046)
bhaible (reporter)
2025-01-16 15:33
edited on: 2025-01-16 15:34
|
geoffclare: 0007045 is partially wrong. This defect is not about 'bindtextdomain'. It is about 'bind_textdomain_codeset'.
'bindtextdomain' *does* have a non-NULL default directory. On glibc systems, it is "/usr/share/locale".
|
|
(0007047)
geoffclare (manager)
2025-01-16 15:42
|
Re: Note: 0007046, the "section: bindtextdomain()" is correct because the text is on the bindtextdomain() page. |
|
(0007048)
bhaible (reporter)
2025-01-16 15:52
|
But changing the sentence "the function shall return the implementation-defined default directory pathname" is not right, since that sentence belongs to bindtextdomain(), which is out-of-scope of this defect. |
|
(0007049)
geoffclare (manager)
2025-01-16 15:59
|
Re: Note: 0007048, thanks! The line number was right, but somehow I copy+pasted from the wrong line. Fixed now. |
|
(0007050)
bhaible (reporter)
2025-01-16 16:06
|
Now I agree with the (revised) Note: 0007045. |
|
(0007055)
ajosey (manager)
2025-01-18 07:22
|
Interpretation proposed: 18 January 2025 |
|
foo.c [^] (327 bytes) 2025-01-09 17:00 
