On Fri, Apr 19, 2019 at 01:06:47PM -0700, we recorded a bogon-computron collision of the <[email protected]> flavor, containing: > I meant "all warnings" in the first sentence.
Gotcha. I actuall have started building with -Wno-format-truncation and -Wno-stringop-truncation to get it to shut up about that "we want to truncate this string to that length, and gcc warns us that it might truncate" nonsense, but I was uncomfortable about it --- because it could mask a case where we DIDN'T intend to truncate a string. Most uses of this paradigm are to truncate text down into maximum allowed lengths for an APRS packet, but some may just be carelessness. > On Fri, Apr 19, 2019 at 1:06 PM Curt Mills <[email protected]> wrote: > > > Right. I wasn't talking about turning off warnings, just specific warnings > > that might not be real. I know there's a whole set of specific warnings > > that can be turned on/off 'cuz I was turning on more warnings some years > > ago to make sure the code was as good as we could get it. I stopped doing > > that when the compilers by default started turning on more and more with > > each release. > > > > On Fri, Apr 19, 2019 at 12:37 PM km5vy Tom Russo <[email protected]> > > wrote: > > > >> Unfortunately, turning off warnings is a bad idea in this case. Some of > >> the > >> things it's warning about are really errors, such as misuse of snprintf > >> (extremely common in Xastir), using "sizeof" on a pointer to get the size > >> of > >> the object pointed to by the object (in quite a number of places), and so > >> forth. > >> > >> If we tell GCC to shut up, we miss those errors. > >> > >> There are, of course, a number of these warnings that are just annoyance. > >> For example, it is very common in Xastir for us to use something like > >> strncat > >> or snprintf very deliberatly to cause the copy operation to truncate the > >> source down into the size of the destination. GCC8 warns us that the > >> operation > >> could cause truncation, because the destination is smaller than the > >> source. > >> > >> But there are many, many more, and some are real errors. > >> > >> On Fri, Apr 19, 2019 at 12:31:43PM -0700, we recorded a bogon-computron > >> collision of the <[email protected]> flavor, containing: > >> > On Fri, Apr 19, 2019 at 11:30 AM Tom Russo <[email protected]> wrote: > >> > > >> > > > >> > > If we want to release again after we stabilize a little, I'd be OK > >> with it, > >> > > but I really doubt I'll be able to get the warning issue in hand > >> anytime > >> > > this > >> > > month. Unless, perhaps, someone would like to join in the fun and we > >> could > >> > > divide up the work. > >> > > > >> > > >> > I might be able to help a little here and there. I can remember doing > >> the > >> > same thing way back when a couple of times (I'm coming up on 20 years on > >> > this one project!). At more than one point in the project I had it down > >> to > >> > zero errors/warnings. Then another GCC version came out each time. > >> > > >> > One thing we could also perhaps do is change the compile flags to issue > >> > fewer warnings, but of course wouldn't want to turn off ones that are > >> real > >> > and might have implications if we don't correct our code. Don't want to > >> > hide real problems. > >> > > >> > -- > >> > Curt, WE7U http://we7u.wetnet.net > >> http://www.sarguydigital.com > >> > >> -- > >> Tom Russo KM5VY > >> Tijeras, NM > >> > >> echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] > >> [n-z][a-m] > >> > >> > > > > -- > > Curt, WE7U http://we7u.wetnet.net > > http://www.sarguydigital.com > > > > > -- > Curt, WE7U http://we7u.wetnet.net http://www.sarguydigital.com -- Tom Russo KM5VY Tijeras, NM echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m] _______________________________________________ Xastir-dev mailing list [email protected] http://xastir.org/mailman/listinfo/xastir-dev
