PASC Interpretation Ref: pasc-1003.2-143
Topic: c89

Use of the information contained in this unapproved document is at your own risk.

Last update: 03 January,1997

								1003.2-92  #143

 _____________________________________________________________________________


	Interpretation Number:	xxxx
	Topic:			c89
	Relevant Sections:	2.9.1.4 and A.1.2

Interpretation Request:
-----------------------

        From: Andre Bellotti <aab@unx.dec.com>
	Date: Sun, 10 Dec 1995 11:30:00 - 0800

Dear Standards Board,

    I would like to request a formal interpretation concerning 
the following point in IEEE Std 1003.2-1992 (POSIX.2).

Contrary to historical practice, the Standard is ambiguous as to 
whether or not the execute permissions will be set on the file 
created by the c89 compiler if a file of the same name already 
exists without execute permissions.


In section A.1.2, page 688, lines 27 through 31 it states:

   "The executable file shall be created as specified in 2.9.1.4, 
    except that the file permissions shall be set to

	    S_IRWXO|S_IRWXG|S_IRWXU

   (see 6.6.1.2 in POSIX.1 {8}) and that the bits specified by 
    the umask of the process shall be cleared."

This would indicate that in all cases that the file should be 
created with the permissions as specified.  As this is obviously 
the action desired from an executable file created by a compiler 
this should be definitive.  However an ambiguity arises in the 
case of an existing file that is being overwritten by the output 
of the compiler.  

In section 2.9.1.4, page 93, lines 3390 and 3391 the specification
states that:

     "When a file that does not exist is created, the following 
      POSIX.1 {8} features shall apply unless the utility or 
      function description states otherwise:"

Unfortunately in the case of an existing file the modifying language
allowing the utility to override the section 2.9.1.4 does not exist;
page 93, lines 3404 and 3405 read:

     "When an attempt is made to create a file that already exists, 
      the action shall depend on the file type:"

Without the modifying language the intent of the explicit permissions
in the c89 description becomes ambiguous to apply.

As it is obvious that the rules that were being referred to by the
reference to section 2.9.1.4 were those dealing with files other than
regular text files we would recommend that section 2.9.1.4, page 93,
line 3409 be changed to read

" (2) For regular files, unless the utility or function description
  states otherwise:"

This would eliminate any ambiguity of application of explicit
permissions upon existing files that are being overwritten. 


Thank you for your attention to this matter.

Interpretation response
------------------------

The standard clearly states the behavior for setting permissions on a file's
creation and conforming implementations must conform to this.  The exception
stated on Page 688 applies to both cases of a file existing and not existing.
It is not limited to either case.


Rationale
-------------
None.
Forwarded to Interpretations group: Dec 28 1995
Commence 30 day review: Mar 8 1996
Finalised: Oct 28 1996

PASC Interpretation Ref: pasc-1003.2-148
Topic: ar command

Use of the information contained in this unapproved document is at your own risk.

Last update: 03 January,1997

								1003.2-92  #148

 _____________________________________________________________________________


	Interpretation Number:	148
	Topic:			ar command
	Relevant Sections:	6.1.6.1
	Classification:		Ambiguous

Interpretation Request:
-----------------------

	From fredz@pacific-89 
	Fri Jul 12 13:23 PDT 1996

Dear Interpretations Committee,

I would like to request an official binding interpretation of IEEE
Std 1003.2-1992 (POSIX.2).  This request deals with the format
of the standard output of the "ar" utility.  This format is specified
in POSIX.2 subclause 6.1.6.1, and the item for which I request an
interpretation is on lines 127-146. These lines read:

    If the -t option is used with the -v option, the standard output
    format shall be

	"%s %u/%u %u %s %d %d:%d:%d %d %s\n", <member mode>,
	<user ID>, <group ID>, <number of bytes in member>,
	<abbreviated month>, <day-of-month>, <hour>, <minute>,
	<year>, <file>

    where

	file		shall be the operand specified on the
			command line, if file operands were specified,
			or the name of the file in the archive if they
			were not.

	<member mode>	shall be formatted the same as the <file mode>
			string defined in 4.39.6.1, except that the
			first character, the <entry type>, is not used;
			the string represents the file mode of the archive
			member at the time it was added to, or replaced in,
			the archive.

    The following represent the last-modification time of a file when it
    was most recently added to or replaced in the archive:

	<abbreviated month>	Equivalent to the %b format in date
				(see 4.15).

	<day-of-month>		Equivalent to the %e format in date.

	<hour>			Equivalent to the %H format in date.

	<minute>		Equivalent to the %M format in date.

	<year>			Equivalent to the %Y format in date.

My question is: in the day-of-month, hour, minute and year fields,
under what conditions (if any) is a value in the range 0-9 printed with
a leading zero?

My reading of this description is that the different numeric fields in
the archive member's modification time are (logically, at least)
formatted in a two-step process: first strings are created using
formats from the date utility, and then the output is formed from these
strings using the standard output formatting conventions of POSIX.2 as
specified in subclause 2.12 (File Format Notation).  The %d format from
subclause 2.12 is used for all four fields in question.  With no precision
specifier, a default of 1 is assumed (2.12 lines 4104-4105), and thus no
leading zeroes should be printed for values > 0.  Under this reading,
a modification time of June 4 at 3:05:13 am would be printed as

	Jun 4  3:5:13

This does not agree with any of the historical formats, which would
give either

	Jun 04 03:05:13

or

	Jun  4 03:05:13

The use of the %e, %H, %M and %Y formats leads me to suspect that the
intent of the standard was for the use of the latter format (with possibly
different white space).  However, I do not believe that this is what the
standard actually calls for.  Could you please clarify the normative
requirements imposed on the ar utility by this portion of the standard.

