Red Hat Bugzilla – Bug 161602
Missing #include of unistd.h in /usr/include/asm/param.h
Last modified: 2007-11-30 17:07:18 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Description of problem:
The symbol _SC_CLK_TCK is used by the definition of HZ but because unistd.h is not included, this symbol is not defined. The following code works on IA32 but fails on IA64.
static int hz = HZ;
(Not a real program, of course but note that HZ is a symbol being defined in this header so this fragment should compile)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Compile above program
Actual Results: error: `_SC_CLK_TCK' undeclared (first use in this function)
Expected Results: Successful compile
The asm/param.h file changed from EL3. It appears it should now be much more like the IA32 file - but perhaps the change is in error. In the EL3 version, HZ was defined to be one of two integer literal values, depending on a condition.
The program you demonstrate is erroneous. You must not include kernel headers
from userspace. Try this instead:
int c = sysconf(_SC_CLK_TCK);
printf("User-visible tick frequency is %d Hz\n", c);
The real code comes from spec2000/gap. It appears that that code is in fact
wrong. I am seeing if I can get it fixed in spec.
*** Bug 168929 has been marked as a duplicate of this bug. ***
I opened IT 76202. I didn't use <asm/param.h>. I got
[hjl@gnu-11 tmp]$ cat x.c
[hjl@gnu-11 tmp]$ gcc -c x.c
x.c: In function `hz':
x.c:6: error: `_SC_CLK_TCK' undeclared (first use in this function)
x.c:6: error: (Each undeclared identifier is reported only once
x.c:6: error: for each function it appears in.)
It is caused by
[hjl@gnu-11 tmp]$ more /usr/include/asm/param.h
* Fundamental kernel parameters.
* Copyright (C) 1998, 1999 Hewlett-Packard Co
* Copyright (C) 1998, 1999 David Mosberger-Tang <email@example.com>
# define HZ sysconf(_SC_CLK_TCK)
It is a regression from RHEL 3.
I don't believe that HZ is supposed to be defined by <sys/param.h>. It appears
to be namespace pollution which should not be there.
We can't remove it in a RHEL4 update, because we need to keep bug-compatibility
even with things like this, in case people make the mistake of using it -- but
it should be removed for RHEL5. I'll open a separate bug for that.
Please use sysconf(_SC_CLK_TCK) and not HZ, as shown in comment #2.
If HZ can be used by programs? If yes, how should HZ be used, if not by
including <sys/param.h>? The previous Red Hat releases do support HZ.
I don't believe that HZ is something that is supposed to be used by programs.
It's not even supposed to be there.
Previous Red Hat releases do not 'support' it -- they'll give you a hard-coded
value which may well be wrong.
The correct way to obtain this information is given in comment #2.
Existing programs do use HZ, which used to be defined in <sys/param.h>. Chaning
existing programs may not always be feasible. If it is the Red Hat plocy not to
support such programs, it should be stated somewhere.
Existing programs do many things which are broken and won't work in future. In
particular, newer compilers are getting more and more picky about broken code.
It isn't appropriate to go out of our way to pander to broken software, certainly.
An attempt has been made to make HZ work as the erroneous programmer
_presumably_ intended it to work. You just need to include <unistd.h> to make it
work. However, the existence of HZ is still namespace pollution, and the fix for
that namespace pollution is _not_ to include extra header files and pollute the
namespace still further.
Personally, I think the correct answer is to remove HZ altogether.
I agree that removing HZ is the preferred solution if those programs should
replace HZ with sysconf(_SC_CLK_TCK). Can it be done for RHEL 4 U3.
It can be done for RHEL5, but for RHEL4 U3 I think we shouldn't change it. These
programs are wrong, but if they're including unistd.h for themselves they will
be compiling and even working correctly. Breaking that in an update isn't really
within the RHEL policy.
Note that this is currently inconsistent across architectures -- some versions
of asm/param.h do include unistd.h, while others don't.
I still don't think it's appropriate to add unistd.h to those architectures
which don't already have it, as stated in comment #9. Any programs which are
relying on the kernel's private <asm/param.h> are _broken_.
RHEL5 will have a set of kernel headers which are a lot saner, but playing
around with headers in RHEL4 is just a recipe for pain. People do lots of
strange and broken things, and it's best just to leave well alone unless
something which is used by _non_broken software is actually misbehaving.
*** Bug 196012 has been marked as a duplicate of this bug. ***
It's not a serious bug -- it's just an inconsistency in kernel-private headers
which userspace shouldn't be poking at anyway.
Of course, it's an inconsistency which I'm happier to get rid of, and it'll be
consistent in RHEL5. But _changing_ things in RHEL4 is worse than the inconsistency.
I can change the resolution of this bug to WONTFIX or RAWHIDE if that would help.