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: Fri, 10 Aug 2007 01:02:13 +0200 From: Segher Boessenkool <segher@...nel.crashing.org> To: Chris Snook <csnook@...hat.com> Cc: paulmck@...ux.vnet.ibm.com, heiko.carstens@...ibm.com, horms@...ge.net.au, linux-kernel@...r.kernel.org, rpjday@...dspring.com, ak@...e.de, netdev@...r.kernel.org, cfriesen@...tel.com, akpm@...ux-foundation.org, torvalds@...ux-foundation.org, jesper.juhl@...il.com, Geert Uytterhoeven <geert@...ux-m68k.org>, linux-arch@...r.kernel.org, zlynx@....org, schwidefsky@...ibm.com, davem@...emloft.net, wensong@...ux-vs.org, wjiang@...ilience.com Subject: Re: [PATCH 1/24] make atomic_read() behave consistently on alpha >>>> So, why not use the well-defined alternative? >>> Because we don't need to, and it hurts performance. >> It hurts performance by implementing 32-bit atomic reads in assembler? > > No, I misunderstood the question. Implementing 32-bit atomic reads in > assembler is redundant, because any sane compiler, *particularly* and > optimizing compiler (and we're only in this mess because of optimizing > compilers) Oh please, don't tell me you don't want an optimising compiler. And if you _do_ want one, well you're in this mess because you chose C as implementation language and C has some pretty strange rules. Trying to use not-all-that-well-defined-and-completely- misunderstood features of the language doesn't make things easier; trying to use something that isn't even part of the language and that your particular compiler originally supported by accident, and that isn't yet an officially supported feature, and that on top of it all has a track record of problems -- well it makes me wonder if you're in this game for fun or what. > will give us that automatically without the assembler. No, it does *not* give it to you automatically; you have to do either the asm() thing, or the not-defined-at-all *(volatile *)& thing. > Yes, it is legal for a compiler to violate this assumption. It is > also legal for us to refuse to maintain compatibility with compilers > that suck this badly. So that's rm include/linux/compiler-gcc*.h then. Good luck with the intel compiler, maybe it works more to your liking. Segher - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists