I think we should just remove the __STRICT_ANSI__ check from
asm/types.h. long long will still work in gcc under -ansi (and, in
fact, will only elicit a warning even under -pedantic) so there should
be no real problem here.
__STRICT_ANSI__'s intended use in header files is to guard
I think we should just remove the __STRICT_ANSI__ check from
asm/types.h. long long will still work in gcc under -ansi (and, in
fact, will only elicit a warning even under -pedantic) so there should
be no real problem here.
__STRICT_ANSI__'s intended use in header files is to guard
I had a look at this on raptor.debian.org (dchroot unstable). The
triggering code seem to be in in /usr/include/asm/types.h:
#ifndef __s390x__
#if defined(__GNUC__) !defined(__STRICT_ANSI__)
typedef __signed__ long long __s64;
typedef unsigned long long __u64;
#endif
#else /*
Here is more info on the problem.
The issue is that 'struct user' in sys/user.h on s390 need 'struct
user_regs_struct' from asm/ptrace.h, and this need type
's390_fp_regs' which need type 'freq_t' which need type '__u64' which
is unavailable when compiling with -ansi. The reason the '__u64'
On Sun, Feb 15, 2004 at 01:48:10PM +0100, Petter Reinholdtsen wrote:
I assume that all glibc headers should be compilable when using 'gcc
-ansi'.
sys/user.h is not part of ANSI C/C++ so this is a broken assumption.
Really guys, there's seldomly a reason to use -ansi as you're most
probably
I had a look at this on raptor.debian.org (dchroot unstable). The
triggering code seem to be in in /usr/include/asm/types.h:
#ifndef __s390x__
#if defined(__GNUC__) !defined(__STRICT_ANSI__)
typedef __signed__ long long __s64;
typedef unsigned long long __u64;
#endif
#else /*
Here is more info on the problem.
The issue is that 'struct user' in sys/user.h on s390 need 'struct
user_regs_struct' from asm/ptrace.h, and this need type
's390_fp_regs' which need type 'freq_t' which need type '__u64' which
is unavailable when compiling with -ansi. The reason the '__u64'
Noticed that ksysguardd includes sys/user.h only to
get PAGE_SIZE.
other apps seem to use asm/page.h for that? Is using that
ansi safe on all platforms?
--
Riku Voipio|[EMAIL PROTECTED] |
kirkkonummentie 33 |+358 40 8476974 --+--
02140 Espoo|
On Sun, Feb 15, 2004 at 05:02:10PM +0200, Riku Voipio wrote:
Noticed that ksysguardd includes sys/user.h only to
get PAGE_SIZE.
other apps seem to use asm/page.h for that? Is using that
ansi safe on all platforms?
Both are wrong. Use sysconf(_SC_PAGESIZE) instead.
On Sun, Feb 15, 2004 at 01:48:10PM +0100, Petter Reinholdtsen wrote:
I assume that all glibc headers should be compilable when using 'gcc
-ansi'.
sys/user.h is not part of ANSI C/C++ so this is a broken assumption.
Really guys, there's seldomly a reason to use -ansi as you're most
probably
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-15
Severity: serious
I saw in the s390 buildd attempt of kdebase 3.1.5-2 that if failed with
the error below. Notice the application is attempting to use
/usr/include/sys/user.h which is supposed to be safe to use... before
anyone says you
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-15
Severity: serious
I saw in the s390 buildd attempt of kdebase 3.1.5-2 that if failed with
the error below. Notice the application is attempting to use
/usr/include/sys/user.h which is supposed to be safe to use... before
anyone says you
12 matches
Mail list logo
