[AGENT++] Consts in SNMP++

Marek Malowidzki malowidz at wil.waw.pl
Wed Feb 11 09:32:13 CET 2004


> Unfortunately, the original v2.x of SNMP++ did not use const at all
> (or only accidentially). The reason for it were some internal needs at
> HP. Peter Mellquist wrote me, that they otherwise had some compilation
> problems with existing applications.
>
> Since SNMP++v2.x seems to be a dead end these days, I do not think
> that we have to worry about those SNMP++v2.x users. That's why
> Jochen has already made most of the const methods const. Obviously,
> we missed some of those. So thanks for your hints, we will try to fix
them.

There is no problem and I realize that the library is being continuously
improved. I hit the problem after I had added some 'const's to SNMP++.NET
and got multiple compilation errors.

By the way, are you going to add locking to friendly_name()? It uses
strcpy() to write the friendly name to a buffer. In fact, the danger is
quite slight (short strings, most likely the same names got in multiple
calling threads) but still exists. In many places, you use:

iv_friendly_name[0]=0;

and friendly_name() checks the first byte. The problem is that when one
thread checks this first byte while the other one is writing the firiendly
name, a crash may cause (if the terminating '\0' is not present
accidentally). The solution is either:
1.) locking
2.) when we assume that the resolver returns the same friendly name each
time it is called, or that we can tollerate "messed" names, it would be
sufficient to either fill the buffer with zeros (completely) or write the
first byte as the last one:

// strcpy(iv_friendly_name, s);
strcpy(iv_friendly_name + 1, s + 1);
iv_friendly_name[0] = s[0];    // now the buffer is valid

Note that setting the validity flag is prone to race conditions, so it will
not help.

Marek




More information about the AGENTPP mailing list