View Issue Details

IDProjectCategoryView StatusLast Update
00007211003.1(2013)/Issue7+TC1System Interfacespublic2022-08-11 15:38
Reporterh3h3h3 Assigned To 
PrioritynormalSeverityEditorialTypeClarification Requested
Status ClosedResolutionDuplicate 
NameJohn Peters
Organization
User Reference
Sectionbasename, dirname
Page Number619, 730
Line Number21157, 24602
Interp Status---
Final Accepted Text
Summary0000721: Internal storage vs static storage
DescriptionThe former term appears only in the cited lines, whereas "static storage" is more often used to describe the same thing.
Desired ActionIn lines 21157 and 24602, change "internal storage" to "static storage".
TagsNo tags attached.

Relationships

related to 0001064 Closedajosey 1003.1(2008)/Issue 7 basename() and dirname(): Specification is not complete enough to allow existing thread-unsafe implementations 

Activities

dalias

2013-07-13 15:54

reporter   bugnote:0001678

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.

h3h3h3

2013-07-13 16:02

reporter   bugnote:0001679

Last edited: 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.

dalias

2013-07-13 16:21

reporter   bugnote:0001680

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.

h3h3h3

2013-07-13 16:29

reporter   bugnote:0001681

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.

Don Cragun

2022-08-11 15:38

manager   bugnote:0005931

This text has already been changed by the resolution of 0001064.

Issue History

Date Modified Username Field Change
2013-07-13 12:16 h3h3h3 New Issue
2013-07-13 12:16 h3h3h3 Name => John Peters
2013-07-13 12:16 h3h3h3 Section => basename, dirname
2013-07-13 12:16 h3h3h3 Page Number => 619, 730
2013-07-13 12:16 h3h3h3 Line Number => 21157, 24602
2013-07-13 15:54 dalias Note Added: 0001678
2013-07-13 16:02 h3h3h3 Note Added: 0001679
2013-07-13 16:03 h3h3h3 Note Edited: 0001679
2013-07-13 16:21 dalias Note Added: 0001680
2013-07-13 16:29 h3h3h3 Note Added: 0001681
2022-08-11 15:37 Don Cragun Relationship added related to 0001064
2022-08-11 15:38 Don Cragun Interp Status => ---
2022-08-11 15:38 Don Cragun Note Added: 0005931
2022-08-11 15:38 Don Cragun Status New => Closed
2022-08-11 15:38 Don Cragun Resolution Open => Duplicate