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
0000810 [1003.1(2013)/Issue7+TC1] System Interfaces Objection Clarification Requested 2013-12-15 23:10 2019-06-10 08:55
Reporter shware_systems View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Mark Ziegast
Organization
User Reference
Section confstr()
Page Number 692
Line Number 23443
Interp Status ---
Final Accepted Text Note: 0002166
Summary 0000810: Potential ambiguity in _CS_V[67]_ENV return value
Description The 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 Action At 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.
Tags tc2-2008
Attached Files

- Relationships

-  Notes
(0002075)
geoffclare (manager)
2013-12-16 11:16

 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()].
(0002076)
shware_systems (reporter)
2013-12-16 20:57
edited on: 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?
(0002166)
geoffclare (manager)
2014-02-27 17:13

 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 => Note: 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

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