Conflicting types - Don't know why

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Freakrs,

 

I copied the following from a working project:

 

//send complete API frame
	//Preamble
	for(uint8_t i = 0; i < sizeof preamble; i++)
	{
		usart_putchar1(preamble[i]);
	}
	
	//frame types and destination address
	for(uint8_t i = 0; i < sizeof lamp_addr[lamp]; i++)
	{
		usart_putchar1(lamp_addr[j][i]);
	}
	
	//variables
	usart_putchar1(lamp);
	usart_putchar1(intensity);
	usart_putchar1(cmd);
	usart_putchar1(0x0D);
	usart_putchar1(CRC);
	
}

void usart_putchar1(uint8_t c)
{
	while ((UCSR1A & DATA_REGISTER_EMPTY)==0);
	UDR1=c;
}

 

Here is what is in the 'preamble':

uint8_t preamble[] = {0x7E, 0x00, 0x12};

 

And in the 'lamp_addr':

uint8_t lamp_addr[3][14] = {
	{0x10, 0x00, 0x00, 0x13, 0xA2, 0x00, 0x41, 0x05, 0xA2, 0xF1, 0xFF, 0xFE, 0x00, 0xC0},
	{0x10, 0x00, 0x00, 0x13, 0xA2, 0x00, 0x41, 0x05, 0xA2, 0xA4, 0xFF, 0xFE, 0x00, 0xC0},
	{0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFE, 0x00, 0xC0}
};

when I hit BUILD, I get the following warning:

Severity Code Description Project File Line

Warning implicit declaration of function 'usart_putchar1' [-Wimplicit-function-declaration] Starlight_Controller C:\Users\jgmDESIGNS-Laptop\Documents\Roger Nedel\Engineering\Master Projects\Starlight_Controller\Starlight_Controller\Starlight_Controller\main.c 205

 

Warning conflicting types for 'usart_putchar1' Starlight_Controller C:\Users\jgmDESIGNS-Laptop\Documents\Roger Nedel\Engineering\Master Projects\Starlight_Controller\Starlight_Controller\Starlight_Controller\main.c 209

the first warning points to:

 

//send complete API frame
	//Preamble
	for(uint8_t i = 0; i < sizeof preamble; i++)
	{
		usart_putchar1(preamble[i]);
	}

and the second warning points to:

oid usart_putchar1(uint8_t c)
{
	while ((UCSR1A & DATA_REGISTER_EMPTY)==0);
	UDR1=c;
}

 

 

Do not understand why I am getting the waring, which to me is a potential error.

 

any suggestions?

 

JIm

This topic has a solution.

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

Last Edited: Tue. Apr 24, 2018 - 05:23 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Its the old, tried and true, C requirement that functions must be declared or defined before they are used. put_char() is not declared,  anywhere, and the definition is after it is used.

 

Just put a declaration before the code and it will be happier.

 

When the warning or error is about conflicting types, it refers to the returned value, pretty sure. This may arise because there is no declaration.

 

The first warning can arise when the  function is in a different code module (file) and you forgot  to #include the header file within the one containing the reference. Or, if forgot to put the declaration into the header or if there is a difference (example upper/lower case) between the definition and the declaration or several other things.

 

Jim

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Tue. Apr 24, 2018 - 04:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
functions must be declared or defined before they are used.

Indeed.

And not just functions - any symbol must be declared before it is used.

 

Because it didn't find an actual, explicit, declaration, the compiler created an implicit - default - declaration for you.

 

Then, when it did find your actual declaration, it didn't match the default that the compiler made up - hence the mismatch.

 

Just put a declaration before the code and it will be happier.

aka, a function prototype.

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To add to what Jim says. If C sees a function it has not yet been told about it assumes the interface is:

int fn();

So when it later comes to the actual delaration/definition:

void fn(uint8_t c)

then that does not match in two ways. It doesn't have the int return that C assumed and it has a parameter that C was not expecting.

 

As always one error (or warning) leads to another. The actual fault here - and the thing you needed to fix which would caused the other problems to go away was:

