datacute
commented
1 year ago Thanks, those fonts are old, missing the optional fields I added to support variable width fonts. Those particular warnings are spurious, but I too like to examine and fix any warning I see, so I'll look into those.
It looks like we're missing some field initializers, so compilation is throwing mad warnings.
I do not know whether these warnings have practical effect (they're C++ class stuff, but I'm not a classy guy - I don't have a very good understanding of classes in C++), but this makes me uncomfortable using this library - they should either be corrected, or if they are spurious, suppressed within the library.
The list of missing initializers includes at least:
I normally program under a "warnings should be treated as errors (though I do not enforce this at the compiler level - it's a matter of "did you see orange text when you verified? Yes? Okay don't bother uploading, go fix those problems first". I generally do not bother to upload any code which produces warnings, as experience has shown that the warning almost always pointed to a bug and the program wold not have worked as intended. I firmly believe that more than 99% of the time, a warning is actually a serious bug or sign of lax programming practices (a matter not helped by the fact that Arduino disables warnings by default, which I consider an unpardonable sin); DxC and mTC (and future ATTinyCore) ignore the user request to disable warnings, and emit warnings regardless, since the default ide configuration is unacceptable (it hides information which would greatly expedite debugging). Since I can't change what the default is, all I could do was make all the options use -Wall. (Occasionally someone complains about this, but I shoot down those issues - My general policy is that I do not support blatantly stupid development practices. Suppressing all warnings counts as such a practice. Having warnings on has saved probably a cumulative week of development time alone, possibly much more
Compilation was performed for an ATtiny3224 (which, like DxC, has the latest modern AVR version of Wire.h which supports a superset of the standard API and uses less flash than the first refactor of Wire.h. That refactor was prompted by a user complaint that the implementation was so bloated that they couldn't compile Wire.h at all on a 4k part, nevermind the rest of the application. The inefficient implementation was easily cut it down by a large degree. The second refactor further reduced flash use while simultaneously adding the option to use master and slave simultaneously - whether on the same pins (any part) or separate pins (dual mode, DD-series and mega0 only), and adds the missing functions needed to implement I2C slave functionality that resembles what you see on commercial I2C devices). It also corrects the setClock() function to provide much better approximations of the baud rate (the actual baud rate depends on hardware conditions, namely the rise time of the SCL and SDA lines, which depends on the bus capacitance which is rarely known; reasonable assumptions are used.)