On Thu, Jul 25, 2013 at 11:59 AM, Zdenek Styblik
<zdenek.styb...@gmail.com> wrote:
> On Thu, Jul 25, 2013 at 4:52 PM, Dan Gora <dan.g...@gmail.com> wrote:
>> On Thu, Jul 25, 2013 at 1:40 AM, Zdenek Styblik
>> <zdenek.styb...@gmail.com> wrote:
>>> Hi,
>>>
>>> attached is a patch to mitigate possible int *flows via user input.
>>> It's pretty much no brainer except those shifts. Therefore I'd
>>> appreciate if somebody could give it a look.
>>> Are those shifts correct?
>>> Will they work correctly on big endian too?
>>>
>>
>> well it now packs the data into the buffer in little endian format on
>> both little endian and big endian hosts, so at least it's now
>> consistent. It's not clear if the data is _supposed_ to be packed in
>> little endian format, but presumably it was..
>>
>
> First of all, thanks looking into it.
> I can compare "old" code with a new one, but I don't anything big
> endian ready to test at. And I don't feel like setting up QEMU-ARM
> right now. However, I can share small code snippet with a test
> code(later).
I have a big endian setup, but honestly I don't even know what this
dcmi stuff is or if it's relevant to my ATCA setup or if I can test
it.. I'll have a quick look later when I get to the office.
>
>> The other thing that I would recommend is that you _not_ initialize
>> local variables when you declare them. What this does is to preclude
>> the compiler from finding code paths where the variable is used, but
>> uninitialized. The compiler is much better at finding those code
>> paths than humans are.
>>
>
> Hm, I see your point. Perhaps a dumb question, but do you mean only
> variables or structures/arrays as well?
Both. The gcc compiler cannot pick out used, but uninitialized fields
from a structure (other compilers might), but IMHO it's better to
explicitly initialize the structure near where it's going to be used
so that people can see that you're explicitly initializing it and know
that you didn't just forget about it.
For instance:
struct blahblah {
int foo;
int bar;
};
int somefunc(void)
{
struct blahblah test;
<code>
<code>
/* initialize test to all 0's */
memset(test, 0, sizeof(test));
test.bar = 1;
printf ("foo=%d bar=%d\n", test.foo, test.bar);
}
Also, remember that:
uint8_t data[256] = {0};
does not zero all the elements of 'data', only the first element.
> Because I'd think to have
> variable initialized to a known value is better, eg. this was proven
> in 'ipmi_sel.c' where uninitialized 'struct time_t' had random
> results.
I'm not sure really about this particular case, but (IHMO) you should
leave it uninitialized in the declaration and if you know that there
is a code path where it's not going to get initialized, initialize it
in that code path. Either that or set it to some default value close
by the first use of that variable so that the reader knows that it's
supposed to have some default value and that default value has not
scrolled off the top of the screen.
thanks
d
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
