Fix decoding issue after buffer overflow. (#253)

The bug was tickled when the capture buffer overflowed.
Though, it probably also manifests when are large or garbage message is
captured, and writes data through out the buffer.
When a smaller message comes in, the last entry which is typically the
post message gap, is not cleared. This could caused the decoder(s) to get
confused as they would be reading previous messages (or garbage) data.

- Fixes Issue #246
- No unit tests for this bug is only tickled 'on device' due to interrupt
  handling. Our unit tests don't really cover that aspect.

Author: crankyoldgit

src/IRrecv.cpp

@@ -126,7 +126,7 @@ void IRrecv::copyIrParams(irparams_t *dest) {
   char *cdest = (char *) dest;  // NOLINT(readability/casting)
 
   // Copy contents of src[] to dest[]
-  for (uint16_t i=0; i < sizeof(irparams_t); i++)
+  for (uint16_t i = 0; i < sizeof(irparams_t); i++)
     cdest[i] = csrc[i];
 }
 
@@ -149,6 +149,16 @@ bool IRrecv::decode(decode_results *results, irparams_t *save) {
     return false;
 #endif
 
+  // Clear the entry we are currently pointing to when we got the timeout.
+  // i.e. Stopped collecting IR data.
+  // It's junk as we never wrote an entry to it and can only confuse decoding.
+  // This is done here rather than logically the best place in read_timeout()
+  // as it saves a few bytes of ICACHE_RAM as that routine is bound to an
+  // interrupt. decode() is not stored in ICACHE_RAM.
+  // Another better option would be to zero the entire irparams.rawbuf[] on
+  // resume() but that is a much more expensive operation compare to this.
+  irparams.rawbuf[irparams.rawlen] = 0;
+
   bool resumed = false;  // Flag indicating if we have resumed.
 
   if (save == NULL) {