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
> Freeipmi-devel@gnu.org
> 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
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel

Reply via email to