Hi,

after porting and successfull testinig of a project i have two sorts of 
strange warnings left:

gcc version 3.2.3:
main.c:1526: warning: concatenation of string literals with __FUNCTION__ 
is deprecated
handler.c:43: warning: concatenation of string literals with 
__FUNCTION__ is deprecated

these lines are:
 _BIS_SR_IRQ (LPM3_bits);  // Change the SR register on the stack, 
within interrupt service routine.
_BIC_SR_IRQ (LPM4_bits);      // Change the SR register on the stack, 
within interrupt service routine.

IAR 1.26:
Linking...
Warning[w6]: Type conflict for external/entry "atoi", in module main 
against external/entry in module ?atoi; different types
Warning[w6]: Type conflict for external/entry "sprintf", in module
check 
against external/entry in module ?sprintf; different types
Warning[w6]: Type conflict for external/entry "strcmp", in module main

against external/entry in module ?strcmp; different types
Warning[w6]: Type conflict for external/entry "strcpy", in module main

against external/entry in module ?strcpy; different types
Warning[w6]: Type conflict for external/entry "strlen", in module
check 
against external/entry in module ?strlen; different types
Warning[w6]: Type conflict for external/entry "strncpy", in module
check 
against external/entry in module ?strncpy; different types
 
Any ideas?

Rolf F.

Rolf,

> after porting and successfull testinig of a
project i have 
> two sorts of 
> strange warnings left:
> 
> gcc version 3.2.3:
> main.c:1526: warning: concatenation of string literals with 
> __FUNCTION__ 
> is deprecated
> handler.c:43: warning: concatenation of string literals with 
> __FUNCTION__ is deprecated
> 
> these lines are:
>  _BIS_SR_IRQ (LPM3_bits);  // Change the SR register on the stack, 
> within interrupt service routine.
> _BIC_SR_IRQ (LPM4_bits);      // Change the SR register on the stack, 
> within interrupt service routine.

Get a decent compiler... ;-)  No idea, but __FUNCTION__ is a gcc-ism and
if you need access to the function name, you should use __func__.
However, that doesn't explain what's happening with _BIS_SR_IRQ,
perhaps
you need to preprocess the file or look at the definition of these
intrinsics/macros?

> IAR 1.26:
> Linking...
> Warning[w6]: Type conflict for external/entry "atoi", in module
main 
> against external/entry in module ?atoi; different types
> Warning[w6]: Type conflict for external/entry "sprintf", in 
> module check 
> against external/entry in module ?sprintf; different types
> Warning[w6]: Type conflict for external/entry "strcmp", in 
> module main 
> against external/entry in module ?strcmp; different types
> Warning[w6]: Type conflict for external/entry "strcpy", in 
> module main 
> against external/entry in module ?strcpy; different types
> Warning[w6]: Type conflict for external/entry "strlen", in 
> module check 
> against external/entry in module ?strlen; different types
> Warning[w6]: Type conflict for external/entry "strncpy", in 
> module check 
> against external/entry in module ?strncpy; different types
>  
> Any ideas?

Perhaps atoi and friends have been mis-prototyped by #including an
errant header file or even declared with both a prototype and an
old-style function definition [int atoi()] which are incompatible.  The
IAR linker has picked this up and is complaining?

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

I get the same warnings, and looking for some relief from these 
warnings I came across a manual page 
http://mspgcc.sourceforge.net/manual/x1028.html

Good or bad, the manual says, "there are warnings, but the code is 
good".  Except for these warnings, I am liking the mspgcc compiler.  
Perhaps annoying bugs are how an open source project recruits 
developers though.


