Re: ipsec: slight inconsistency

[tlaronde%polynum.com@localhost]

Le Sat, Jul 01, 2023 at 10:49:45AM -0400, Greg Troxel a écrit :
> tlaronde%polynum.com@localhost writes:
> 
> > The two functions are said "inverse" from each other but the problem is
> > that if one gives a delimiter to ipsec_dump_policy(3) that is neither
> > a blank nor a new line, the string obtained can not be an input
> > to ipsec_set_policy(3). So there are not really inverse from each other.
> >
> > Wouldn't it be more logical whether to have no delimiter to
> > ipsec_dump_policy(3) (defaulting to '\n' for separating the elementary
> > statements) or to allow a delimiter to ipsec_set_policy(3) when parsing
> > the policy passed?
> 
> I think it would be most logical to document in ipsec_dump_policy that
> the default delimeter matches what is expected by ipsec_set_policy, and
> that alternate delimiters might be useful for people but do not produce
> valid syntax.  That resolves your consternation but does not break
> anyone relying on the current behavior.  This problem is surely
> longstanding and that you seem to be the first to notice or care, so the
> severity would seem to be extremely low.

Yes, at least for it to be documented.

But there is a more general lesson to draw from this and inetd(8): when 
giving a syntax, it has to be checked from all angles in order to settle
for something that makes sense and a documentation that matches. And the
documentation is really part of the implementation---in fact, it should
come first, and be amended while you implement...
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C