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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Wed, 5 Dec 2012 17:48:24 -0600
From:	Bryce Lelbach <blelbach@....lsu.edu>
To:	Compiling the Linux Kernel with Clang/LLVM 
	<llvmlinux@...ts.linuxfoundation.org>
Cc:	Behan Webster <behanw@...verseincode.com>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	Felipe Balbi <balbi@...com>, netfilter-devel@...r.kernel.org,
	davem@...emloft.net
Subject: Re: [llvmlinux] [PATCH V2 2/3] Remove VLAIS usage from gadget code

On 2012.12.04 23.24, Sebastian Andrzej Siewior wrote:
> > VLAIS is not something they are willing to accept (for various
> > reasons). There are other patches to LLVM that are still working
> Is this not described in C99 6.7.2.1p16?

No, this is not the case - flexible array members are a very different beast,
which are in-and-of-themselves of debatable merit. C99 6.7.2.1p8 explicitly
states that VLAIS are illegal. The same language is present in C11 (same
section):

	A member of a structure or union may have any object type other than a variably
	modified type.

In C99 6.7.5.1p3, the definition of a variably modified type is given:

	.. [snip] ... If the nested sequence of declarators in a full declarator
	contains a variable length array type, the type specified by the full
	declarator is said to be variably modified.

It would require incredible, earth-moving acts for VLAIS to become a part of the
ISO/IEC standard for the C programming language.

P.S. As a general note, while I do agree that it is preferable to rewrite code
using VLAIS instead of utilizing a macro, I would ask that some reconsideration
be given, unless there are Linux kernel developers who are willing and able
to implement the necessary rewrites. The LLVMLinux project does not wish to
decrease the code quality of the Linux kernel, and certainly we do not intend to
cause any GCC breakage.

However, I think that rewrites to all the relevant VLAIS code would be quite
time consuming for the LLVMLinux team, and the proposed macro does not appear
to me to present any particular evil, other than by nature of being a macro.

If faced between the choice of either accepting this VLAIS patch, or not being
able to compile the Linux kernel with standard-compliant, largely GCC-compatible
compilers such as Clang and icc, I would think that accepting the VLAIS patch
would be preferable.

(note also that I have only come in on the end of this thread, and I may have
missed part of the context).

-- 
Bryce Adelstein-Lelbach aka wash
STE||AR Group, Center for Computation and Technology, LSU
--
860-808-7497 - Cell
225-578-6182 - Work (no voicemail)
--
stellar.cct.lsu.edu
boost-spirit.com
llvm.linuxfoundation.org
--

Download attachment "signature.asc" of type "application/pgp-signature" (491 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