Normal numbers in, weird numbers out

What do you think the answer to the unparenthesised 32768 / 65536 is, assuming that's what you are trying to do ?. Also, where are _count and _readings[] defined and what are they ?.

Rewrite as more than single messy line of code might improve clarity as well :-)...

Regards,

Chris

Am 25.11.2015 um 16:06 schrieb Tom Gardner:

I object to the latter. It cannot possibly be "important", because there's absolutely no way a compiler developer can reliably guess where any individual user might think it would be necessary to look.

Naming should help with remembering what you read. But it's never substitute for reading in the first place.

GCC with its long-named options has consistently been way better at this than the vast majority of compilers. -Wunused is orders of magnitude easier to understand and remember than what most of its competitors did back then, and some still do.

A hint or a reminder: sure. But confidence in your ability to guess what it does because you couldn't be bothered to look: no.

You don't have to know it all, but for a tool this complex, you really have to spend the effort to get a workable mental model of what it does.

We were discussing a loop

So n runs from 0 to 2 not to 10 billion.

Question was why Tim used size_t for a loop index. The answer was that in some situations, loop indexes don't fit in an int.

I don't understand why people are bringing up this n

^ ^^^^^^^^^________ Isn't this zero ?

R.W.

Look at the parentheses. The line wrap is in a bad spot, look past that.

If you think naming is unimportant, then presumably you wouldn't have any problem if -Wall was actually named -Wmarshmallow

Ah, the old "it is only a symbol which means what I want it to mean, no more no less" contention.

That's reasonable if you are only talking to yourself and your acolytes, but is discourteous (at best) when you expect to have a wider audience. Fundamentally everything you write should be for your audience's benefit not for your benefit. The meaning of "-Wall" clearly violates that principle.

And I think that most people would be significantly mislead by the -Wall name. Clearly at least one experienced person (Tim Wescott) /was/ misled.

"all" should mean "all", not "some bits of"

My suspicion is that it meant "all" in an earlier version of gcc, and then new warnings got added which annoyed -Wall users from the older versions, so they kept it meaning about what it did before. I have no inside info about this though. I agree it should be named something different, like maybe -Whigh for high level of warnings but not necessarily everything.

I am the same. The Makefile is part of the source code, and compiler flags go in there (as well as details of exactly which compiler toolchain to use, and everything else needed for the build). Makefiles fit nicely in the source code repository. I truly hate it when someone puts all the details in the AVR Studio project file, or similar incomprehensible and non-portable files.

Yes, you need good reason for that. Sometimes you /have/ good reason, such as significant differences in programming style between your own code and third-party code such as an RTOS or network stack. But such things should be kept to a minimum, and clearly labelled. If you need a small change to options, such as a particular piece of code that triggers some of the warnings you normally enable, then I like that special case to be a pragma in the source code.

I have not heard anyone argue that unit tests will spot differing command-line arguments, merely that they will check the functionality of the code. But people who really understand unit testing also understand its limitations - it is an aid to code checking, but it is a complement to other methods (such as coding standards, static error checking, code reviews), not a replacement. Testing can prove the presence of bugs, but it cannot prove their absence.

That's plausible and sensible.

I have considerable sympathy with the concept of not breaking previous makefiles when the compiler inevitably changes. That would be a problem whatever name is chosen for an aggregate set of flags.

But then the requirement for an ever increasing number of compiler flags is an "orange flag" (ho ho) that something is seriously amiss with the language and/or compiler implementation.

The compiler is doing more and more static analysis of the code to find possible errors. This is a good thing, but it means more false positives that people want to turn off. You might like this article, about the Coverity static analyzer:

I disagree -- Gnu has always maintained that you don't need lint, you just need to turn on lots of compiler warnings. I like that idea.

My mistake was thinking that -Wall would do it.

I think they should depreciate it, in stages -- first put it in the manual, then a few versions down the road fire off a command-line warning (with no generated error) for using it, then a few versions down make the compiler exit if -Werror is set, then finally just don't recognize it.

Replace it with -Wrecommended, or -Wlevel0, 1, 2, etc.

I like the idea, but the in practice the warnings have grown like a cancer. Gcc is neither the cause of the problem nor uniquely affected by it.

Consider (with my *emphasis*) one 4.9.3 example: -Wsequence-point Warn about code that *may* have undefined semantics because of violations of sequence point rules in the C and C++ standards. ... Some more complicated cases are *not* diagnosed by this option, ... but in general it has been found *fairly* effective at detecting this sort of problem in programs. The *standard* is worded *confusingly*, therefore there is some *debate* over the *precise meaning* of the sequence point rules in subtle cases.

That is an accurate summary of the built-on-sand starting point, and the response is the very imperfect - although helpful and probably about as good as can be achieved in the circumstances.

Seems sane and preferable, but I doubt it will happen.

That sounds like a problem with the C standard not with gcc. gcc's goal is to be the best compiler. What are they supposed to do, give up and go home because of a potential C standard ambiguity?

It seems perfectly reasonable (and useful) to have available a diagnostic for cases like this.

We seem to be agreeing with each other.

Oh yes. Well that's all right then!

Carry on... :)

Ok, i'll dip in here :-)

Over the years, gcc has added a whole load more diagnostic capability. Seems to me partly because of the growing number of architectures supported, which leads to design input from many more people, some of whom may have conflicting agendas, but also to provide a more fine grained fault analysis. It's also much more complex and won't even build without the inclusion of other obscure math library sources, for example. You could build gcc 2.7 vintage with little more than a stock host compiler, make and ld, but you need a whole load of gnu infrastructure in place these days just to get it to build at all. I guess the point is that you really can't expect to get consistent results from such a complex product without putting some effort into understanding what the various flags mean, what the optimisations do and don't do etc. For embedded work, looking at the asm output to see if it's what's expected is routine here as well, at least until i'm confident about the capabilities.

There's a tendency to become complacent, as we get familiar with tools and processors, to assume that we never have to read the manual any more. May have worked in the past, but not any more. Just as you have to read the manual to access the more obscure capabilities of modern digital scopes over the older analog types, for example, same with the software tools.

As for -Wall, no problem so long as I know what it means...

Regards,

Chris

Ah, but how can you really be sure that it means what you think it means, especially if it varies between compiler releases :)

It varies in that it gets better, for most users, between releases - checks get added to -Wall if they have very few possible false-positive cases and don't add significantly to the compile time (some people like to run quick "-O0 -Wall" passes for rough error checking on big projects).

But for details, as always when you change compiler versions you should read the release notes. gcc publish pretty good release notes, as do most gcc "vendors" such as the ARM-maintained "gcc-arm-embedded" that many manufacturers use as their base, and CodeSourcery (the other favourite base). And the gcc documentation gives a nice clear list of exactly what is in -Wall.