Anonymous | Login | 2024-04-26 19:37 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 | ||
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 | |||||||
|
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 |