Warning implicit declaration of function 'usart_putchar1' 

Once you removed the implicit declaration any other "knock on" effect such as

Warning conflicting types for 'usart_putchar1' 

would then go away.

 

This is one of the many reasons I don't like "Error List" in Visual Studio because it has a habit of reordering things. The only thing you should ever concentrate on is the FIRST warning/error that came out of the build. Often fixing one will fix the next 200 things listed. So just scan the "Output" and look for the first thing that comes up and concentrate on that. This is why I would always aim for a "clean" build with no warnings because then it really is the very first thing in the build output that looks wrong that needs fixing first.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
This is one of the many reasons I don't like "Error List" in Visual Studio because it has a habit of reordering things. 

Likewise with Eclipse.

 

angry

 

These things must be written by programmers - so you'd have thought that they'd realise immediately how stupid this is?!

 

<rolls-eyes>

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
Its the old, tried and true, C requirement that functions must be declared or defined before they are used. put_char() is not declared,  anywhere, and the definition is after it is used.   Just put a declaration before the code and it will be happier.

 

Oh foo! I missed that!  Very embarrassing...angry

 

Thanks Cliff and Andy as well.

 

Jim

 

Edit:  I was not completely accurate...The code I used DOES work, and compile without errors or warnings.  In the 'working' app I have the functions in warning at the beginning of the code, as opposed to what I posted and have in this app.  My error.

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

Last Edited: Tue. Apr 24, 2018 - 05:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I mis-wrote, slightly. For functions, that is a "prototype", as was stated in #3. The effect does not change, however.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How are you getting

for(uint8_t i = 0; i < sizeof preamble; i++)

to compile without errors?  Unless this is some programming language I've never seen before 'sizeof' needs parenthesis around preamble.

Letting the smoke out since 1978

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

digitalDan wrote:

How are you getting

for(uint8_t i = 0; i < sizeof preamble; i++)

to compile without errors?  Unless this is some programming language I've never seen before 'sizeof' needs parenthesis around preamble.

Dunno...  But if I put the parentheses around 'sizeof' I get an arror

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah, you're using c++ which I've seen but not used very much.smiley

Letting the smoke out since 1978

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

digitalDan wrote:
Ah, you're using c++

Ummm, no.  I think GCC.

 

Jim

 

Edit:

Maybe you were thinking:

sizeof(preamble)

That compiles without any hiccups

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

Last Edited: Tue. Apr 24, 2018 - 06:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
Ummm, no. I think GCC.
GCC is a multi headed beast and can be made to conform to many different versions of C and C++ standards, and even other languages.

