Does anybody learn C any more?

[SiliconWizard]

I think is required in most "safe C" rules such as MISRA-C

In avionics, we have to pass external tools' validation.

Of course. The "zero warning" policy is a general rule. Warnings may be issued from external tools, and/or from compilers. Same policy.

External tools will usually detect a lot more than the compilers, but conversely, in case the compiler detects a problem that the other tools didn't (which admittedly would be a rare event), the code should still be rejected.

As to using UTF-8 *inside* source code files, I'm against it, until I change my mind. Maybe someday. It's too slippery still. Only tolerated use is inside comments, but still not too fond of that.
Dealing with UTF-8 inputs and outputs, yes! But editing your source code as UTF-8, nope. Two very different things. It may look cute, but poses a number of problems in practice.

What it means is that the only acceptable UTF-8 litterals, to me, are UTF-8 codes inserted in numeric form, as I gave an example for above. Of course it's mainly just for often-used symbols that don't exist in ASCII, not full sentences!

Full sentences should not be written as litterals anyway IMO. Most cases for them are for words/sentences in various natural languages. There is a potential need for translating them, so putting those directly as litterals is not that great an idea. Or, the default language should be English. I know it's biased, but we deal with it and move on.

Just my 2 cents.

[legacy]

Of course. The "zero warning" policy is a general rule. Warnings may be issued from external tools, and/or from compilers. Same policy.

External tools will usually detect a lot more than the compilers, but conversely, in case the compiler detects a problem that the other tools didn't (which admittedly would be a rare event), the code should still be rejected.

QA guys do not use the C compiler, it's not their job. They check the source with external tools, which have been certified for the validation. Those things are very expensive, usually 50K euro per license, so bugs inside the validator are *(1)supposed to be* very very rare.

The developing squad does use the C compiler and ... well ... it's a policy that Adamulti rejects the source if there is a single warning (-wall), but this is not considered by QA guys.

The testing squad does also use the C compiler, and "-wall" usually means something smalls bad, so the code is not rejected but re-addressed to some senior Engineer to have some word about it.

Anyway, what actually makes a code passed is the QA-tool, plus a signature on the test-report, plus someone (usually the team leader) who sign the commit with his name.

Moral of the story, it's not a formal rule, but "-wall" statistically does not pass


edit:
(1) fixed

[legacy]

only acceptable UTF-8 litterals, to me, are UTF-8 codes inserted in numeric form

Just checked: the DDE's C compiler does accept it, and the result (size(msg)-1) is now correctly shown by RISC OS Adjust. So it was something in the DDE ecosystem that - between what you type and what the compiler sees - didn't correctly understand the input.

Funny. Thanks for the tips! 

[coppice]

As to using UTF-8 *inside* source code files, I'm against it, until I change my mind. Maybe someday. It's too slippery still. Only tolerated use is inside comments, but still not too fond of that.

Huge numbers of developers don't know English very well, and comment their source code in their mother tongue. You may not like source code being regarded as UTF-8, and the C spec may say its not valid. However, you are going to have a real hard time convincing someone whose English is poor to make their source code ASCII, when UTF-8 is working just fine for them.

[magic]

I'm actually not sure if C spec has anything against UTF-8 in comments. If it does, it probably also prohibits Windows-125x, ISO-8859 et al. Guess what, I have never seen a compiler which enforces that

[SiliconWizard]

I'm actually not sure if C spec has anything against UTF-8 in comments. If it does, it probably also prohibits Windows-125x, ISO-8859 et al. Guess what, I have never seen a compiler which enforces that

