[Swan-dev] test_enum handles negative values stored in an unsigned!

[Andrew Cagney]

On 22 September 2017 at 07:30, D. Hugh Redelmeier <hugh at mimosa.com> wrote:

> 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.
>
>
Nice archaeology.


> But enum_names really assumes that all names are for unsigneds.  After
> all, that's the way IPSec works.
>
>
Yea.


> 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.)
>

https://gcc.gnu.org/ml/gcc-bugs/2000-09/msg00271.html

The only guarantee is that an enum containing a -ve value is signed.

GCC defults to unsigned int (but I get the feeling that at some point this
might have changed/).



> _______________________________________________
> Swan-dev mailing list
> Swan-dev at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20171001/785ba73b/attachment.html>