Anonymous | Login | 2024-03-29 07:31 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||
ID | Category | Severity | Type | Date Submitted | Last Update | ||
0000402 | [1003.1(2008)/Issue 7] System Interfaces | Objection | Error | 2011-04-04 14:26 | 2013-04-16 13:06 | ||
Reporter | geoffclare | View Status | public | ||||
Assigned To | ajosey | ||||||
Priority | normal | Resolution | Accepted | ||||
Status | Closed | ||||||
Name | Geoff Clare | ||||||
Organization | The Open Group | ||||||
User Reference | |||||||
Section | nl_langinfo | ||||||
Page Number | 1375 | ||||||
Line Number | 45100, 45109 | ||||||
Interp Status | --- | ||||||
Final Accepted Text | |||||||
Summary | 0000402: nl_langinfo() and nl_langinfo_l() internal data | ||||||
Description |
This statement on the nl_langinfo() page currently applies to both nl_langinfo() and nl_langinfo_l(): Calls to setlocale() with a category corresponding to the category of item (see <langinfo.h>), or to the category LC_ALL , may overwrite the array pointed to by the return value. Calls to uselocale() which change the category corresponding to the category of item may overwrite the array pointed to by the return value. This doesn't make any sense for nl_langinfo_l(). Since it takes a locale object as an argument, there is no reason that calls to setlocale() or uselocale() would affect the string it returned. The text should instead talk about what happens if the locale object is subsequently freed or modified. Also this statement in the RETURN VALUE section is not quite right given that nl_langinfo_l() must be thread-safe but nl_langinfo() need not be: This pointer may point to static data that may be overwritten on the next call to either function. In both cases the text is already the subject of changes in bug 0000075. The proposed changes below constitute a further modification to the new text from that bug (plus some rationale). |
||||||
Desired Action |
After applying the changes specified for (draft 5.1) P1375 L45113 in bug 0000075, change this new text: The returned pointer might be invalidated or the string content might be overwritten by a subsequent call to either function to: The pointer returned by nl_langinfo() might be invalidated or the string content might be overwritten by a subsequent call to nl_langinfo() in any thread or to nl_langinfo_l() in the same thread or the initial thread and add a new sentence to the end of the same paragraph: The pointer returned by nl_langinfo_l() might be invalidated or the string content might be overwritten by a subsequent call to nl_langinfo_l() in the same thread or to nl_langinfo() in any thread, or by subsequent calls to freelocale() or newlocale() which free or modify the locale object that was passed to nl_langinfo_l(). At page 1376 line 45126 change the RATIONALE section from: None. to: The possible interactions between internal data used by nl_langinfo() and nl_langinfo_l() are complicated by the fact that nl_langinfo_l() must be thread-safe but nl_langinfo() need not be. The various implementation choices are: 1. nl_langinfo_l() and nl_langinfo() use separate buffers, or at least one of them does not use an internal string buffer. In this case there are no interactions. 2. nl_langinfo_l() and nl_langinfo() share an internal per-thread buffer. There can be interactions, but only in the same thread. 3. nl_langinfo_l() uses an internal per-thread buffer, and nl_langinfo() uses (in all threads) the same buffer that nl_langinfo_l() uses in the initial thread. There can be interactions, but only when nl_langinfo_l() is called in the initial thread. |
||||||
Tags | tc1-2008 | ||||||
Attached Files | |||||||
|
Relationships | ||||||
|
There are no notes attached to this issue. |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |