Re: Translating an embedded C algorithm -- OT

[Cesar Rabak <csrabak@yahoo.com.br>]

Maciej Sobczak escreveu:
> Cesar Rabak wrote:
> 
>>>> if (a = 1) {
> 
>>>> if (a == 1) {
> 
>>> No need for separate tools, gcc -Wall issues an informative warning.
>>> And you do compile with -Wall, right?
>>>
>> Not all C code is compiled [only] with gcc...
> 
> If you use another compiler and it does not provide the functionality 
> that you have for free from gcc, you should certainly report this 
> complaint to the vendor.

It is arguable something to try but not a thing the vendor would be 
obliged to.

> 
> More to this, if you are at least moderately serious about robustness of 
> your code, I'd expect that you compile it (or at least its isolated 
> critical parts) with a *set* of compilers (the fact that gcc is free 
> makes it an easy candidate) to get as much feedback as you can. 

With embedded work this approach brings a lot of problems on the side. 
If you work for a rich enough company that can afford more than a vendor 
for the compiler, the problems are bearable, but even so many (most of 
them on non standard header names and so on).

Attempting to check C source code intended for some MCU with hosted 
compilers (ca. 15 yrs ago the company I worked had some guys that tried 
that using Turbo C) opens a can of worms about the header files and the 
constants, macros, etc.

In the last chapter of a soap opera, management had to forbid due the 
ammount of #ifdefs in code and vendor supplied files.

Then (PC) Lint came to scene!

> Preferably on a regular basis, nightly build or such.
> 
> If your working environment is so constrained that you don't even run 
> noghtly builds on a set of compilers, you can always write a simple 
> Perl/Tcl/Python/awk/grep/whatever script that will highlight such 
> constructs - just look for if and = that comes in the subsequent pair of 
> parentheses.

For that single one, yes, for a lot of idiomatic symptoms worth looking, 
in a moderate size shop buying some licenses for lint or using LCLint 
(a.k.a. Splint) which is FOSS, is better.

> 
> Note also that in C++ the above constructs are both legal provided that 
> the following two are true:
> 
> 1. assignment operator returns something ...
> 2. ... that is implicitly convertible to some fundamental type.
 >
 > These two points already give you many opportunities to guard against
 > such mistakes.
 >

OK. But C++ in embedded work still is not as widespread.
> In general - I totally understand your points, but I don't count them as 
> showstoppers.

I agree. The showstoppers belong to the management [dept.]!

> 
> And coming back to Ada - can you believe that when I write Finalise 
> instead of Finalize, it is legal but does not do what I want? 
> Unbelievable. Any compiler options for this? ;-)

Yes. Sinc I'm a non native English speaker I _do_ know what you're 
writing about!

> 
> (I know - in some future I will be able to enjoy the override keyword.)
> 

Probably sooner than you might expect!