Hi,
I'm assuming you meant to post this on the mailing list rather than just
to me. It's easy to press the "Reply" button on your mail program
rather than the "Reply All" - it's a mistake we've all made on occasion.
There was some good reason for the mailing list being configured the
way it is, but I've forgotten what it was.
And please don't strip attributions - for anyone reading this without
threading in their mail client, or people dipping in to the archives, it
is very hard to see who wrote what.
David VanHorn wrote:
>
>
>
> I used to have a colleague who had a large piece of foam rubber
> taped to his wall - it was labelled "bang your head here".
> Sometimes I think I need to get one of these myself.
>
>
> I'm sorry that I failed to provide what you asked for.
>
>
>
> The code you posted is *not* a code snippet that others can compile
> and test. It doesn't even use lcd_puts !!
>
>
> My typo, lcd_putc is the function in question. String or char, I would
> not expect either function to require signedness, and if a signed char
> worked, then I would expect int8_t to work.
>
That paragraph covers a number of points.
First, it is extremely difficult for others to guess which function you
are talking about if you repeatedly refer to a different function with a
similar name.
Secondly, it is up to the definition of the function whether it wants
signed char, unsigned char or plain char. I agree that plain char is
normally more natural for such functions, but I didn't write the code
for lcd_putc, or lcd_puts, and I have not seen the functions definitions
or declarations. So I haven't the faintest idea whether using "signed
char" was a sensible idea or not.
Thirdly, there is a huge difference between a char and a string (a
pointer to some flavour of char). If you are mixing up chars and
strings, there is no wonder you are having problems. If you ever get
round to posting useful code, someone will quickly tell you if you have
made such a mistake (although you may well spot it when preparing the
code snippet - people often spot small errors when re-writing for a code
snippet).
Fourthly, the error message you got referred to mixing a pointer to a
signed char with a pointer to an unsigned char, implying you are dealing
with strings. You would not get a warning about mixing a signed char
and an unsigned char with the flags you mentioned in your previous post
- that requires the -Wconversion flag as well.
You are entirely correct in your expectation that int8_t should give
identical warnings (or lack of warnings) to "signed char". My testing
showed that this is the case, at least in my test code. Either you are
misinterpreting something, or your code has errors, or you have found a
very obscure bug in gcc. That's why it's important to get your code and
find the root of your problem. It's certainly going to be of help to
you, and if it turns out to be a compiler issue, it's of great
importance to everyone here.
>
> Post a *minimal* code snippet that can be compiled. There should be
> an absolute minimum of #include lines, and never any #include's that
> don't come as part of a standard avr-gcc installation.
>
>
> I feel like you're expecting me to guess what the "rules" are for this.
> Have >I< not made it VERY clear that I am VERY new to C?
>
Yes, but are you VERY new to the English language? I have given you the
"rules" as simply and clearly as I can, and given you a simple and clear
demonstration of exactly what I mean.
Take the code you posted, save it in a file called "test.c" in an empty
directory, and run (from a command line prompt) avr-gcc on the file
using the flags you listed in your post. Will it compile? No, it will
fail because it does not have the file "lcd.h". Thus it is not a
compilable code snippet. Is the Delay_QS function relevant to the
discussion? No, thus it should not be there because we are looking for
a *minimal* code snippet. Is the definition (or at the very least, an
extern declaration) of lcd_putc and/or lcd_puts in the file? No, thus
we don't have the relevant code in the snippet.
Now do you see what I mean?
It's traditional to use car analogies in explanations - if you phone
your car garage and tell them your car is making a funny noise, and they
ask what it sounds like and when it makes the noise, do you tell them
the headlight bulb needs changed? No, of course you don't - you tell
them it makes a grinding noise whenever you change into reverse, and
then they have the useful information without the useless information.
>
>
> Putting #include "lcd.h" is totally, utterly useless - how are we
> supposed to guess what's in lcd.h ?? Perhaps it contains the
> declaration for lcd_puts() - the function you are needing help with?
>
>
> I wrote a minimal app that exercises the function, compiles, and
> generates the warning message.
> lcd.h is one of the support files that came with WinAVR.
> I don't know much about it other than the few functions that I'm using
> in my app.
> I'm not sure if it would compile and run with the other includes taken
> out or not.
>
Now we are beginning to get somewhere (not far, but somewhere). There
*is* an lcd.h file included in WinAVR - it's one of the examples
included in the avr-libc documentation, and is not part of the library
itself. It contains two function declarations :
void lcd_init(void);
int lcd_putchar(char c, FILE *stream);
Neither of these refers to signed char, neither is called lcd_puts or
lcd_putc, and neither is at all relevant here.
Assuming your code compiles, you have a different lcd.h file in your
project's directory. Maybe you didn't write it, but it came from
somewhere and it is (presumably) where the declaration for lcd_putc
and/or lcd_puts is to be found.
The point is that you should create a new file "test.c" in its own empty
directory, and copy-and-paste the minimal entries from the headers into
the start of the test.c file, so that you can compile the test code
*without* headers (except perhaps essential standard headers like
stdint.h). Such a code snippet does not need any delays, or any io
pins, or anything else not directly related to the question in hand.
>
>
> An example code snippet is shown below.
>
> With the flag -funsigned-char and appropriate warnings enabled, this
> gives - as expected - a warning "pointer targets in passing argument
> 1 of 'lcd_puts' differ in signedness" for lcd_test2, 3, and 4.
> Using uint8_t gives no warning, because it is the same as "signed
> char".
>
>
> That is exactly what I would expect, but not what's happening here.
>
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list