Re: Tree-walker callbacks vs -Wdeprecated-non-prototype
| От | Thomas Munro |
|---|---|
| Тема | Re: Tree-walker callbacks vs -Wdeprecated-non-prototype |
| Дата | |
| Msg-id | CA+hUKGL=dNzs7h85xq1UiHWVRU7+DYrqFkC4J4VZp_s2KD1dMA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Tree-walker callbacks vs -Wdeprecated-non-prototype (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Tree-walker callbacks vs -Wdeprecated-non-prototype
|
| Список | pgsql-hackers |
On Mon, Sep 19, 2022 at 3:39 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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. Yeah, I don't expect it to be a practical problem on any real system (that is, I don't expect any real calling convention to transfer a struct T * argument in a different place than void *). I just wanted to mention that it's a new liberty. It's one thing to cast struct T * to void * and back before dereferencing, and another to cast a pointer to a function that takes struct T * to a pointer to a function that takes void * and call it. I considered proposing that myself when first reporting this problem, but fear of language lawyers put me off.
В списке pgsql-hackers по дате отправления: