Understanding GCC

[lpcware]

Content originally posted in LPCWare by RA1981 on Thu Jun 02 00:24:13 MST 2011
Hi,

I'm still getting familiar with Cortex-M controllers, currently still on a beginners level, moving from 8-bit 8051/8052 derivates to Cortex :)

I'm having trouble to find a GCC manual regarding how GCC manages variables and their types etc. I searched the online documentation (http://gcc.gnu.org/onlinedocs/gcc/index.html) but couldn't find any answers - this documentation is very large and I assume it's perhaps the wrong documentation for me.

The current problem is as follows:
I want to write some UART functions for sending and receiving characters.
Simple test program which simply echoes back the incoming data works well.

But transmitting hardcoded texts throws a warning on build process:

---

Quote:
pointer targets in passing argument 1 of 'UART_PUTTXT' differ in signedness

---

The function prototype:

---

Quote:
void UART_PUTTXT(uint8_t *ucpData);

---

The function call:

---

Quote:
UART_PUTTXT("Hello World");

---

This worked many times well on the 8-bitters...

Changing to 'int8_t' doesn't help, but changing to 'char' removed the warning. A function which only sends a single character accepts 'uint8_t'.
So there are a few question:
- why is 'char' accepted without warning but uint8_t/int8_t are not accepted? I thought a 'char' is the same as 'int8_t', which is declared in 'stdint.h' as signed char? So I have to know more about the interna of GCC :)
- where can I find a tutorial/manual or something similar which enables me to solve such problems myself?

Regards,

Ralf

[lpcware]

Content originally posted in LPCWare by RA1981 on Fri Jun 03 05:19:23 MST 2011
Hi John,

---

Quote:
Since your [I]UART_PUTTXT [/I]function receives char strings then you  should use the appropriate type which is char *.

---

Done ;)

---

Quote:
When you need to pass  in more then one type then you can use a void pointer in the parameter  to avoid needing to typecast the value passed in.

---

Hm... That would be something I have to play a little with :)

Regards,

Ralf

[lpcware]

Content originally posted in LPCWare by atomicdog on Thu Jun 02 23:01:39 MST 2011

---

Quote: RA1981
Hi all,  thank you for your answers.

So, what would be best way to solve my "problem"? Since it's machine-depending I'd assume to use simply char instead of uint8_t/int8_t. For my text transmission functions it doesn't matter using simply char. And for other functions where signedness is relevant I use uint8_t/int8_t :)

Thank you all for the help.

Regards,  Ralf

---

This issue isn't machine-depended (although related) it only has to do with the C standard. Some other compilers will also give similar warnings.
Your function parameter should match the type of value you're passing to it.
Since your [I]UART_PUTTXT [/I]function receives char strings then you should use the appropriate type which is char *. When you need to pass in more then one type then you can use a void pointer in the parameter to avoid needing to typecast the value passed in.

[lpcware]

Content originally posted in LPCWare by RA1981 on Thu Jun 02 22:23:48 MST 2011
Hi all,  thank you for your answers.

So, what would be best way to solve my "problem"? Since it's machine-depending I'd assume to use simply char instead of uint8_t/int8_t. For my text transmission functions it doesn't matter using simply char. And for other functions where signedness is relevant I use uint8_t/int8_t :)

Thank you all for the help.

Regards,  Ralf

[lpcware]

Content originally posted in LPCWare by atomicdog on Thu Jun 02 14:18:33 MST 2011

---

Quote: larryvc
I'm not disagreeing with you John, just asking for clarification.:)

Is the GCC used with the LPCXpresso IDE C99 compliant?

I know that Redlib is C90 and Newlib is C99.

---

Yeah, the C compiler for gcc has supported C99 for a while now.
LPCXpresso 3.6.3.117 uses gcc version 4.3.3.

It may also be in the previous standards but I've never read them.

[lpcware]

Content originally posted in LPCWare by larryvc on Thu Jun 02 13:26:38 MST 2011

---

Quote: atomicdog
This has to do with the C standard (C99).

---

I'm not disagreeing with you John, just asking for clarification.:)

