Re: Large writable variables
От | Andres Freund |
---|---|
Тема | Re: Large writable variables |
Дата | |
Msg-id | 20181016165003.ruxut4wbxyytuhyh@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Large writable variables (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Large writable variables
|
Список | pgsql-hackers |
Hi, On 2018-10-16 12:41:44 -0400, Robert Haas wrote: > On Tue, Oct 16, 2018 at 12:26 PM Andres Freund <andres@anarazel.de> wrote: > > /* > > * Macro that allows to cast constness away from a variable, but doesn't > > * allow changing the underlying type. Enforcement of the latter > > * currently only works for gcc like compilers. > > * > > * Please note IT IS NOT SAFE to cast constness away if the variable will ever > > * be modified (it would be undefined behaviour). Doing so anyway can cause > > * compiler misoptimizations or runtime crashes (modifying readonly memory). > > * It is only safe to use when the the variabble will not be modified, but API > > * design or language restrictions prevent you from declaring that > > * (e.g. because a function returns both const and non-const variables). > > */ > > "variabble" is a little too rich in "b"s. variababble. > In terms of a function that returns both const and non-const > variables, it seems a bit sketchy that the caller would know what the > function is doing in particular cases and make decisions based on it, > but maybe that's just how life is. I don't think it's necessary the callers doing so in most cases. E.g. in the DestReceiver case, it'll be the choice of the testreceiver (say intorel_receive modifying things for DestIntoRel), not the caller choosing when to modify things. The caller / users of dest receivers won't necessarily know. I agree it's not pretty, but I don't quite see any really realistic other approaches here. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: