Bug 88455 - SIGRTMAX defined differently in 2 header files
SIGRTMAX defined differently in 2 header files
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2003-04-10 01:21 EDT by Craig Worthington
Modified: 2016-11-24 10:18 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-04-17 00:10:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Craig Worthington 2003-04-10 01:21:54 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314

Description of problem:
When a program uses real-time signals then attempting to
use SIGRTMAX with sigaddset fails with EINVAL. The cause
is probably due to the mis-match:

[/usr/include]# uname -a
Linux *.*.* 2.4.20-9 #1 Wed Apr 2 13:42:50 EST 2003 i686 i686 i386 GNU/Linux
[/usr/include]# cat /etc/redhat-release
Red Hat Linux release 9 (Shrike)
[/usr/include]# grep SIGRTMAX */*.h
asm/signal.h:#define SIGRTMAX   (_NSIG-1)
bits/signum.h:#define SIGRTMAX        (__libc_current_sigrtmax ())
bits/signum.h:#define __SIGRTMAX        _NSIG

On a machine running Phoebe,
asm/signal.h:#define SIGRTMAX   (_NSIG-1)
bits/signum.h:#define SIGRTMAX        (__libc_current_sigrtmax ())
bits/signum.h:#define __SIGRTMAX        (_NSIG - 1)

Version-Release number of selected component (if applicable):
glibc-kernheaders-2.4-8.10 glibc-devel-2.3.2-27.9

How reproducible:

Steps to Reproduce:
1.try to add SIGRTMAX to a signal set using sigaddset()

Actual Results:  sigaddset() failed with EINVAL

Expected Results:  sigaddset() should have succeeded

Additional info:
Comment 1 Ulrich Drepper 2003-04-17 00:10:08 EDT
It is none of your business to look at the kernel headers.  Their content is
valid for the kernel but not userlevel.

Note You need to log in before you can comment on or make changes to this bug.