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