This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: A sniprintf question


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,


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]