Re: [PATCH RFC 00/13] improve constexpr handling

[Nicolai Stange <nicstange@gmail.com>]

josh@joshtriplett.org writes:
> On Thu, Jul 23, 2015 at 11:13:57AM +0200, Nicolai Stange wrote:
>> josh@joshtriplett.org writes:
>> >> Since the additional information on expressions obtained through the
>> >> first two parts is rather pointless without making any use of it, I
>> >> implemented part three, the checking of static storage duration
>> >> objects' initializers for constness.
>> >> This part is the reason why there is a 'RFC' tag in the subject.
>> >> It is up to you to decide whether letting sparse check for C99
>> >> conformity is a valuable thing to have or whether being stricter than
>> >> GCC is counter-productive/completely idiotic.
>> >
>> > I think it's absolutely a valuable thing to have.  It may or may not be
>> > the right *default* behavior, but having an appropriate -W option to
>> > enable it would be a good start.
>> 
>> My next resend will contain such a -Wcheck-static-initializers then.
>
> <bikeshed>Shouldn't it be something like -Wnon-constant-initializer,
> since that's what it checks for?</bikeshed>
>
>> However, I will delay that resend in order to be able to incorporate
>> other reviews arriving in the meantime.
>
> Sounds reasonable.
>
>> > On Thu, Jul 23, 2015 at 12:54:25AM +0200, Nicolai Stange wrote:
>> >> sparse now finds 519 occurences of non-const initializers of static
>> >> storage duration objects, 474 of which are located in drivers/acpi
>> >> and stem from this subsystem's custom offsetof macro implemented by
>> >> means of taking pointer differences.
>> >
>> > Ideally, I'd suggest that ACPICA should add a translation from
>> > ACPI_OFFSET to offsetof as part of its Linux-izing scripts.
>> >
>> > That said, I also can't think of an obvious reason why ACPI_OFFSET
>> > *should* be considered non-constant.  Perhaps there's a detail in the
>> > C99 spec that explains why what it does isn't OK, but it *seems* like it
>> > should be a compile-time constant expression.  I've CCed Al Viro, who
>> > knows the C99 constant expression rules very well; Al, could you provide
>> > some clarity here?  The ACPI_OFFSET macro in question expands to this:
>> >
>> > (acpi_size) (((u8 *) (void *) ((&(((struct some_struct *) 0)->fieldname)))) - ((u8 *) (void *) (((void *) (void *) 0))))
>> >
>> > Does the -> make this non-constant?
>> 
>> No, it is the pointer difference. At least to my interpretion of C99
>> [6.6(9)] which might be arguable.
>> Upon your request, I could relax these constraints as I have did already for
>> some special cases of conditionals in [11/13].
>
> Ah, I see.  I don't know whether relaxing that makes sense or not; Al?

Just a friendly ping to get some more reviews to consider in my next
resend, especially on [13/13] and whether to relax the constant
expression rules to treat pointer differences of address constants as
(arithmetic or integer) constant expressions.