[avr-gcc-list] Re: Passing a string variable to lcd_puts

[David Brown]

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.
>