[Swan-dev] test_enum handles negative values stored in an unsigned!
D. Hugh Redelmeier
hugh at mimosa.com
Fri Sep 22 11:30:54 UTC 2017
Andrew asks in IRC:
DHR, I'm puzzled by test_enum("ike_idtype_names_extended",
&ike_idtype_names_extended, -10, 0); enum_names has unsigned
fields, but it contains entries for -ve numbers
In 7b476df8b2e144d0ec8ba41c99b45a708a6e0bae (2007 MCR) "ID_FROMCERT" was
added as a negative integer.
But enum_names really assumes that all names are for unsigneds. After
all, that's the way IPSec works.
So this negative value is awkward. I made it kind of work in
20506c6e52ee4cf180ac124e8923ed3e702bddab
I also added enumcheck coverage for it. This is currently the only case
where negative numbers enter the Libreswan enum machinery and I kind of
documented that in a comment on the declaration for
ike_idtype_names_extended. Maybe more needs to be said.
Look at how ID_FROMCERT was printed before this commit. The literal value
-3 (not ID_FROMCERT) was explicitly tested for. And ID_MYID was not
handled. Oh, and ID_IMPOSSIBLE was defined but never used.
(C says enums are effectively signed ints. That's unfortunate. It isn't
actually what we want in most of Libreswan. If I'd designed C I'd have
made them their own type and required explicit conversion when you wanted
to use them as some kind of integral type (like Algol-X where they were
first introduced). Or maybe have keyword "uenum" to declare an unsigned
enum type. It's all a mess.)
More information about the Swan-dev
mailing list