Dude, you are wierd.  Perhaps you need to up the dosage on your
anti-paranoia 
medicine.

	The "proper way" meant the way that keeps the compiler from throwing
warnings 
when strict checking is turned on.  I never said there was an
"improper" way.  

	--jc

On Tuesday 02 December 2003 12:16 pm, microbit wrote:
>  ----- 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

Hi,

> > 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 used e. g. sprintf(foo, "%u", bar)  (for unsigned int) and e. g.
sprintf(foo, "%hu", bar)  (for unsigned short int) and no version
worked
although no warnings/errors where produced and although the length modifier
h and the conversion specifier u  in the conversion specification
are defined in the ANSI standard! As a workaround for icc430 i'm only using
the working conversion specifiers d and s.

Because the sscanf from icc430 does nothing i had to use separate arrays and
other functions like atoi for scanning parts of strings. It's ugly but this
works and is better than a not working sscanf.

Another bug is that inside a typedef struct a union has to have a name for
the icc430; the MS-Visual C++ does not have this bug.
As a workaround i'm using the same header files but with many ifdef _WIN32
and unnessisary union names.

I'm sure there are dozens of other bugs and ANSI incompatibilities in
icc430
but i didn't used a compiler test suit.

Rolf F.

Hi,

8 is the correct answer on a 16 bit processor with word alignment.  Amongst
other things, sizeof() is used to define the storage requirements so you can
index and array correctly using pointer math or assign enough memory for
'n'
elements.

I have had to deal with passing data between an 8bit and 16 bit processor
where an odd structure size was rounded up on the 16 bit processor so you
can't expect to disengage your brain and have the toolset do all your
thinking for you.

Regards,

Ray
  -----Original Message-----
  From: R. F. [mailto:rolf.freitag@rolf...]
  Sent: Wednesday, 3 December 2003 2:05 AM
  To: msp430@msp4...
  Subject: Re: [msp430] C language tools to use with MSP430 or ...


  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.


        




  .



  

I agree with Raymond.  Though not an ANSI guru, I know from many 
years of using various C compilers on different platforms that the 
compiler is given latitude in internal structure alignment.  From 
my "ANSI C: A Lexical Guide":

"The members of a structure are stored sequentially. ... Aligning 
bytes may not be inserted at the beginning of a struct, but may 
appear in its middle, or at the end.  For this reason, it is 
incorrect to assume that any two members of a structure abut each 
other in memory."

The "pack" #pragma was a big deal in TurboC 2.0 or 3.0, IIRC.  :)

Lee

--- In msp430@msp4..., "Raymond Keefe" <ray@b...> wrote:
> Hi,
> 
> 8 is the correct answer on a 16 bit processor with word alignment.  
Amongst
> other things, sizeof() is used to define the
storage requirements 
so you can
> index and array correctly using pointer math or
assign enough 
memory for 'n'
> elements.
> 
> I have had to deal with passing data between an 8bit and 16 bit 
processor
> where an odd structure size was rounded up on the
16 bit processor 
so you
> can't expect to disengage your brain and have
the toolset do all 
your
> thinking for you.
> 
> Regards,
> 
> Ray
>   -----Original Message-----
>   From: R. F. [mailto:rolf.freitag@d...]
>   Sent: Wednesday, 3 December 2003 2:05 AM
>   To: msp430@msp4...
>   Subject: Re: [msp430] C language tools to use with MSP430 or ...
> 
> 
>   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.
> 
> 
>         
> 
> 
> 
> 
>   .
> 
> 
> 
>   Your use of Yahoo! Groups is subject to the Yahoo! Terms of 
Service.
> 
> 
> 

Ing. Morra Antonio wrote:
> Sorry, it was not my goal to arise such a debate
on the "quality" of the C 
> compilers.
> In my company we choose the IAR compiler and we do find it a good tool.
> There were not any other serious tools at the moment we needed to start 
> serious work.
> In my opinion this is a strong point in favour of it anyway. The new 
> version does improve on a number of features, including 64 bit floating 
> point numbers, which we need for a number of applications (despite what 
> someone thinks in this forum).

;@}

> Cost is always an issue, of course, so I
can't say if we would make the 
> same choice today that a number of good compilers are available from other 
> vendors.
> Also I do know that it (IAR) has some language "strong checking"
capabilities.
> 
> But what I wanted to explore is whether,  in the experience of the people 
> here, a LINT checker, and a version control application software, can be of

> help or not.
> Possibly, to know in which specific way such software can be of help.
> Also ... if there are free versions or trial versions to test, before we 
> make a purchase.
> Or .. get to know that such tools simply are not considered useful enough 
> by this specific MSP430 developer community.
> 
> This is not to say that the (somewhat mis-targeted) debate on my first 
> question was useless, it gives a good idea of how strong the opinions are, 
> among us firmware engineers!
> 
> Regards
> A.M.
> 
> 
> 
> .
> 
>  
> 
> ">http://docs.yahoo.com/info/terms/ 
> 
> 
> 

