[Swan-dev] proposal: "const struct ip_protocol" => "ip_protocol"

[Andrew Cagney]

for const:

because it gets confusing and is obscure; better to spell out:
   const something
where the code is being used than leave everyone wondering, for instance, given:
   ip_something(something *foo, const someotherthing *bar, somethingelse *baz);
which are typos and which are correct?  imnsho field_desc et.al.,
being made typedef const struct were a massive mistake

for struct something vs typedef something;
kernel guidelines say don't use typedefs; we've modified that to say
"typedef" denotes stay-out but here we're saying welcome aboard


On Sun, 13 Oct 2019 at 11:42, D. Hugh Redelmeier <hugh at mimosa.com> wrote:
>
> We currently have
>         struct ip_protocol {...};
>
> As far as I can tell, all uses of it are of the form
>         const struct ip_protocol
>
> Why not
>         typedef const struct {...} ip_protocol;
>
> Then all uses should be changed appropriately (a sed script would do it).
>
> That way the "const" could not be left off accidentally, the code becomes
> more concise, easier to fit on a line, easier to type, easier to read
> ("chunking"), etc.  More importantly, I think that the code becomes easier
> to think about -- the power of abstraction.
>
> BETTER:
>
> Almost all uses would be of the form
>         ip_protocol *
>
> If instead, we define:
>         struct ip_protocol {...};
>         typedef const struct *ip_protocol;
>
> then the table initialization can use "const struct ip_protocol" and all
> other uses get to eliminate the *.  This should make the use even simpler
> and less error prone.  A better abstraction all around.
>
> This change might not be a simple sed operation (I haven't checked) but it
> should be easy to do it without introducing errors.
>
> I propose to make this change if there are no serious objections.
>
> It should be done when most code is at rest.  Can people tell me if they
> have code in-flight that would be affected?
>
> Practical detail:
>
> We can make the transition "hard" by naming the struct differently
> (perhaps "ip_protocol_").  That way unconverted code would fail to
> compile.  That would be my preference.
>
> Perhaps an initial soft transition would be easier.  Then we could switch
> to hard after we think all in-flight code has landed.
> _______________________________________________
> Swan-dev mailing list
> Swan-dev at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev