View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
00008101003.1(2013)/Issue7+TC1System Interfacespublic2013-12-15 23:102019-06-10 08:55
Reportershware_systems Assigned To 
PrioritynormalSeverityObjectionTypeClarification Requested
Status ClosedResolutionAccepted As Marked 
NameMark Ziegast
Organization
User Reference
Sectionconfstr()
Page Number692
Line Number23443
Interp Status---
Final Accepted Text0000810:0002166
Summary0000810: Potential ambiguity in _CS_V[67]_ENV return value
DescriptionThe sentence ending at line 23443 has:
"the string stored in buf will contain the <space>-separated list of variable=value environment
variable pairs required by the implementation to create a conforming environment, as described
in the implementations’ conformance documentation."

I do not see any text requiring any of the =value settings to be without spaces or '=' characters, however, so a straight examination of the string using ' ', '=', and NUL as delimiters may get confused. It's highly unlikely an implementation might do something like this, but it doesn't seem accounted for.

Example, when:
VALUE1=DATA NAME IS VALUE2=
VALUE3=OTHER DATA

is what is required in the environment to set the mode, but confstr(_CS_V7_ENV,...) returns:
'VALUE1=DATA NAME IS VALUE2= VALUE3=OTHER DATA'

A simple (look for '=', look for ' ' or NUL) loop would split it as:
"VALUE1"="DATA" ; value truncated
"NAME IS VALUE2"="" ; spaces illegal in name, bogus additional setting
"VALUE3"="OTHER" ; value truncated again
"DATA" ; error about no '=' char when NUL encountered.

Similar loops have other difficulties, as might the value returned by `getconf V7_ENV` in a script.
The best case I see would be:
"VALUE1"="DATA NAME IS" ; value still truncated
"VALUE2"="" ; still a bogus setting
"VALUE3"="OTHER DATA" ; is ok

This also indicates that implementations can't provide special utilities to set conforming mode, but just use one or more environment settings, yet the text at Line 491 leaves that open. I'm not sure if that's a separate ERN, can be handled here, or it's moot from the confstr() description being normative.
Desired ActionAt Line 23443, Add:
"If the value portion of a name=value pair contains a space or '=' character, the implementation shall surround the value with single or double quote pairs to further delimit the value. The application shall be responsible for removing these quotes, if present, before use of value with an interface that modifies the environment such as setenv() or putenv()."

or text requiring implementations not use ' ' or '=' in any value.

or an Application Usage addition warning that is a possibility an application's use of the return value may need to account for.
Tagstc2-2008

Activities

geoffclare

2013-12-16 11:16

manager   bugnote:0002075

Suggested change:

After XBD page 16 line 493 section 2.1.1 add a small-font note:

    Note: If the documented method of setting up a conforming environment
    includes the need to set one or more environment variables, then the
    values of those environment variables cannot include any <space>
    characters, since the confstr() function must be able to
    return them in a <space>-separated list of variable=value pairs.
    See [xref to XSH confstr()].

shware_systems

2013-12-16 20:57

reporter   bugnote:0002076

Last edited: 2013-12-16 21:02

 Re: 0002075
That'll work. Your point, on mailing list, about if spaces are precluded "=" is include-able well taken; I was trying to keep neither precluded in case there was a technical reason an implementation might need spaces in a value. I can't point to a specific existing example, which is why I said highly unlikely, but it's not entirely implausible. Rather than have the interface add quotes automatically, it could be left to the implementation to add them, and then the interface description would reflect they may be present and need to be accounted for in splitting the string, but it would be up to the implementation, where needed, to strip them out when it sees those values.

I also suggest changing, to better reflect intent:
"the string stored in buf will contain the <space>-separated list of variable=value environment
variable pairs required by the implementation to create a conforming environment, as described
in the implementations’ conformance documentation."

to:
"a string stored in buf will contain a <space>-separated list of the variable=value environment
variable pairs an implementation requires as part of specifying a conforming environment, as described
in the implementations’ conformance documentation."

With 'a string', 'a ... list' and 'as part of' that leaves open there may be other things needed to be done, where 'the string' and 'the ... list' implies it's the only thing needed and will return some string other than "". A blurb that "The value 0 is a valid return for *_ENV names that indicates the method an implementation uses to specify a conforming environment is done with special implementation defined utilities or as boot time options that don't reference the environment.", also appears appropriate, probably as an App Usage note. Yes? No?

I was also thinking, for implementations that support multiple versions of the standard can the V6 constants be considered obsolete? If Issue 8 removes them as LEGACY but the implementation supports V6, V7, and V8 that'll force a V6 app to be changed to compile properly. I can see keeping _CS_PATH and *_ENV as explicit values that never obsolete, and generic identifiers being introduced for the compilation values, with the caveat '_CS_V' and '_CS_POSIX_' are prefixes reserved to the standard.

To account for that possibility, I think at Line 23446:
"that accesses all of the standard utilities of POSIX.1-2008,"

should be changed to:
"that accesses all of the standard utilities of the POSIX version, nominally POSIX.1-2008, set as the base conforming environment,"

This would be in keeping with using separate directories for utilities that conform to specific versions, but not preclude single executables in one dir from adjusting to version changes in other ways. Comments?

geoffclare

2014-02-27 17:13

manager   bugnote:0002166

At page 692 line 23441 section confstr change:

   the string stored in buf will contain the <space>-separated
   list of variable=value environment variable pairs required by the
   implementation to create a conforming environment, as described
   in the implementations’ conformance documentation.

to:

   the string stored in buf shall contain a <space>-separated
   list of the variable=value environment variable pairs an
   implementation requires as part of specifying a conforming
   environment, as described in the implementations’ conformance
   documentation

After XBD page 16 line 493 section 2.1.1 add a small-font note:

    Note: If the documented method of setting up a conforming environment
    includes the need to set one or more environment variables, then the
    values of those environment variables cannot include any <space>
    characters, since the confstr() function must be able to
    return them in a <space>-separated list of variable=value pairs.
    See [xref to XSH confstr()].

Issue History

Date Modified Username Field Change
2013-12-15 23:10 shware_systems New Issue
2013-12-15 23:10 shware_systems Name => Mark Ziegast
2013-12-15 23:10 shware_systems Section => confstr()
2013-12-15 23:10 shware_systems Page Number => 692
2013-12-15 23:10 shware_systems Line Number => 23443
2013-12-16 11:16 geoffclare Note Added: 0002075
2013-12-16 20:57 shware_systems Note Added: 0002076
2013-12-16 21:02 shware_systems Note Edited: 0002076
2014-02-27 17:13 geoffclare Note Added: 0002166
2014-02-27 17:17 geoffclare Interp Status => ---
2014-02-27 17:17 geoffclare Final Accepted Text => 0000810:0002166
2014-02-27 17:17 geoffclare Status New => Resolved
2014-02-27 17:17 geoffclare Resolution Open => Accepted As Marked
2014-02-27 17:17 geoffclare Tag Attached: tc2-2008
2019-06-10 08:55 agadmin Status Resolved => Closed