Re: asn1.c/asn_parse_string() null-termination behaviour

HI,

"Fixing" by putting a "0" on the end, and then calling
printf is not a good approach. This is because the
value of OCTET STIRNGs are binary, the the result
when just doing a printf may not result is a usable
output. Even when the value of the OCTET STRING is
suppose to be printable, the SNMP agent may have
a bug and return a value that contains nonprintable
octets. Thus, I suggest that you ALWAYS use a function
that takes an OCTET STRING value and creates a displayable
string in a supplied buffer, and then printf the resulting
buffer.

PS Be aware of OCTET STRINGs whose value is UTF-8, and
know what you want to do for non-US-ASCII display.

On Fri, 16 Jun 2006, Gustaf Gunnarsson wrote:
> Robert Story wrote:
> > On Thu, 15 Jun 2006 12:41:36 +0200 Gustaf wrote:
> > GG> The problem I am having is that the asn_parse_string() function
> > GG> null-terminates the string it parses if the size of the recieving char*
> > GG> is large enough to contain such terminator.
> > GG>
> > GG> I think this behaivour is wrong and that the returned string should
> > GG> always be null-terminated (or never).
> >
> > The correct answer is never, since ASN strings are not null terminated.
> > However, if the buffer is large enough, we do add a null because so many
> > people think they are null terminated and pass them to printf and friends.
> > It's just a little additional safety.
>
> I really think this is wrong.
>
> The reason why I think it is wrong is exactly what you mention, people
> will pass this string to printf() since it works. I however think it
> would be a lot better if people would learn the first time to do
> something like:
>
> asn1p = asn_parse_string(asn1p, &asn1p_len,
> &asn1p_type, string, &string_len_MINUS_ONE);
> *(string+&string_len_MINUS_ONE) = '\0';
>
> Instead of having to figure out that this is what they need to do the
> 2784117371 time they run it and the program segfaults in their face
> (without a clue why it happened).
>
> Anyways, I am not going to argue about it (more than this :P).
>
> Thanks for your answer.
>
> //Gustaf

Regards,
/david t. perkins



_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/...et-snmp-coders