Re: plenty code is confused about function level static

2024-04-18 Thread Michael Paquier
On Thu, Apr 18, 2024 at 07:56:35PM +0200, Peter Eisentraut wrote: > On 18.04.24 19:11, Andres Freund wrote: >> Thoughts about when to apply these? Arguably they're fixing mildly broken >> code, making it appropriate to fix in 17, but it's also something that we >> could end up fixing for a

Re: plenty code is confused about function level static

2024-04-18 Thread Peter Eisentraut
On 18.04.24 19:11, Andres Freund wrote: Thoughts about when to apply these? Arguably they're fixing mildly broken code, making it appropriate to fix in 17, but it's also something that we could end up fixing for a while... Yeah, let's keep these for later. They are not regressions, and there

Re: plenty code is confused about function level static

2024-04-18 Thread Ranier Vilela
Em qui., 18 de abr. de 2024 às 14:16, Andres Freund escreveu: > Hi, > > On 2024-04-18 09:07:43 -0300, Ranier Vilela wrote: > > On 18/04/2024 00:39, Andres Freund wrote: > > >There are lots of places that could benefit from adding 'static > > >const'. > > > > I found a few more places. > > Good

Re: plenty code is confused about function level static

2024-04-18 Thread Andres Freund
Hi, On 2024-04-18 09:07:43 -0300, Ranier Vilela wrote: > On 18/04/2024 00:39, Andres Freund wrote: > >There are lots of places that could benefit from adding 'static > >const'. > > I found a few more places. Good catches. > Patch 004 > > The opposite would also help, adding static. > In

Re: plenty code is confused about function level static

2024-04-18 Thread Andres Freund
Hi, On 2024-04-18 10:33:30 +0200, Peter Eisentraut wrote: > > Attached are fixes for struct option and a few more occurrences I've found > > with a bit of grepping. > > These look good to me. Thoughts about when to apply these? Arguably they're fixing mildly broken code, making it appropriate to

Re: plenty code is confused about function level static

2024-04-18 Thread Ranier Vilela
On 18/04/2024 00:39, Andres Freund wrote: >We have a fair amount of code that uses non-constant function level static >variables for read-only data. Which makes little sense - it prevents the >compiler from understanding >a) that the data is read only and can thus be put into a segment that's

Re: plenty code is confused about function level static

2024-04-18 Thread Peter Eisentraut
On 18.04.24 10:43, Andrey M. Borodin wrote: On 18 Apr 2024, at 02:39, Andres Freund wrote: There are lots of places that could benefit from adding 'static const'. +1 for helping compiler. GCC has a -Wsuggest-attribute=const, we can count these warnings and threat increase as an error :)

Re: plenty code is confused about function level static

2024-04-18 Thread Andrey M. Borodin
> On 18 Apr 2024, at 02:39, Andres Freund wrote: > > There are lots of places that could benefit from adding 'static > const'. +1 for helping compiler. GCC has a -Wsuggest-attribute=const, we can count these warnings and threat increase as an error :) Best regards, Andrey Borodin.

Re: plenty code is confused about function level static

2024-04-18 Thread Peter Eisentraut
On 17.04.24 23:39, Andres Freund wrote: Is there some reason we went for this pattern in a fair number of places? I assume it's mostly copy-pasta, but... Right. I don't think it is commonly understood that adding const qualifiers can help compiler optimization, and it's difficult to

Re: plenty code is confused about function level static

2024-04-18 Thread Heikki Linnakangas
On 18/04/2024 00:39, Andres Freund wrote: Hi, We have a fair amount of code that uses non-constant function level static variables for read-only data. Which makes little sense - it prevents the compiler from understanding a) that the data is read only and can thus be put into a segment that's

plenty code is confused about function level static

2024-04-17 Thread Andres Freund
Hi, We have a fair amount of code that uses non-constant function level static variables for read-only data. Which makes little sense - it prevents the compiler from understanding a) that the data is read only and can thus be put into a segment that's shared between all invocations of the