Austin Group Defect Tracker

Aardvark Mark IV

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
0000738 [1003.1(2013)/Issue7+TC1] System Interfaces Objection Omission 2013-08-22 19:25 2019-06-10 08:55
Reporter shware_systems View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Mark Ziegast
Organization SHware Systems
User Reference
Section c138.pdf, strdup( )/strndup( )
Page Number 2012
Line Number 64214-64220
Interp Status ---
Final Accepted Text see Note: 0001792
Summary 0000738: Size of buffer returned by strndup( ) ambiguous.
Description For strdup( ) the presumption seems to be the implementation shall try to do a malloc(strlen(s)) and then copy characters.

For strndup( ), it looks as if malloc(size+1) is to be attempted before any length checks or copying occur.
When this interpretation is used and strlen(s) < size this leaves some room an application could be expecting to use for appending characters, but this conflicts with strdup( ) doesn't leave room of that sort.

If the intent is: malloc( (strlen(s) < size ? strlen(s) : size) + 1) and then copy, I think that needs to be explicit.

If the intent is which interpretation is used is up to the implementation, that should be indicated, but it seems to me this is more of a this or that situation from the portability viewpoint.
Desired Action Add to paragraph at 64214:
If successful, strndup shall return a block sufficient to hold size + 1 characters, though not all positions may be used when length of s less than size. It is implementation-defined whether any unused positions are initialized to a specific character value such as NUL.

or

Replace paragraph 64214-64220 with:
The strndup( ) function shall be equivalent to the strdup( ) function, except strndup( ) copies at most size characters plus a terminating NUL character. The new block of memory allocated as if by using malloc( ) shall hold at most the lesser of (size + 1) or (length of s + 1) characters. If the length of s is larger than size, only size characters shall be copied, otherwise all characters from s shall be duplicated. The newly created string shall always be properly terminated with a NUL character.
Tags tc2-2008
Attached Files

- Relationships

-  Notes
(0001752)
shware_systems (reporter)
2013-08-22 19:38

 Sorry, that should be Category: Issue 7 + TC1... I also noticed there is wcsdup( ), but not the complementary wcsndup( ), with numwchar as parameter rather than size.
(0001753)
Don Cragun (manager)
2013-08-22 19:58

 Moved to Project 1003.1(2013)/Issue7+TC1 as requested in Note: 0001752
(0001792)
eblake (manager)
2013-09-05 15:44
edited on: 2013-09-05 17:18

 At least glibc and AIX use only strnlen(s,size)+1; the existing requirements are fine, but we propose adding explanatory text:

After line 64235 page 2012 [XSH strndup APPLICATION USAGE], add a new paragraph:

Implementations are free to malloc() a buffer containing either (size + 1) bytes or (strnlen(s, size) + 1) bytes. Applications should not assume that strndup() will allocate (size + 1) bytes, when strlen(s) is smaller than size.
(0001795)
shware_systems (reporter)
2013-09-05 17:13

 "will allocate (size + 1) bytes."
Add to end "when strlen(s) less than size", please.
Use of str n len( ) covers that in first sentence, but doesn't make it obvious.
(0001796)
dalias (reporter)
2013-09-05 17:24

 Unless there are historical implementations which always allocate size+1 bytes, I don't see the value in explicitly allowing this behavior. malloc can always have waste/overhead which is unobservable. All that should be specified is that strndup(s,n) returns a pointer to an array of length strnlen(s,n)+1 obtained as if by malloc. A conforming application cannot access past this offset in the array, so I cannot see any benefit from explicitly mentioning that the amount allocated might actually be something larger like n+1.
(0001797)
shware_systems (reporter)
2013-09-05 18:26

 Re: 1796
I agree, but either does make sure at least as much as is required are allocated. When the result is used for column justifying in multi-line output, if the app knows size+1 will be allocated it can set size=col width and just space fill, rather than do a strcpy( ) to a separate buffer of col width size. So there's at least one reason overallocating could be desirable, from an application efficiency standpoint, and possibly an application not bombing from an ENOMEM error. Limiting to strnlen( ) forces those extra allocs and copies, but that's consistent with strdup( ) requires them also so IMO it's a toss up which is 'more correct' from the standpoint of original intent of the wording.
(0003017)
ch3root (reporter)
2016-01-07 11:11

 I think it is a wrong direction to permit strndup() to malloc() a buffer containing (size + 1) bytes. POSIX should set clear expectations about the amount of allocated memory for strndup, that is, spell out that malloc() is asked to allocate exactly (strnlen(s, size) + 1) bytes (usual malloc() overhead applies of cause).

Otherwise it's not clear if strndup could portably be used with size much greater than the length of s. E.g., you cannot use strndup(s, SIZE_MAX) because malloc(SIZE_MAX + 1) contains an integer overflow and is expected to fail even if it's reduced to malloc(SIZE_MAX).
You can hardly expect to meet straight strndup(s, SIZE_MAX) in user's code -- strdup(s) would be more natural in such a case. But size=SIZE_MAX could be arise implicitly, e.g., when the width is parametrized: 
p = strndup(s, get_truncation_width());
. The alternative is unnecessarily longer:
  size_t truncation_width = get_truncation_width();
  if (truncation_width == SIZE_MAX)
    p = strdup(s);
  else
    p = strndup(s, truncation_width);

- Issue History
Date Modified Username Field Change
2013-08-22 19:25 shware_systems New Issue
2013-08-22 19:25 shware_systems Status New => Under Review
2013-08-22 19:25 shware_systems Assigned To => ajosey
2013-08-22 19:25 shware_systems Name => Mark Ziegast
2013-08-22 19:25 shware_systems Organization => SHware Systems
2013-08-22 19:25 shware_systems Section => c138.pdf, strdup( )/strndup( )
2013-08-22 19:25 shware_systems Page Number => 2012
2013-08-22 19:25 shware_systems Line Number => 64214-64220
2013-08-22 19:38 shware_systems Note Added: 0001752
2013-08-22 19:57 Don Cragun Project 2008-TC1 => 1003.1(2013)/Issue7+TC1
2013-08-22 19:58 Don Cragun Note Added: 0001753
2013-09-05 15:44 eblake Note Added: 0001792
2013-09-05 15:45 eblake Interp Status => ---
2013-09-05 15:45 eblake Final Accepted Text => see Note: 0001792
2013-09-05 15:45 eblake Status Under Review => Resolved
2013-09-05 15:45 eblake Resolution Open => Accepted As Marked
2013-09-05 15:45 eblake Tag Attached: tc2-2008
2013-09-05 17:13 shware_systems Note Added: 0001795
2013-09-05 17:18 eblake Note Edited: 0001792
2013-09-05 17:24 dalias Note Added: 0001796
2013-09-05 18:26 shware_systems Note Added: 0001797
2016-01-07 11:11 ch3root Note Added: 0003017
2016-01-10 16:54 ch3root Issue Monitored: ch3root
2019-06-10 08:55 agadmin Status Resolved => Closed

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker