I was reviewing the k_g hex input/output as it exists in the CVS trunk
now, and I ran across a problem. Fortunately, it should only show
itself when debugging is enabled. Here's the issue: When printing the
k_g key in hex, the caller of format_kg must allocate sufficient memory
to hold it. I believe when I originally wrote format_kg, I told it to
allocate IPMI_MAX_K_G_LENGTH*2+2, which accounts for the hex
representation of 20 bytes plus the '0x' prepended to it. It seems to
have been changed to IPMI_MAX_K_G_LENGTH*2+1, which accounts for the hex
representation of 20 bytes plus the NULL termination. What it really
should be, and is in my bmc-config patches where it's really called in a
non-debug context, is IPMI_MAX_K_G_LENGTH*2+3, which accounts for the
'0x' and NULL.
Sorry I didn't catch and report this earlier. Maybe a better fix for
this would be to define a new macro, IPMI_K_G_STRING_REP_LENGTH or
something similar, that would expand to IPMI_MAX_K_G_LENGTH*2+2, and
then we would only have to account for the NULL byte with a +1. What do
you think?
--Levi
_______________________________________________
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel
