It’s yet another hack-y way of getting debug output that is probably undocumented and you can probably desupport if you like. Where it has come in useful is this: * Someone develops an app with note-c (or note-arduino, or whatnot) * Because of the nature of their hardware, they have no “Arduino debug console” or other such thing where they can see debug output on their mcu. (We had this problem badly with, I believe, some little msp432 we were playing with.) BUT they are desperate to see what is happening inside their host MCU * The NoteDebug, when hooks aren’t registered, will call card.debug and output the app’s debug output on the notecarrier’s “trace mode” usb console * The reason for “inLog” is self-evident if you were to remove it: NoteTransaction ITSELF does NoteDebug output for transaction debugging, and without the flag we’d go recursive and blow the stack From: Zachary J. Fields ***@***.***> Date: Thursday, January 12, 2023 at 6:13 AM To: blues/note-c ***@***.***> Cc: Ray Ozzie ***@***.***>, Mention ***@***.***> Subject: Re: [blues/note-c] Add more unit tests and other cleanups. (PR #38) @zfields requested changes on this pull request.

NoteDebug(text); return true; } - int inLog = 0; @rayozzie<https://github.com/rayozzie> , Can you remind us of the original intent of the inLog variable? Obviously, it wasn't doing anything as it stood, but is there some functionality we should have and are missing?

for (retries=0; transmitErr==NULL && !notecardReady && retries<3; retries++) { // Loop to drain all chunks of data that may be ready to transmit to us - int chunklen = 0; + uint32_t chunklen = 0; ⬇️ Suggested change - uint32_t chunklen = 0; + uint16_t chunklen = 0; I'm always leary of changing types. Moving to unsigned is a good change, and I cannot see any immediate side-effects of uint32_t. However, since you are making the change, perhaps you can select a type that is "guaranteed to be safe", like uint16_t. The signature for _I2CReceive() is: const char *NoteI2CReceive(uint16_t DevAddress, uint8_t* pBuffer, uint16_t Size, uint32_t *available) chunklen goes into the Size parameter, which is uint16_t. As note-c written today, the value in chunklen cannot exceed 127, so there is no problem. That being said, why not play is safe?

_Debug("no notecard\n"); #endif _DelayMs(500); - _SerialReset(); Whoa. Does this change behavior? I'm concerned, because note-c is used by all our customers. If this is a bug, then it probably needs to be documented and stay a bug, because it's likely either depended upon or already been worked around, and the worst thing we could do is break our customers code. @rayozzie<https://github.com/rayozzie> Can you bless this change?

if (segLen > CARD_REQUEST_SERIAL_SEGMENT_MAX_LEN) { segLen = CARD_REQUEST_SERIAL_SEGMENT_MAX_LEN; } - _SerialTransmit((uint8_t *)&transmitBuf[segOff], segLen, false); + _SerialTransmit(&transmitBuf[segOff], segLen, false); Based on the type of transmitBuf above, this looks like a nice clean-up. 👍 But just to confirm, the tests running with -Wall, -Wextra, -Wpedantic, -Werror, right? The reason I ask, is because a lot of the casting you see throughout the code was to keep different compilers from issuing warnings about our code. This one seems to be a non-issue, but it made me think about us having our flags enabled. I didn't look too hard, but I couldn't immediately find them the CMakeLists.txt below.

for (retries=0; transmitErr==NULL && !notecardReady && retries<3; retries++) { // Loop to drain all chunks of data that may be ready to transmit to us - int chunklen = 0; + uint32_t chunklen = 0; It's odd that the available parameter returns a uint32_t, which is then loaded into chunklen. 🤔 NoteI2cReceive is executing a callback (beyond our control), so it seems like we should program defensively and also add a bounds check (along with test) around this edge case. Below (line #266) you could change the logic to protect against it with: // Read everything that's left on the module chunklen = (available > USHRT_MAX) ? USHRT_MAX : available; — Reply to this email directly, view it on GitHub<#38 (review)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAF2CPNRH72WZHUMCHR76ETWSAGORANCNFSM6AAAAAATYQWBMU>. You are receiving this because you were mentioned.Message ID: ***@***.***>