>>>>> On Fri, 16 Jun 2006 12:29:59 -0400, Robert Story <[EMAIL PROTECTED]> said:
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).
Robert> The correct answer is never, since ASN strings are not null
Robert> terminated. However, if the buffer is large enough, we do add
Robert> a null because so many people think they are null terminated
Robert> and pass them to printf and friends. It's just a little
Robert> additional safety.
I agree with Gustaf. The reason we null-terminate is because people
do pass strings to print functions and other things that expect null
terminated strings. Yes, the caller may not need a null termination.
However, they might also be stupid and expecting it (even though, yes
Virginia, an ASN string isn't defined to be null terminating and you
shouldn't expect it to be).
So, in the end we have choices:
1) don't ever null terminate
result: boat-loads of code that has to do this:
asn_parse_string(&buf, &len, ...)
buf[len] = '\0';
printf("%s",buf);
Requiring *more* code for every invitation seems bad if 99% of the
time in a management app or deamon with syslog you're going to be
spitting it out and will need to null terminate it.
2) always null terminate
result: it doesn't hurt people who are only looking at the real
data and real length; it helps people who are going to treat it as
a string.
The *only* negative is by someone who expects binary and is passing
in an exact-length buffer. Unfortunately, I could see this as a
common problem (I know the size of an ipv4, ipv6 and mac address is
going to be X and why wouldn't I pass in a buffer of *just* size
X).
3) in the middle... null terminate when room.
This is where we are today. The problem is it's the middle ground.
you get some of the good, with the downside of expectations are that
it's always null terminated. Obviously this downside isn't
necessarily good because sometimes it may be exactly the some
length. The upside is all the parsing that pulls directly into an
exact length buffer works just fine.
So.... The solution? Either:
A) The solution you've done which is to create a new
wrapper function. Put that in the base code and encourage it for
all use of strings which need to be null terminated.
B) encourage people to simply pass in the re-allocatable bit if
they're going to print. Then reallocate if you're at exact
length so you can add the null.
Robert> No, sorry. There is no reason to force anyone who understands
Robert> the ASN strings come with a length to allocate bigger buffers
Robert> because some people don't understand ASN strings.
Now, having said all of the above: the one thing here is that very
very few places in general code need to call asn parsing functions
directly. Our asn parsing routines were never really meant as a
stand-alone parsing set. Normally, the PDU structures (varbind lists)
are created from that, and it's these structures that are passed
around used by the apps. Thus just assuring that these are null
terminated means you cove 99% of the case (leaving just the experts to
shoot themselves).
--
Wes Hardaker
Sparta, Inc.
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
