[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <mvmwpplns8n.fsf@hawking.suse.de>
Date: Wed, 02 Mar 2016 10:28:40 +0100
From: Andreas Schwab <schwab@...ux-m68k.org>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Arnd Bergmann <arnd@...db.de>,
Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
"linux-arm-kernel\@lists.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Kyle McMartin <kyle@...artin.ca>,
RTCLINUX <rtc-linux@...glegroups.com>,
Alessandro Zummo <a.zummo@...ertech.it>,
"linuxppc-dev\@lists.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
Linux-sh list <linux-sh@...r.kernel.org>,
Parisc List <linux-parisc@...r.kernel.org>,
linux-m68k <linux-m68k@...ts.linux-m68k.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/6] rtc: generic: allow building on all architectures
Geert Uytterhoeven <geert@...ux-m68k.org> writes:
>> +#else
>> +#define generic_rtc_ops *(struct rtc_class_ops*)NULL
>> +#endif
>>
>> static int __init generic_rtc_probe(struct platform_device *dev)
>> {
>> struct rtc_device *rtc;
>> + const struct rtc_class_ops *ops;
>> +
>> + ops = dev_get_platdata(&dev->dev);
>> + if (!ops)
>> + ops = &generic_rtc_ops;
>
> I hope no compiler version treats "&*(struct rtc_class_ops*)NULL" as
> undefined behavior?
Yes, that is guaranteed, the operations cancel each other (6.5.3.2#3: If
the operand is the result of a unary * operator, neither that operator
nor the & operator is evaluated and the result is as if both were
omitted).
Andreas.
--
Andreas Schwab, schwab@...ux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Powered by blists - more mailing lists