Hey Levi, I see what you're saying. Right now I only see this issue in ipmipower/src/ipmipower_prompt.c. Do you see it anywhere else?
Also, looking at format_kg() it seems that: assert(outsz > IPMI_MAX_K_G_LENGTH*2); should be assert(outsz > IPMI_MAX_K_G_LENGTH*2+2); ?? Al On Mon, 2007-05-07 at 11:51 -0600, Levi Pearson wrote: > 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 > [email protected] > http://lists.gnu.org/mailman/listinfo/freeipmi-devel > -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/freeipmi-devel
