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 <[email protected]> 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 > [email protected] > https://lists.libreswan.org/mailman/listinfo/swan-dev _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
