plenty code is confused about function level static

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Subject: plenty code is confused about function level static
Date: 2024-04-17 21:39:53
Message-ID: 20240417213953.zegcual4q3pyxmvw@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 program
b) the data will be the same on every invocation, and thus from optimizing
based on that.

The most common example of this is that all our binaries use
static struct option long_options[] = { ... };
which prevents long_options from being put into read-only memory.

Is there some reason we went for this pattern in a fair number of places? I
assume it's mostly copy-pasta, but...

In practice it often is useful to use 'static const' instead of just
'const'. At least gcc otherwise soemtimes fills the data on the stack, instead
of having a read-only data member that's already initialized. I'm not sure
why, tbh.

Attached are fixes for struct option and a few more occurrences I've found
with a bit of grepping.

There are lots of places that could benefit from adding 'static
const'.

E.g. most, if not all, HASHCTL's should be that, but that's more verbose to
change, so I didn't do that.

Greetings,

Andres Freund

Attachment Content-Type Size
v1-0001-static-const-Convert-struct-option-arrays.patch text/x-diff 20.0 KB
v1-0002-static-const-Convert-transformRelOptions-callers.patch text/x-diff 3.8 KB
v1-0003-static-const-Convert-some-more.patch text/x-diff 1.4 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2024-04-17 21:50:21 Re: fix tablespace handling in pg_combinebackup
Previous Message Robert Haas 2024-04-17 20:16:55 fix tablespace handling in pg_combinebackup