Put in my 2 cents worth too I guess.

> It really is not the fault of the compiler if you
are allowed to write "if 
> (a = b)", after all that is not an illegal C statement.  It's
immoral but 

I don't see what the big deal is.
Although hardly needed, it's not _that_ weird to do an assignment within an
IF statement !
And if I did, the compiler bleating about it would just jack me off anyway...

If I'm worried that I'll stuff up the IF with literals eg. I'll
write it this way :

if (  LITERAL == _foo_ ) ......
instead of 
if ( _foo_ == LITERAL ) ....

If I then type "=" instead of "==", the compiler will give
an assignment error.

I really don't see what the fuss is about, seems the first to bag high end
tools are the ones that don't have them...
I use CrossWorks for MSP430 because of its far superior GUI/IDE, but the 3 years
before that I used IAR EW430, 
and it _always_ had been a very, very dependable compiler I had to rely on to
literally earn my crust with.
What more can you want ?

It seems pathetic to compare free tools with high-end tools.

-- Kris

Hello,

for the people who get interested:

where is more infor to find about LINT?
who sells LINT?

best regards

D vd E

>From: "Tamarack Eng"
<tamarack_e@tama...>
>Reply-To: msp430@msp4...
>To: msp430@msp4...
>Subject: RE: [msp430] C language tools  ... Get Lint
>Date: Tue, 02 Dec 2003 08:00:05 -0600
>
> >What tools are you using together with a C compiler, to keep track of
> >versions and the like?
> >Also are you using a program checker like LINT  ?
>
>After reading several responses, I have to strongly recommend anyone who is
>writing C code to get Lint.  For those that do not know about it, it is a
>super compiler that does not generate any code - it just checks the code 
>for
>potential errors.  Lint has saved me many times.  I can detect if a 
>variable
>has not been initialized, or not used, or used in an odd way.  Lint can be
>tailored to run as strict as you like, even down to the level of reporting
>incorrect indent levels.
>
>It really is not the fault of the compiler if you are allowed to write
"if
>(a = b)", after all that is not an illegal C statement.  It's
immoral but
>not illegal.  So if a compiler lets me do strange things, I have to 
>conclude
>it is letting me write C code, and C is the problem not the compiler.
>Having said that, Lint can be configured to be the most picky compiler you
>ever saw, catching just about everything except spelling mistakes in quoted
>strings :-)
>
>Get Lint.
>
>I currently use an older version of PVCS for version control and I am in 
>the
>market for a new but affordable version control program.
>
>Lou
>
>_________________________________________________________________
>Need a shot of Hank Williams or Patsy Cline?  The classic country stars are
>always singing on MSN Radio Plus.  Try one month free!
>http://join.msn.com/?page=offers/premiumradio
>

_________________________________________________________________
Play online games with your friends with MSN Messenger 
http://messenger.msn.nl/

The "proper way" to do an assignment within an if() statement is

	if ((a = b)) { ... }

This will cause smart compilers to not throw warnings (such as GCC).  And if 
you're using GCC without the -W -Wall switches, you're short changing 
yourself.  Lint is an excellent program, but you can get the compiler to do 
most of the work for you, for free.  

Because I frequently mistype, I use fairly agressive error checking.

It's also very wise to use ()'s around #define elements, more so the
ones that 
use compile time calculated constants.  This helps prevents order of 
evaluation errors when used in an expressions.

#define SECTOR_SIZE 128
#define SECTORS_PER_TRACK 26
#define TRACKS_PER_DISK 80
#define DISK_SIZE (SECTOR_SIZE * SECTORS_PER_TRACK * TRACKS_PER_DISK)

	--jc

On Tuesday 02 December 2003 09:18 am, microbit wrote:
>  Put in my 2 cents worth too I guess.
>
>  > It really is not the fault of the compiler if you are allowed to
write
>  > "if (a = b)", after all that is not an illegal C
statement. It's
>  > immoral but
>
>  I don't see what the big deal is.
>  Although hardly needed, it's not _that_ weird to do an assignment
within
> an IF statement !
>  And if I did, the compiler bleating about it would just jack me off
> anyway...
>
>  If I'm worried that I'll stuff up the IF with literals eg.
I'll write it
> this way :
>
>  if ( LITERAL == _foo_ ) ......
>  instead of
>  if ( _foo_ == LITERAL ) ....
>
>  If I then type "=" instead of "==", the compiler will
give an assignment
> error.
>
>  I really don't see what the fuss is about, seems the first to bag
high end
> tools are the ones that don't have them... I use CrossWorks for MSP430
> because of its far superior GUI/IDE, but the 3 years before that I used IAR
> EW430, and it _always_ had been a very, very dependable compiler I had to
> rely on to literally earn my crust with. What more can you want ?
>
>  It seems pathetic to compare free tools with high-end tools.
>
>  -- Kris
>
>
>  
>
>
>
>
> 
>
>
>
>
>
>
>  .
>
>
>
>  

Hi John,

Who said anything about an "improper" assignment ?

I *merely* mentioned doing assignments in an IF statement is not that weird.
(and actually sometimes desirable !)
The point was comparing free tools with high-end tools on points where there
is no merit.

> The "proper way" to do an assignment
within an if() statement is
>       if ((a = b)) { ... }

-- Kris

On Tue, Dec 02, 2003 at 09:41:51AM -0500, J.C. Wren wrote:
> The "proper way" to do an assignment
within an if() statement is
> 
> 	if ((a = b)) { ... }

Or an even better way is

	if((a = b) != 0) {... }


-- 
Clyde Stubbs                     |            HI-TECH Software
Email: clyde@clyd...          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger clyde@clyd...   | AUS: +61 7 3552 7777 +61 7 3552 7778
---
HI-TECH C: compiling the real world.