--- In msp430@msp4..., "Rolf F." <rolf.freitag@d...> wrote:
> Hi,
> 
> after porting and successfull testinig of a project i have two 
sorts of 
> strange warnings left:
> 
> gcc version 3.2.3:
> main.c:1526: warning: concatenation of string literals with 
__FUNCTION__ 
> is deprecated
> handler.c:43: warning: concatenation of string literals with 
> __FUNCTION__ is deprecated
> 
> these lines are:
>  _BIS_SR_IRQ (LPM3_bits);  // Change the SR register on the stack, 
> within interrupt service routine.
> _BIC_SR_IRQ (LPM4_bits);      // Change the SR register on the 
stack, 
> within interrupt service routine.
> 
> IAR 1.26:
> Linking...
> Warning[w6]: Type conflict for external/entry "atoi", in module 
main 
> against external/entry in module ?atoi; different
types
> Warning[w6]: Type conflict for external/entry "sprintf", in
module 
check 
> against external/entry in module ?sprintf;
different types
> Warning[w6]: Type conflict for external/entry "strcmp", in module

main 
> against external/entry in module ?strcmp;
different types
> Warning[w6]: Type conflict for external/entry "strcpy", in module

main 
> against external/entry in module ?strcpy;
different types
> Warning[w6]: Type conflict for external/entry "strlen", in module

check 
> against external/entry in module ?strlen;
different types
> Warning[w6]: Type conflict for external/entry "strncpy", in
module 
check 
> against external/entry in module ?strncpy;
different types
>  
> Any ideas?
> 
> Rolf F.

Hi,

> > IAR 1.26:
> > Linking...
> > Warning[w6]: Type conflict for external/entry "atoi", in
module main 
> > against external/entry in module ?atoi; different types
> > Warning[w6]: Type conflict for external/entry "sprintf", in 
> > module check 
> > against external/entry in module ?sprintf; different types
> > Warning[w6]: Type conflict for external/entry "strcmp", in 
> > module main 
> > against external/entry in module ?strcmp; different types
> > Warning[w6]: Type conflict for external/entry "strcpy", in 
> > module main 
> > against external/entry in module ?strcpy; different types
> > Warning[w6]: Type conflict for external/entry "strlen", in 
> > module check 
> > against external/entry in module ?strlen; different types
> > Warning[w6]: Type conflict for external/entry "strncpy", in 
> > module check 
> > against external/entry in module ?strncpy; different types
> >  
> > Any ideas?
> 
> Perhaps atoi and friends have been mis-prototyped by #including an
> errant header file or even declared with both a prototype and an
> old-style function definition [int atoi()] which are incompatible.  The
> IAR linker has picked this up and is complaining?

The problem is present with the same project under MS-Win98 and not under
MS-WinXP but with WinXP the dongle can be used only 3/4 year. After the timeout
i get random errors (dongle not found, wrong dongle, license error, no valid
license found) with no change after reboots/cleaning of the dongle. That's
the reason why i had to change to MS-Win98 (and another computer). Now the
dongle works fine but the linker complains.

It seems that's another bug because today i found another error: A union
can be initialized (without warning/error) without braces ( T_union u = 1; works
although K&R and ANSI say only T_union1 u = {1}; is right).

Rolf

Hi Rolf!

> after porting and successfull testinig of a
project i have two sorts of 
> strange warnings left:

> IAR 1.26:
> Linking...
> Warning[w6]: Type conflict for external/entry "atoi", in module
main
> against external/entry in module ?atoi; different types
> Warning[w6]: Type conflict for external/entry "sprintf", in
module check
> against external/entry in module ?sprintf; different types
> Warning[w6]: Type conflict for external/entry "strcmp", in module
main
> against external/entry in module ?strcmp; different types
> Warning[w6]: Type conflict for external/entry "strcpy", in module
main
> against external/entry in module ?strcpy; different types
> Warning[w6]: Type conflict for external/entry "strlen", in module
check
> against external/entry in module ?strlen; different types
> Warning[w6]: Type conflict for external/entry "strncpy", in
module check
> against external/entry in module ?strncpy; different types

