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: Wed, 01 Feb 2012 02:48:43 -0500 (EST) From: David Miller <davem@...emloft.net> To: geunsik.lim@...il.com Cc: isdn@...ux-pingi.de, lucas.demarchi@...fusion.mobi, netdev@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH] Keep kernel coding style rule of hfs-s+/sp source From: Geunsik Lim <geunsik.lim@...il.com> Date: Wed, 1 Feb 2012 16:45:09 +0900 > On Wed, Feb 1, 2012 at 4:06 PM, David Miller <davem@...emloft.net> wrote: > >> From: Geunsik Lim <geunsik.lim@...il.com> >> Date: Wed, 1 Feb 2012 15:59:53 +0900 >> >> > Modified for kernel coding style rule of hfs-s+/sp device driver . >> > . reference: ./Documentation/CodingStyle >> > >> > ex) >> > 60 Don't put multiple statements on a single line unless you have >> > 61 something to hide: >> > 62 >> > 63 if (condition) do_this; >> > 64 do_something_everytime; >> > >> > Signed-off-by: Geunsik Lim <geunsik.lim@...sung.com> >> >> This was probably there to eliminate compiler warnings or avoid the >> > Thank you for your opinion. > It's strange. I did not meet compiler warnings you replied. > What is the version of GCC that You tried to compile Linux kernel source > in your experience? I'm saying the code was likely written this way "because" of that reason, I didn't say I saw such a warning. Where did I say I saw the warning in question? I stated a very likely reason why the original code was written the way that it was. >> code being eliminated completely, because the result of the register >> read is unused. >> > Are you mean that the result of the register read is used if we append > "if statement" of c language? I was saying that without some kind of use of the interface's return value, without some other control such as a volatile asm statement or a reference to a volatile memory location, the compiler might legally be able to remove the I/O register read completely. You need to make sure that the assembler code does not change due to your changes, and in particular these I/O register read calls do not get eliminated. -- 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