<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 22 September 2017 at 07:30, D. Hugh Redelmeier <span dir="ltr"><<a href="mailto:hugh@mimosa.com" target="_blank">hugh@mimosa.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Andrew asks in IRC:<br>
<br>
        DHR, I'm puzzled by test_enum("ike_idtype_names_<wbr>extended",<br>
        &ike_idtype_names_extended, -10, 0); enum_names has unsigned<br>
        fields, but it contains entries for -ve numbers<br>
<br>
In 7b476df8b2e144d0ec8ba41c99b45a<wbr>708a6e0bae (2007 MCR) "ID_FROMCERT" was<br>
added as a negative integer.<br>
<br></blockquote><div><br></div><div>Nice archaeology.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
But enum_names really assumes that all names are for unsigneds.  After<br>
all, that's the way IPSec works.<br>
<br></blockquote><div><br></div><div>Yea.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So this negative value is awkward.  I made it kind of work in<br>
20506c6e52ee4cf180ac124e8923ed<wbr>3e702bddab<br>
I also added enumcheck coverage for it.  This is currently the only case<br>
where negative numbers enter the Libreswan enum machinery and I kind of<br>
documented that in a comment on the declaration for<br>
ike_idtype_names_extended.  Maybe more needs to be said.<br>
<br>
Look at how ID_FROMCERT was printed before this commit.  The literal value<br>
-3 (not ID_FROMCERT) was explicitly tested for.  And ID_MYID was not<br>
handled.  Oh, and ID_IMPOSSIBLE was defined but never used.<br>
<br></blockquote><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
(C says enums are effectively signed ints.  That's unfortunate.  It isn't<br>
actually what we want in most of Libreswan.  If I'd designed C I'd have<br>
made them their own type and required explicit conversion when you wanted<br>
to use them as some kind of integral type (like Algol-X where they were<br>
first introduced).  Or maybe have keyword "uenum" to declare an unsigned<br>
enum type.  It's all a mess.)<br></blockquote><div><br></div><div><a href="https://gcc.gnu.org/ml/gcc-bugs/2000-09/msg00271.html">https://gcc.gnu.org/ml/gcc-bugs/2000-09/msg00271.html</a><br></div><div><br></div><div>The only guarantee is that an enum containing a -ve value is signed.</div><div><br></div><div>GCC defults to unsigned int (but I get the feeling that at some point this might have changed/).</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
______________________________<wbr>_________________<br>
Swan-dev mailing list<br>
<a href="mailto:Swan-dev@lists.libreswan.org">Swan-dev@lists.libreswan.org</a><br>
<a href="https://lists.libreswan.org/mailman/listinfo/swan-dev" rel="noreferrer" target="_blank">https://lists.libreswan.org/<wbr>mailman/listinfo/swan-dev</a><br>
</blockquote></div><br></div></div>