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
| ||
|
Message-ID: <d96fe60e-c029-b400-9c29-0f95c3632301@marcan.st> Date: Mon, 3 Jan 2022 09:41:27 +0900 From: Hector Martin <marcan@...can.st> To: Dmitry Osipenko <digetx@...il.com>, Kalle Valo <kvalo@...eaurora.org>, "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Rob Herring <robh+dt@...nel.org>, "Rafael J. Wysocki" <rafael@...nel.org>, Len Brown <lenb@...nel.org>, Arend van Spriel <aspriel@...il.com>, Franky Lin <franky.lin@...adcom.com>, Hante Meuleman <hante.meuleman@...adcom.com>, Chi-hsien Lin <chi-hsien.lin@...ineon.com>, Wright Feng <wright.feng@...ineon.com> Cc: Sven Peter <sven@...npeter.dev>, Alyssa Rosenzweig <alyssa@...enzweig.io>, Mark Kettenis <kettenis@...nbsd.org>, Rafał Miłecki <zajec5@...il.com>, Pieter-Paul Giesberts <pieter-paul.giesberts@...adcom.com>, Linus Walleij <linus.walleij@...aro.org>, Hans de Goede <hdegoede@...hat.com>, "John W. Linville" <linville@...driver.com>, "brian m. carlson" <sandals@...stytoothpaste.net>, linux-wireless@...r.kernel.org, netdev@...r.kernel.org, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org, brcm80211-dev-list.pdl@...adcom.com, SHA-cyfmac-dev-list@...ineon.com Subject: Re: [PATCH 03/34] brcmfmac: firmware: Support having multiple alt paths On 03/01/2022 05.11, Dmitry Osipenko wrote: > 02.01.2022 17:18, Hector Martin пишет: >> On 2022/01/02 15:45, Dmitry Osipenko wrote: >>> 26.12.2021 18:35, Hector Martin пишет: >>>> -static char *brcm_alt_fw_path(const char *path, const char *board_type) >>>> +static const char **brcm_alt_fw_paths(const char *path, const char *board_type) >>>> { >>>> char alt_path[BRCMF_FW_NAME_LEN]; >>>> + char **alt_paths; >>>> char suffix[5]; >>>> >>>> strscpy(alt_path, path, BRCMF_FW_NAME_LEN); >>>> @@ -609,27 +612,46 @@ static char *brcm_alt_fw_path(const char *path, const char *board_type) >>>> strlcat(alt_path, board_type, BRCMF_FW_NAME_LEN); >>>> strlcat(alt_path, suffix, BRCMF_FW_NAME_LEN); >>>> >>>> - return kstrdup(alt_path, GFP_KERNEL); >>>> + alt_paths = kzalloc(sizeof(char *) * 2, GFP_KERNEL); >>> >>> array_size()? >> >> Of what array? > > array_size(sizeof(*alt_paths), 2) Heh, TIL. I thought you meant ARRAY_SIZE. First time I see the lowercase macro. That's a confusing name collision... >>>> + alt_paths[0] = kstrdup(alt_path, GFP_KERNEL); >>>> + >>>> + return (const char **)alt_paths; >>> >>> Why this casting is needed? >> >> Because implicit conversion from char ** to const char ** is not legal >> in C, as that could cause const unsoundness if you do this: >> >> char *foo[1]; >> const char **bar = foo; >> >> bar[0] = "constant string"; >> foo[0][0] = '!'; // clobbers constant string > > It's up to a programmer to decide what is right to do. C gives you > flexibility, meanwhile it's easy to shoot yourself in the foot if you > won't be careful. Which is why that conversion is illegal without a cast and you need to explicitly choose to shoot yourself in the foot :-) >> But it's fine in this case since the non-const pointer disappears so >> nothing can ever write through it again. >> > > There is indeed no need for the castings in such cases, it's a typical > code pattern in kernel. You would need to do the casting for the other > way around, i.e. if char ** was returned and **alt_paths was a const. You do need to do the cast. Try it. $ cat test.c int main() { char *foo[1]; const char **bar = foo; return 0; } $ gcc test.c test.c: In function ‘main’: test.c:4:28: warning: initialization of ‘const char **’ from incompatible pointer type ‘char **’ [-Wincompatible-pointer-types] 4 | const char **bar = foo; | You can implicitly cast char* to const char*, but you *cannot* impliclicitly cast char** to const char** for the reason I explained. It requires a cast. -- Hector Martin (marcan@...can.st) Public Key: https://mrcn.st/pub
Powered by blists - more mailing lists