On 4 July 2014 15:20, Toralf Förster <toralf.foers...@gmx.de> wrote:
> On 07/04/2014 11:17 AM, Ben Laurie wrote:
>> It'd be nice, btw, if someone would report the bug to cppcheck.
> http://5.150.254.56:443/trac-cppcheck/ticket/5970#ticket

Thanks.

>
> Thx
>>
>> On 4 July 2014 10:15, Ben Laurie <b...@links.org> wrote:
>>> On 3 July 2014 22:35, Kurt Roeckx <k...@roeckx.be> wrote:
>>>> On Thu, Jul 03, 2014 at 09:28:47PM +0100, Ben Laurie wrote:
>>>>> On 3 July 2014 20:06, Kurt Roeckx via RT <r...@openssl.org> wrote:
>>>>>> On Thu, Jul 03, 2014 at 07:51:28PM +0200, Toralf Förster via RT wrote:
>>>>>>> I think cppcheck is right here in void DES_ofb64_encrypt(), line 84, 85
>>>>>>> and 96, or ?:
>>>>>>>
>>>>>> The line before that:
>>>>>>
>>>>>>         dp=d;
>>>>>>>         l2c(v0,dp);<--- Uninitialized variable: d
>>>>>>>         l2c(v1,dp);<--- Uninitialized variable: d
>>>>>>>         while (l--)
>>>>>>>                 {
>>>>>>>                 if (n == 0)
>>>>>>>                         {
>>>>>>>                         DES_encrypt1(ti,schedule,DES_ENCRYPT);
>>>>>>>                         dp=d;
>>>>>>>                         t=ti[0]; l2c(t,dp);
>>>>>>>                         t=ti[1]; l2c(t,dp);
>>>>>>>                         save++;
>>>>>>>                         }
>>>>>>>                 *(out++)= *(in++)^d[n];<--- Uninitialized variable: d
>>>>>>>                 n=(n+1)&0x07;
>>>>>>>                 }
>>>>>>
>>>>>> d is uninitialized, but it's being written to, not read from,
>>>>>> so I don't see a problem with this.
>>>>>
>>>>> What?
>>>>
>>>> So l2c is:
>>>> #define l2c(l,c)        (*((c)++)=(unsigned char)(((l))&0xff), \
>>>>                          *((c)++)=(unsigned char)(((l)>> 8L)&0xff), \
>>>>                          *((c)++)=(unsigned char)(((l)>>16L)&0xff), \
>>>>                          *((c)++)=(unsigned char)(((l)>>24L)&0xff))
>>>>
>>>> It reads v0 and v1 and writes to d (dp).  d being uninitialized
>>>> shouldn't be an issue.  Or am I missing something?
>>>
>>> It writes to *d, surely? Which means d uninitialised is very much an issue, 
>>> no?
>>>
>>> However, now I've read the code (it'd help if people posted enough
>>> snippet to make that unnecessary!) I see d is DES_cblock, i.e. an
>>> array, so the diagnosis is basically incorrect. And therefore I agree
>>> with you, not a problem.
>>
>
>
> --
> Toralf
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to