RE: [sdcc-devel]weird printf behaviour

[Scott H. <sh...@da...>]

Thanks..  That fixed my printf hex problem.  That isn't the way it works
with gcc, so I assumed it was a bug.  I'm still getting some weird behaviour
from printf and sprintf on a few strings.

I'm trying to compile tstfind.c from the 1-Wire public domain kit.  There's
a string which I changed from:
char return_msg[128];

to:
char msg_buf[128];
char _generic *return_msg = (char _generic*)&msg_buf[0];

Then it's sent to a function defined in owsesu.c:
int  owAcquire(int,char *,char *);

Which I changed all references to char * into char _generic *;

Yet still, I sprintf a few bits of text into the return_msg buffer and upon
return from that function call, the return_msg buffer contains whatever was
in that memory location from the last time I successfully put anything there
(i.e. from several test applications ago)...  but not the text inserted by
owAcquire.

In fact, it looks like:
  printf("return_msg=%s\r\n",(char _generic*)return_msg);>
  sprintf((char _generic*)return_msg, "testing");
  printf("return_msg=%s\r\n",(char _generic*)return_msg);

Shows no change to the return_msg.  Am I doing something wrong?

Thanks in advance...

Scott

--
Scott Hughes - sh...@da...
Engineer, Auto Information
Dallas Semiconductor



 -----Original Message-----
> From: sdc...@li...
> [mailto:sdc...@li...]On Behalf Of Kevin Vigor
> Sent: Wednesday, January 24, 2001 6:02 PM
> To: sdc...@li...
> Subject: RE: [sdcc-devel]weird printf behaviour
>
>
>
> On 24-Jan-2001 Scott Hughes wrote:
> > Thanks for the feedback about the pointer to the sfr.  Guess I'm stuck
>  But I'm seeing some pretty strange
> > behaviour
> > from printf.  With the following code:
> >  printf("%01X\r\n",0x0f);
>
> SDCC is passing the constant parameter 0x0f as a single byte; the %X
> format specifier wants an int argument. This may be a bug (I'm not sure
> offhand if the constant should be promoted to int), but in the meantime,
> you should be able to work around it either by typecasting the constant
> to int, or by using the 'b' modifier in your printf format string (btw, I
> believe this is non-standard and should be changed to 'h', which is
> standard, someday), like so:
>
>  printf("%01bX\r\n",0x0f);
>
> (I am not near a working TINI, so I can't actually test this right now).
>
>
> > one test program from the 1-Wire api, I have a string that I know to be
> > valid and it can be printed fine with puts(char*).  But use that same
> > string
> > with printf("%s",char*) and it hangs the tini.
>
> Probably a similar problem: the %s printf conversion expects a generic
> pointer to char. The following code will blow up:
>
>     char _xdata *str;
>     printf("%s",str);
>
> (quite apart from the fact that str is uninitialized) because str is
> passed to printf as an xdata * rather than a generic *.
>
> Because puts() has a proper prototype instead of a varargs ..., the
> compiler can do the proper conversions for you (if necessary).
>
> The only workaround for this one is an explicit typecast:
>
>     char _xdata *str;
>     printf("%s",(char _generic *)str);
>
> Take-home lesson here: varargs functions (like printf) are weird, and
> SDCC probably doesn't follow all the rules for argument promotion
> properly.
>
>         Peace,
>                 Kevin
>
>
> _______________________________________________
> sdcc-devel mailing list
> sdc...@li...
> http://lists.sourceforge.net/lists/listinfo/sdcc-devel