On Mon, Sep 9, 2013 at 5:14 PM, Liebig, Holger
wrote:
> [Liebig, Holger]
> Just a heads up:
> unfortunately the change breaks 'ipmitool dcmi power set_limit action
> power_off' due to the test for a valid integer value at the beginning of the
> ipmi_dcmi_pwr_slimit() function which should be val
>
> 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?
>
[Liebig, Holger]
Just a he
On Mon, Aug 5, 2013 at 8:43 PM, Dan Gora wrote:
> Hi Zdenek,
>
> Sorry it took so long to get back to this...
Hello Dan,
it's better late than never. We're all busy :)
>
[...]
> This is why you have to use:
>
> data[4] = correction >> 0;
> data[5] = correction >> 8;
> da
Hi Zdenek,
Sorry it took so long to get back to this...
On Thu, Jul 25, 2013 at 3:11 PM, Zdenek Styblik
wrote:
> DCMI is some M$ server power management thing or whatnot. I believe
> trying out similar code snippet should be enough to verify it works as
> expected.
> Please, can you test http://
On Thu, Jul 25, 2013 at 8:48 PM, Dan Gora wrote:
[...]
>
> Let's consider an example:
>
> int foo(int arg)
> {
>int i;
>
>if (arg < 1)
> i = 1;
>else if (arg >= 2)
> i = 2;
>
>printf("i=%d\n", i);
> }
>
> Now in this case if 'arg' is 1, then the value printed will be
>
On Thu, Jul 25, 2013 at 3:11 PM, Zdenek Styblik
wrote:
>> 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 th
On Thu, Jul 25, 2013 at 5:39 PM, Dan Gora wrote:
>> 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
>>
On Thu, Jul 25, 2013 at 11:59 AM, Zdenek Styblik
wrote:
> On Thu, Jul 25, 2013 at 4:52 PM, Dan Gora wrote:
>> On Thu, Jul 25, 2013 at 1:40 AM, Zdenek Styblik
>> wrote:
>>> Hi,
>>>
>>> attached is a patch to mitigate possible int *flows via user input.
>>> It's pretty much no brainer except those
On Thu, Jul 25, 2013 at 4:52 PM, Dan Gora wrote:
> On Thu, Jul 25, 2013 at 1:40 AM, Zdenek Styblik
> 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
On Thu, Jul 25, 2013 at 1:40 AM, Zdenek Styblik
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 correctl
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?
Thanks,
Z.
ipmi_dcmi.c-fix_flows.diff
Descrip
11 matches
Mail list logo
