[OpenTRV-dev] Strange c code behaviour on the arduino

[Jeremy Poulter]

Where is the memory for tag1 and tag2 allocated from? If on the the stack
maybe the stack is being corrupted?

As an aside I would also pass on the size of the two buffers and/or use a
#define in-place of the 16 to make it a bit for readable.

Cheers,

Jeremy
On 7 Sep 2015 19:24, "Deniz Erbilgin" <deniz.erbilgin at gmail.com> wrote:

> Hi all,
>
> I'm currently putting the AESGCM encryption libraries together for the
> arduino and have been getting some interesting behaviour from my tag
> checking function:
>
> static uint8_t checkTag(const uint8_t *tag1, const uint8_t *tag2)
> {
>    uint8_t result;
>
>    // compare tags. If any byte fails, will set bits in result
>    for (uint8_t i = 0; i < 16; i++) {
>        result |= *tag1 ^ *tag2;
>        //Serial.print(result, HEX);    // when this is uncommented, the
> function works correctly
>        tag1++;
>        tag2++;
>    }
>    return result;
> }
>
>
> The function just loops through an array and sets bits in result whenever
> there is a difference between bytes.
>
> I had all the functions visible externally while I was debugging another
> problem and it was working fine. However, when I made all the functions
> static again, the decrypt function started returning a failed tag check.
>
> I included the arduino headers in the library so that I could print from
> it to serial, and as long as I print 'result' to the console it works fine.
> I printed both tags from within the function just in case and they're both
> identical, whether or not the function fails.
>
> All I can think of is that the compiler is trying to optimise it in some
> strange way.
>
> Thanks,
>
> Deniz
>
> _______________________________________________
> OpenTRV-dev mailing list
> OpenTRV-dev at lists.opentrv.org.uk
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opentrv.org.uk/pipermail/opentrv-dev/attachments/20150907/09cfa10a/attachment.html>