Bill Fenner <fen...@gmail.com>: > I don't think the patch is the issue. There are two questions to be > addressed first: > > 1. For the embedded environment, is it acceptable to use an extra several > bytes for this (or is there a way to rearrange the struct so that padding > reduces the extra cost)?
A couple of instances I looked at could be repacked to avoid the 1 char of slop using techniques I described in http://www.catb.org/esr/structure-packing/ On the other hand, I question whether the extra overhead is a real issue in 2018. I have old-school reflexes about this myself, but even embedded systems are shipping with a lot more RAM than they used to. Unless variable instances are being spawned by the tens of thousands it's hard to imagine this being a real problem. And how likely is that on a resource-constrained system? I actually did think about repacking the struct (see: old-school reflexes) but decided not to in order to avoid compromising the readability by separating the two elements that seem to be in all variants. Also to make the patch itself easy to understand. > 2. Is it reasonable to have more than 255 variables in a single > registration, or should the reporter just split up his registration into > multiple groups, each with less than 255 variables? That I have no opinion on. My domain knowledge of SNMP and its usage is very limited. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. ------------------------------------------------------------------------------ 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