[quagga-dev 4394] Re: bgpd printf size_t warning

David Young dyoung at pobox.com
Sat Sep 23 19:33:23 BST 2006


On Sat, Sep 23, 2006 at 05:43:12PM +0100, Paul Jakma wrote:
> On Sat, 23 Sep 2006, Andrew J. Schorr wrote:
> 
> >On Fri, Sep 22, 2006 at 09:06:09PM +0100, Paul Jakma wrote:
> >>I'd prefer the cast to %z right now, just not supported widely
> >>enough.
> 
> Oops, I meant %lu.
> 
> >But that's not really a problem unless you're worried that casting 
> >a size_t to u_long is somehow problematic.  I don't see anything 
> >wrong with casting size_t to u_long, unless we end up trying to 
> >support a platform where size_t is wider than u_long.  Are you 
> >aware of any such platforms?
> 
> No, that's not my concern though.
> 
> My concern is that it will becom really difficult to find all the 
> printf()'s if/when %z becomes useable. Right now, it's obvious where 
> they are ;).
> 
> I.e. my concerns centre on the warnings actually having a (future) 
> use. :)

Paul,

I use some standard macros to print uint8_t, ..., uint64_t, called PRIu8,
..., PRIu64.  I'm not sure if ISO C99 defines them, or what.

Perhaps Quagga can introduce platform-dependent _PRISIZET and _PRISSIZET
for formatting size_t and ssize_t arguments, and _PRISIZET_ARG() and
_PRISSIZE_ARG() for optionally casting the arguments?  E.g.,

#define _PRISIZET		"lu"
#define _PRISIZET_ARG(__x)	((u_long)(__x))

zlog_warn ("peer_uptime (): buffer shortage %" _PRISIZET, _PRISIZET_ARG(len));

It's not pretty, but it gets the job done, and it eases a switch to %z
in the future.

(BTW, u_long, while prevalent, may not be standard.  I am not a C-language
lawyer. :-)

Dave

-- 
David Young             OJC Technologies
dyoung at ojctech.com      Urbana, IL * (217) 278-3933



More information about the Quagga-dev mailing list