On Sun, 13 Oct 2019 at 13:29, D. Hugh Redelmeier wrote:
>
> | From: Andrew Cagney
>
> | 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
| From: Andrew Cagney
| 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
PS:
Moving the size logic out of ttorange() and into a function vis:
bool range_size(const ip_range *range, uintmax_t *staturated_size)
MUST_USE_RESULT /* false if overflow */
(same for converse range+offset) I think does have merit.
Andrew
On Sun, 13 Oct 2019 at 12:49, Andrew Cagney wrote:
On Sun, 13 Oct 2019 at 11:04, D. Hugh Redelmeier wrote:
>
> The ip_range type seems to be used for two purposes:
>
> - traffic selectors
The (ikev2) traffic selector code outputs an ip_subnet, not an
ip_range Internally it just happens to use an ip_range as part of the
journey towards a subnet.
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?
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
The ip_range type seems to be used for two purposes:
- traffic selectors
- ip address pools
The two uses have diverged. Lots of complexity has been added for the
address pool case which is not clearly correct or useful for the traffic
selector case.
Is there an RFC-based limit on range