It looks like there is a mismatch between how your application sees
these functions and how they are defined in the library.  (As a side
note: our linker actually performs full type checking when linking an
application -- this is a feature that I haven't seen anywhere else!)

This can occur, for example, if the program uses these functions
without first declaring them, or if the declaration somehow is
different from the standard one.  You can start by first eliminating
all the obvious stuff, like checking that the your source code
contains #include statement for the appropriate files and, if so,
there are no "ghost" header files (i.e. files the the same name as the
standard header files) laying around.

Also, you can look in the linker list file (the .map file) for more
information, in that file the full type of the conflicting functions
will be listed -- maybe that can give you a clue.

    -- Anders Lindgren, IAR Systems
-- 
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

Hi Anders,

>>Warning[w6]: Type conflict for external/entry
"strncpy", in module check
>>against external/entry in module ?strncpy; different types
>>    
>>
>
>It looks like there is a mismatch between how your application sees
>these functions and how they are defined in the library.  (As a side
>note: our linker actually performs full type checking when linking an
>application -- this is a feature that I haven't seen anywhere else!)
>
>This can occur, for example, if the program uses these functions
>without first declaring them, or if the declaration somehow is
>different from the standard one.  You can start by first eliminating
>all the obvious stuff, like checking that the your source code
>contains #include statement for the appropriate files and, if so,
>there are no "ghost" header files (i.e. files the the same name as
the
>standard header files) laying around.
>
>Also, you can look in the linker list file (the .map file) for more
>information, in that file the full type of the conflicting functions
>will be listed -- maybe that can give you a clue.
>  
>

i looked in the .map file but found no further information.
I finally found the reason by looking at the options and the standard: 
atoi and the other functions are functions of char* and i changed the 
project options from char = unsigned char to char = signed char. The 
linker complains about the not exactly fitting types (char * != unsigned 
char *). In future i will use only the ANSI types (int8_t, ... uint64_t) 
with a separate stdint.h (which includes stdint.h under gcc).
gcc and the 1.26 IAR version installed under WinXP don't care about it 
and i would expect this unnessisary type check only from a syntax 
checker like s
splint.

>I get the same warnings, and looking for some
relief from these 
>warnings I came across a manual page 
>http://mspgcc.sourceforge.net/manual/x1028.html

Thanks.

Rolf

Hi Rolf,

I have seen this type of error with Intel C compilers I used in the 80s and
early 90s.  It was caused by strict type checking of the library functions.
I had to fudge the header files because I was producing ROMable code which
was a different memory model type to the standard C Library type.

So try checkign the following:
- compiler memory model is set correctly
- you are including the right library for your memory model
- are including the right header files for the library
- you are including all the right include files so that none of the
functions are declared as int by default.  THis should generate a compiler
warning if they are turned on.

Good luck tracking it down.  These problems are really annoying when they do
crop up.

Kind Regards,

Ray

Hi Anders,

>It looks like there is a mismatch between how your
application sees
>these functions and how they are defined in the library.  (As a side
>note: our linker actually performs full type checking when linking an
>application -- this is a feature that I haven't seen anywhere else!)

The Intel C compiler toolset for the 8088/8086 used to do this.  Just a side
note.  I send a reply to Rolf before I read your reply.

Regards,

Ray

Hi,

i finally found the reason: The option for chars has changed char =unsigned char
to char == signed char. The linker files of the 1.26A 
version are hard coded for only char == unsigned char.

Rolf


Raymond Keefe schrieb:

>Hi Anders,
>
>  
>
>>It looks like there is a mismatch between how your application sees
>>these functions and how they are defined in the library.  (As a side
>>note: our linker actually performs full type checking when linking an
>>application -- this is a feature that I haven't seen anywhere
else!)
>>    
>>
>
>The Intel C compiler toolset for the 8088/8086 used to do this.  Just a side
>note.  I send a reply to Rolf before I read your reply.
>
>Regards,
>
>Ray
>
>
>
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>