From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751454AbdALMRT (ORCPT ); Thu, 12 Jan 2017 07:17:19 -0500 Received: from mail1.bemta12.messagelabs.com ([216.82.251.16]:43636 "EHLO mail1.bemta12.messagelabs.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751157AbdALMRQ (ORCPT ); Thu, 12 Jan 2017 07:17:16 -0500 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkleJIrShJLcpLzFFi42I5fN1ilW5hcXm EwZ75yhZ/Jx1jt9j0+BqrxeVdc9gsbqzbx27xZOEZJosfD6czWSy9fpHJ4vbEyYwWt2a8YHXg 9Fgzbw2jx+9fkxg9rm0W89i8pN7jzelT7B79fw08dn5vYPf4vEkugCOKNTMvKb8igTXjUVsLU 8ETwYrpP7azNjBu5+ti5OIQEljGKPFq913WLkZODmGBSIkHS+ewg9giAkoS8zvusIAUMQvcZ5 J4/WYqO0THGRaJR/cvg1WxCZhI3Lx/jgXE5hVwljj35wMTiM0ioCpx6VEvM4gtKpAgseLcHCa IGkGJkzOfANVzcHAKGEpMPS8LEmYW0JOYcrWFEcIWlFjyeg2ULS/RvHU22BghAW2J9xsXgx0q IaAgMXVyK/MERoFZSKbOQjJqFpJRs5CMWsDIsopRvTi1qCy1SNdYL6koMz2jJDcxM0fX0NBIL ze1uDgxPTUnMalYLzk/dxMjMIoYgGAH4/0+50OMkhxMSqK8qzzKI4T4kvJTKjMSizPii0pzUo sPMcpwcChJ8J4sAsoJFqWmp1akZeYA4xkmLcHBoyTCexskzVtckJhbnJkOkTrFqCglznsCJCE AksgozYNrg6WQS4yyUsK8jECHCPEUpBblZpagyr9iFOdgVBLmvQsyhSczrwRu+iugxUxAiy/a gC0uSURISTUw2qeb/bAudOh/tPA1s3iwm5DzwSoug4JcG2GD0OMd510FNPIl6r5E1L/+XhL+0 vm9FmuGh5i54pN/UVKxV7ZMPRqd3tr+5a4Cj7zMv1see9/NWtcW2Tdvm/UNbT/Be1wLrsUU+l nfzf94bfXV/MCmWqnieQ6vn/Imf/vsJSHj8O/x4qq9qneUWIozEg21mIuKEwHsHUE3HAMAAA= = X-Env-Sender: Marc_Gonzalez@sigmadesigns.com X-Msg-Ref: server-7.tower-219.messagelabs.com!1484223343!132066049!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: Mans Rullgard CC: Guenter Roeck , Wim Van Sebroeck , , , , 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> <0f68aa11-161b-0435-ea0f-851432464bc1@sigmadesigns.com> From: Marc Gonzalez Message-ID: <0f8550e9-3f1c-6240-5c2f-c776bd238d0b@sigmadesigns.com> Date: Thu, 12 Jan 2017 13:15:42 +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: Content-Type: text/plain; charset="ISO-8859-1" Content-Language: Content-Transfer-Encoding: 8bit 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 12/01/2017 12:24, Måns Rullgård wrote: > Marc Gonzalez writes: > >>> 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. > > Only if the function types are incompatible. C99 6.7.5.3 subclause 15: > > For two function types to be compatible, both shall specify compatible > return types. Moreover, the parameter type lists, if both are > present, shall agree in the number of parameters and in use of the > ellipsis terminator; corresponding parameters shall have compatible > types. > > The question then is whether pointer to void and pointer to struct clk > are compatible types. 6.2.7 Compatible type and composite type sub-clause 1 "Two types have compatible type if their types are the same. Additional rules for determining whether two types are compatible are described in 6.7.2 for type specifiers, in 6.7.3 for type qualifiers, and in 6.7.5 for declarators." 6.7.5.1 Pointer declarators sub-clause 2 "For two pointer types to be compatible, both shall be identically qualified and both shall be pointers to compatible types." I don't think void and struct clk are compatible types. AFAIU, conversion and compatibility are two separate subjects. Regards. From mboxrd@z Thu Jan 1 00:00:00 1970 From: marc_gonzalez@sigmadesigns.com (Marc Gonzalez) Date: Thu, 12 Jan 2017 13:15:42 +0100 Subject: [PATCH 56/62] watchdog: tangox_wdt: Convert to use device managed functions In-Reply-To: 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> <0f68aa11-161b-0435-ea0f-851432464bc1@sigmadesigns.com> Message-ID: <0f8550e9-3f1c-6240-5c2f-c776bd238d0b@sigmadesigns.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 12/01/2017 12:24, M?ns Rullg?rd wrote: > Marc Gonzalez writes: > >>> 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. > > Only if the function types are incompatible. C99 6.7.5.3 subclause 15: > > For two function types to be compatible, both shall specify compatible > return types. Moreover, the parameter type lists, if both are > present, shall agree in the number of parameters and in use of the > ellipsis terminator; corresponding parameters shall have compatible > types. > > The question then is whether pointer to void and pointer to struct clk > are compatible types. 6.2.7 Compatible type and composite type sub-clause 1 "Two types have compatible type if their types are the same. Additional rules for determining whether two types are compatible are described in 6.7.2 for type specifiers, in 6.7.3 for type qualifiers, and in 6.7.5 for declarators." 6.7.5.1 Pointer declarators sub-clause 2 "For two pointer types to be compatible, both shall be identically qualified and both shall be pointers to compatible types." I don't think void and struct clk are compatible types. AFAIU, conversion and compatibility are two separate subjects. Regards.