toggle quoted messageShow quoted text
Several people have asked about compiler warnings they are getting, like:
warning: ISO C++ forbids converting a string constant to 'char*'
A variation on this are the "deprecated" warnings issued by the compiler. Even more confusing is the fact that the warnings they now see were not there before. Usually, this is because of a compiler update. As a general rule, compiler warnings do not prevent the compile from finishing or performing an upload. However, warnings mean something is bending the rules. For anyone who might be interested, this was my answer to one of those people.
I think everyone understands what a syntax error is: Not following the rules of the language. Semantic errors are more difficult because the rules are followed, but the context is wrong. For example, we know an English sentence needs a noun and a verb...those are the rules. However, if I say: "The dog meowed.", it obeys the syntax rules, but the semantics are out of context. I'm not sure how far back, but around version 1.65 the GCC compiler started performing some syntax and semantic checking at the "lint" level. My company produced a C compiler back in the '80's and we had a "picky flag" that could be set from 0 to 10. It performed syntax and semantic checks at increasing stringent levels. I never saw any published C code that passed our Picky Level 10. Indeed, that level was so intrusive that we never used it. Most work was done at Picky Level 4. When we were ready for distribution, we cranked it up to level 10. Truth be told, we still didn't bother to fix some of the warnings. Somewhere between 1.65 and 1.85 they kicked the GCC compiler's equivalent of our Picky Flag up a notch, hence warnings now where none existed before. That's a good thing.
However, the bad thing is that there are now a lot of warnings that unnecessarily cause people concern. Even worse, a lot of it comes from libraries, which is NOT your responsibility to fix. The library writer should fix those. When I first compiled the µBITX code, I had probably a hundred such warnings, mainly because I insisted on using only one INO file, making all the other CPP files (plus a header). True, it was a pain in the butt to fix all the warnings, but it was worth it. Why? First, by not using multiple INO files, the compiler cannot perform data type checking. You'd be surprised by how many bugs hide under the blanket of missing type checking. Second, because the compiler no longer has to glom all the source files into one huge file to compile it, it allows the GCC to perform incremental compiles. This is a HUGE win. When I compile the JackAl code for the first time in the morning, it must recompile all files. In the process, it clears the "dirty flag" for each source file. Even with my 8-core, 3.7GHz machine with a mega-munch of memory, the JackAl code takes almost 2 minutes to compile. If I used all INO files, it would always take 2 minutes to compile the source code regardless of how many file changes I made. With incremental compiles, it sets the dirty flag and recompiles only those files that have changed since the last compile. This drops my compile time (on a single-file change) to about 5 seconds. Given that I might do 30-50 compiles a day, you do the math
Kind of a long answer, but it's important that you understand what's going on "under the hood" from time-to-time. Usually, compiler warnings can be ignored, but always keep in mind it still means the compiler saw something it didn't like.
On Thursday, June 28, 2018, 7:13:32 PM EDT, Steve Smith <steve@...> wrote:
thanks - I erased the EPROM and then calibrated and I am getting real results. These were new part so I am not sure how the EPROM would have had values, but the first few times we loaded the software we did not have an SD card in. Could that have affected it?
Also, thanks for the explanation of the warnings, Jack. I am running version 1.85 of the Arduino IDE on Windows 10. Is there a reason some folks get the warnings and others don't? Is it a setting in the IDE?