Normal numbers in, weird numbers out

That is all sane.

One of the bees I have in my bonnet is that everything necessary to comprehend what the compiler is going to do should be in one place, i.e. the source code. (That's based on some truly bizarre things I've seen in some companies!)

I'm prepared to compromise (remarkably :) ) and accept a single global set of command line compiler flags, provided they are treated in exactly the same way as source code, especially w.r.t. changing them. I get very suspicious when different sub-systems have different flags, since the probability of a maintenance engineer understanding everything and getting it right in 5 years time is vanishingly small - even if that engineer is the creator such as me.

Now the non-embedded (e.g. web-based) developers will argue that unit tests are sufficient to detect when command line arguments are wrong. I beg to differ, both for their cases and especially for the embedded systems with stimuli and responses that simply cannot be expressed in a unit test.

Reply to
Tom Gardner
Loading thread data ...

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

Reply to
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.

Reply to
Hans-Bernhard Bröker

We were discussing a loop

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

--
Reinhardt
Reply to
Reinhardt Behm

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

Reply to
Paul Rubin

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

R.W.

Reply to
Roberto Waltman

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

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

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"

Reply to
Tom Gardner

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.

Reply to
Paul Rubin

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.

Reply to
David Brown

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.

Reply to
Tom Gardner

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:

formatting link

Reply to
Paul Rubin

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.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

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.

Reply to
Tom Gardner

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.

[...]
--

John Devereux
Reply to
John Devereux

We seem to be agreeing with each other.

Reply to
Tom Gardner

Oh yes. Well that's all right then!

Carry on... :)

--

John Devereux
Reply to
John Devereux

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

Reply to
Chris

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

Reply to
Tom Gardner

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.

Reply to
David Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.