> > Well, I was also a bit surprised to see that text in the barrier,
> > mutex, cv, rwlocks... I understood it that way:
> > "the address stored in attr is invalid", since attr is a pointer and
> > thus "the value of attr" is an address. Ok, from an implementation
> > point of view this means checking attr==NULL, or eventually (if
> > extremely user friendly) checking that the pointer refers to valid
> > memory address within the process.
>
> SOME of the pthread_*attr_destroy functions allow for EINVAL because the
> attr is invalid; NONE of the pthread_*attr_init functions do. At least
> not in the 1996 POSIX edition or in SUSv3 (2001 or 2003). Where are you
> getting this? Are you simply confused by the fact that the init and
> destroy functions are documented on the same man page? The EINVAL is
> carefully documented as "The pthread_*attr_destroy() function may fail
> if:" in each case where it appears.
For the pthread_*attr_destroy that was clear from the beginning.
I was confused for the pthread_*attr_init, because it was clear that
"we cannot check something that it is not initialized". So I had
difficulty to understand what
" [EINVAL] The value specified by attr is invalid. " could mean in this
case...
> The point, though, it that the "attr is invalid" is intended to be
> "MAY FAIL" so that none of this is actually REQUIRED. IF an
> implementation can and chooses to take any of these measures
> (or others) to attempt to diagnose the use of an improper address, or
> even of a block of storage that had been initialized as an attributes
> object but later overwritten by irrelevant values, it may.
> If it chooses not to, it need not.
Yes, that was the point I was definitively missing :(
We could have avoided this long discussion, though extremely usefull
for me, if I would have from the right beginning understood what you
meant by:
> > The pthread_attr_init() may fail if:
> > [EINVAL] The value specified by attr is invalid.
> >
>
> Um, that would be bad. One does not normally expect to be initializing
> a valid object, so this would suggest failure in the only case where
> one ought to be applying the interface! ;-)
I understood that this sentence was all wrong. But what you said is,
that without the [EBUSY] it would be bad (but not that the sentence is
bad).
And so I logically deduced that all pthread_*attr_init were wrong, since
this text is present everywhere...
I think we are now in sync.
Sorry about that!
Loic.
--
COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test
--------------------------------------------------
1. GMX TopMail - Platz 1 und Testsieger!
2. GMX ProMail - Platz 2 und Preis-Qualitätssieger!
3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post
|