>>>>> Guy Harris writes:
Guy> Elsewhere in "packet-snmp.c", we, in effect, rely on "%.*s" not
Guy> to print any characters if the precision argument supplied is 0.
Guy> In addition, "%.*s" should probably be used for counted strings;
Guy> there's no guarantee that what "asn1_octet_string_value_decode()"
Guy> returns is '\0'-terminated.
Guy> Thus, assuming the formatting routine we use doesn't dereference
Guy> the pointer handed to it if the precision argument supplied to
Guy> "%.*s" is zero (which we should, perhaps, not rely on, unless the
Guy> ANSI C standard says it's so - but, if we shouldn't, we have
Guy> other calls to fix as well)
Assuming that ANSI C says a NULL is valid if the length in "%.*s" is
zero, then the "%.*s" seems the right solution. Unfortunately, the
replacement snprintf implementation which is shipped with ethereal
crashes if you do that. (I am running things right now on Solaris
5.5.1 which does not have its own snprintf and friends). Just do the
following to trigger the core dump:
char buf[1234];
snprintf(buf, sizeof(buf), ">%.*s<\n", 0, NULL);
The stack trace:
#0 0xef1a3ec0 in strlen ()
#1 0xbfbdc in strings (p=0xefffe6c0, tmp=0x0) at snprintf.c:328
#2 0xc0f7c in vsnprintf (string=0x1 "O", length=1234,
format=0x13b8d8 ">%.*s<\n", args=0xefffe7d0) at snprintf.c:603
#3 0xc1110 in snprintf (string=0xefffe880 ">,VE", length=1234,
format=0x13b8d8 ">%.*s<\n") at snprintf.c:669
The strings() function in snprintf.c does a strlen() regardless
whether precision is 0 or not. Looks like we need an ASNI C expert
now.
>> [Also note that a context name can contain arbitrary octets
>> including \0. The %s format specifier thus does not return useful
>> results in all possible cases.]
Guy> Is it expected to be a "human-readable" string in all cases, or
Guy> only in some cases?
The SNMPv3 specs do not say anything about it. I expect that in most
cases, this will actually be a human readable string. But it does not
have to.
Guy> And if it contains '\0', does that mean it's not intended to be
Guy> human-readable?
It can be human readable - but it does not have to. This also applies
to SNMPv1/SNMPv2c community strings. They usually contain human
readable characters - but they do not have to. (In fact, SNMPv2u (RFC
1910) did put binary data into the community string.)
Guy> If it's sometimes but not always intended to be human-readable,
Guy> perhaps we should check whether all the octets in it correspond
Guy> to printable characters and, if they're not all printable
Guy> characters, display it as hex, otherwise display it as text.
Yes.
/js
--
Juergen Schoenwaelder Technical University Braunschweig
<schoenw@xxxxxxxxxxxxxxx> Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax: +49 531 391 5936 <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>