Bug 161602 - Missing #include of unistd.h in /usr/include/asm/param.h
Missing #include of unistd.h in /usr/include/asm/param.h
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: glibc-kernheaders (Show other bugs)
4.0
ia64 Linux
medium Severity medium
: ---
: ---
Assigned To: David Woodhouse
Brian Brock
:
: 168929 196012 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-24 15:14 EDT by Need Real Name
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-07-14 08:26:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2005-06-24 15:14:10 EDT
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):
glibc-kernheaders-2.4-9.1.87

How reproducible:
Always

Steps to Reproduce:
1. Compile above program 
2.
3.
  

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 17:35:30 EDT
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 12:49:53 EDT
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 08:37:48 EDT
*** Bug 168929 has been marked as a duplicate of this bug. ***
Comment 4 H.J. Lu 2005-09-22 06:04:39 EDT
I opened IT 76202. I didn't use <asm/param.h>. I got

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

int
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 <davidm@hpl.hp.com>
*/

# define HZ     sysconf(_SC_CLK_TCK)

It is a regression from RHEL 3. 
Comment 5 David Woodhouse 2005-09-22 06:19:51 EDT
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 06:38:17 EDT
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 06:51:12 EDT
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 06:59:37 EDT
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 07:27:58 EDT
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 09:11:36 EDT
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 09:32:02 EDT
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 11:47:05 EDT
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 11:48:28 EDT
*** Bug 196012 has been marked as a duplicate of this bug. ***
Comment 15 David Woodhouse 2006-08-29 21:53:32 EDT
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.

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