headers
rajani.g.k | 8 Jan 2009 08:41
Picon
Favicon

Defect in XSH 2.4.3

	Defect report from : G. K. Rajani , Hewlett Packard

(Please direct followup comments direct to austin-group-l@...)

 <at>  page 489 line 16723 section 2.4.3 comment {GKRFORK012009}

Problem:

Edition of Specification (Year): 2008

Defect code :  3. Clarification required

Section 2.4.3. P489 L16723 Asserts that fork() is async-signal safe. 

The fork() system interfaces section P882 L29311-29312 asserts that registered fork handlers are
executed during the fork.

P882 L 29313-29315 asserts that only async-signal safe functions are 
to be called by pthread_at_fork handlers to provide signal safety for fork().

The rationale section of pthread_atfork() explains the purpose of 
these functions.

As per this section, XSH P1529, L49389-49402, it is possible that 
multithreaded libraries could be used by single threaded 
applications. In which case, atfork handlers are essential for the 
libraries to protect their internal state during fork. As explained 
further P1530, L49403-49404, pthread_atfork functions are mainly 
required to acquire/release mutex locks, for protecting the 
applications/libraries from fork() calls. C-library needs to as well
(Continue reading)

Permalink | Reply | 0 comments |
headers
Geoff Clare | 9 Jan 2009 16:32
Picon
Favicon

Defect in XSH 2.9.3

 <at>  page 508 line 17536-17542 section 2.9.3 objection [gwc 2.9.3 EOWNERDEAD]

Problem:

Edition of Specification (Year): 2008

Defect code :  1. Error

The second paragraph of 2.9.3 states:

    A thread shall become the owner of a mutex, m, when one of the
    following occurs:

        * It returns successfully from pthread_mutex_lock( ) with m as
          the mutex argument.

        * It returns successfully from pthread_mutex_trylock( ) with m
          as the mutex argument.

        * It returns successfully from pthread_mutex_timedlock( ) with
          m as the mutex argument.

        * It returns (successfully or not) from pthread_cond_wait() with
          m as the mutex argument (except as explicitly indicated
          otherwise for certain errors).

        * It returns (successfully or not) from pthread_cond_timedwait()
          with m as the mutex argument (except as explicitly indicated
          otherwise for certain errors).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Geoff Clare | 9 Jan 2009 16:36
Picon
Favicon

Defect in XBD signal.h

 <at>  page 330 line 11032 section signal.h editorial [gwc SIGPROF XSR]

Problem:

Edition of Specification (Year): 2008

Defect code :  1. Error

In the September 2006 plenary meeting, the decision was made to
make SIGPROF obsolescent in the revision.  The minutes (Austin/317)
state:

    signal.h: SIGPOLL should be OB as well as XSR. SIGPROF: should
    be OB (but SIGSYS SIGTRAP just XSI). 

However, this change was not implemented correctly in POSIX.1-2008,
where the shading for SIGPROF changed from XSI to OB XSR, instead
of to OB XSI.

Action:

Change the shading on SIGPROF from OB XSR to OB XSI.
Permalink | Reply | 0 comments |
headers
Geoff Clare | 9 Jan 2009 16:42
Picon
Favicon

Defect in XCU mv

 <at>  page 2955 line 97288 section mv objection [gwc mv AI-016]

Problem:

Edition of Specification (Year): 2008

Defect code :  1. Error

The following text was added to the end of the first paragraph on the
mv page in the 2008 revision, as a result of interpretation AI-016:

    "In this case, if target_file ends with a trailing <slash>
    character, mv shall treat this as an error and no source_file
    operands will be processed."

Here, "in this case" is a reference to "the final operand does not
name an existing directory and is not a symbolic link referring to an
existing directory".

This is fine for the case where an attempt is made to rename a
non-directory file, e.g.:

    mv regular_file new_name/

but I can see no reason that an attempt to rename a directory
should fail, e.g.:

    mv existing_dir new_dir/

or:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Geoff Clare | 9 Jan 2009 16:47
Picon
Favicon

Defect in XSH pthread_cond_timedwait

 <at>  page 1587 line 51027-51034 section pthread_cond_timedwait editorial [gwc pctw timeout]

Problem:

Edition of Specification (Year): 2008

Defect code :  3. Clarification required

In the description of pthread_cond_timedwait(), a statement about the
clock attribute and a paragraph break have been inserted between two
closely related sentences.  The text should be rearranged in order
to reunite the related sentences.

Action:

In the two paragraphs:

    The pthread_cond_timedwait() function shall be equivalent to
    pthread_cond_wait(), except that an error is returned if the
    absolute time specified by abstime passes (that is, system time
    equals or exceeds abstime) before the condition cond is signaled
    or broadcasted, or if the absolute time specified by abstime has
    already been passed at the time of the call.

    The condition variable shall have a clock attribute which
    specifies the clock that shall be used to measure the time
    specified by the abstime argument. When such timeouts occur,
    pthread_cond_timedwait() shall nonetheless release and re-acquire
    the mutex referenced by mutex.  The pthread_cond_timedwait()
    function is also a cancellation point.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Geoff Clare | 9 Jan 2009 16:53
