This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Add sigaltstack() to RTEMS conditional path
- From: Ralf Corsepius <ralf dot corsepius at rtems dot org>
- To: newlib at sourceware dot org
- Date: Fri, 07 Sep 2012 05:35:29 +0200
- Subject: Re: Add sigaltstack() to RTEMS conditional path
- References: <5047D491.4030507@oarcorp.com>
On 09/06/2012 12:39 AM, Joel Sherrill wrote:
Hi
This patch adds sigaltstack() prototypes and structures to
the shared sys/signal.h for the RTEMS conditional part
of the file
2012-09-05 Joel Sherrill <joel.sherrill@oarcorp.com>
* libc/include/sys/signal.h: Add sigaltstack() support for RTEMS.
This patch is causing me headaches.
1.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigaltstack.html
says sigaltstack should be provided as an XSI extension to <signal.h>
Your patch adds sigaltstack to <sys/signal.h>, however I don't see much
reasons, why it can't be added to <signal.h>.
2. Your patch contains this:
typedef struct sigalstack { ... } stack_t
Am I correct in assuming the "sigalstack" to be a typo?
FreeBSD has
#if __BSD_VISIBLE
typedef struct sigaltstack {
#else
typedef struct {
#endif
...
} stack_t;
[Note: "struct sigaltstack" vs. "struct sigalstack"]
3. The "stack_t" structure has a field defined as an int.
int ss_flags; /* Flags. */
I don't know what this field is used for, but in general, in BSD code
such "int"s implicitly actually are meant to be least32_t's. They
therefore may cause problems on platforms with sizeof(int) << 32bit.
That said, if this was an RTEMS internal data structure, I'd now propose
to change "ss_flags" type into an int32_t or least32_t.
Ralf