I didn't say there was. I just said I'm not fond of them. And yes, any compiler (unless it's a real dinosaur that rejects > 7-bit characters) will gladly just ignore them. UTF-8 or any 8-bit charset.

I'm not fond of comments in UTF-8 because they imply editing the source code as UTF-8, which in turn can be an incentive to use UTF-8 outside of comments. That's my rationale behind it, no editing in UTF-8.
One of the reasons being that opening an UTF-8 encoded file in an editor not supporting it can break everything badly in some cases. And shit happens. Another is that, outside of comments, using UTF-8 identifiers, for instance, could be an enormous disaster for code readability. I'm not even sure this is supported by C compilers, but if it ever becomes so, ouch. And yes I know it's not fair to people with languages using non-latin letters, but we have enough problems with software engineering as it is.

Windows-125x, ISO-8859 etc. charsets are a different beast. Opening the files in any editor will not break anything. You may just not see some characters as intended, but saving the files will NOT change them (unless the editor is very broken.)

Just of course my approach. As I said, I may change rules when UTF-8 becomes more ubiquitous and supported in a clear fashion in all the programming languages, and code editors, that I'm confronted with.

[SiliconWizard]

QA guys do not use the C compiler, it's not their job. They check the source with external tools, which have been certified for the validation. Those things are very expensive, usually 50K euro per license, so bugs inside the validator are *(1)supposed to be* very very rare.
(...)

Just a few thoughts about what you said. By no means are they hard truths, just my (and those of some teams I've worked with) opinion/rules/habits. I know every field, and potentially every company in each field, has a different approach and different policies.

- I think this would be a mistake that QA teams only deal with source code, and not with the build tools, and the artefacts of the builds, which are every bit as important to check. So in that matter, QA people not even looking at the result of building steps is not fully right IMO. Ultimately, the build artefacts end up in the final product, not source code. So the whole chain is important.

- You didn't exactly say that, but if you think this would rather be a job for the test teams, I don't quite agree with that. Test teams are for testing. Not for checking that the object code/binaries/whatever (the artefacts) are correctly built or if there are any message from the tools. I'd think it would be more of a job for QA. Of course this is just an organizational detail, but it's important regarding who is taking responsibility for what, or who even looks at what...

- Compilers and build tools in general are not just used by developers/engineers. They are ultimately used for the builds that are tested and eventually become released. So it would be a mistake that only engineers care about them and their outputs, as said above.

- Regarding source code only, no tools, however expensive they are, are perfect. So combining checks from different tools, including, why not, the compilers themselves, is always a good idea. Don't put all your eggs in the same basket.

- I again don't tolerate ANY warning from compilers and build tools in general. I've just checked in the MISRA-C recommendations, and it's not really even mentioned actually (I think it's more of a commonly seen company policy). But I think this is an important rule to enforce. Writing code that emits no warning at all from compilers is NOT hard, and leaving warnings, even if they are checked by someone at some point, is never a good idea. You end up having them pile up and unable to see which are false flags and which may be critical.

- Regarding the above point, you may think that expensive analysis tools run before builds can catch everything a compiler will and much more. As I hinted earlier, most often this is true, but in some cases, it may not. And when it happens, it's never, IMO, a good idea to just ignore what the build tools say, because you know, they must all be much dumber than the tools you spent an arm and a leg on. For the reasons mentioned above, and also for an additional one: even for perfectly conforming code, a given compiler could be issuing a warning that thus would seem a false flag, but could be an indication that said compiler sees some piece of code as ambiguous or problematic and could compile it incorrectly, maybe because the compiler itself has a bug or an implementation-defined behavior that is not caught by your expensive tools. So warnings should never be ignored IMO. You may be biased by your experience of using maybe almost exclusively certified compilers that have a very very low probability of exhibiting what I just said, but that's not always the case in all settings...

- Finally, and I know those expensive tools are REALLY f*cking expensive, but I still think it's a good idea that developers have access to them on a regular basis, and not just QA guys. That saves a lot of time and tremendously helps them get better. You don't need to have a license for each workstation. You can have one on a server and have it run on a regular basis on commited code (like several times a day), which not only makes engineers get better at what they do, but also saves a lot of time for everyone including QA people.

* Just a side comment regarding GCC warning flags:
Contrary to what it looks like, the -Wall option doesn't quite enable ALL warnings. For instance, last I checked, GCC with -Wall was not enabling the -Wconversion check that you have to enable as an additional option. This check is especially important when writing embedded code. (Very recent versions of GCC may have changed this, but I'm not sure they have, probably because it would suddenly spit out a LOT of warnings for existing code with sloppy conversions...)

[legacy]

