-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Saving config with wrong type wipes EEPROM memory #88
Comments
So the first question I have is, how does C++ even allow the assignment. Its a strong type language, I would have thought it would be a compile error. In any case, if it allows it with direct assignment, it likely will not kick up a fuss if we try coerce the type. I agree that the long -> json -> int will work, but I dont love it as a solution. I think, should my brain cooperate for long enough, we can tackle this in v3? |
Its literally GROSS
There is no pressing need, it was something that I stumbled into not knowing better. A cleaner
That is a mystery beyond my google-fu |
I think I have a partial answer this this conundrum. https://www.arduino.cc/reference/en/language/variables/data-types/int/ At the bottom here it points to the dangers of overflowing an int. I must wonder if the assignment of long is overflowing the int and affecting other memory. I also think it might be an Arduino thing to allow the assignment, or my mind is stuck in Go mode and this is always allowed in C++. This is my best guess at the moment. |
Discussed here
When putting the wrong type in a config parameter and saving, the memory allocation gets screwy and gets wiped.
Device will no longer have Wifi credentials/etc at next boot.
To recreate
** This may be an odd type cast I came across and doesnt apply to other scenarios.
Suggestion
A better setter for parameters via ConfigManager.
This would particularly be useful since setting a string is not straightforward
Update method
Something like:
I had zero luck figuring out how to identify a
parameter
by name from thestd::list<BaseParameter*>
and a tripped over the same trap of Arduino not having std::unordered_map at least twice now ;)Explicit parameter objects for the main project
I also tried having the
addParameter
call return theConfigParameter
object and the main project code could track/index it. That got complicated, and compiler errors in the type returns/etcDoing something bad ...
Finally .. I came up with this monster that exploits ConfigManagers use of JSON for updating ... worked, but felt icky
The text was updated successfully, but these errors were encountered: