[Xenomai] Why does mqueue.h define mqd_t as unsigned

[Xenomai] Why does mqueue.h define mqd_t as unsigned

[Phil Mitchell]

Dear All,

mqueue.h defines mqd_t as an unsigned long. The function mq_open returns
type mqd_t and states that -1 is returned in case of error.

Is mqd_t defined incorrectly or am I missing something?

Thanks,
Phil Mitchell

Re: [Xenomai] Why does mqueue.h define mqd_t as unsigned

[Gilles Chanteperdrix]

On Thu, Apr 09, 2015 at 04:52:26PM -0400, Phil Mitchell wrote:
> Dear All,
> 
> mqueue.h defines mqd_t as an unsigned long. The function mq_open returns
> type mqd_t and states that -1 is returned in case of error.
> 
> Is mqd_t defined incorrectly or am I missing something?

The specification does not say what mqd_t should be and says that
mq_open returns (mqd_t)-1, not -1, and (unsigned long)-1 is valid,
so, this is valid even if a bit strange. mqd_t is an opaque type for
the user anyway, so its actual type should not matter to you.

But in fact we do not even need a long type since what is returned
is a file descriptor, so, we could have typedef int mqd_t like
glibc.

-- 
					    Gilles.

Re: [Xenomai] Why does mqueue.h define mqd_t as unsigned

[Paul Janzen]

Phil Mitchell <p.mitch@gmail.com> writes:

> mqueue.h defines mqd_t as an unsigned long. The function mq_open returns
> type mqd_t and states that -1 is returned in case of error.
>
> Is mqd_t defined incorrectly or am I missing something?

The man page says mq_open returns (mqd_t)(-1) on error. If you include
that cast when you test the return value it works, even if mqd_t is
unsigned.  (Or a pointer.)

-- Paul

Re: [Xenomai] Why does mqueue.h define mqd_t as unsigned

[Lennart Sorensen]

On Thu, Apr 09, 2015 at 02:11:53PM -0700, Paul Janzen wrote:
> Phil Mitchell <p.mitch@gmail.com> writes:
> 
> > mqueue.h defines mqd_t as an unsigned long. The function mq_open returns
> > type mqd_t and states that -1 is returned in case of error.
> >
> > Is mqd_t defined incorrectly or am I missing something?
> 
> The man page says mq_open returns (mqd_t)(-1) on error. If you include
> that cast when you test the return value it works, even if mqd_t is
> unsigned.  (Or a pointer.)

Yuck!

Some of us try to avoid explicit casts since they are a great way to
hide bugs in ways the compiler can't help you find.

Making a cast required by design seems like a major design bug that
ought to be fixed.

-- 
Len Sorensen

Re: [Xenomai] Why does mqueue.h define mqd_t as unsigned

[Gilles Chanteperdrix]

On Thu, Apr 09, 2015 at 06:09:56PM -0400, Lennart Sorensen wrote:
> On Thu, Apr 09, 2015 at 02:11:53PM -0700, Paul Janzen wrote:
> > Phil Mitchell <p.mitch@gmail.com> writes:
> > 
> > > mqueue.h defines mqd_t as an unsigned long. The function mq_open returns
> > > type mqd_t and states that -1 is returned in case of error.
> > >
> > > Is mqd_t defined incorrectly or am I missing something?
> > 
> > The man page says mq_open returns (mqd_t)(-1) on error. If you include
> > that cast when you test the return value it works, even if mqd_t is
> > unsigned.  (Or a pointer.)
> 
> Yuck!
> 
> Some of us try to avoid explicit casts since they are a great way to
> hide bugs in ways the compiler can't help you find.
> 
> Making a cast required by design seems like a major design bug that
> ought to be fixed.

This design is specified by POSIX. This looks like a "fighting the
windmill" case.

-- 
					    Gilles.

Re: [Xenomai] Why does mqueue.h define mqd_t as unsigned

[Gilles Chanteperdrix]

