Re: [PATCH nft 1/3] parser: don't mark "string" as const

[Thomas Haller <thaller@redhat.com>]

On Fri, 2023-11-10 at 00:10 +0100, Florian Westphal wrote:
> Thomas Haller <thaller@redhat.com> wrote:
> > ifname_expr_alloc() calls `free(name)`, destroying the thing that
> > is
> > pointed at. That's a modification.
> > 
> > The code required to cast away the constness, which also indicates
> > that
> > it is not actually const.
> 
> It it.  I hate that free() isn't const void *.

That would work too. But C choose instead to disallow that.

Note that in nftables, ~75% of the free() operate on non-const just
fine. And the compiler is helpful confirming that.

> 
> I prefer to have const used as much as humanly possible.
> 

Definitely. Especially for long-lived data.


The "string" in question is a short-lived data allocated by "scanner.l"
and handed over to "parser_bison.y".

See:

»·······»·······»·······|»······rule_alloc»·····comment_spec
»·······»·······»·······{
»·······»·······»·······»·······$$->cOmment = $2;
»·······»·······»·······}

Here no free() is involved, but ownership is passed on without
strdup(). If "string" is const, this is another ugliness where you pass
on a string that you seemingly don't own.


There are places where it's ugly and const-correctness breaks down
(during destruction/ref/unref). See free_const() and
datatype_get()/datatype_free(). But those places should be at a minimum
by choosing const (and free_const()) when it makes sense.



Thomas