>>>>> On Thu, 7 Jan 2010 19:53:52 +0100, Bart Van Assche >>>>> <[email protected]> said:
BVA> Trying e.g. to read 16 bytes into a 16-byte array with the trunk BVA> version of read_config_read_octet_string() will cause a buffer overflow BVA> message to be printed, at least when -Dread_config_read_octet_string has BVA> been specified. The caller certainly needed to be aware that reading a 16-byte value into a 16-byte array wouldn't null terminate. It wouldn't break though. I don't think that's better than returning an error as you're now changing the behavior of the function which isn't safe for those out in user-land. Yes, I realize I'm speaking somewhat at odds with myself. But generally backwards-compatibility is actually more important in cases like this. Note that I've put backwards-compatibility on the discussion list for next Monday's meeting. But your new version is *not* currently backwards compatible, which means it can't (based on existing policy) be put into the immediate next release. There are lots of users out there that may have exactly allocated their buffers and you'll now return an error when you didn't before... - * don't require caller to have +1 for good measure, and - * bail if not enough space. + * require caller to have +1, and bail if not enough space. That's a compatibility change. -- Wes Hardaker Please mail all replies to [email protected] ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
