From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751460AbdALJpS (ORCPT ); Thu, 12 Jan 2017 04:45:18 -0500 Received: from mail1.bemta8.messagelabs.com ([216.82.243.195]:20200 "EHLO mail1.bemta8.messagelabs.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750856AbdALJpO (ORCPT ); Thu, 12 Jan 2017 04:45:14 -0500 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkleJIrShJLcpLzFFi42I5fN1ile4r//I Ig0e/DCz+TjrGbrHp8TVWi8u75rBZ3Fi3j93iycIzTBY/Hk5nslh6/SKTxe2Jkxktbs14werA 6bFm3hpGj9+/JjF6XNss5rF5Sb3Hm9On2D36/xp47PzewO7xeZNcAEcUa2ZeUn5FAmvGm+W3G Que8lXM7t7G3MD4mLuLkYtDSGAZo8Tys5fZuxg5OYQFIiUeLJ0DZosIqEk0n2phA7GZBe4ySX xqCIJoeMssMff8HkaQBJuAicTN++dYQGxeAWeJ61dbwGwWAVWJJTNXs4LYogIJEivOzWGCqBG UODnzCVANBwengJHE5Y+KEPP1JKZcbWGEsAUllrxeA2XLS2x/O4cZxBYS0JZ4v3Ex2EgJAQWJ qZNbmScwCsxCMnUWklGzkIyahWTUAkaWVYwaxalFZalFuoYGeklFmekZJbmJmTlAnoVebmpxc WJ6ak5iUrFecn7uJkZgFDEAwQ7G9a3OhxglOZiURHlXeZRHCPEl5adUZiQWZ8QXleakFh9ilO HgUJLgneAHlBMsSk1PrUjLzAHGM0xagoNHSYT3HEiat7ggMbc4Mx0idYpRUUqclxeYBIQEQBI ZpXlwbbAUcolRVkqYlxHoECGegtSi3MwSVPlXjOIcjErCvK9BxvNk5pXATX8FtJgJaPFFG7DF JYkIKakGRj3+pEzzpe0lt/c+DpkrGTpX/jtHEkP+yiifv39OrUl8wabKsW3THU3GaQ/T84xWJ m5csEp32/Y5ahENS18/u9q4WvTXEfXwmz5eK+SilS/2GS6/fGB9/ssVa9wfCee6L0hdlxWwut +wvnj+y7wpSvpNrF0cG56q/JyxIqyzdGVOdIBhwQ//+0osxRmJhlrMRcWJADf+ioEcAwAA X-Env-Sender: Marc_Gonzalez@sigmadesigns.com X-Msg-Ref: server-9.tower-96.messagelabs.com!1484214249!58578868!1 X-Originating-IP: [195.215.56.170] X-StarScan-Received: X-StarScan-Version: 9.1.1; banners=-,-,- X-VirusChecked: Checked Subject: Re: [PATCH 56/62] watchdog: tangox_wdt: Convert to use device managed functions To: Guenter Roeck CC: Wim Van Sebroeck , , , , "Mans Rullgard" , Thibaud Cornic , Mark Rutland , Uwe Kleine-Konig , Arnd Bergmann References: <1484091325-9199-1-git-send-email-linux@roeck-us.net> <1484100561-17638-1-git-send-email-linux@roeck-us.net> <1484100561-17638-5-git-send-email-linux@roeck-us.net> <94c4d5c0-f639-eab1-6706-335977690e88@roeck-us.net> <20170111175110.GB22289@roeck-us.net> From: Marc Gonzalez Message-ID: <0f68aa11-161b-0435-ea0f-851432464bc1@sigmadesigns.com> Date: Thu, 12 Jan 2017 10:44:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0 SeaMonkey/2.47 MIME-Version: 1.0 In-Reply-To: <20170111175110.GB22289@roeck-us.net> Content-Type: text/plain; charset="ISO-8859-1" Content-Language: Content-Transfer-Encoding: 7bit X-Originating-IP: [172.27.0.114] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/01/2017 18:51, Guenter Roeck wrote: > However, some other unrelated undefined behavior does not mean that this > specific behavior is undefined. True :-) Let me just give two additional examples of UB that /have/ bitten Linux kernel devs. int i; for (i = 1; i > 0; ++i) /* do_something(); */ => optimized into an infinite loop and void func(struct foo *p) { int n = p->field; if (!p) return; => null-pointer check optimized away > So far we have a claim that a cast to a void * may somehow be different > to a cast to a different pointer, if used as function argument, and that > the behavior with such a cast may be undefined. In other words, you claim > that a function implemented as, say, > > void func(int *var) {} > > might result in undefined behavior if some header file declares it as > > void func(void *); > > and it is called as > > int var; > > func(&var); > > That seems really far fetched to me. Thanks for giving me an opportunity to play the language lawyer :-) C99 6.3.2.3 sub-clause 8 states: "A pointer to a function of one type may be converted to a pointer to a function of another type and back again; the result shall compare equal to the original pointer. If a converted pointer is used to call a function whose type is not compatible with the pointed-to type, the behavior is undefined." So, the behavior is undefined, not when you cast clk_disable_unprepare, but when clk_disable_unprepare is later called through the devres->action function pointer. However, I agree that it will work as expected on typical platforms (where all pointers are the same size, and the calling convention treats all pointers the same). > I do get the message that you do not like this kind of cast. But that doesn't > mean it is not correct. If it's already widely used in the kernel, it seems there is no point fighting it ;-) Regards.