gcc compilation flag about char's sign


#1

Hello to everyone,

I’m porting my application from OAT 3.02 (EDLib) to OAT 3.12 and WIP library on a Fastrack 1306B (firmware 6.57).

I’m using Visual C++ and I don’t have any warnings in Debug mode.
Using gcc in Wismo Target mode, I’m facing many warnings like :
“warning: pointer targets in passing argument 1 of ‘strlen’ differ in signedness”
I don’t like warnings :smiley: I think it’s related to the default sign of char.
‘unsigned char’ ? ‘signed char’ ?

does anyone succeed to use gcc compilation flag to force char’s sign ?


#2

you can cast it :wink:

(char)variable


#3

Yes, I am just doing almost exactly the same thing - I’m going from v3.03 to v3.12.

In fact, that is the only warning I get - but lots of them!

The warnings didn’t happen with OAT v3.03 - it seems that Wavecom are now using a different version of GCC (4.0.1) , and it’s more picky about this!

Absolutely - especially when there’s 93 of them! :open_mouth:

I think you’re right, but the warnings happen only in function calls wherever I’ve passed a specifically unsigned char actual parameter, but the function has an unadorned char formal parameter - particularly the standard string functions like strlen, strcpy, etc (and the wm_… equivalents).

Note that it only happens with pointers to char.

I couldn’t find anything.

I tried adding -funsignedchar to the GCC options, but it made no difference - it seems that this doesn’t affect references via pointers.

The only solution I’ve come up with is to go through all my definitions and make sure that I use plain char where the data type is really “text/characters”, and only specify signed/unsigned where the data is pure binary numerical values.

Note that Wavecom provide the ascii typedef for this purpose - so the 3 types are:
ascii - ASCII-coded text/characters;
u8 - unsigned 8-bit binary data;
s8 - signed 8-bit binary data.

You will then just have to add a few casts where you pass ascii variables to funcions that handle data just as binary bytes; eg, adl_fcmSendData.


#4

The really annoying thing is that neither the MS Visual Studio nor the Eclipse projects allow you to just double-click on the message to go straight to the affected source line. :angry:

They’ve managed to set-up Eclipse to do that with the Remote build, so why couldn’t they do it for the Target (GCC) build? :angry:

Does anyone know how to set this up properly in Eclipse?
Or even in Visual Studio?


#5

this is not true, in visual studio you can do that, but to do this double click in results window not in task window and the line it will be selected and show, i am talking about visual studio 2003, i do not know in previuos versions.


#6

Ah - I omitted to say that I meant specifically the GCC messages (ie, the Target build) under MSVC.

Yes, clicking the Remote Build messages (ie, the actual MS compiler messages) does work fine :smiley:
it’s just the Target Build messages (ie, messages from the GCC compiler) that don’t :frowning:

Sorry?
I don’t have a ‘Results’ Window! :confused:

I have an ‘Output’ window:
clicking MS messages (Remote build) in the ‘Output’ window works :smiley:
clicking GCC messages (Target build) in the ‘Output’ window doesn’t :frowning:

I’m using Visual Studio 2003 Version 7.1.3088


#7

yeahh it does not work for the wismo target version but anyway they give you the file and the line number, easy to go there.

about results and output, i think it is the same window, i have not an english version and the traslation for me it is results. but this is the only one from which can be done.


#8

Not difficult - but tedious.

Especially when you’ve got 93 warnings to plough through…! :frowning:

This is really such basic functionality for any so-called “IDE” these days that they shouldn’t even have considered releasing it without this working! :angry:

It must be over ten years since I last had to suffer a development environment where you had to manually seek to the errored file & line - and it was considered archaic even then! :open_mouth:

Ah - I understand!