View Issue Details

IDProjectCategoryView StatusLast Update
00002881003.1(2004)/Issue 6System Interfacespublic2013-04-16 13:06
Reportermsbrown Assigned Toajosey  
PrioritynormalSeverityObjectionTypeError
Status ClosedResolutionAccepted As Marked 
NameMark Brown
OrganizationThe Open Group
User Referenceud-setlocale-ret
Sectionsetlocale
Page Number1318
Line Number41265
Interp StatusApproved
Final Accepted Text0000288:0000466
Summary0000288: setlocale and static return buffer
DescriptionThe specification currently (including the draft for the next revision)
 says this about the string pointer returned by setlocale():

     The application shall not modify the string returned which may be
     overwritten by a subsequent call to setlocale().

 The problem with this wording is that it requires a pointer to a static
 buffer to be returned which is used for the string representing the
 current locale setting for the category. This is highly undesirable
 since it limits the size of the used strings.

 If no static buffer would be required an additional condition has to be
 mentioned: the returned string pointer can become unusable after the
 next setlocale() call. This is perfectly reasonable. If the caller
 cares about the actual value s/he must make sure that no other
 setlocale() call is made before the string is copied. In most cases
 the caller only cares about the success of the call. This can be
 recognized even if the pointer becomes invalid.


[Copied from xshbug2.txt ERN 250.
Originally submitted by Ulrich Drepper.
Processed too late to be included in IEEE Std 1003.1-2008. ]
Desired ActionAction:

 Change line 41265f to

   [...] The application shall not modify the string returned. The
   returned string pointer might be invalidated or the string content
   overwritten by a subsequent call to setlocale().

Tagsc99, tc1-2008

Relationships

related to 0000075 Closedajosey 1003.1(2008)/Issue 7 functions that are allowed to overwrite returned static data 

Activities

msbrown

2010-07-16 21:04

manager   bugnote:0000466

Interpretation response
------------------------
The standard states the requirements for setlocale() , and
conforming implementations must conform to this. However, concerns have
been raised about this which are being referred to the sponsor.

Rationale:
-------------
See Description.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
Change line 41265f to

   [...] The application shall not modify the string returned. [CX]The
   returned string pointer might be invalidated or [/CX] the string content
    might be overwritten by a subsequent call to setlocale().


Add new para as last para of DESCRIPTION

The implementation shall behave as if no function defined
in this volume of POSIX.1-200x calls setlocale()

A new para of APP USAGE

    "In order to make use of different locale settings while
    multiple threads are running, applications should use
    uselocale() in preference to setlocale()."

ajosey

2010-07-30 08:22

manager   bugnote:0000504

Comments/objections on the proposed interpretation are due by COB Aug 31 2010

Issue History

Date Modified Username Field Change
2010-07-16 21:02 msbrown New Issue
2010-07-16 21:02 msbrown Status New => Under Review
2010-07-16 21:02 msbrown Assigned To => ajosey
2010-07-16 21:02 msbrown Name => Mark Brown
2010-07-16 21:02 msbrown Organization => The Open Group
2010-07-16 21:02 msbrown User Reference => ud-setlocale-ret
2010-07-16 21:02 msbrown Section => setlocale
2010-07-16 21:02 msbrown Page Number => 1318
2010-07-16 21:02 msbrown Line Number => 41265
2010-07-16 21:02 msbrown Interp Status => Pending
2010-07-16 21:02 msbrown Final Accepted Text => 0000287:0000465
2010-07-16 21:02 msbrown Issue generated from: 0000287
2010-07-16 21:04 msbrown Note Added: 0000466
2010-07-16 21:05 msbrown Final Accepted Text 0000287:0000465 => 0000288:0000466
2010-07-16 21:05 msbrown Status Under Review => Interpretation Required
2010-07-16 21:05 msbrown Resolution Open => Accepted As Marked
2010-07-30 08:22 ajosey Interp Status Pending => Proposed
2010-07-30 08:22 ajosey Note Added: 0000504
2010-09-03 16:43 ajosey Interp Status Proposed => Approved
2010-09-03 21:22 Don Cragun Tag Attached: tc1-2008
2010-09-07 10:53 geoffclare Relationship added related to 0000075
2011-03-17 10:42 nick Tag Attached: c99
2013-04-16 13:06 ajosey Status Interpretation Required => Closed