I didn't say there was. I just said I'm not fond of them. And yes, any compiler (unless it's a real dinosaur that rejects > 7-bit characters) will gladly just ignore them. UTF-8 or any 8-bit charset.

put { SierraC/68k, Avocet/68k, MIPS/Pro } in the list 

[westfw]

Contrary to what it looks like, the -Wall option doesn't quite enable ALL warnings.

-Wextra adds a bunch more.

[legacy]

Among the QA-squad, there are ATL-guys, who are literally beyond any language except math and they usually address their attention to how an error does propagate, how the software has been proved by facts to fail when it's supposed it has to fail in abnormal conditions...  and all whistles and bells they can read from the test-report and from their tools.

For the whole QA team, the test-report is more interesting than any source code, as well as the ATL-modelling is more interesting than the C or Ada implementation, while their colleagues usually care about approving *how* a piece of code is tested, and if all constraints and requirements have been properly tested. They also check if a piece of code has passed everything, the most interesting feedback from them is: "it's ok, but ... this piece of code has measured too much *cyclomatic complexity*, so .. it shall be rewritten".

-

For a reason or for another both the dev-team and the test-team have to re-compile the project and if some line of C issues a warning then we both usually looks for a senior for some word about.

Seniors are the highest authorities of competence in both test and dev teams. And the brain-storming is managed as internal and informal feedback since the two squads are not decoupled but rather part of the same software life-cycle.

So, before someone wants to commit the project and the test-report to the QA-team, feedbacks from the dev-team to test-team, and vice versa, are more than welcome. It's also a good way to perform team-working since both teams learn something.

A completely different matter is when you commit something on Doors because this way it's exposed to the customer's QA.

We also receive internal feedback from the QA team, but ... they are at a higher layer: they are usually related to the software design and modeling, so more addressed to the dev-team, unless the test-team finds a serious problem, which usually sounds like "guys? that feature is great, but ... how can we test it?".

It's a rare event, but when it happens we have a super meeting with all the three teams 

For discussing things, and sometimes even ATL guys do participate because some of them are involved with the purchase of new developing/testing tools.

[SiliconWizard]

Contrary to what it looks like, the -Wall option doesn't quite enable ALL warnings.

-Wextra adds a bunch more.

Indeed. Note that it doesn't enable -Wconversion either though.

https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options

[Karel]

- I again don't tolerate ANY warning from compilers and build tools in general. I've just checked in the MISRA-C recommendations,
and it's not really even mentioned actually (I think it's more of a commonly seen company policy). But I think this is an important rule to enforce.
Writing code that emits no warning at all from compilers is NOT hard, and leaving warnings, even if they are checked by someone at some point,
is never a good idea. You end up having them pile up and unable to see which are false flags and which may be critical.

I couldn't agree more     ... and I use always these flags: -Wall -Wextra -Wshadow -Wformat-nonliteral -Wformat-security -Wtype-limits

[Nominal Animal]

I'm ambivalent on some warnings.  The one that comes to mind is unused parameter, which bugs me when using three-parameter signal handlers (as the third one is usually not used).  For Linux-specific code, or code compiled only using gcc or compatible compilers, I tend to use __attribute__((unused)) (via a macro, usually), but for portable code, I tend to disable the warning instead (-Wno-unused-parameter).  I would prefer there to be a portable unused parameter attribute, at it'd make it clear to the human programmer (and not just the compiler) that the parameter is intentionally unused.

I like to avoid defined but unused function warnings for accessor functions by declaring them static inline instead of static.  Since these accessor functions tend to be trivial, telling the compiler that inlining these functions is desirable, does no harm.  (You can use -Wno-unused-function instead to suppress the warning, but I never do.)

In all cases, I do not like leaving any warnings visible when compiling.  Just the way I address certain warnings vary.  I always use at least -O2 -Wall, sometimes -O2 -Wall -pedantic -std=c99 (or -std=gnu99 for Linux-specific stuff, using built-ins), or -O2 -Wall -Wextra.

[SiliconWizard]

I'm ambivalent on some warnings.  The one that comes to mind is unused parameter,

I agree. I rarely enable this one. That's why I don't use -Wextra with GCC - most of the added warnings, I find not very useful, except the '-Wsign-compare', that I add manually. Of course your own use case/environment may differ. I think some safety-critical software guidelines, for instance, require a "no unused parameter" policy, so if you have to follow that, you have no choice. The idea behing that is debatable, but it's not stupid either.

The standard way of dealing with it would then be to enable the "unused parameter" warning/rule. And in functions not using all their parameters (on purpose), you have to explicitely mark the ones that are unused to shut up the warning. It's annoying, but can make sense to make sure you did that ON PURPOSE.

To mark an unused parameter or local variable, the standard C way is adding a statement like so:

Code: [Select]

(void) xxx; with xxx being the local variable or parameter.
You way encounter source code that defines some macro such as: UNUSED_PARAMETER(xxx) or something like that, to make it clearer, but all they translate to is the above (and then there's often a rule not to replace standard C constructs with macros in safety-critical code anyway... so I don't recommend using a macro for that.) There are also compiler-specific attributes, as you mentioned, that I don't recommend either as they are non-standard. A cast to void works, and it's standard! (Even if it looks funny.)

The set of warnings I enable most often with GCC for C code is: '-Wall -Wconversion -Wsign-compare'

Of course, using additional static analysis tools is also very useful - even when you're not strictly REQUIRED to!
There are many out there. Open-source and actively maintained ones, while being easy to use, are: CppCheck and clang-check. I often use both. CppCheck is not bad and pretty fast. clang-check is slower but will catch more subtle potential problems. Of course there are commercial and expensive tools that do better, but unless you/your company can afford them and/or MUST use them, you'll have to stick to the free ones.