Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 161602

Summary: Missing #include of unistd.h in /usr/include/asm/param.h
Product: Red Hat Enterprise Linux 4 Reporter: Need Real Name <david.moore>
Component: glibc-kernheadersAssignee: David Woodhouse <dwmw2>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC:, tao
Target Milestone: ---   
Target Release: ---   
Hardware: ia64   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-07-14 12:26:02 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Need Real Name 2005-06-24 19:14:10 UTC
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.

#include <asm/param.h>
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):

How reproducible:

Steps to Reproduce:
1. Compile above program 

Actual Results:  error: `_SC_CLK_TCK' undeclared (first use in this function)

Expected Results:  Successful compile

Additional info:

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.

Comment 1 David Woodhouse 2005-06-24 21:35:30 UTC
The program you demonstrate is erroneous. You must not include kernel headers
from userspace. Try this instead:

#include <unistd.h>
#include <stdio.h>

int main(void)
        int c = sysconf(_SC_CLK_TCK);
        printf("User-visible tick frequency is %d Hz\n", c);

Comment 2 Need Real Name 2005-07-14 16:49:53 UTC
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.

Comment 3 Jatin Nansi 2005-09-21 12:37:48 UTC
*** Bug 168929 has been marked as a duplicate of this bug. ***

Comment 4 H.J. Lu 2005-09-22 10:04:39 UTC
I opened IT 76202. I didn't use <asm/param.h>. I got

[hjl@gnu-11 tmp]$ cat x.c
#include <sys/param.h>

hz ()
 return HZ;
[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
#ifndef _ASM_IA64_PARAM_H
#define _ASM_IA64_PARAM_H

* Fundamental kernel parameters.
* Copyright (C) 1998, 1999 Hewlett-Packard Co
* Copyright (C) 1998, 1999 David Mosberger-Tang <>

# define HZ     sysconf(_SC_CLK_TCK)

It is a regression from RHEL 3. 

Comment 5 David Woodhouse 2005-09-22 10:19:51 UTC
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.

Comment 6 H.J. Lu 2005-09-22 10:38:17 UTC
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.

Comment 7 David Woodhouse 2005-09-22 10:51:12 UTC
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. 

Comment 8 H.J. Lu 2005-09-22 10:59:37 UTC
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.

Comment 9 David Woodhouse 2005-09-22 11:27:58 UTC
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.

Comment 10 H.J. Lu 2005-09-22 13:11:36 UTC
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.

Comment 11 David Woodhouse 2005-09-22 13:32:02 UTC
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.

Comment 12 David Woodhouse 2006-08-18 15:47:05 UTC
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.

Comment 13 David Woodhouse 2006-08-18 15:48:28 UTC
*** Bug 196012 has been marked as a duplicate of this bug. ***

Comment 15 David Woodhouse 2006-08-30 01:53:32 UTC
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.