>although I feel the >array out of bounds is probably always a bad thing to do.
I agree, but as you said, there is no junk in the result. However I think it should be fixed. >>> > Also, I believe the output of the above example is semantically > > incorrect. I personally agree but I'm afraid our users are used to this reversed notation. François Isabelle > -----Message d'origine----- > De : Al Chu [mailto:ch...@llnl.gov] > Envoyé : 25 novembre 2009 10:44 > À : ipmitool-devel@lists.sourceforge.net > Objet : Re: [Ipmitool-devel] ipmitool sensor bug(s) > > Thinking about this for another 10 seconds, I suppose if the ipmi > response (rsp var) were cleared properly in each ipmitool interface > (lan, open, etc.), then this problem might go away, although I feel the > array out of bounds is probably always a bad thing to do. (note the > array out of bounds is not going off the array of allocated memory, but > rather going passed the "max index" of data read.) > > Al > > On Tue, 2009-11-24 at 10:54 -0800, Al Chu wrote: > > I was trying to figure out why some output in FreeIPMI was different > > than in ipmitool, then I figured it out. In lib/ipmi_sensor.c in > > several locations after a sensor reading, there is code like this: > > > > printf("| 0x%-8x | %-10s | 0x%02x%02x", > > val, > > unitstr, rsp->data[2], rsp->data[3]); > > > > Most notably, the code is reading data[2] and data[3] from the response, > > which maps to state offsets 0-7 and 8-14 of discrete sensors. > > > > In the IPMI spec (35.14), only states 0-7 (byte data[2]) are required to > > be returned, states 8-14 (byte data[3]) are optional. So if you have a > > sensor that is returning only the first set of offsets, you have an > > array out of bounds and the output is returning whatever junk is out > > there. I've also found some sensors that don't return either byte > > (which is a compliance issue, but nevertheless), perhaps that should be > > handled as well. This probably requires a reasonable amount of > > re-coding, so I'll leave it to someone who is more familiar and a bigger > > maintainer of the code. > > > > Also, I believe the output of the above example is semantically > > incorrect. data[2] represents state offsets 0-7 and data[3] represents > > state offsets 8-14. So semantically, shouldn't the output be: > > > > printf("0x%02x%02x", rsp->data[3], rsp->data[2]); > > > > In other words, is the "endian" of the output backwards? [1] It's > > possible that the original output wanted to output event bitmasks 0-14 > > in order left to right, but it's actually outputting > > "7-0,reserved(ie. bit 15),14-8". > > > > Al > > > > [1] - "endian" isn't the right word, but hopefully you get what I'm > > trying to say :-) > > > -- > Albert Chu > ch...@llnl.gov > Computer Scientist > High Performance Systems Division > Lawrence Livermore National Laboratory > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Ipmitool-devel mailing list > Ipmitool-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ipmitool-devel ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Ipmitool-devel mailing list Ipmitool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
