[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