Thank you for your attention to this matter.

Fred Zlotnick
fred.zlotnick@eng.sun.com

IEEE Interpretation for 1003.2-1992 
-----------------------------------

The standard is ambiguous on this issue and no conformance
distinction can be made between alternative implementations
based on this.  This is being referred to the sponsor.
           

Rationale for Interpretation:
-----------------------------
None.



Editorial note for future revision of standard (not part of this interpretation)
-------------------------------------------------------------------------------
A proposed change to the section 6.1.6.1 ar Command is as follows:

Page 664, line 128:
From:
	"%s %u/%u %u %s %d %d:%d %d %s\n", <member mode>,
To:
	"%s %u/%u %u %s %s\n", <member mode>,

Page 664, line 130:
From:
	<abbreviated month>, <day-of-month>, <hour>, <minute>, <year>,
	<file>
To:
	<date and time>, <file>

Page 664, lines 140-149:
From:
	The following represent the last-modification time of a file when
	it was most recently added to or replaced in the archive:

	<abbreviated month>	Equivalent to the %b format in date (see 4.15).
	<day-of-month>		Equivalent to the %e format in date.
	<hour>			Equivalent to the %H format in date.
	<minute>		Equivalent to the %M format in date.
	<year>			Equivalent to the %Y format in date.

	When LC_TIME does not specify the POSIX Locale, a different format
	and order of presentation of these fields relative to each other
	may be used in a format appropriate in the specified locale.
To:
	The <date and time> field shall contain the last-modification date
	and time of the file as of when it was most recently added to or
	replaced in the archive.  In the POSIX Locale, the field shall be
	the equivalent of the output of the following date command (see
	4.15):

		date "+%b %e %H:%M %Y"

	However, the final <newline> produced by date shall not be included
	and the output shall be as if the date command were executed at
	the time of the last-modification date of the file as described
	above rather than the current time.  When the LC_TIME locale
	category is not set to the POSIX Locale, a different format and
	order of presentation of this field may be used.
	
NOTE: There is no certainty that these comments will apply to any
revision of IEEE Std 1003.2-1992.

Finalised:  3rd Jan 1997

PASC Interpretation Ref: pasc-1003.2-149
Topic: sh and SIGTERM

Use of the information contained in this unapproved document is at your own risk.

Last update: 03 January,1997

								1003.2-92  #149

 _____________________________________________________________________________


	Interpretation Number:	xxxx
	Topic:			sh and SIGTERM
	Relevant Sections:	6.1.6.1

Interpretation Request:
-----------------------

	From: ajosey@xopen.org (Andrew Josey)
	Date: Thu, 8 Aug 1996 15:25:34 +0100

I wish to ask for an interpretation request of the Shell and
Utilities standard, IEEE Std 1003.2-1992 (ISO/IEC 9945-2:1993)
related to signal handling by the shell. This issue
has been raised due to a test for a POSIX.2 test assertion.

To operate correctly, historically the shell has ignored SIGTERM for
shells that are deemed an interactive shell.  

Although POSIX.2 does not seem to discuss this issue, all shells we 
could check (ksh88, Bourne shell, ksh93, csh) are documented to 
ignore SIGTERM when they are interactive shells so that the 
command "kill 0" will not kill the login shell. We believe this
is valid for the POSIX shell as well.
	
To allow the "kill 0" for process group to have the desired
functionality a newly invoked utility needs to reset the disposition of
SIGTERM at startup and so introduces a race condition which is being hit
by this test case on systems which are fast (typically those with shells
that implement many common utilities by builtins).

The test suite assumes that a shell is interactive  - based on the 
page 414 of POSIX.2 lines 8852-8854:

	"if the -i option is present, or if there are no operands and the
	shell's standard input and standard error are attached to a terminal,
	the shell is considered to be interactive"

The test does not allow for the possibility of a race condition.
This problem can usually be duplicated by issuing the following
commands from an interactive shell:

        sleep 20 & kill %1

The "kill %1" doesn't terminate the "sleep 20" if the kill is
performed before the signal handlers are reset in the subshell
invoking the sleep.  

This may not work 100% of the time, because of the race for the child to start
and reset the disposition of SIGTERM before kill sends the signal; 
shells with builtin kill commands should demonstrate this most easily.

The actual test does the following:

sleep 300 & bg 2>/dev/null >/dev/null; cat - ; kill %1 2>/dev/null >/dev/null;

The following points are the important issues

1) all interactive shells need to handle/ignore SIGTERM.

2) jobs started by these interactive shells must reset the
disposition of SIGTERM at startup.

3) there is a race condition where the jobs may receive SIGTERM
after they are created but before they have had time to reset
SIGTERM's disposition.

4) VSC bg-17 test can hit that race condition, especially when the
shell is very fast with respect to "bg" and "cat", both of
which are builtins in our shell.
	   
Does a conforming shell have to delay continued processing
in the parent shell until the signal handlers in the asynchronous
list have been reset? 
	   
	
Interpretation response
------------------------
The standard clearly states the requirement sof execution
of asynchronous lists and conforming implementations
must conform to this.

The description of asynchronous lists in section 3.9.3.1 says that
the command terminated by the control operator & shall be executed
in a subshell. We believe that this means that the command runs
asynchronously with the parent shell, but not the creation of the
subshell, therefore the standard requires the sleep to be killed
in the example given.

If the phrase in 3.9.3.1 had stated that a subshell was created
asynchronously to execute the command the behaviour suggested would
be ok.

Rationale
-------------
None.

Forwarded to Interpretations group: Aug 9 1996
Forward for 30 day review: 22 Oct 1996
Finalised: 24 Nov 1996