Re: Tree-walker callbacks vs -Wdeprecated-non-prototype
От | Tom Lane |
---|---|
Тема | Re: Tree-walker callbacks vs -Wdeprecated-non-prototype |
Дата | |
Msg-id | 251836.1663558778@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Tree-walker callbacks vs -Wdeprecated-non-prototype (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: Tree-walker callbacks vs -Wdeprecated-non-prototype
|
Список | pgsql-hackers |
Thomas Munro <thomas.munro@gmail.com> writes: > On Mon, Sep 19, 2022 at 8:57 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> ... This is fairly annoying, in that it gives up the function >> type safety the C committee wants to impose on us; but I really think >> the data type safety that we're giving up in this version of the patch >> is a worse hazard. > But is it defined behaviour? > https://stackoverflow.com/questions/559581/casting-a-function-pointer-to-another-type Well, what we're talking about is substituting "void *" (which is required to be compatible with "char *") for a struct pointer type. Standards legalese aside, that could only be a problem if the platform ABI handles "char *" differently from struct pointer types. The last architecture I can remember dealing with where that might actually be a thing was the PDP-10. Everybody has learned better since then, but the C committee is apparently still intent on making the world safe for crappy machine architectures. Also, if you want to argue that "void *" is not compatible with struct pointer types, then it's not real clear to me that we aren't full of other spec violations, because we sure do a lot of casting across that (and even more with this patch as it stands). I don't have the slightest hesitation about saying that if there's still an architecture out there that's like that, we won't support it. I also note that our existing code in this area would break pretty thoroughly on such a machine, so this isn't making it worse. regards, tom lane
В списке pgsql-hackers по дате отправления: