Reply by Kellogg Dave ●March 31, 20032003-03-31
I have looked at splint superficially. However, I did not see anywhere near
the power that PC-Lint has for inhibiting errors. Comments? 607-656-2597 -----Original Message-----
From: Oliver Betz [mailto:]
Sent: Monday, March 31, 2003 8:19 AM
To:
Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help! Erich Styger wrote:

> PC-Lint is not the same as LC-Lint (http://lclint.cs.virginia.edu),
> but both doing the same thing: static analysis or source code.

LC-Lint is no more LC-Lint but "Splint" http://www.splint.org/

Splint has many problems with the non-ANSI extensions of "embedded"
compilers, e.g. the various "@" qualifiers like @interrupt
or the @<address> construct. #pragma asm / endasm confuses the
parser. You have to hide all this from splint while PC-Lint handles
it.

Another problem I have been reading about is that literal constants
assigned to (unsigned) char results in "Assignment of int to unsigned
char" error. If you cast the literal, not even the compiler can
complain about unsigned char n = (unsigned char)1234; so I would
never do so.

PC-Lint also checks for many Misra rules if you want (there _are_
wise Misra rules) and "cosmetic" issues as wrong indentation.

Oliver
--
Oliver Betz, Muenchen ------------------------ Yahoo! Groups Sponsor ---------------------~--> Get
128 Bit SSL Encryption!
http://us.click.yahoo.com/W7NydA/hdqFAA/VygGAA/dN_tlB/TM
---------------------------------~->

--------------------
">http://docs.yahoo.com/info/terms/

Reply by Oliver Betz ●March 31, 20032003-03-31
Erich Styger wrote:

> PC-Lint is not the same as LC-Lint (http://lclint.cs.virginia.edu),
> but both doing the same thing: static analysis or source code.

LC-Lint is no more LC-Lint but "Splint" http://www.splint.org/

Splint has many problems with the non-ANSI extensions of "embedded"
compilers, e.g. the various "@" qualifiers like @interrupt
or the @<address> construct. #pragma asm / endasm confuses the
parser. You have to hide all this from splint while PC-Lint handles
it.

Another problem I have been reading about is that literal constants
assigned to (unsigned) char results in "Assignment of int to unsigned
char" error. If you cast the literal, not even the compiler can
complain about unsigned char n = (unsigned char)1234; so I would
never do so.

PC-Lint also checks for many Misra rules if you want (there _are_
wise Misra rules) and "cosmetic" issues as wrong indentation.

Oliver
--
Oliver Betz, Muenchen

Reply by Erich Styger ●March 31, 20032003-03-31
PC-Lint is not the same as LC-Lint (http://lclint.cs.virginia.edu),
but both doing the same thing: static analysis or source code.

Erich

> -----Original Message-----
> From: Andrew Lohmann's New Email Server
> [mailto:]
> Sent: Montag, 31. Marz 2003 08:53
> To:
> Subject: Re: [68HC12] Metrowerks Disassembly Obfuscation - Help! > Is that the same as the free LC-Lint? I can't at the moment find
> a link for that, but it's a very tool though I did not find a way
> to redirect (pipe) the output to file. I ran it from a batch file
> - note in only runs in windows as its a 32 bit application.
>
> Has anyone know a better environment for LC-Lint? > Andrew Lohmann AIIE
> Design Engineer
>
> Bellingham + Stanley Ltd.
> Longfield Road, Tunbridge Wells, Kent, TN2 3EY, England.
> Tel: +44 (0) 1892 500400
> Fax: +44 (0) 1892 543115
> Website: www.bs-ltd.com
>
> ----- Original Message -----
> From: Erich Styger
> To:
> Sent: Sunday, March 30, 2003 3:45 PM
> Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help! > yeah, PC-lint is a real good thing.
> Found glitches in the source code with it which are hard to
> find otherwise.
> The plugin for PC-Lint is delivered with CodeWarrior too: just set the
> linker to 'pclint linker' in the project preference panel and you
> can use it as a front end to PC-Lint.
>
> Erich
>
> > -----Original Message-----
> > From: Kellogg Dave [mailto:]
> > Sent: Samstag, 29. Marz 2003 16:26
> > To: '
> > Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> >
> >
> > In addition to enabling all warnings, I use PC-Lint
> > (www.gimpel.com). It is
> > very configurable and much more picky than a compiler. One of
> > its strengths
> > is that it can look across multiple modules. Recommended. It
> > has saved me
> > several times.
> >
> >
> > 607-656-2597
> >
> >
> > -----Original Message-----
> > From: Karl Lunt [mailto:]
> > Sent: Thursday, March 27, 2003 2:39 PM
> > To: '
> > Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> >
> >
> > Also, turn the warning level all the way up. This means enable every
> > warning that the compiler can produce. If your code still
> > compiles without
> > warnings, you are more assured of having created very clean code.
> >
> > (Naturally, there are some execptions to the above. For example, some
> > compilers might gen a warning over formatting issues on otherwise
> > perfectly
> > good code; your mileage will vary.)
> >
> > Karl
> >
> >
> > > -----Original Message-----
> > > From: Mike Burgess [mailto:]
> > > Sent: Thursday, March 27, 2003 11:19 AM
> > > To:
> > > Subject: Re: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> > >
> > >
> > > Paul,
> > > Usually compile warnings are not useless, you should try at
> > > all cost to
> > > write code that
> > > does not produce warnings. As was the case with your
> > > integer. Sooner or
> > > later
> > > what you thought was useless warnings will come back to haut you.
> > >
> > >
> > > Michael.
> > >
> > >
> > > ----- Original Message -----
> > > From: "Paul Johnson" <>
> > > To: <>
> > > Sent: Thursday, March 27, 2003 9:52 AM
> > > Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> > >
> > >
> > > > Hi Erich,
> > > >
> > > > I could follow the common code optimization, and that makes
> > > sense -- it
> > > was
> > > > the BSR -1 that really confused me. I generated this code by
> > > right-clicking
> > > > in in the editor window (in CodeWarrior) and selecting
> > > "Disassemble". I
> > > did
> > > > not see any errors related to this, so I assume it was displaying
> > > > incorrectly but linking correctly.
> > > >
> > > > The actual problem that had me on my hands and knees
> > > pouring through the
> > > > assembly code was a much more subtle bug. Every function
> > > in the chain
> > > that
> > > > had the failure worked correctly individually, but failed
> > > when used in
> > > > context. I looked for interrupts that might be stepping on
> > > data, overflow
> > > > of input buffers and all sorts of things. The answer was
> > > much simpler,
> > > but
> > > > harder to detect.
> > > >
> > > > I have a routine -- unsigned long str8tolong(const char *
> > > str); -- which
> > > > expects str to be pointing at an 8 character hexadecimal
> > > value and returns
> > > > an unsigned long. I use it for parsing highly formatted
> > > input data. I
> > > have
> > > > several similar routines in one file - strfun.c - that was
> > > written, tested
> > > > and added to a library a long time ago. It turns out that
> > > str8tolong was
> > > > the only one that did NOT have a prototype in the header
> > > file. I have
> > > > apparently never yet used this particular function from
> that module.
> > > >
> > > > As a result, the compiler resorted to implicit parameter
> > > declaration, and
> > > > the return value was assumed (properly) to be of type
> > > integer. Since it
> > > was
> > > > then assigned to a long, it was sign-extended to a long,
> > > and my troubles
> > > > began. This bug was darn hard to find.
> > > >
> > > > I never noticed the implicit parameter declaration warning
> > > in the dozens
> > > of
> > > > meaningless warnings I get on every compile. Is there any
> > > way to promote
> > > a
> > > > particular warning to an actual error? Or is there any
> way to get a
> > > > particular type of warning to really stand out at compile
> > > time? This is a
> > > > nasty one, and should get more attention.
> > > >
> > > > Thanks,
> > > >
> > > > Paul Johnson
> > > >
> > > > > -----Original Message-----
> > > > > From: Erich Styger [mailto:]
> > > > > Sent: Wednesday, March 26, 2003 7:19 AM
> > > > > To:
> > > > > Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> > > > >
> > > > >
> > > > > Hello Paul,
> > > > > what you see is called 'common code': the compiler
> folds togehter
> > > > > pieces of code
> > > > > at to the end of the function.
> > > > > You may use the option -Onf to switch this optimization off.
> > > > >
> > > > > But some questions:
> > > > > how did you generate the listing file? With the decoder
> (decoding
> > > > > the object
> > > > > file)
> > > > > or decoding the .abs file?
> > > > > I ask because the output looks like generated from the
> > > .abs file (say
> > > > > function starts
> > > > > at 0000243, but the presence of relocation/fixup information)
> > > > > 0000027C 07FF BSR skipWhitespace ;abs = 027D
> > > > > says that it is an object file?
> > > > >
> > > > > What you see with the 0x07FF code pattern is the BSR
> > > instruction with
> > > the
> > > > > offset -1 plus
> > > > > a relocation/fixup which has to be resolved by the linker. So if
> > > > > the listing below is from the .abs file, this is
> > > potentially a
> > > bug.
> > > > > In case the linker cannot resolve the BSR call, the
> > > linker will issue an
> > > > > error. Did you
> > > > > see this?
> > > > >
> > > > > Hope this help,
> > > > > Erich
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Paul Johnson [mailto:]
> > > > > > Sent: Mittwoch, 26. Marz 2003 01:44
> > > > > > To:
> > > > > > Subject: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> > > > > >
> > > > > >
> > > > > > Hi Metrowerks gurus,
> > > > > >
> > > > > > I've disassembled a module in my program where I think
> > > there may be a
> > > > > > problem. I have include the relevant section below,
> which has a
> > > > > > construction that I cannot understand. Can someone explain it
> > > > > to me? The
> > > > > > problems are described inline, starting with ***.
> > > > > >
> > > > > > 143: char * parseLong(char * str,long * data)
> > > > > > parseLong:
> > > > > > 00000243 3B PSHD
> > > > > > 145: str = skipWhitespace(str);
> > > > > > 00000244 EC84 LDD 4,SP
> > > > > > 00000246 0734 BSR *+54 ;abs = 027C
> > > > > >
> > > > > > *** I have to assume that there is a call of
> > > skipWhitespace at 027C,
> > > but
> > > > > > wait until you see what's actually there (below)
> > > > > >
> > > > > > 146: if ((*str == ',') || !(*str)) {
> > > > > > 00000248 2704 BEQ *+6 ;abs = 024E
> > > > > > 0000024A E600 LDAB 0,X
> > > > > > 0000024C 2610 BNE *+18 ;abs = 025E
> > > > > > 147: *data = 0;
> > > > > > 0000024E EE80 LDX 0,SP
> > > > > > 00000250 C7 CLRB
> > > > > > 00000251 87 CLRA
> > > > > > 00000252 6C02 STD 2,X
> > > > > > 00000254 6C00 STD 0,X
> > > > > > 148: if (*str) str++;
> > > > > > 00000256 EE84 LDX 4,SP
> > > > > > 00000258 E600 LDAB 0,X
> > > > > > 0000025A 271C BEQ *+30 ;abs = 0278
> > > > > > 0000025C 2017 BRA *+25 ;abs = 0275
> > > > > > 151: *data = str8tolong(str);
> > > > > > 0000025E B754 TFR X,D
> > > > > > 00000260 160000 JSR str8tolong
> > > > > > 00000263 160000 JSR ILSEXT
> > > > > > 00000266 ED80 LDY 0,SP
> > > > > > 00000268 6C42 STD 2,Y
> > > > > > 0000026A 6E40 STX 0,Y
> > > > > > 152: str+=8;
> > > > > > 0000026C EC84 LDD 4,SP
> > > > > > 0000026E C30008 ADDD #8
> > > > > > 153: str = skipWhitespace(str);
> > > > > > 00000271 0709 BSR *+11 ;abs = 027C
> > > > > > 154: if (*str == ',') str++;
> > > > > > 00000273 2603 BNE *+5 ;abs = 0278
> > > > > > 00000275 08 INX
> > > > > > 00000276 6E84 STX 4,SP
> > > > > > 155: return(str);
> > > > > > 00000278 EC84 LDD 4,SP
> > > > > > 157: }
> > > > > > 0000027A 30 PULX
> > > > > > 0000027B 3D RTS
> > > > > >
> > > > > > *** Here's the apparent call to skipWhitespace (which is at
> > > > > 0135), but the
> > > > > > disassembler says it's going to branch to 027d, which would
> > > > > start with the
> > > > > > opcode FF and be out of phase with everything else.
> > > > > >
> > > > > > 0000027C 07FF BSR skipWhitespace ;abs = 027D
> > > > > > 0000027E 6C86 STD 6,SP
> > > > > > 00000280 B745 TFR D,X
> > > > > > 00000282 E600 LDAB 0,X
> > > > > > 00000284 C12C CMPB #44
> > > > > > 00000286 3D RTS
> > > > > >
> > > > > > Can someone explain this to a tired, old programmer?
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Paul Johnson
> > > > > >
> > > > > >
> > > > > >
> > > > > > --------------------
> > > > > >
> > > > > >
> > > > > >
> > > > > > ">http://docs.yahoo.com/info/terms/
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --------------------
> > > > >
> > > > >
> > > > >
> > > > > ">http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --------------------
> > > >
> > > >
> > > >
> > > > ">http://docs.yahoo.com/info/terms/
> > >
> >
> >
> >
> > --------------------
> >
> >
> >
> > ">http://docs.yahoo.com/info/terms/
> >
> >
> > ------------------------

--------------------
">http://docs.yahoo.com/info/terms/



Reply by Andrew Lohmann's New Email Server ●March 31, 20032003-03-31
Is that the same as the free LC-Lint? I can't at the moment find a link for that, but it's a very tool though I did not find a way to redirect (pipe) the output to file. I ran it from a batch file - note in only runs in windows as its a 32 bit application.

Has anyone know a better environment for LC-Lint? Andrew Lohmann AIIE
Design Engineer

Bellingham + Stanley Ltd.
Longfield Road, Tunbridge Wells, Kent, TN2 3EY, England.
Tel: +44 (0) 1892 500400
Fax: +44 (0) 1892 543115
Website: www.bs-ltd.com

----- Original Message -----
From: Erich Styger
To:
Sent: Sunday, March 30, 2003 3:45 PM
Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help! yeah, PC-lint is a real good thing.
Found glitches in the source code with it which are hard to find otherwise.
The plugin for PC-Lint is delivered with CodeWarrior too: just set the
linker to 'pclint linker' in the project preference panel and you
can use it as a front end to PC-Lint.

Erich

> -----Original Message-----
> From: Kellogg Dave [mailto:]
> Sent: Samstag, 29. Marz 2003 16:26
> To: '
> Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help! > In addition to enabling all warnings, I use PC-Lint
> (www.gimpel.com). It is
> very configurable and much more picky than a compiler. One of
> its strengths
> is that it can look across multiple modules. Recommended. It
> has saved me
> several times. > 607-656-2597 > -----Original Message-----
> From: Karl Lunt [mailto:]
> Sent: Thursday, March 27, 2003 2:39 PM
> To: '
> Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help! > Also, turn the warning level all the way up. This means enable every
> warning that the compiler can produce. If your code still
> compiles without
> warnings, you are more assured of having created very clean code.
>
> (Naturally, there are some execptions to the above. For example, some
> compilers might gen a warning over formatting issues on otherwise
> perfectly
> good code; your mileage will vary.)
>
> Karl > > -----Original Message-----
> > From: Mike Burgess [mailto:]
> > Sent: Thursday, March 27, 2003 11:19 AM
> > To:
> > Subject: Re: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> >
> >
> > Paul,
> > Usually compile warnings are not useless, you should try at
> > all cost to
> > write code that
> > does not produce warnings. As was the case with your
> > integer. Sooner or
> > later
> > what you thought was useless warnings will come back to haut you.
> >
> >
> > Michael.
> >
> >
> > ----- Original Message -----
> > From: "Paul Johnson" <>
> > To: <>
> > Sent: Thursday, March 27, 2003 9:52 AM
> > Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> >
> >
> > > Hi Erich,
> > >
> > > I could follow the common code optimization, and that makes
> > sense -- it
> > was
> > > the BSR -1 that really confused me. I generated this code by
> > right-clicking
> > > in in the editor window (in CodeWarrior) and selecting
> > "Disassemble". I
> > did
> > > not see any errors related to this, so I assume it was displaying
> > > incorrectly but linking correctly.
> > >
> > > The actual problem that had me on my hands and knees
> > pouring through the
> > > assembly code was a much more subtle bug. Every function
> > in the chain
> > that
> > > had the failure worked correctly individually, but failed
> > when used in
> > > context. I looked for interrupts that might be stepping on
> > data, overflow
> > > of input buffers and all sorts of things. The answer was
> > much simpler,
> > but
> > > harder to detect.
> > >
> > > I have a routine -- unsigned long str8tolong(const char *
> > str); -- which
> > > expects str to be pointing at an 8 character hexadecimal
> > value and returns
> > > an unsigned long. I use it for parsing highly formatted
> > input data. I
> > have
> > > several similar routines in one file - strfun.c - that was
> > written, tested
> > > and added to a library a long time ago. It turns out that
> > str8tolong was
> > > the only one that did NOT have a prototype in the header
> > file. I have
> > > apparently never yet used this particular function from that module.
> > >
> > > As a result, the compiler resorted to implicit parameter
> > declaration, and
> > > the return value was assumed (properly) to be of type
> > integer. Since it
> > was
> > > then assigned to a long, it was sign-extended to a long,
> > and my troubles
> > > began. This bug was darn hard to find.
> > >
> > > I never noticed the implicit parameter declaration warning
> > in the dozens
> > of
> > > meaningless warnings I get on every compile. Is there any
> > way to promote
> > a
> > > particular warning to an actual error? Or is there any way to get a
> > > particular type of warning to really stand out at compile
> > time? This is a
> > > nasty one, and should get more attention.
> > >
> > > Thanks,
> > >
> > > Paul Johnson
> > >
> > > > -----Original Message-----
> > > > From: Erich Styger [mailto:]
> > > > Sent: Wednesday, March 26, 2003 7:19 AM
> > > > To:
> > > > Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> > > >
> > > >
> > > > Hello Paul,
> > > > what you see is called 'common code': the compiler folds togehter
> > > > pieces of code
> > > > at to the end of the function.
> > > > You may use the option -Onf to switch this optimization off.
> > > >
> > > > But some questions:
> > > > how did you generate the listing file? With the decoder (decoding
> > > > the object
> > > > file)
> > > > or decoding the .abs file?
> > > > I ask because the output looks like generated from the
> > .abs file (say
> > > > function starts
> > > > at 0000243, but the presence of relocation/fixup information)
> > > > 0000027C 07FF BSR skipWhitespace ;abs = 027D
> > > > says that it is an object file?
> > > >
> > > > What you see with the 0x07FF code pattern is the BSR
> > instruction with
> > the
> > > > offset -1 plus
> > > > a relocation/fixup which has to be resolved by the linker. So if
> > > > the listing below is from the .abs file, this is
> > potentially a
> > bug.
> > > > In case the linker cannot resolve the BSR call, the
> > linker will issue an
> > > > error. Did you
> > > > see this?
> > > >
> > > > Hope this help,
> > > > Erich
> > > >
> > > > > -----Original Message-----
> > > > > From: Paul Johnson [mailto:]
> > > > > Sent: Mittwoch, 26. Marz 2003 01:44
> > > > > To:
> > > > > Subject: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> > > > >
> > > > >
> > > > > Hi Metrowerks gurus,
> > > > >
> > > > > I've disassembled a module in my program where I think
> > there may be a
> > > > > problem. I have include the relevant section below, which has a
> > > > > construction that I cannot understand. Can someone explain it
> > > > to me? The
> > > > > problems are described inline, starting with ***.
> > > > >
> > > > > 143: char * parseLong(char * str,long * data)
> > > > > parseLong:
> > > > > 00000243 3B PSHD
> > > > > 145: str = skipWhitespace(str);
> > > > > 00000244 EC84 LDD 4,SP
> > > > > 00000246 0734 BSR *+54 ;abs = 027C
> > > > >
> > > > > *** I have to assume that there is a call of
> > skipWhitespace at 027C,
> > but
> > > > > wait until you see what's actually there (below)
> > > > >
> > > > > 146: if ((*str == ',') || !(*str)) {
> > > > > 00000248 2704 BEQ *+6 ;abs = 024E
> > > > > 0000024A E600 LDAB 0,X
> > > > > 0000024C 2610 BNE *+18 ;abs = 025E
> > > > > 147: *data = 0;
> > > > > 0000024E EE80 LDX 0,SP
> > > > > 00000250 C7 CLRB
> > > > > 00000251 87 CLRA
> > > > > 00000252 6C02 STD 2,X
> > > > > 00000254 6C00 STD 0,X
> > > > > 148: if (*str) str++;
> > > > > 00000256 EE84 LDX 4,SP
> > > > > 00000258 E600 LDAB 0,X
> > > > > 0000025A 271C BEQ *+30 ;abs = 0278
> > > > > 0000025C 2017 BRA *+25 ;abs = 0275
> > > > > 151: *data = str8tolong(str);
> > > > > 0000025E B754 TFR X,D
> > > > > 00000260 160000 JSR str8tolong
> > > > > 00000263 160000 JSR ILSEXT
> > > > > 00000266 ED80 LDY 0,SP
> > > > > 00000268 6C42 STD 2,Y
> > > > > 0000026A 6E40 STX 0,Y
> > > > > 152: str+=8;
> > > > > 0000026C EC84 LDD 4,SP
> > > > > 0000026E C30008 ADDD #8
> > > > > 153: str = skipWhitespace(str);
> > > > > 00000271 0709 BSR *+11 ;abs = 027C
> > > > > 154: if (*str == ',') str++;
> > > > > 00000273 2603 BNE *+5 ;abs = 0278
> > > > > 00000275 08 INX
> > > > > 00000276 6E84 STX 4,SP
> > > > > 155: return(str);
> > > > > 00000278 EC84 LDD 4,SP
> > > > > 157: }
> > > > > 0000027A 30 PULX
> > > > > 0000027B 3D RTS
> > > > >
> > > > > *** Here's the apparent call to skipWhitespace (which is at
> > > > 0135), but the
> > > > > disassembler says it's going to branch to 027d, which would
> > > > start with the
> > > > > opcode FF and be out of phase with everything else.
> > > > >
> > > > > 0000027C 07FF BSR skipWhitespace ;abs = 027D
> > > > > 0000027E 6C86 STD 6,SP
> > > > > 00000280 B745 TFR D,X
> > > > > 00000282 E600 LDAB 0,X
> > > > > 00000284 C12C CMPB #44
> > > > > 00000286 3D RTS
> > > > >
> > > > > Can someone explain this to a tired, old programmer?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Paul Johnson
> > > > >
> > > > >
> > > > >
> > > > > --------------------
> > > > >
> > > > >
> > > > >
> > > > > ">http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --------------------
> > > >
> > > >
> > > >
> > > > ">http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > >
> > >
> > > --------------------
> > >
> > >
> > >
> > > ">http://docs.yahoo.com/info/terms/
> >
> -------------------- >
> ">http://docs.yahoo.com/info/terms/ > ------------------------

--------------------

--- Email Disclaimer --- Internet communications are not secure and therefore Bellingham + Stanley Ltd does not accept legal responsibility for the contents of this message. Any views or opinions presented are solely those of the author and do not necessarily represent those of Bellingham + Stanley Ltd unless otherwise specifically stated. If this message is received by anyone other than the addressee, please notify the sender and then delete the message and any attachments from your computer. --- End --- --- Email Disclaimer ---

Internet communications are not secure and therefore Bellingham + Stanley Ltd does
not accept legal responsibility for the contents of this message. Any views
or opinions presented are solely those of the author and do not necessarily
represent those of Bellingham + Stanley Ltd unless otherwise specifically stated.
If this message is received by anyone other than the addressee, please
notify the sender and then delete the message and any attachments from your
computer.

--- End ---


Reply by Erich Styger ●March 30, 20032003-03-30
yeah, PC-lint is a real good thing.
Found glitches in the source code with it which are hard to find otherwise.
The plugin for PC-Lint is delivered with CodeWarrior too: just set the
linker to 'pclint linker' in the project preference panel and you
can use it as a front end to PC-Lint.

Erich

> -----Original Message-----
> From: Kellogg Dave [mailto:]
> Sent: Samstag, 29. Marz 2003 16:26
> To: '
> Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help! > In addition to enabling all warnings, I use PC-Lint
> (www.gimpel.com). It is
> very configurable and much more picky than a compiler. One of
> its strengths
> is that it can look across multiple modules. Recommended. It
> has saved me
> several times. > 607-656-2597 > -----Original Message-----
> From: Karl Lunt [mailto:]
> Sent: Thursday, March 27, 2003 2:39 PM
> To: '
> Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help! > Also, turn the warning level all the way up. This means enable every
> warning that the compiler can produce. If your code still
> compiles without
> warnings, you are more assured of having created very clean code.
>
> (Naturally, there are some execptions to the above. For example, some
> compilers might gen a warning over formatting issues on otherwise
> perfectly
> good code; your mileage will vary.)
>
> Karl > > -----Original Message-----
> > From: Mike Burgess [mailto:]
> > Sent: Thursday, March 27, 2003 11:19 AM
> > To:
> > Subject: Re: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> >
> >
> > Paul,
> > Usually compile warnings are not useless, you should try at
> > all cost to
> > write code that
> > does not produce warnings. As was the case with your
> > integer. Sooner or
> > later
> > what you thought was useless warnings will come back to haut you.
> >
> >
> > Michael.
> >
> >
> > ----- Original Message -----
> > From: "Paul Johnson" <>
> > To: <>
> > Sent: Thursday, March 27, 2003 9:52 AM
> > Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> >
> >
> > > Hi Erich,
> > >
> > > I could follow the common code optimization, and that makes
> > sense -- it
> > was
> > > the BSR -1 that really confused me. I generated this code by
> > right-clicking
> > > in in the editor window (in CodeWarrior) and selecting
> > "Disassemble". I
> > did
> > > not see any errors related to this, so I assume it was displaying
> > > incorrectly but linking correctly.
> > >
> > > The actual problem that had me on my hands and knees
> > pouring through the
> > > assembly code was a much more subtle bug. Every function
> > in the chain
> > that
> > > had the failure worked correctly individually, but failed
> > when used in
> > > context. I looked for interrupts that might be stepping on
> > data, overflow
> > > of input buffers and all sorts of things. The answer was
> > much simpler,
> > but
> > > harder to detect.
> > >
> > > I have a routine -- unsigned long str8tolong(const char *
> > str); -- which
> > > expects str to be pointing at an 8 character hexadecimal
> > value and returns
> > > an unsigned long. I use it for parsing highly formatted
> > input data. I
> > have
> > > several similar routines in one file - strfun.c - that was
> > written, tested
> > > and added to a library a long time ago. It turns out that
> > str8tolong was
> > > the only one that did NOT have a prototype in the header
> > file. I have
> > > apparently never yet used this particular function from that module.
> > >
> > > As a result, the compiler resorted to implicit parameter
> > declaration, and
> > > the return value was assumed (properly) to be of type
> > integer. Since it
> > was
> > > then assigned to a long, it was sign-extended to a long,
> > and my troubles
> > > began. This bug was darn hard to find.
> > >
> > > I never noticed the implicit parameter declaration warning
> > in the dozens
> > of
> > > meaningless warnings I get on every compile. Is there any
> > way to promote
> > a
> > > particular warning to an actual error? Or is there any way to get a
> > > particular type of warning to really stand out at compile
> > time? This is a
> > > nasty one, and should get more attention.
> > >
> > > Thanks,
> > >
> > > Paul Johnson
> > >
> > > > -----Original Message-----
> > > > From: Erich Styger [mailto:]
> > > > Sent: Wednesday, March 26, 2003 7:19 AM
> > > > To:
> > > > Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> > > >
> > > >
> > > > Hello Paul,
> > > > what you see is called 'common code': the compiler folds togehter
> > > > pieces of code
> > > > at to the end of the function.
> > > > You may use the option -Onf to switch this optimization off.
> > > >
> > > > But some questions:
> > > > how did you generate the listing file? With the decoder (decoding
> > > > the object
> > > > file)
> > > > or decoding the .abs file?
> > > > I ask because the output looks like generated from the
> > .abs file (say
> > > > function starts
> > > > at 0000243, but the presence of relocation/fixup information)
> > > > 0000027C 07FF BSR skipWhitespace ;abs = 027D
> > > > says that it is an object file?
> > > >
> > > > What you see with the 0x07FF code pattern is the BSR
> > instruction with
> > the
> > > > offset -1 plus
> > > > a relocation/fixup which has to be resolved by the linker. So if
> > > > the listing below is from the .abs file, this is
> > potentially a
> > bug.
> > > > In case the linker cannot resolve the BSR call, the
> > linker will issue an
> > > > error. Did you
> > > > see this?
> > > >
> > > > Hope this help,
> > > > Erich
> > > >
> > > > > -----Original Message-----
> > > > > From: Paul Johnson [mailto:]
> > > > > Sent: Mittwoch, 26. Marz 2003 01:44
> > > > > To:
> > > > > Subject: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> > > > >
> > > > >
> > > > > Hi Metrowerks gurus,
> > > > >
> > > > > I've disassembled a module in my program where I think
> > there may be a
> > > > > problem. I have include the relevant section below, which has a
> > > > > construction that I cannot understand. Can someone explain it
> > > > to me? The
> > > > > problems are described inline, starting with ***.
> > > > >
> > > > > 143: char * parseLong(char * str,long * data)
> > > > > parseLong:
> > > > > 00000243 3B PSHD
> > > > > 145: str = skipWhitespace(str);
> > > > > 00000244 EC84 LDD 4,SP
> > > > > 00000246 0734 BSR *+54 ;abs = 027C
> > > > >
> > > > > *** I have to assume that there is a call of
> > skipWhitespace at 027C,
> > but
> > > > > wait until you see what's actually there (below)
> > > > >
> > > > > 146: if ((*str == ',') || !(*str)) {
> > > > > 00000248 2704 BEQ *+6 ;abs = 024E
> > > > > 0000024A E600 LDAB 0,X
> > > > > 0000024C 2610 BNE *+18 ;abs = 025E
> > > > > 147: *data = 0;
> > > > > 0000024E EE80 LDX 0,SP
> > > > > 00000250 C7 CLRB
> > > > > 00000251 87 CLRA
> > > > > 00000252 6C02 STD 2,X
> > > > > 00000254 6C00 STD 0,X
> > > > > 148: if (*str) str++;
> > > > > 00000256 EE84 LDX 4,SP
> > > > > 00000258 E600 LDAB 0,X
> > > > > 0000025A 271C BEQ *+30 ;abs = 0278
> > > > > 0000025C 2017 BRA *+25 ;abs = 0275
> > > > > 151: *data = str8tolong(str);
> > > > > 0000025E B754 TFR X,D
> > > > > 00000260 160000 JSR str8tolong
> > > > > 00000263 160000 JSR ILSEXT
> > > > > 00000266 ED80 LDY 0,SP
> > > > > 00000268 6C42 STD 2,Y
> > > > > 0000026A 6E40 STX 0,Y
> > > > > 152: str+=8;
> > > > > 0000026C EC84 LDD 4,SP
> > > > > 0000026E C30008 ADDD #8
> > > > > 153: str = skipWhitespace(str);
> > > > > 00000271 0709 BSR *+11 ;abs = 027C
> > > > > 154: if (*str == ',') str++;
> > > > > 00000273 2603 BNE *+5 ;abs = 0278
> > > > > 00000275 08 INX
> > > > > 00000276 6E84 STX 4,SP
> > > > > 155: return(str);
> > > > > 00000278 EC84 LDD 4,SP
> > > > > 157: }
> > > > > 0000027A 30 PULX
> > > > > 0000027B 3D RTS
> > > > >
> > > > > *** Here's the apparent call to skipWhitespace (which is at
> > > > 0135), but the
> > > > > disassembler says it's going to branch to 027d, which would
> > > > start with the
> > > > > opcode FF and be out of phase with everything else.
> > > > >
> > > > > 0000027C 07FF BSR skipWhitespace ;abs = 027D
> > > > > 0000027E 6C86 STD 6,SP
> > > > > 00000280 B745 TFR D,X
> > > > > 00000282 E600 LDAB 0,X
> > > > > 00000284 C12C CMPB #44
> > > > > 00000286 3D RTS
> > > > >
> > > > > Can someone explain this to a tired, old programmer?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Paul Johnson
> > > > >
> > > > >
> > > > >
> > > > > --------------------
> > > > >
> > > > >
> > > > >
> > > > > ">http://docs.yahoo.com/info/terms/
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --------------------
> > > >
> > > >
> > > >
> > > > ">http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > >
> > >
> > > --------------------
> > >
> > >
> > >
> > > ">http://docs.yahoo.com/info/terms/
> >
> -------------------- >
> ">http://docs.yahoo.com/info/terms/ > ------------------------ Yahoo! Groups Sponsor
> ---------------------~--> Get
> 128 Bit SSL Encryption!
> http://us.click.yahoo.com/xaxhjB/hdqFAA/xGHJAA/dN_tlB/TM
> ---------------------------------~->
>
> -------------------- >
> ">http://docs.yahoo.com/info/terms/ >
> -------------------- >
> ">http://docs.yahoo.com/info/terms/



Reply by Kellogg Dave ●March 29, 20032003-03-29
In addition to enabling all warnings, I use PC-Lint (www.gimpel.com). It is
very configurable and much more picky than a compiler. One of its strengths
is that it can look across multiple modules. Recommended. It has saved me
several times. 607-656-2597 -----Original Message-----
From: Karl Lunt [mailto:]
Sent: Thursday, March 27, 2003 2:39 PM
To: '
Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help! Also, turn the warning level all the way up. This means enable every
warning that the compiler can produce. If your code still compiles without
warnings, you are more assured of having created very clean code.

(Naturally, there are some execptions to the above. For example, some
compilers might gen a warning over formatting issues on otherwise perfectly
good code; your mileage will vary.)

Karl > -----Original Message-----
> From: Mike Burgess [mailto:]
> Sent: Thursday, March 27, 2003 11:19 AM
> To:
> Subject: Re: [68HC12] Metrowerks Disassembly Obfuscation - Help! > Paul,
> Usually compile warnings are not useless, you should try at
> all cost to
> write code that
> does not produce warnings. As was the case with your
> integer. Sooner or
> later
> what you thought was useless warnings will come back to haut you. > Michael. > ----- Original Message -----
> From: "Paul Johnson" <>
> To: <>
> Sent: Thursday, March 27, 2003 9:52 AM
> Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help! > > Hi Erich,
> >
> > I could follow the common code optimization, and that makes
> sense -- it
> was
> > the BSR -1 that really confused me. I generated this code by
> right-clicking
> > in in the editor window (in CodeWarrior) and selecting
> "Disassemble". I
> did
> > not see any errors related to this, so I assume it was displaying
> > incorrectly but linking correctly.
> >
> > The actual problem that had me on my hands and knees
> pouring through the
> > assembly code was a much more subtle bug. Every function
> in the chain
> that
> > had the failure worked correctly individually, but failed
> when used in
> > context. I looked for interrupts that might be stepping on
> data, overflow
> > of input buffers and all sorts of things. The answer was
> much simpler,
> but
> > harder to detect.
> >
> > I have a routine -- unsigned long str8tolong(const char *
> str); -- which
> > expects str to be pointing at an 8 character hexadecimal
> value and returns
> > an unsigned long. I use it for parsing highly formatted
> input data. I
> have
> > several similar routines in one file - strfun.c - that was
> written, tested
> > and added to a library a long time ago. It turns out that
> str8tolong was
> > the only one that did NOT have a prototype in the header
> file. I have
> > apparently never yet used this particular function from that module.
> >
> > As a result, the compiler resorted to implicit parameter
> declaration, and
> > the return value was assumed (properly) to be of type
> integer. Since it
> was
> > then assigned to a long, it was sign-extended to a long,
> and my troubles
> > began. This bug was darn hard to find.
> >
> > I never noticed the implicit parameter declaration warning
> in the dozens
> of
> > meaningless warnings I get on every compile. Is there any
> way to promote
> a
> > particular warning to an actual error? Or is there any way to get a
> > particular type of warning to really stand out at compile
> time? This is a
> > nasty one, and should get more attention.
> >
> > Thanks,
> >
> > Paul Johnson
> >
> > > -----Original Message-----
> > > From: Erich Styger [mailto:]
> > > Sent: Wednesday, March 26, 2003 7:19 AM
> > > To:
> > > Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> > >
> > >
> > > Hello Paul,
> > > what you see is called 'common code': the compiler folds togehter
> > > pieces of code
> > > at to the end of the function.
> > > You may use the option -Onf to switch this optimization off.
> > >
> > > But some questions:
> > > how did you generate the listing file? With the decoder (decoding
> > > the object
> > > file)
> > > or decoding the .abs file?
> > > I ask because the output looks like generated from the
> .abs file (say
> > > function starts
> > > at 0000243, but the presence of relocation/fixup information)
> > > 0000027C 07FF BSR skipWhitespace ;abs = 027D
> > > says that it is an object file?
> > >
> > > What you see with the 0x07FF code pattern is the BSR
> instruction with
> the
> > > offset -1 plus
> > > a relocation/fixup which has to be resolved by the linker. So if
> > > the listing below is from the .abs file, this is
> potentially a
> bug.
> > > In case the linker cannot resolve the BSR call, the
> linker will issue an
> > > error. Did you
> > > see this?
> > >
> > > Hope this help,
> > > Erich
> > >
> > > > -----Original Message-----
> > > > From: Paul Johnson [mailto:]
> > > > Sent: Mittwoch, 26. Marz 2003 01:44
> > > > To:
> > > > Subject: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> > > >
> > > >
> > > > Hi Metrowerks gurus,
> > > >
> > > > I've disassembled a module in my program where I think
> there may be a
> > > > problem. I have include the relevant section below, which has a
> > > > construction that I cannot understand. Can someone explain it
> > > to me? The
> > > > problems are described inline, starting with ***.
> > > >
> > > > 143: char * parseLong(char * str,long * data)
> > > > parseLong:
> > > > 00000243 3B PSHD
> > > > 145: str = skipWhitespace(str);
> > > > 00000244 EC84 LDD 4,SP
> > > > 00000246 0734 BSR *+54 ;abs = 027C
> > > >
> > > > *** I have to assume that there is a call of
> skipWhitespace at 027C,
> but
> > > > wait until you see what's actually there (below)
> > > >
> > > > 146: if ((*str == ',') || !(*str)) {
> > > > 00000248 2704 BEQ *+6 ;abs = 024E
> > > > 0000024A E600 LDAB 0,X
> > > > 0000024C 2610 BNE *+18 ;abs = 025E
> > > > 147: *data = 0;
> > > > 0000024E EE80 LDX 0,SP
> > > > 00000250 C7 CLRB
> > > > 00000251 87 CLRA
> > > > 00000252 6C02 STD 2,X
> > > > 00000254 6C00 STD 0,X
> > > > 148: if (*str) str++;
> > > > 00000256 EE84 LDX 4,SP
> > > > 00000258 E600 LDAB 0,X
> > > > 0000025A 271C BEQ *+30 ;abs = 0278
> > > > 0000025C 2017 BRA *+25 ;abs = 0275
> > > > 151: *data = str8tolong(str);
> > > > 0000025E B754 TFR X,D
> > > > 00000260 160000 JSR str8tolong
> > > > 00000263 160000 JSR ILSEXT
> > > > 00000266 ED80 LDY 0,SP
> > > > 00000268 6C42 STD 2,Y
> > > > 0000026A 6E40 STX 0,Y
> > > > 152: str+=8;
> > > > 0000026C EC84 LDD 4,SP
> > > > 0000026E C30008 ADDD #8
> > > > 153: str = skipWhitespace(str);
> > > > 00000271 0709 BSR *+11 ;abs = 027C
> > > > 154: if (*str == ',') str++;
> > > > 00000273 2603 BNE *+5 ;abs = 0278
> > > > 00000275 08 INX
> > > > 00000276 6E84 STX 4,SP
> > > > 155: return(str);
> > > > 00000278 EC84 LDD 4,SP
> > > > 157: }
> > > > 0000027A 30 PULX
> > > > 0000027B 3D RTS
> > > >
> > > > *** Here's the apparent call to skipWhitespace (which is at
> > > 0135), but the
> > > > disassembler says it's going to branch to 027d, which would
> > > start with the
> > > > opcode FF and be out of phase with everything else.
> > > >
> > > > 0000027C 07FF BSR skipWhitespace ;abs = 027D
> > > > 0000027E 6C86 STD 6,SP
> > > > 00000280 B745 TFR D,X
> > > > 00000282 E600 LDAB 0,X
> > > > 00000284 C12C CMPB #44
> > > > 00000286 3D RTS
> > > >
> > > > Can someone explain this to a tired, old programmer?
> > > >
> > > > Thanks,
> > > >
> > > > Paul Johnson
> > > >
> > > >
> > > >
> > > > --------------------
> > > >
> > > >
> > > >
> > > > ">http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > >
> > >
> > >
> > > --------------------
> > >
> > >
> > >
> > > ">http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> >
> >
> > --------------------
> >
> >
> >
> > ">http://docs.yahoo.com/info/terms/
>
 --------------------
">http://docs.yahoo.com/info/terms/ ------------------------ Yahoo! Groups Sponsor ---------------------~--> Get
128 Bit SSL Encryption!
http://us.click.yahoo.com/xaxhjB/hdqFAA/xGHJAA/dN_tlB/TM
---------------------------------~->

--------------------
">http://docs.yahoo.com/info/terms/


Reply by Paul Johnson ●March 28, 20032003-03-28
Eric, and all,

This has been an extremely rewarding thread with much good information. I'm
away from work at the moment, but when I get back to it next week, I will be
researching all of these pragmas, and especially promoting implicit
parameter declaration to an error message.

Thanks to everyone who responded.

Paul Johnson > -----Original Message-----
> From: Erich Styger [mailto:]
> Sent: Friday, March 28, 2003 8:27 AM
> To:
> Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help! > Hi Pat,
> It is one menu entry below:
> menu Edit > xxxxxxx Settings <Alt-F7>
> where xxxxxx is the CodeWarrior target name.
> Then Compiler for HC12, and here you go.
>
> Let the optimization turned on, this is what I can suggest.
>
> I think the compiler is too picky here.
>
> Something else (about your past life): have a look to the #pragma
> TEST_CODE
> which allows you
> to 'lock' tested code.
>
> Erich
>
> > -----Original Message-----
> > From: Pat Fitzpatrick [mailto:]
> > Sent: Freitag, 28. Mz 2003 16:46
> > To:
> > Subject: Re: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> >
> >
> > Hi Erich,
> >
> > I click Edit, Preferences... but there doesn't seem to be anything about
> > "Messages" anywhere. What am I missing?
> >
> > I looked at the manual, and the explanation for the warning
> confuses me a
> > little. I don't really want to try to decipher the compiler
> > output, but I would
> > like to see the debugger report correct info (which, sure enough,
> > it sometimes
> > doesn't seem to -- don't know for sure whether that correlates to
> > theses C12056
> > warnings or not -- but I'll sure be looking into it). The manual
> > seems to imply
> > that I have to choose between accurate debugger output and
> optimized code.
> > Turning off the optimization might be ok for debugging, but am I really
> > guaranteed that turning it back on will give correct code? How
> > can I be sure of
> > that when the code I stepped through with the debugger isn't the
> > same code as
> > I'm releasing?
> >
> > In a past life, where software reliability was VERY important,
> > changing compiler
> > options between unit test and software delivery would have gotten
> > me fired!! Am
> > I better just leaving the optimization off and living with the
> > inefficiency?
> >
> > advice appreciated,
> >
> > Pat
> >
> >
> >
> >
> >
> > Erich Styger wrote:
> >
> > > You get a description of the messages here:
> > > go to the preference panel, Messages, select the message
> > > you want to have the information about, and press F1/Help.
> > > They are also all listed in the PDF file located in
> > > CodeWarrior Manuals\pdf\Manual Compiler HC12.pdf
> > >
> > > Erich
> > >
> > > > -----Original Message-----
> > > > From: Bob White [mailto:]
> > > > Sent: Freitag, 28. Mz 2003 01:50
> > > > To:
> > > > Subject: Re: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> > > >
> > > >
> > > > I get that warning, too. I hate ignoring warnings, but I also
> > > > don't have a
> > > > clue what it means, or how to get rid of it. I have so far
> > just supposed
> > > > that it means that the debugger will be a little weak. Most
> > of my code is
> > > > assembly. I do have some in-line assembly statements in my C
> > code. I'd
> > > > love to hear an explanation. The debugger seems to work fine.
> > > >
> > > > Oddly, I can't determine when I will get the warning message.
> > > > Doing a full
> > > > build doesn't trigger it. It just pops up every now and then.
> > > >
> > > > "CodeWorrier," good one.
> > > >
> > > > Bob White
> > > >
> > > > ----- Original Message -----
> > > > From: "Pat Fitzpatrick" <>
> > > > To: <>
> > > > Sent: Thursday, March 27, 2003 3:30 PM
> > > > Subject: Re: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> > > >
> > > >
> > > > Hi list,
> > > >
> > > >
> > > > I agree in principle, having been burned more than I ought to be
> > > > by ignoring
> > > > warnings. However, I don't know what to do about the
> > following CodeWorrier
> > > > warning:
> > > >
> > > > Warning : C12056 : SP debug info incorrect because of
> > > > optimization or inline
> > > > assembler.
> > > >
> > > > Anyhow, there's no inline assembler and the code seems to work
> > > > just fine so
> > > > I presume it's a result of some ooptimization or other. I get rid
> > > > of it with
> > > > a #pragma, but it's still a little worrying.
> > > >
> > > > Can anyone explain what this message is really trying to tell
> > > > me?? And if I
> > > > ought to be concerned about it at all? And even how I might get
> > > > rid of it by
> > > > modifying the source code?
> > > >
> > > > thanks,
> > > >
> > > > Pat
> > > >
> > > >
> > > > Steve Russell wrote:
> > > >
> > > > > Hi Paul,
> > > > >
> > > > > Let me add my voice to the chorus and explain why I
> compile with the
> > > > > highest warning level available, and keep the warnings to zero.
> > > > >
> > > > > As others have pointed out, it is easy to prevent a warning
> > from being
> > > > > printed, either by using a #pragma or by adding a cast or
> redundant
> > > > assignment.
> > > > >
> > > > > So suppressing the ones that you have determined you are not
> > > > interested in
> > > > > one by one is pretty easy.
> > > > >
> > > > > The advantage is that when you add new code with that produces
> > > > a warning,
> > > > > you get told about it by the compiler, and you can easily fix
> > > > it, because
> > > > > the compiler is pretty good about pointing to exactly where
> > the problem
> > > > is.
> > > > >
> > > > > Sometimes the problem is obvious and a quick edit will fix it.
> > > > >
> > > > > Sometimes the problem is that you really don't understand some
> > > > C feature,
> > > > > and you have to study the manuals. In this case you learn
> > something.
> > > > >
> > > > > Sometimes its just the compiler being picky, and you can
> > make it shut up
> > > > > with a quick edit.
> > > > >
> > > > > On the average all of these take much less time than
> > loading the program
> > > > > and debugging it, as you just reported.
> > > > >
> > > > > Keeping the reports of warnings to zero as a matter of policy,
> > > > saves your
> > > > > time (and frustration)!
> > > > >
> > > > > Steve
> > > >
> > > >
> > > >
> > > > --------------------
> > > >
> > > >
> > > >
> > > > ">http://docs.yahoo.com/info/terms/
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > --------------------
> > >
> > >
> > >
> > > ">http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> >
> > --------------------
> >
> >
> >
> > ">http://docs.yahoo.com/info/terms/ >
> -------------------- >
> ">http://docs.yahoo.com/info/terms/ >
>
> -------------------- >
> ">http://docs.yahoo.com/info/terms/



Reply by Erich Styger ●March 28, 20032003-03-28
Hi Pat,
It is one menu entry below:
menu Edit > xxxxxxx Settings <Alt-F7>
where xxxxxx is the CodeWarrior target name.
Then Compiler for HC12, and here you go.

Let the optimization turned on, this is what I can suggest.

I think the compiler is too picky here.

Something else (about your past life): have a look to the #pragma TEST_CODE
which allows you
to 'lock' tested code.

Erich

> -----Original Message-----
> From: Pat Fitzpatrick [mailto:]
> Sent: Freitag, 28. Mz 2003 16:46
> To:
> Subject: Re: [68HC12] Metrowerks Disassembly Obfuscation - Help! > Hi Erich,
>
> I click Edit, Preferences... but there doesn't seem to be anything about
> "Messages" anywhere. What am I missing?
>
> I looked at the manual, and the explanation for the warning confuses me a
> little. I don't really want to try to decipher the compiler
> output, but I would
> like to see the debugger report correct info (which, sure enough,
> it sometimes
> doesn't seem to -- don't know for sure whether that correlates to
> theses C12056
> warnings or not -- but I'll sure be looking into it). The manual
> seems to imply
> that I have to choose between accurate debugger output and optimized code.
> Turning off the optimization might be ok for debugging, but am I really
> guaranteed that turning it back on will give correct code? How
> can I be sure of
> that when the code I stepped through with the debugger isn't the
> same code as
> I'm releasing?
>
> In a past life, where software reliability was VERY important,
> changing compiler
> options between unit test and software delivery would have gotten
> me fired!! Am
> I better just leaving the optimization off and living with the
> inefficiency?
>
> advice appreciated,
>
> Pat > Erich Styger wrote:
>
> > You get a description of the messages here:
> > go to the preference panel, Messages, select the message
> > you want to have the information about, and press F1/Help.
> > They are also all listed in the PDF file located in
> > CodeWarrior Manuals\pdf\Manual Compiler HC12.pdf
> >
> > Erich
> >
> > > -----Original Message-----
> > > From: Bob White [mailto:]
> > > Sent: Freitag, 28. Mz 2003 01:50
> > > To:
> > > Subject: Re: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> > >
> > >
> > > I get that warning, too. I hate ignoring warnings, but I also
> > > don't have a
> > > clue what it means, or how to get rid of it. I have so far
> just supposed
> > > that it means that the debugger will be a little weak. Most
> of my code is
> > > assembly. I do have some in-line assembly statements in my C
> code. I'd
> > > love to hear an explanation. The debugger seems to work fine.
> > >
> > > Oddly, I can't determine when I will get the warning message.
> > > Doing a full
> > > build doesn't trigger it. It just pops up every now and then.
> > >
> > > "CodeWorrier," good one.
> > >
> > > Bob White
> > >
> > > ----- Original Message -----
> > > From: "Pat Fitzpatrick" <>
> > > To: <>
> > > Sent: Thursday, March 27, 2003 3:30 PM
> > > Subject: Re: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> > >
> > >
> > > Hi list,
> > >
> > >
> > > I agree in principle, having been burned more than I ought to be
> > > by ignoring
> > > warnings. However, I don't know what to do about the
> following CodeWorrier
> > > warning:
> > >
> > > Warning : C12056 : SP debug info incorrect because of
> > > optimization or inline
> > > assembler.
> > >
> > > Anyhow, there's no inline assembler and the code seems to work
> > > just fine so
> > > I presume it's a result of some ooptimization or other. I get rid
> > > of it with
> > > a #pragma, but it's still a little worrying.
> > >
> > > Can anyone explain what this message is really trying to tell
> > > me?? And if I
> > > ought to be concerned about it at all? And even how I might get
> > > rid of it by
> > > modifying the source code?
> > >
> > > thanks,
> > >
> > > Pat
> > >
> > >
> > > Steve Russell wrote:
> > >
> > > > Hi Paul,
> > > >
> > > > Let me add my voice to the chorus and explain why I compile with the
> > > > highest warning level available, and keep the warnings to zero.
> > > >
> > > > As others have pointed out, it is easy to prevent a warning
> from being
> > > > printed, either by using a #pragma or by adding a cast or redundant
> > > assignment.
> > > >
> > > > So suppressing the ones that you have determined you are not
> > > interested in
> > > > one by one is pretty easy.
> > > >
> > > > The advantage is that when you add new code with that produces
> > > a warning,
> > > > you get told about it by the compiler, and you can easily fix
> > > it, because
> > > > the compiler is pretty good about pointing to exactly where
> the problem
> > > is.
> > > >
> > > > Sometimes the problem is obvious and a quick edit will fix it.
> > > >
> > > > Sometimes the problem is that you really don't understand some
> > > C feature,
> > > > and you have to study the manuals. In this case you learn
> something.
> > > >
> > > > Sometimes its just the compiler being picky, and you can
> make it shut up
> > > > with a quick edit.
> > > >
> > > > On the average all of these take much less time than
> loading the program
> > > > and debugging it, as you just reported.
> > > >
> > > > Keeping the reports of warnings to zero as a matter of policy,
> > > saves your
> > > > time (and frustration)!
> > > >
> > > > Steve
> > >
> > >
> > >
> > > --------------------
> > >
> > >
> > >
> > > ">http://docs.yahoo.com/info/terms/
> >
> >
> >
> >
> >
> >
> >
> > --------------------
> >
> >
> >
> > ">http://docs.yahoo.com/info/terms/
> >
> > -------------------- >
> ">http://docs.yahoo.com/info/terms/
 --------------------
">http://docs.yahoo.com/info/terms/



Reply by Pat Fitzpatrick ●March 28, 20032003-03-28
Hi Erich,

I click Edit, Preferences... but there doesn't seem to be anything about
"Messages" anywhere. What am I missing?

I looked at the manual, and the explanation for the warning confuses me a
little. I don't really want to try to decipher the compiler output, but I would
like to see the debugger report correct info (which, sure enough, it sometimes
doesn't seem to -- don't know for sure whether that correlates to theses C12056
warnings or not -- but I'll sure be looking into it). The manual seems to imply
that I have to choose between accurate debugger output and optimized code.
Turning off the optimization might be ok for debugging, but am I really
guaranteed that turning it back on will give correct code? How can I be sure of
that when the code I stepped through with the debugger isn't the same code as
I'm releasing?

In a past life, where software reliability was VERY important, changing compiler
options between unit test and software delivery would have gotten me fired!! Am
I better just leaving the optimization off and living with the inefficiency?

advice appreciated,

Pat Erich Styger wrote:

> You get a description of the messages here:
> go to the preference panel, Messages, select the message
> you want to have the information about, and press F1/Help.
> They are also all listed in the PDF file located in
> CodeWarrior Manuals\pdf\Manual Compiler HC12.pdf
>
> Erich
>
> > -----Original Message-----
> > From: Bob White [mailto:]
> > Sent: Freitag, 28. Mz 2003 01:50
> > To:
> > Subject: Re: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> >
> >
> > I get that warning, too. I hate ignoring warnings, but I also
> > don't have a
> > clue what it means, or how to get rid of it. I have so far just supposed
> > that it means that the debugger will be a little weak. Most of my code is
> > assembly. I do have some in-line assembly statements in my C code. I'd
> > love to hear an explanation. The debugger seems to work fine.
> >
> > Oddly, I can't determine when I will get the warning message.
> > Doing a full
> > build doesn't trigger it. It just pops up every now and then.
> >
> > "CodeWorrier," good one.
> >
> > Bob White
> >
> > ----- Original Message -----
> > From: "Pat Fitzpatrick" <>
> > To: <>
> > Sent: Thursday, March 27, 2003 3:30 PM
> > Subject: Re: [68HC12] Metrowerks Disassembly Obfuscation - Help!
> >
> >
> > Hi list,
> >
> >
> > I agree in principle, having been burned more than I ought to be
> > by ignoring
> > warnings. However, I don't know what to do about the following CodeWorrier
> > warning:
> >
> > Warning : C12056 : SP debug info incorrect because of
> > optimization or inline
> > assembler.
> >
> > Anyhow, there's no inline assembler and the code seems to work
> > just fine so
> > I presume it's a result of some ooptimization or other. I get rid
> > of it with
> > a #pragma, but it's still a little worrying.
> >
> > Can anyone explain what this message is really trying to tell
> > me?? And if I
> > ought to be concerned about it at all? And even how I might get
> > rid of it by
> > modifying the source code?
> >
> > thanks,
> >
> > Pat
> >
> >
> > Steve Russell wrote:
> >
> > > Hi Paul,
> > >
> > > Let me add my voice to the chorus and explain why I compile with the
> > > highest warning level available, and keep the warnings to zero.
> > >
> > > As others have pointed out, it is easy to prevent a warning from being
> > > printed, either by using a #pragma or by adding a cast or redundant
> > assignment.
> > >
> > > So suppressing the ones that you have determined you are not
> > interested in
> > > one by one is pretty easy.
> > >
> > > The advantage is that when you add new code with that produces
> > a warning,
> > > you get told about it by the compiler, and you can easily fix
> > it, because
> > > the compiler is pretty good about pointing to exactly where the problem
> > is.
> > >
> > > Sometimes the problem is obvious and a quick edit will fix it.
> > >
> > > Sometimes the problem is that you really don't understand some
> > C feature,
> > > and you have to study the manuals. In this case you learn something.
> > >
> > > Sometimes its just the compiler being picky, and you can make it shut up
> > > with a quick edit.
> > >
> > > On the average all of these take much less time than loading the program
> > > and debugging it, as you just reported.
> > >
> > > Keeping the reports of warnings to zero as a matter of policy,
> > saves your
> > > time (and frustration)!
> > >
> > > Steve
> >
> >
> >
> > --------------------
> >
> >
> >
> > ">http://docs.yahoo.com/info/terms/
> >
> >
> >
> >
> >
> >
> >
> > --------------------
> >
> >
> >
> > ">http://docs.yahoo.com/info/terms/
> >
> > -------------------- >
> ">http://docs.yahoo.com/info/terms/
Reply by Erich Styger ●March 28, 20032003-03-28
Hello Pat,
about C12056: see the documentation provided on this one (see previous
post).
In your code it may be because of common code optimization (which could
result
in some pretty tricky stack operations).

Erich

> -----Original Message-----
> From: Pat Fitzpatrick [mailto:]
> Sent: Freitag, 28. Marz 2003 00:30
> To:
> Subject: Re: [68HC12] Metrowerks Disassembly Obfuscation - Help! > Hi list, > I agree in principle, having been burned more than I ought to be
> by ignoring warnings. However, I don't know what to do about the
> following CodeWorrier warning:
>
> Warning : C12056 : SP debug info incorrect because of
> optimization or inline assembler.
>
> Anyhow, there's no inline assembler and the code seems to work
> just fine so I presume it's a result of some ooptimization or
> other. I get rid of it with a #pragma, but it's still a little worrying.
>
> Can anyone explain what this message is really trying to tell
> me?? And if I ought to be concerned about it at all? And even how
> I might get rid of it by modifying the source code?
>
> thanks,
>
> Pat > Steve Russell wrote:
>
> > Hi Paul,
> >
> > Let me add my voice to the chorus and explain why I compile with the
> > highest warning level available, and keep the warnings to zero.
> >
> > As others have pointed out, it is easy to prevent a warning from being
> > printed, either by using a #pragma or by adding a cast or
> redundant assignment.
> >
> > So suppressing the ones that you have determined you are not
> interested in
> > one by one is pretty easy.
> >
> > The advantage is that when you add new code with that produces
> a warning,
> > you get told about it by the compiler, and you can easily fix
> it, because
> > the compiler is pretty good about pointing to exactly where the
> problem is.
> >
> > Sometimes the problem is obvious and a quick edit will fix it.
> >
> > Sometimes the problem is that you really don't understand some
> C feature,
> > and you have to study the manuals. In this case you learn something.
> >
> > Sometimes its just the compiler being picky, and you can make it shut up
> > with a quick edit.
> >
> > On the average all of these take much less time than loading the program
> > and debugging it, as you just reported.
> >
> > Keeping the reports of warnings to zero as a matter of policy,
> saves your
> > time (and frustration)!
> >
> > Steve >
> -------------------- >
> ">http://docs.yahoo.com/info/terms/