On Thu, Jan 7, 2010 at 7:29 PM, Wes Hardaker <[email protected] > wrote:
> [ ... ] > > The important end point from all of this is I have yet to hear why this > is a bad thing? > > a) read 0x656667 from the .conf file > b) pad it to 0x65666700 > c) return it with a length of 3 > > Where is the evil? What is breaking because of that? What would the > benefits of removing that 00 be? I see no gains for removing it and > many positives. Hello Wes, Thanks for jumping in on this discussion. I'm not sure whether it was clear from the commit messages, but the behavior you described above is the current behavior of read_config_read_octet_string() (since r17998). This involves a change compared to the 5.5 and earlier code, namely that callers of read_config_read_octet_string() that pass a pre-allocated buffer to this function have to be aware that they must reserve space for the terminating '\0'. Trying e.g. to read 16 bytes into a 16-byte array with the trunk version of read_config_read_octet_string() will cause a buffer overflow message to be printed, at least when -Dread_config_read_octet_string has been specified. The version on the 5.5 branch of this function will successfully read the data into the buffer. Bart.
------------------------------------------------------------------------------ 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