Hi,

> I just ran this both on 1.26 and on version 2 of
the compiler.  Both
> specifies that the size was 8.

ok, it was untested and the wrong right code, but this is the right wrong
code:

typedef unsigned char TUINT8;
typedef unsigned short int TUINT16;
typedef struct
{
  TUINT8 lP;
  TUINT8 lW;
  TUINT8 lT;
  TUINT16 te:5;
  TUINT16 de:3;
  TUINT16 ct;
} T_M_H_T;
#define T_M_D_T  sizeof(T_M_D_T) // Warning: The IAR compiler calculates 8
(instead of correct 7)!!!

As i said other compilers like the MS-Visual C++ do not have this bug with
sizeof.

Another example is

sprintf("%u", ui);

which produces "%hu" but not printout of the value of ui.

Rolf F.

Hello,

I would suggest Gimpel's PC-Lint. See http://www.gimpel.com for details.

All the best,

Preston Gurd
(AQ430 C compiler guy)

> 
> for the people who get interested:
> 
> where is more infor to find about LINT?
> who sells LINT?
> 
> best regards
> 
> D vd E
> 

	I'm not sure where you're going with this... I do assignments in
if(), 
switch(), and a few others all the time.  What I'm pointing out is that 
strict checking by the compiler is satisfied by the double parens.  Since the 
compiler treats the inner set of parens as a subexpression, the unary result 
is tested by the outer set.

	Someone else just mentioned using

		if ((a = b) != 0) { ... }

	I find that much less readable, in my personal opinion.  Also, the compiler 
should not require that to be happy.  I also don't like 

		if ((a == b) == 0) { ... }

	although I tolerate

		if (!(a == b)) {  ... }

	However, those are simply issues of personal coding styles.  

	--jc

On Tuesday 02 December 2003 09:53 am, microbit wrote:
>  Hi John,
>
>  Who said anything about an "improper" assignment ?
>
>  I *merely* mentioned doing assignments in an IF statement is not that
> weird. (and actually sometimes desirable !)
>  The point was comparing free tools with high-end tools on points where
> there is no merit.
>
>  > The "proper way" to do an assignment within an if()
statement is
>  > if ((a = b)) { ... }
>
>  -- Kris

Hi!

> ok, it was untested and the wrong right code, but
this is the right wrong
> code:
>
> typedef unsigned char TUINT8;
> typedef unsigned short int TUINT16;
> typedef struct
> {
>   TUINT8 lP;
>   TUINT8 lW;
>   TUINT8 lT;
>   TUINT16 te:5;
>   TUINT16 de:3;
>   TUINT16 ct;
> } T_M_H_T;
> #define T_M_D_T  sizeof(T_M_D_T) // Warning: The IAR compiler calculates 8
> (instead of correct 7)!!!
>
> As i said other compilers like the MS-Visual C++ do not have this bug
with
> sizeof.

Ok, where do we begin?  Do you know what alignment is?

Most processors, including the MSP430, has got restrictons on how data
in memory is placed in order to read it.  In our case then data read
using word (i.e. two-bytes) must be placed on even bytes.  If not then
the access would be unaligned.

In this case the three bytes lP, lW, and lT will occupy one byte each.
Then a word will follow containing the two bitfields "te" and
"de",it
must be placed (due the alignment requirements) on an even boundary
from the start of the struct.  So we must insert a pad byte into the
struct.

Finally we add the word "ct".  The total is 8 bytes.

(Note that we would not get seven bytes even if the bytes would be
placed after the words.  Why?  Well, if we would create an array of
structs then they are placed after eachother, and if the size of a
struct would be 7 then the second would be unaligned.)

Also note that if we would mix bytes and words then we could end up
with more than one pad byte.  For example, the following struct has
size *six* since it contains two pad bytes, one after "a" and one at
the
end of the struct.

  struct x
  {
    char a;
            /* <- Pad byte */
    int  b;
    char c;
            /* <- Pad byte */
  };

By simply rearranging the order of a struct the size would be *four*:

  struct x
  {
    char a;
    char c;
    int  b;
  };


Finally, after this crash course in struct layout, we come the the
real question: Is our compiler ANSI compliant.

Yes, this is according to the ANSI standard!  However, that it is
possible that for some other compiler that the layout of the struct
would differ and still correct according to the ANSI standard.  This
is because the standard leave certain aspects open to the
implementation, especially when it comes to bit-fields.  (However,
Visual Studio is not one of them, I just verified that it also
specified size "8".)

And the lesson of today is?  Don't make assumptions on the layout of
the struct if you're using structs containing bitfields.


Oh, well, is that all?  No, if you really (really!) want the struct to
be seven bytes then we provide a mechanism called "pragma pack" that
can lower the alignment (and thus the need for pad bytes).  The
drawbacks, however, are enourmous as it is no longer possible to
access the struct using word instructions.  Instead two byte
instructions must be used.


> Another example is
>
> sprintf("%u", ui);
>
> which produces "%hu" but not printout of the value of ui.


(I just assume that you really meant %hu, otherwise your example
wouldn't make sense.)

I just checked, it runs correctly on both our libraries, unless you
explicitly has selected the smallest printf version in CLib that
deliberately has no support for anything but the most basic things.

    -- Anders Lindgren, IAR Systems

Ps. My appologies to anyone who thinks that this discussion has runed
out of proportion.  You're right -- it has!

--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

----- Original Message ----- 
From: "J.C. Wren" <jcwren@jcwr...>
To: <msp430@msp4...>
Sent: Wednesday, December 03, 2003 2:38 AM
Subject: Re: [msp430] C language tools ... Get Lint


> I'm not sure where you're going with
this...


The point is that you frequently seem litiguous over nothing ....

-- Kris