Re: SVr4/SVID/SUS IPC conformance

["Jesper Juhl" <jesper.juhl@gmail.com>]

On 17/08/07, Arjan van de Ven <arjan@infradead.org> wrote:
>
> On Fri, 2007-08-17 at 19:18 +0200, Anton Arapov wrote:
> >
> >   IPC code is good, EIDRM is justification of EINVAL. But neither SVr4 nor SVID \
> > documents EIDRM.   Single Unix Specification mentions EINVAL but not EIDRM as a \
> > possible failure for shmctl(), so the current kernel behavior is not merely \
> > self-inconsistent but a flat violation of the spec.
>
> these specs tend to always allow additional error codes.
>
I can't seem to find anything in SuS v3 that says that. If you know
where I'd appreciate a pointer.
In fact, the spec seems pretty clear on what errors are OK.


"
    The shmctl() function shall fail if:

    [EACCES]
        The argument cmd is equal to IPC_STAT and the calling process
does not have read permission; see XSI Interprocess Communication.
    [EINVAL]
        The value of shmid is not a valid shared memory identifier, or
the value of cmd is not a valid command.
    [EPERM]
        The argument cmd is equal to IPC_RMID or IPC_SET and the
effective user ID of the calling process is not equal to that of a
process with appropriate privileges and it is not equal to the value
of shm_perm.cuid or shm_perm.uid in the data structure associated with
shmid.

    The shmctl() function may fail if:

    [EOVERFLOW]
        The cmd argument is IPC_STAT and the gid or uid value is too
large to be stored in the structure pointed to by the buf argument.
"


But I guess removing EIDRM is out of the question since that would
break userspace applications currently depending on it.
So I guess that the only way to write applications that are portable
between Linux and other *NIX clones is to test for the error code
being  (EINVAL || EIDRM)...

Or am I missing something?

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html