linux-kernel - Re: __STRICT_ANSI_

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 15 Sep 2006 09:27:32 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	Ismail Donmez <ismail@...dus.org.tr>,
	LKML <linux-kernel@...r.kernel.org>, mchehab@...radead.org
Subject: Re: __STRICT_ANSI__ checks in headers

On Sep 15, 2006, at 02:42:58, David Woodhouse wrote:
> On Fri, 2006-09-15 at 09:01 +0300, Ismail Donmez wrote:
>> Kernel headers currently uses __STRICT_ANSI__ check before  
>> defining a long
>> long variable because ANSI-C doesn't allow long long variables.  
>> But this
>> seems to harsh because any project including linux/videodev2.h  
>> ( and similar
>> ones ) and using -ansi flag will not compile because some types  
>> like __s64
>> will not be defined.
>
> One possible fix is to let videodev2.h use int64_t, and in userspace
> they can include <stdint.h>
>
> Another is just to declare videodev2.h incompatible with -ansi, or  
> maybe
> just omit 'value64' from the union if __STRICT_ANSI__ is defined, and
> replace it with an array of two __s32s.

A mildly better alternative is (on 32-bit architectures, 64-bit archs  
have no problem) change the typedef from this:

> #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
> typedef unsigned long long __u64;
> typedef   signed long long __s64;
> #endif

to this:

> #if defined(__GNUC__)
> __extension__ typedef unsigned long long __u64;
> __extension__ typedef   signed long long __s64;
> #endif

GCC always supports __extension__ to indicate not to warn or error on  
GCC-only extensions.  You only have to declare __extension__ on the  
typedef, any uses are considered OK.  I think this also works for  
code-expressions like this:

> int x = __extension__ ({ foo(); 1; })

but I don't remember exactly.  In certain really complex expressions  
GCC can get confused and give bogus errors, but as long as you don't  
start sprinkling it in macros you should be fine.

Cheers,
Kyle Moffett

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