Post code - this is all just hand-waving.
The source file in question is here, on Github:https://github.com/jrowberg/keyglove/blob/master/keyglove/support_bluetooth2_iwrap.h#L1105The full project is on the same Github repo:https://github.com/jrowberg/keyglove/tree/master/keyglove
(You can't put code formatting inside code tags)
payload = 0; // no NAME yet
if (name_len) memcpy(payload + 13, friendly_name, name_len);
In the code you posted (at the #105 link), kg_evt_bluetooth_inquiry_response is NOT explicitly set to NULL anywhere. Where is the pointer EXPLICITLY set to NULL. Where is it set to point to some real function?
/* 0x03 */ uint8_t (*kg_evt_bluetooth_inquiry_response)(uint8_t *address, uint8_t *cod, int8_t rssi, uint8_t status, uint8_t index, uint8_t name_len, uint8_t *name_data) = 0;
In short the presence or absence of braces is a red-herring, since it makes no difference. The presence of a memcpy() call earlier up is suggestive, you've likely smashed the stack or heap. Small changes in code structure can lead to the compiler generating different stack frame layout, which can interact with the stack corruption in different ways - in other words the symptoms of memory corruption can be anything at all and typically are Heisenbugs. You may have run out of RAM.
The only ways the braces could have an effect is if there is some broken macro being expended that turns what looks like a single assigment statement into several statements, or if the compiler has a bug. Are you using any macros?
In one function you set the name at position 13 ( index 12 )...And index twelve is unset. (could be zero, which is effectively an empty string.)
payload = name_len;
Code: [Select]if (name_len) memcpy(payload + 13, friendly_name, name_len);So the name you copy in overruns the array by 1 byte!
The repo code doesn't explicitly set the pointers to NULL, though I did modify line 133 in the "support_bluetooth2_iwrap.h" file to do this as a test:
Have you actually checked your available memory. You may well be running out of sRam.
Can you confirm that the code as currently found on GitHub also exhibits these characteristics (described in the OP)? ... this different register allocation is springing a crash caused by the memory leak / overwriting.
How big can the (contents of the) variable iwrap_autocall_index get? (eg. 42)
You can not initialize variables in a header file. What that did was make the function a pure virtual function. Which means that, if the code compiled, some other class inherits from the class you modified, AND actually implements the function. So, you are NOT looking at the code that actually gets executed.
I think it is still allowed to declare and initialize this kind of value in a header file, right?
You have so many files and such useless comments that it's hard to keep track of what's what.
If the function is not in a class, then nothing I said about it applies.
I sussed out your approach which is a bit unusual, but in itself I don't think would cause a problem...more conventionally, you would have a lot of .cpp files, and manage calls from one to the other by using function prototypes in a .h file. ... *Having said that, your .h file approach effectively produces a monolithic object file which may possibly have problems compared to separate compilation units.
What device are you running this on? A Teensy++? Is that the one with a AT90USB1286 processor? 8192 bytes of RAM, 130048 bytes of flash? ...I seem to recall some issues with the Atmega2560 where code (or data?) crosses a 64 kB boundary.