Anonymous | Login | 2024-05-04 13:40 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 | ||
0000721 | [1003.1(2013)/Issue7+TC1] System Interfaces | Editorial | Clarification Requested | 2013-07-13 12:16 | 2022-08-11 15:38 | ||
Reporter | h3h3h3 | View Status | public | ||||
Assigned To | |||||||
Priority | normal | Resolution | Duplicate | ||||
Status | Closed | ||||||
Name | John Peters | ||||||
Organization | |||||||
User Reference | |||||||
Section | basename, dirname | ||||||
Page Number | 619, 730 | ||||||
Line Number | 21157, 24602 | ||||||
Interp Status | --- | ||||||
Final Accepted Text | |||||||
Summary | 0000721: Internal storage vs static storage | ||||||
Description | The former term appears only in the cited lines, whereas "static storage" is more often used to describe the same thing. | ||||||
Desired Action | In lines 21157 and 24602, change "internal storage" to "static storage". | ||||||
Tags | No tags attached. | ||||||
Attached Files | |||||||
|
Relationships | |||||||
|
Notes | |
(0001678) dalias (reporter) 2013-07-13 15:54 |
I think this change would be a change in the wrong direction. "Static storage" implies storage with static storage duration, whereas "internal storage", despite not being defined explicitly, has a common-sense meaning of "storage managed internally by the implementation", which could include static storage, allocated storage, or thread-local storage. As many implementations want to use thread-local storage for such interfaces, changes should not be made that require static storage. |
(0001679) h3h3h3 (reporter) 2013-07-13 16:02 edited on: 2013-07-13 16:03 |
In reply to 1678: > "Static storage" implies storage with static storage duration, whereas "internal storage", despite not being defined explicitly, has a common-sense meaning of "storage managed internally by the implementation", which could include static storage, allocated storage, or thread-local storage. This report was not meant to invite semantic discussion of static versus internal. The only information perused in this report is the frequency of usage of each term, and the fact that they are interchangeable in the only two cases where "internal storage" is used. Proof of that is how once "internal" is changed for "static", the affected sections imitate other function return descriptions that either use the term "static storage" explicitly or say something to the effect that the calling program shall not modify the data pointed at by the return value. Because of that, your comment is unrelated and depends on a definition of internal that simply isn't in the standard. I'd advise making another report instead of changing the purpose of this one. |
(0001680) dalias (reporter) 2013-07-13 16:21 |
It's not my intent to change the purpose of this report, but rather to object to the change requested in it. Right now there is no formal requirement that this (ill-defined) "internal storage" be static, and I believe adding such a requirement would be an unwelcome change to many implementors. I agree that the current language is unclear and ambiguous, and that it should be changed, but not in the manner of the desired-action for this issue report. |
(0001681) h3h3h3 (reporter) 2013-07-13 16:29 |
In reply to 1680: > It's not my intent to change the purpose of this report, but rather to object to the change requested in it. As it stands right now, the two terms are interchangeable, so you can't base an objection on one description being different from the other. If you look at the set of changes as cumulative instead of mutually-exclusive, then my proposal is concerned with consistency of usage of terms, whereas yours is concerned with replacement of terms. I don't see how can you object based on alternative tentative changes that don't conflict with those proposed in this report. > Right now there is no formal requirement that this (ill-defined) "internal storage" be static, and I believe adding such a requirement would be an unwelcome change to many implementors. I concur, but for that to happen you need a distinction between the two terms, and the standard doesn't bear one. I hope you understand. |
(0005931) Don Cragun (manager) 2022-08-11 15:38 |
This text has already been changed by the resolution of 0001064. |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |