lkml.org 
[lkml]   [2007]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Linux Kernel include files
Date
On Jun 22, 2007, at 11:00:38, Adrian Bunk wrote:
> It would certainly help if Joerg would tell what exactly breaks,
> but I spot one likely problem in include/asm-i386/types.h:
>
> #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
> typedef __signed__ long long __s64;
> typedef unsigned long long __u64;
> #endif
>
> It might make sense to remove the #if and simply require that a C
> compiler under Linux must know about the C99 "long long"?

Gah, this particular topic and a few other similar header-
compatibility ones show up once a month on LKML; I should probably
just make a patch to fix all the types.h files and be done with it.
The proper solution is this:

# if __STDC_VERSION__ >= 19901L
typedef signed long long __s64;
typedef unsigned long long __u64;
# elif defined(__GNUC__)
__extension__ typedef signed long long __s64;
__extension__ typedef unsigned long long __u64;
# else
# error "Your compiler doesn't support long long (IOW: It sucks).
Please get a new one"
# endif

That way if you have any kind of vaguely-long-long-compatible
compiler then it will work, and otherwise you'll get a nice useful
error message. It also makes sure that GCC doesn't spew warnings/
errors when in c89-pedantic mode. The "__extension__" keyword is
designed for use in implementation header files which want to use GCC-
isms unconditionally.

Cheers,
Kyle Moffett

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-06-27 03:35    [W:0.126 / U:0.600 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site