From: SourceForge.net <no...@so...> - 2006-12-17 20:08:53
|
Bugs item #1617503, was opened at 2006-12-17 21:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1617503&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Frieder Ferlemann (frief) Assigned to: Nobody/Anonymous (nobody) Summary: pic16, printf, problem with "%b" Initial Comment: there are 2 problems related to %b on pic16. (%b is used to output at number at base 2 there) - buffer[16] is too small (would have to be at least 17 or 33 bytes) - there's a "%b" clash with the other ports. %b is used as a length indicator there and specifies that only one byte is popped of the stack. Both uses are not ANSI/ISO C standard, so may be difficult to decide for either one. I'd suggest to consider dropping the "binary" output format option for pic16 printf though, because a) it doesn't seem to be in wide-spread use (we'd otherwise probably have complaints about the buffer overflow) b) the additional resource use (33 bytes instead of 12 bytes which would be needed for a buffer for long octal) seems huge. Even gcc/glibc don't offer this format so why should an embedded device? c) there's a name clash within SDCC. And yet another nonstd letter would be needed for the byte popping functionality. (%hh is not equivalent to %b as popps an int and just outputs as char) Would it do harm to just remove it? (device/lib/pic16/libc/stdio/vfprintf.c line 121: else if(*ch == 'b')radix = 2;) Greetings, Frieder ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1617503&group_id=599 |