Sorry, it was not my goal to arise such a debate on the "quality"
of the C 
compilers.
In my company we choose the IAR compiler and we do find it a good tool.
There were not any other serious tools at the moment we needed to start 
serious work.
In my opinion this is a strong point in favour of it anyway. The new 
version does improve on a number of features, including 64 bit floating 
point numbers, which we need for a number of applications (despite what 
someone thinks in this forum).
Cost is always an issue, of course, so I can't say if we would make the 
same choice today that a number of good compilers are available from other 
vendors.
Also I do know that it (IAR) has some language "strong checking"
capabilities.

But what I wanted to explore is whether,  in the experience of the people 
here, a LINT checker, and a version control application software, can be of 
help or not.
Possibly, to know in which specific way such software can be of help.
Also ... if there are free versions or trial versions to test, before we 
make a purchase.
Or .. get to know that such tools simply are not considered useful enough 
by this specific MSP430 developer community.

This is not to say that the (somewhat mis-targeted) debate on my first 
question was useless, it gives a good idea of how strong the opinions are, 
among us firmware engineers!

Regards
A.M.

Just for your info, there is a opensource lint available:
http://www.splint.org/

        Matthias

> > 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)!!!

Actually, from my reading of the ISO standard, a compiler can do what it
jolly well pleases when packing a structure and thus different compilers
for the same architecture can return different values for the size of
the same structure.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430 and ARM processors 

On Fri, 5 Dec 2003 16:38:50 -0000, Paul wrote:

>> > 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)!!!
>
>Actually, from my reading of the ISO standard, a compiler can do what it
>jolly well pleases when packing a structure and thus different compilers
>for the same architecture can return different values for the size of
>the same structure.

It can also do what it jolly well pleases when casting an
unsigned int to a signed int, if the magnitude of the value
being assigned is outside the positive extent of the signed int.
Like deciding to generate a random number in that case, for
example.  (ISO/IEC 9899:1999(E) 6.3.1.3)  Negative zero integers
are also permitted.

Luckily, consumer pressures keep most of those weirdnesses in
the closet and not in the products.

Sounds like IAR is using word alignments, so that 16-bit values
are aligned on even address boundaries.  Do you think that the
case here?  And would there be a rational argument for this, if
so?

Jon

Jon,

> On Fri, 5 Dec 2003 16:38:50 -0000, Paul wrote:
> 
> >> > 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)!!!
> >
> >Actually, from my reading of the ISO standard, a compiler 
> can do what 
> >it jolly well pleases when packing a structure and thus different 
> >compilers for the same architecture can return different 
> values for the 
> >size of the same structure.
> 
> It can also do what it jolly well pleases when casting an 
> unsigned int to a signed int, if the magnitude of the value 
> being assigned is outside the positive extent of the signed 
> int. Like deciding to generate a random number in that case, 
> for example.  (ISO/IEC 9899:1999(E) 6.3.1.3)  Negative zero 
> integers are also permitted.
> 
> Luckily, consumer pressures keep most of those weirdnesses in 
> the closet and not in the products.
> 
> Sounds like IAR is using word alignments, so that 16-bit 
> values are aligned on even address boundaries.  Do you think 
> that the case here?  And would there be a rational argument 
> for this, if so?

The rationale is that the ANSI standard *only* specifies bit packing
with unsigned int and signed int types, nothing else.  Thus, bitfields
are required to be packed into the natural size of an int, usually the
processor word size.  You can argue, however, that using "signed int"
and "unsigned int" with field widths of 3 and 5 is no different from
using "signed long" and "unsigned long" with field witdhs of
3 and 5.
The fact is, you're still asking for *only* 3 and 5 bits of information
so the compiler *could* pack all that into a byte and it would be
*transparent* at the C level.  Are you with me on this?

Thus, you could argue that a structure is allocated like this:

struct {
  TUINT8 lP;     // byte 0
  TUINT8 lW;     // byte 1
  TUINT8 lT;     // byte 2
  TUINT16 te:5;  // bits 7-3 of byte 3
  TUINT16 de:3;  // bits 2-0 of byte 3
  TUINT16 ct;    // bytes 4 and 5
};

So, the structure can be allocated in *six* bytes; the packing into a
word of the two bitfields is *not* necessary.  It's always confused me,
and possibly other people too, what effect the type of a bitfield gives
you other than to denote whether the field is treated as signed or
not--I mean, you're telling the compiler how many bits you need, so
surely it should be man enough to figure it out the optimal pacing for
itself?

I know that people think that using "unsigned char" means "pack
this
into a byte" and "unsigned long" usually means "pack this
into a 32-bit
word", but, well, both "unsigned char x : 3" and "unsigned
long x : 3"
are *beyond* the ANSI standard and are *not* defined by it.  Such
constructs are noted as extensions to the ANSI standard by CrossWorks.

Regards,

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430 and ARM processors