On Fri, Apr 10, 2015 at 12:17:18AM +0200, Gilles Chanteperdrix wrote:
> On Thu, Apr 09, 2015 at 06:09:56PM -0400, Lennart Sorensen wrote:
> > On Thu, Apr 09, 2015 at 02:11:53PM -0700, Paul Janzen wrote:
> > > Phil Mitchell <p.mitch@gmail.com> writes:
> > > 
> > > > mqueue.h defines mqd_t as an unsigned long. The function mq_open returns
> > > > type mqd_t and states that -1 is returned in case of error.
> > > >
> > > > Is mqd_t defined incorrectly or am I missing something?
> > > 
> > > The man page says mq_open returns (mqd_t)(-1) on error. If you include
> > > that cast when you test the return value it works, even if mqd_t is
> > > unsigned.  (Or a pointer.)
> > 
> > Yuck!
> > 
> > Some of us try to avoid explicit casts since they are a great way to
> > hide bugs in ways the compiler can't help you find.
> > 
> > Making a cast required by design seems like a major design bug that
> > ought to be fixed.
> 
> This design is specified by POSIX. This looks like a "fighting the
> windmill" case.

I think the upside of this design is that it allows mqd_t being
implemented as a pointer or as an integer, this gives freedom to the
implementer by making the type opaque.

-- 
					    Gilles.

Re: [Xenomai] Why does mqueue.h define mqd_t as unsigned

[Lowell Gilbert]

Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> writes:

> On Fri, Apr 10, 2015 at 12:17:18AM +0200, Gilles Chanteperdrix wrote:

>> This design is specified by POSIX. This looks like a "fighting the
>> windmill" case.
>
> I think the upside of this design is that it allows mqd_t being
> implemented as a pointer or as an integer, this gives freedom to the
> implementer by making the type opaque.

Yes, but in other cases POSIX specified symbolic constants rather than
numeric values for exactly that problem.  It's possible that somebody just
made a mistake by not doing that here, but I would venture to guess that
there was probably an issue with existing code that led to this hack.

Re: [Xenomai] Why does mqueue.h define mqd_t as unsigned

[Lennart Sorensen]

On Fri, Apr 10, 2015 at 12:17:18AM +0200, Gilles Chanteperdrix wrote:
> This design is specified by POSIX. This looks like a "fighting the
> windmill" case.

Yeah "Posix says so" always wins any argument it seems. :)

-- 
Len Sorensen

Re: [Xenomai] Why does mqueue.h define mqd_t as unsigned

[Gilles Chanteperdrix]

On Fri, Apr 10, 2015 at 10:44:10AM -0400, Lennart Sorensen wrote:
> On Fri, Apr 10, 2015 at 12:17:18AM +0200, Gilles Chanteperdrix wrote:
> > This design is specified by POSIX. This looks like a "fighting the
> > windmill" case.
> 
> Yeah "Posix says so" always wins any argument it seems. :)

Adding #define MQ_FAILED ((mqd_t)-1) in your application and using
it makes your application portable. Adding it to Xenomai headers and
using it in your application makes your application non portable. If
the POSIX standard added this definition, then if you wanted your
application to be portable, you would want it to support previous
POSIX standards, so you would still add this definition to your
application (with an added ifdef on the posix standard level).

So, all and all, adding #define MQ_FAILED ((mqd_t)-1) to your
application and move on wins the argument.

-- 
					    Gilles.

Re: [Xenomai] Why does mqueue.h define mqd_t as unsigned

[Gilles Chanteperdrix]

On Thu, Apr 09, 2015 at 11:07:13PM +0200, Gilles Chanteperdrix wrote:
> On Thu, Apr 09, 2015 at 04:52:26PM -0400, Phil Mitchell wrote:
> > Dear All,
> > 
> > mqueue.h defines mqd_t as an unsigned long. The function mq_open returns
> > type mqd_t and states that -1 is returned in case of error.
> > 
> > Is mqd_t defined incorrectly or am I missing something?
> 
> The specification does not say what mqd_t should be and says that
> mq_open returns (mqd_t)-1, not -1, and (unsigned long)-1 is valid,
> so, this is valid even if a bit strange. mqd_t is an opaque type for
> the user anyway, so its actual type should not matter to you.
> 
> But in fact we do not even need a long type since what is returned
> is a file descriptor, so, we could have typedef int mqd_t like
> glibc.

In fact mqd_t is already an int in the following case:
- in kernel-space where it gets defined by kernel/types.h
- in user-space when the glibc has mqueue.h, since then include that
header.

The only remaining cases where we use unsigned long are:
- glibc without an mqueue.h, but I believe they are rare now a days
- when compiling for xeno-sim, which has been unusable with recent
compilers for years now.

So, I think we do not care.

-- 
					    Gilles.