[Bug 1204] sigset_t type change proposal

[rtems-bugs at rtems.org]

http://www.rtems.org/bugzilla/show_bug.cgi?id=1204





------- Comment #4 from ralf.corsepius at rtems.org  2007-01-09 22:26 -------
1. Let me cite SUSv3:

<cite>
sigset_t
    [CX] [Option Start] Integer or structure type of an object used to
represent sets of signals. [Option End]
</cite>

=> using a long for sigset_t is perfectly legitimate (Note they explicitly
mention "integer"!)

2. As with other similar issues before:
* cygwin (also newlib based - sigset_t == long) 
* mingw (which is NOT newlib based - sigset_t == int)
have the same issue.

3. As with other similar issues before, this RTEMS inherits its sigset_t from
newlib, so addressing this in newlib would be appropriate.

(In reply to comment #3)
> sigset_t is typedef'ed to long.  Would changing it to uint32_t be enough to
> really resolve his overloading issue?
No. It would probably only shift the problem around (uint32_t is just a typedef
to other ordinal types, in most cases int).

[Also, without having checked details in newlib and RTEMS, I am not sure if the
"typedef long sigset_t;" in newlib actually is a historical artefact/portable
work-around to newlib/gcc having lacked intptr_t. I.e. if it actually is being
used as a pointer.]

> Or does it need to change to "typedef struct { uint32_t signals; } sigset_t"?
> I know the latter will involve a fair number of code changes to address.
I guess this is what Johnny had in mind and seems to be what ACE is expecting.

That said, I think, ACE's expectations are bogus and is having a design
problem.

Nevertheless, I am not opposed to changing sigset_t into a struct. But if, then
then this change should happen in newlib, which probably won't be an easy task.


-- 
Configure bugmail: http://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.