| 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
| ||
|
Date: Thu, 5 Jul 2007 10:02:00 -0700 (PDT) From: Chris Lattner <sabre@...dot.org> To: Al Viro <viro@....linux.org.uk> cc: Linus Torvalds <torvalds@...ux-foundation.org>, linux-sparse@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [RFC] bloody mess with __attribute__() syntax On Thu, 5 Jul 2007, Al Viro wrote: > On Thu, Jul 05, 2007 at 09:41:55AM -0700, Linus Torvalds wrote: >>> Note that gcc rules for __attribute__() (and that's the only source >>> of rules we _have_ for the damn thing) clearly say that >>> int __user *p; >>> is the same thing as >>> int *__user p; >> >> Quick question: is there some reason why we have to honor the crazy gcc >> rules, and cannot try to convince gcc people that they are insane? > > AFAICS, they started with storage-class-like attributes. Consider e.g. > always_inline or section; these are not qualifiers at all and you want > to have > static __attribute__((always_inline)) int foo(int *p); > interpreted with attribute applied to foo, not to its return type. This is true, but I don't think this is related. attributes in GCC can apply either to types or two decls. In this case, the always_inline attribute is being applied to the decl, but other attributes could be applied to the return type. -Chris -- http://nondot.org/sabre/ http://llvm.org/ - 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/
Powered by blists - more mailing lists