Thanks Don and Roger. So I guess the symbols need to be protected as
Don suggests. Otherwise it looks pretty good to me. ;-)
- Garrett
Don Cragun wrote:
>> Date: Wed, 01 Oct 2008 05:28:10 -0700 (PDT)
>> From: "Roger A. Faulkner" <Roger.Faulkner at sun.com>
>>
>>
>>> Date: Tue, 30 Sep 2008 21:04:52 -0700
>>> From: "Garrett D'Amore" <gdamore at sun.com>
>>>
>>> Q: Has there been any activity (that you're aware of) to amend the
>>> standard to support this kind of functionality? Is this something that
>>> our representative(s) with the POSIX group should be proposing for the
>>> next revision of the standard?
>>>
>>> -- Garrett
>>>
>> Garrett:
>> There has been no such activity as far as I know.
>> The SUSv4 specification has just been approved and it
>> contains nothing about this in the posix_spawn() specification.
>>
>> Don:
>> (Sorry, I should have Cc'd you on the original PSARC mail, shown below.)
>> Do you know of any such discussions by the Posix folks?
>> Do you think it's something we should propose to Posix for the future?
>>
>> Thanks,
>> Roger
>>
>>
>
> Roger,
> You didn't need to Cc me on the PSARC mail; I'm on the PSARC
> alias. No one has raised this issue for to the groups responsible for
> POSIX and SUS maintenance. SUSv4 became an official TOG standard a few
> months ago; IEEE Std 1003.1-2008 was approved by IEEE last Thursday
> (with the same text as SUSv4). The final ISO ballot to also adopt the
> same text as ISO/IEC 9945-1:200x should start two weeks from today.
> So, the next revision of the standards won't happen until 2013 at the
> earliest.
> But, we have another problem. The standards reserve all names
> with the prefixes posix, POSIX, _posix, and _POSIX for standards use
> only. Even with _NP or _np at the end, the names
> POSIX_SPAWN_SETSIGIGN_NP, posix_spawnattr_setsigignore_np(), and
> posix_spawnattr_getsigignore_np() will have to be hidden in the headers
> when building in standards conformance mode unless the source defines
> __EXTENSIONS__ before including <spawn.h>. (This is different from
> things like mq_reltimedreceive_np() and pthread_cond_reltimedwait_np()
> because the standards reserve names starting with mq_ and MQ_ in
> <mqueue.h> for implementation use and names starting with pthread_ and
> PTHREAD_ in <pthread.h> for implementation use.)
> I'll be happy to help you submit an aardvark report to request
> inclusion of this feature (without the _NP and _np suffixes) in the
> next revision of the standard. I don't see any reason at this point
> why there should be any problem getting this feature into the next
> revision.
>
> Cheers,
> Don
>
>
