Strange sender log file characters
ssorce at redhat.com
Tue Sep 2 13:11:22 GMT 2008
On Mon, 2008-09-01 at 13:31 -0700, Wayne Davison wrote:
> On Sun, Aug 31, 2008 at 10:44:11PM -0400, Matt McCutchen wrote:
> > Wayne, you might want to consider applying this even though the
> > immediate problem is solved.
> Yeah, I had noticed that lack-of-negative number-handling deficiency
> when I was working on an enhancement for 3.1.0 to output numbers in
> 3-digit clusters (e.g. 1,234,567). I hadn't thought that I needed
> special handling of INT_MIN, though, so I fixed that. I've gone ahead
> and committed my enhancement to the 3.1.0 branch, and ported that
> improved negation fix from the trunk to the 3.0.x branch.
> I'm interesting in what folks think about my making the outputting of
> clustered numbers the default for 3.1.0 (see the --human-readable option
> in the 3.1.0 manpage for a full discussion of how it works and is
> overridden). The code attempts to intuit if it should use a comma or a
> period for the 3-digit clustering based on if sprintf() puts a period or
> a comma into a floating point number.
Reading the snprintf manpage (at least on Linux). It seem you don't have
to meka eany special manipulation to get the thousands separator but
just use the "'" modifer:
The five flag characters above are defined in the C standard. The
SUSv2 specifies one further flag character.
’ For decimal conversion (i, d, u, f, F, g, G) the output is to be
grouped with thousands’ grouping characters if the locale infor-
mation indicates any. Note that many versions of gcc(1) cannot
parse this option and will issue a warning. SUSv2 does not
The advantage of using a glibc function is that it uses the correct
locale settings for the thousands separator and does not require
Simo Sorce * Red Hat, Inc * New York
More information about the rsync