On Fri, 22 Sep 2017 08:33:42 +0200 Florian wrote: FF> I noticed that snmp_sess_synch_response() *sometimes* (not FF> always) frees the "netsnmp_pdu *pdu" argument passed to it when FF> returning STAT_ERROR. For example: FF> FF> snmp_sess_session() == NULL -> pdu is not freed FF> snmp_sess_send() == 0 -> pdu is freed FF> FF> The caller therefore has to chose between risk leaking memory FF> and risk a double-free. I assume that given these choices, FF> users opt for the inconvenient leak over a double free. FF> FF> Would you accept a patch that make the behavior deterministic FF> (from the POV of the caller)? I see the following options: FF> FF> * If the return value is STAT_ERROR, *always* free the "pdu" FF> argument. This is likely the less intrusive change, since FF> callers must already assume that this is what happens. FF> -- OR -- FF> * Introduce a new error code. The callers already expect that FF> the argument has been freed when they get a STAT_ERROR, so FF> returning SNMPERR_GENERR in cases where pdu is *not* freed FF> might be a reasonable way forward.
I think the first option seems best. Robert
pgp4f4A0U7FLL.pgp
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
