A sniprintf question

Jeff Johnston jjohnstn@redhat.com
Wed Aug 27 08:25:00 GMT 2008


No, appending should not happen.  The routine writes data starting at 
the location you give it.

I would suggest verifying that the USART_puts call is not changing the 
value of ui_buffer
inside the loop.  You should also verify that <stdio.h> is included and 
that ui_buffer is declared properly
(i.e. an array vs a pointer) so that sizeof(ui_buffer) is giving you the 
expected result: 256.  The return
code of sniprintf will tell you how many bytes were needed excluding 
null terminator.  If this comes back
256 or more, your buffer is too small.

You should be able to interchange sniprintf with sprintf (no length 
passed) if you want to verify
if there is a problem with sniprintf specifically.

-- Jeff J.

Artur Lipowski wrote:
> Hi,
>
> Is it expected that sniprintf in subsequent calls somehow "appends" 
> data to existing buffer?
>
> E.g.
>
> for (i=0; i<2; i++)
> {
>  sniprintf(ui_buffer, sizeof(ui_buffer),
>   "SSID: %-8s  freq: %lu00Hz  RSSI: %3udB  type: %u  %-6s  MAC: 
> %02X:%02X:%02X:%02X:%02X:%02X\n\r",
>   (const char*)ssid, freq, rssi, type,
>   is_secure ? "secure" : "open",
>   mac[0], mac[1], mac[2], mac[3], mac[4], mac[5]);
>  USART_puts(console, ui_buffer);
> }
>
> Then output is multiplied (except the last line when i == 1).
> If I put:
> ui_buffer[0] = '\0';
> before sniprintf then output looks good.
>
> BTW> ui_buffer is 256 bytes long, USART_puts is blocking (synchronous) 
> call and newlib snapshot is from 25.07.2008
>
>
> Regards,



More information about the Newlib mailing list