Picon
Favicon

Defect in XSH pthread_mutex_lock

 <at>  page 1639 line 52741 section pthread_mutex_lock objection [gwc pmtl return]

Problem:

Edition of Specification (Year): 2008

Defect code :  1. Error

The RETURN VALUE section on the pthread_mutex_lock() page states:

    "The pthread_mutex_trylock() function shall return zero if a lock
    on the mutex object referenced by mutex is acquired. Otherwise, an
    error number is returned to indicate the error."

This conflicts with the description of the EOWNERDEAD error for
pthread_mutex_trylock() which says "The mutex lock shall be acquired
by the calling thread".

Action:

On line 52739 (1st line of RETURN VALUE) change

    "pthread_mutex_lock() and pthread_mutex_unlock()"

to

    "pthread_mutex_lock(), pthread_mutex_trylock() and pthread_mutex_unlock()"

Delete lines 52741-52742 (2nd para of RETURN VALUE).
(Continue reading)

Permalink | Reply | 0 comments |
headers
ebb9 | 9 Jan 2009 22:00
Gravatar

Defect in XCU date

	Defect report from : Eric Blake , N/A

(Please direct followup comments direct to austin-group-l@...)

 <at>  page 2575 line 82893 section date objection {ebb.date}

Problem:

Edition of Specification (Year): 2008

Defect code :  2. Omission

Although the date utility provides an interface similar to the
strftime function, there are several things specified only for the
latter (some with CX shading), which would be useful from a command
line interface.  These include: missing specifiers, addition of flags,
addition of minimum field width.

This aardvark only addresses missing specifiers.  An alternative
solution might be to couch the entire discussion of the format
argument of the date utility in terms of a call to strftime, so that
the next time the strftime interface is extended, the date utility
implicitly picks up that extension; this would also pick up the '0'
and '+' flags as well as minimum field width.

Action:

At line 82893, insert:

%F  Date in the format %Y-%m-%d
(Continue reading)

Permalink | Reply | 1 comment |
headers
Schwarz, Konrad | 12 Jan 2009 09:29
Picon

RE: Defect in XCU date

> -----Original Message-----
> From: ebb9@... [mailto:ebb9@...] 
> 
> 
> 	Defect report from : Eric Blake , N/A
> 
> Defect code :  2. Omission
> 
> Although the date utility provides an interface similar to the
> strftime function, there are several things specified only for the
> latter (some with CX shading), which would be useful from a command
> line interface.  These include: missing specifiers, addition of flags,
> addition of minimum field width.

Another feature which I have missed is the ability to output the number
of
seconds since the "epoch".  This would be useful for simple benchmarking
applications.

Or does the committee feel that the "time" utility suffices?

By the way, http://www.opengroup.org/onlinepubs/000095399/, section
EXAMPLES,
has a typographical error: presumably

while true
do
    command    sleep 37
done
(Continue reading)

Permalink | Reply | 0 comments |
headers
Geoff Clare | 16 Jan 2009 11:06
Picon
Favicon

Defect in XSH ungetc

 <at>  page 2151 line 67920 section ungetc objection [gwc ungetc fseeko]

Problem:

Edition of Specification (Year): 2008

Defect code :  1. Error

The description of ungetc() states:

    "A successful intervening call (with the stream pointed to by
    stream) to a file-positioning function (fseek(), fsetpos(), or
    rewind()) shall discard any pushed-back bytes for the stream."

This text is taken from the C Standard, but in POSIX there is an
additional file-positioning function, fseeko(), which should also
be listed.  The ungetwc() page has the same problem.

Action:

Change

    "(fseek(), fsetpos(), or rewind())"

to

    "(fseek(), [CX]fseeko(),[/CX] fsetpos(), or rewind())"

Also make the same change on the ungetwc() page (P2152 L67964).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Geoff Clare | 16 Jan 2009 11:55
Picon
Favicon

Defect in XSH fscanf

 <at>  page 934 line 31304 section fscanf objection [gwc fscanf return]

Problem:

Edition of Specification (Year): 2008

Defect code :  1. Error

In austin-group-l 11809, Vincent Lefèvre identified a conflict with
the C Standard:

---- begin quote ----

I think there is a contradiction between POSIX.1-2008 and the
ISO C standard concerning fscanf when an input failure occurs
after the first conversion.

The ISO C standard (at least N1124 and N1336) says:

7.19.6.2 The fscanf function

  4  The fscanf function executes each directive of the format in turn.
     If a directive fails, as detailed below, the function returns.
     Failures are described as input failures (due to the occurrence
     of an encoding error or the unavailability of input characters),
     or matching failures (due to inappropriate input).

 16  The fscanf function returns the value of the macro EOF if an
     input failure occurs before any conversion.  Otherwise, the
     function returns the number of input items assigned, which can
(Continue reading)

Permalink | Reply | 1 comment |

Gmane