[Swan-dev] oddity in ikev2_process_child_sa_pl
Andrew Cagney
andrew.cagney at gmail.com
Mon Jun 4 13:41:03 UTC 2018
Occam's razor. The code is, after all working.
accepted_dh == NULL ? "no DH" : accepted_dh->common.fqn);
is to ensure that this code snippet (which means in isolation and even
when moved elsewhere) doesn't dump core.
There's a way to tell coverity to ignore this (or just do it as a
human), I'd be using that feature.
On 3 June 2018 at 18:52, Neal P. Murphy <neal.p.murphy at alum.wpi.edu> wrote:
> 'Inverting' the logic yields
>
> if ( ! (accepted_dh == NULL || accepted_dh == st->st_pfs_group)) {
>
> which doesn't look right either. Mayhap it should be
>
> /*
> * Verify the pointer isn't null before comparing.
> * The error is that either there's no DH or it doesn't match what was negotiated.
> * Otherwise the DH is stored.
> */
> if ( accepted_dh == NULL || accepted_dh != st->st_pfs_group) {
>
> But this still doesn't look quite right. If st->st_pfs_group is null, you want to save the DH, right?
>
> Maybe it wants to be
>
> if ( accepted_dh == NULL || (st->st_pfs_group != NULL && accepted_dh != st->st_pfs_group)) {
>
>
> N
>
> On Sun, 3 Jun 2018 18:18:28 -0400 (EDT)
> "D. Hugh Redelmeier" <hugh at mimosa.com> wrote:
>
>> /*
>> * Update/check the PFS.
>> *
>> * For the responder, go with what ever was negotiated. For
>> * the initiator, check what was negotiated against what was
>> * sent.
>> */
>> const struct oakley_group_desc *accepted_dh = proto_info->attrs.transattrs.ta_dh;
>> switch (st->st_sa_role) {
>> case SA_INITIATOR:
>> pexpect(expect_accepted);
>> if (accepted_dh != NULL && accepted_dh != st->st_pfs_group) {
>> loglog(RC_LOG_SERIOUS,
>> "expecting %s but remote's accepted proposal includes %s",
>> st->st_pfs_group == NULL ? "no DH" : st->st_pfs_group->common.fqn,
>> accepted_dh == NULL ? "no DH" : accepted_dh->common.fqn);
>> return STF_FAIL + v2N_NO_PROPOSAL_CHOSEN;
>> }
>> st->st_pfs_group = accepted_dh;
>> break;
>>
>> coverity noticed that
>> accepted_dh == NULL ? "no DH" : accepted_dh->common.fqn);
>> was silly because we know that accepted_dh is not NULL (the preceding if checks).
>>
>> I'm wondering, whether the test is correct. Should it be || instead of &&? It's not clear to me.
>> _______________________________________________
>> Swan-dev mailing list
>> Swan-dev at lists.libreswan.org
>> https://lists.libreswan.org/mailman/listinfo/swan-dev
>
> _______________________________________________
> Swan-dev mailing list
> Swan-dev at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev
More information about the Swan-dev
mailing list