SVr4/SVID/SUS IPC conformance

SVr4/SVID/SUS IPC conformance

[Anton Arapov]

Hi!

* Please, gurus, who cares about standards conformance, do not ignore this message!

  SysV code returns EIDRM for collision of IDs. I sure it should return EINVAL.

  Steps to reproduce: (this for shared memory code, for msg/sem it is the same)
   1. Create then drop 2 shmem segments, then create a third.
   2. Try to shmctl(IPC_STAT) the two now-invalid shm IDs.
   3. Note error codes returned.

   One call gives EINVAL, one gives EIDRM due to collision with the third shmem \
segment.  Should both give EINVAL, this is what I've got on every other Unix I've \
tried it on. 

  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. 

  Can somebody explain why do we have EIDRM?

Anton.
SUS: http://www.opengroup.org/onlinepubs/007908799/xsh/shmctl.html
-- 
Anton Arapov, <aarapov@redhat.com>

Re: SVr4/SVID/SUS IPC conformance

[Arjan van de Ven]

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.

Re: SVr4/SVID/SUS IPC conformance

[Jesper Juhl]

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