Is the GCC used with the LPCXpresso IDE C99 compliant?

I know that Redlib is C90 and Newlib is C99.

[lpcware]

Content originally posted in LPCWare by atomicdog on Thu Jun 02 13:06:46 MST 2011

---

Quote: RA1981

Changing to 'int8_t' doesn't help, but changing to 'char' removed the warning. A function which only sends a single character accepts 'uint8_t'.
So there are a few question:
- why is 'char' accepted without warning but uint8_t/int8_t are not accepted? I thought a 'char' is the same as 'int8_t', which is declared in 'stdint.h' as signed char? So I have to know more about the interna of GCC :)
- where can I find a tutorial/manual or something similar which enables me to solve such problems myself?

Regards,

Ralf

---

This has to do with the C standard (C99). There is actually three char types. char, unsigned char, and signed char. You can set char to [U]behave[/U] like a signed/unsigned char but it's still a separate type.
"hello World" is a char string literal which is neither a signed char or unsigned char type so you get a warning.

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Thu Jun 02 03:02:27 MST 2011
There are two options in GCC for controlling the type of a 'char':

From the docs:

---

Quote:

-funsigned-char
Let the type char be unsigned, like unsigned char.       Each kind of machine has a default for what char should be.  It is either like unsigned char by default or like signed char by default.      
Ideally, a portable program should always use signed char or unsigned char when it depends on the signedness of an object.  But many programs have been written to use plain char and expect it to be signed, or expect it to be unsigned, depending on the machines they were written for.  This option, and its inverse, let you make such a program work with the opposite default.      
The type char is always a distinct type from each of signed char or unsigned char, even though its behavior is always just like one of those two.      

-fsigned-char
Let the type char be signed, like signed char.       Note that this is equivalent to -fno-unsigned-char, which is the negative form of -funsigned-char.  Likewise, the option -fno-signed-char is equivalent to -funsigned-char.      

---

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Thu Jun 02 02:55:33 MST 2011
According to the C standard, single-character constants (i.e. 'c') have the type int. Thus, your assignments are actually

a = 97; 
b = 98; 
c = 99;

Which don't cause any problems. You would have problems if you started assigning signed values to unsigned types. e.g.

b = -1 ;

BTW: This is all standard C and is nothing 'peculiar' about GCC.

[lpcware]

Content originally posted in LPCWare by Rob65 on Thu Jun 02 02:09:34 MST 2011
I've got the same 'problem'.
If you program something like this:

    signed char *a;
    unsigned char *b;

    char *c;

    a = "test";
    b = "test";
    c = "test";

then GCC will give a warning on both assignments of a and b, not on c.
Fair enough: if the standard choosen by the compiler can be either signed or unsigned it makes sense to warn about the assignment of a char (without classification) to one with classification.

But in the case of:

    signed char a;
    unsigned char b;

    char c;

    a = 'a';
    b = 'b';
    c = 'c';

I would assume similar warnings but here GCC is perfectly happy with my code.
Apparently pointers to char are more strict than chars :confused:

Rob

[lpcware]

Content originally posted in LPCWare by RA1981 on Thu Jun 02 01:37:34 MST 2011
Hi TheFallGuy,

thank you for your answer. The link seems to be helpful, giving a deeper insight of GCC.
I think I'll look for the german version and buy the book :)

Regarding the statement I don't understand why wether uint8_t nor int8_t works - from the statement I'd assume that one of these should work because they're typedefs of char.

Regards,

Ralf

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Thu Jun 02 01:11:50 MST 2011
I don't think this is anything to do with GCC, but more to do with it being ARM.

See
http://www.network-theory.co.uk/docs/gccintro/gccintro_71.html

Where it states that:

---

Quote:

The C and C++ standards allows the character type char to be signed or unsigned, depending on the platform and compiler.  Most systems, including x86 GNU/Linux and Microsoft Windows, use signed char, but those based on PowerPC and ARM processors typically use unsigned char.(29)  This can lead to unexpected results when porting programs between platforms which have different defaults for the type of char.

---