Re: [PATCH] dcache: use QSTR() instead of QSTR_INIT()

[Al Viro]

On Wed, Apr 22, 2026 at 05:04:54PM +0200, Jan Kara wrote:
> On Wed 22-04-26 15:34:37, Al Viro wrote:
> > On Wed, Apr 22, 2026 at 02:33:46PM +0200, Thorsten Blum wrote:
> > > Drop the hard-coded length arguments and use the simpler QSTR().
> > 
> > ... which is not a constant expression.  NAK.
> > 
> > QSTR_INIT() is an initializer list for struct qstr; QSTR() is a
> > compound literal for the same.  IOW, its value is an anonymous
> > local variable with given contents.
> > 
> > C grammar allows both
> > 	struct foo x = {.bar = y};
> > and
> > 	struct foo x = (struct foo){.bar = y};
> > for auto variables, and compiler is able to figure out that they
> > are equivalent.  But the second form is not legal for the static-duration
> > variables.
> 
> Hum, I understand your reasoning but if it isn't legal, I'd expect the
> compiler to complain. Which it doesn't and the generated binary of a sample
> test program with both constructs is exactly the same...

gcc is treating that as an extension, without having clearly documented it.  

Again, compound literal is *not* a fancier way to spell the initializer list;
it's equivalent to having an anonymous local variable with initializer list.
It's an l-value, which quite a few uses of QSTR rely upon (and which the
same patch series misses in several places, keeping useless named locals
for no reason).

It really makes no sense for static storage-duration objects; optimization
I've mentioned above is basically a compiler seeing that
	struct foo anon = <initializer>
	struct foo x = anon;
with no uses of anon anywhere else and figuring out that anon can be eliminated.
Doing something similar for global variables is insane - would you expect

static int __x = 1;
int x = __x;
<no other uses of __x>

to be valid C?  Sure, you can prove that the value of __x will be 1 all along -
no stores to it anywhere, so the value of expression used to initialize x could
be deduced at compile time.  Currently gcc doesn't have that (that's *not*
a suggestion for another extension), but if that changed I'd still recommend
not to make use of such.