The version I have supports:

       -std=
           Determine the language standard.   This option is currently only
           supported when compiling C or C++.

           The compiler can accept several base standards, such as c90 or c++98,
           and GNU dialects of those standards, such as gnu90 or gnu++98.  When a
           base standard is specified, the compiler accepts all programs following
           that standard plus those using GNU extensions that do not contradict
           it.  For example, -std=c90 turns off certain features of GCC that are
           incompatible with ISO C90, such as the "asm" and "typeof" keywords, but
           not other GNU extensions that do not have a meaning in ISO C90, such as
           omitting the middle term of a "?:" expression. On the other hand, when
           a GNU dialect of a standard is specified, all features supported by the
           compiler are enabled, even when those features change the meaning of
           the base standard.  As a result, some strict-conforming programs may be
           rejected.  The particular standard is used by -Wpedantic to identify
           which features are GNU extensions given that version of the standard.
           For example -std=gnu90 -Wpedantic warns about C++ style // comments,
           while -std=gnu99 -Wpedantic does not.

           A value for this option must be provided; possible values are

           c90
           c89
           iso9899:1990
               Support all ISO C90 programs (certain GNU extensions that conflict
               with ISO C90 are disabled). Same as -ansi for C code.

           iso9899:199409
               ISO C90 as modified in amendment 1.

           c99
           c9x
           iso9899:1999
           iso9899:199x
               ISO C99.  Note that this standard is not yet fully supported; see
               <http://gcc.gnu.org/c99status.html> for more information.  The
               names c9x and iso9899:199x are deprecated.

           c11
           c1x
           iso9899:2011
               ISO C11, the 2011 revision of the ISO C standard.  Support is
               incomplete and experimental.  The name c1x is deprecated.

           gnu90
           gnu89
               GNU dialect of ISO C90 (including some C99 features). This is the
               default for C code.

           gnu99
           gnu9x
               GNU dialect of ISO C99.  When ISO C99 is fully implemented in GCC,
               this will become the default.  The name gnu9x is deprecated.

           gnu11
           gnu1x
               GNU dialect of ISO C11.  Support is incomplete and experimental.
               The name gnu1x is deprecated.

           c++98
           c++03
               The 1998 ISO C++ standard plus the 2003 technical corrigendum and
               some additional defect reports. Same as -ansi for C++ code.

           gnu++98
           gnu++03
               GNU dialect of -std=c++98.  This is the default for C++ code.

           c++11
           c++0x
               The 2011 ISO C++ standard plus amendments.  Support for C++11 is
               still experimental, and may change in incompatible ways in future
               releases.  The name c++0x is deprecated.

           gnu++11
           gnu++0x
               GNU dialect of -std=c++11. Support for C++11 is still experimental,
               and may change in incompatible ways in future releases.  The name
               gnu++0x is deprecated.

           c++1y
               The next revision of the ISO C++ standard, tentatively planned for
               2017.  Support is highly experimental, and will almost certainly
               change in incompatible ways in future releases.

           gnu++1y
               GNU dialect of -std=c++1y.  Support is highly experimental, and
               will almost certainly change in incompatible ways in future
               releases.

"sizeof" is an operator. It is not a function. Therefore the parantheses are optional, just as they can be used in about any expression, just like:

int Hello = (3) + (5);

@digitalDan:

Are you sure you get an error if you omit the parentheses? Have you tried?

I think it is more of a habit, you see it once with parentheses used somewhere and that just sinks into your unconcious memory.

Every now and then you also see return parameter encapsulated in parentheses, while those are also purely optional.

 

In this tutorial sizeof is used both with and without the parentheses:

https://www.sanfoundry.com/c-tutorials-sizeof-operator-mention-type-value-return/

To be sure you should read the official standard, but those are usally written in a too formal language for my poor head.

 

Edit / addition:

After Joey's post I did a few simple tests with this code:

#include <stdio.h>

int main( void) {

	int array [3];
	int asize = sizeof array;	// OK.
	int isize = sizeof (int);	// Error without parentheses

	printf(" %d %d \n", asize, isize);
	return 0;
}

Output on my linux box is:

 12 4 

It seems simpler to simply always use the parentheses.

(Edit: Typo: "ellipses" -> "parentheses").

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

Last Edited: Tue. Apr 24, 2018 - 10:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Parenthesis are optional for objects, mandatory for types.

 

 

K&R:

C provides a compile-time unary operator called sizeof that can be used to compute the size
of any object. The expressions

 

sizeof object

 

and

 

sizeof (type name)

unary-expression:
  postfix expression
  ++ unary expression
  -- unary expression
  unary-operator cast-expression

  sizeof unary-expression
  sizeof (type-name) 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:

Parenthesis are optional for objects, mandatory for types.

 

There's the new thing I learned today.  Thanks!

 

Since parenthesis can always be used I guess most programmers adopt that style?  Might explain why I've never seen sizeof without parenthesis before today (not that I've looked).

 

PS sorry for adding noise to the thread.

Letting the smoke out since 1978

 

 

 

 

Last Edited: Tue. Apr 24, 2018 - 07:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

digitalDan wrote:

joeymorin wrote:

Parenthesis are optional for objects, mandatory for types.

 

There's the new thing I learned today.  Thanks!

 

 

That makes 2 of us. I thought parenthesis were always needed.