zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <okiddle@yahoo.co.uk>
To: Zsh hackers list <zsh-workers@sunsite.dk>
Subject: Re: printf
Date: Thu, 01 Nov 2001 18:17:25 +0000	[thread overview]
Message-ID: <3BE191B5.B4FDC8E8@yahoo.co.uk> (raw)
In-Reply-To: <13357.1004634977@csr.com>

Peter Stephenson wrote:
> 
> Oliver Kiddle wrote:
> > I'd like to be able to support the ' (thousand grouping)
> 
> The more I think about this, the more it seems to me that using quotes is
> simply going to cause grief (unless I've misunderstood).  Is there any
> reason for this rather than the perl version, `_', which isn't going to
> conflict with anything?

Ksh and many newer printf(3)s use the single quote but I agree with you
that it is a bad choice.

Is this `_' a new perl feature:
    perl -e 'printf "%_g\n",132643.45'
does not work with 5.0005_03 or am I putting the underscore in the
wrong place. We can always offer a choice of flag character here.

Going back to my questions earlier this week, fcvt() etc are a bad
idea. They don't exist everywhere, on some (BSD) systems, they are in
compat libraries and sprintf is seemingly just as good but more
available.

My idea of writing a function from scratch to format floats was also a
bad idea. I've been referred to http://plan9.bell-labs.com/netlib/fp as
example source. A brief glance was enough to appreciate that it would
be bloat and overkill as well as being not at all easy.

This returns me to using sprintf which should be okay.

The first issue is dealing with very large precisions specified for
floating point variables. To use sprintf, I would potentially have to
allocate a stupidly large amount of memory which I'd prefer to avoid.

Large widths are not an issue - I'll not use sprintf for the widths but
will just call putchar in a loop before or after outputting the
formatted argument. They might cause problems with print -s and -z
though. I could maybe truncate these to the maximum length a command
can be (how do I find that out again?).

One solution for dealing with large precisions would be to put a limit
on the precision. I can't really see why anyone would want something
like '%.10000f' anyway. An easy solution would be to allocate a buffer
for sprintf which is based on the maximum length of any argument and at
least say 100. You don't get any greater precision than about 60 with
doubles anyway. If someone tries '%.101g', they would then get a
warning that such precisions are not supported. Or I could just
truncate the number returned. Any views on these ideas?

To support the ' flag, I'll try a configure test to check for support
in printf(3) and otherwise, insert the separators retrospectively.

The second issue is working out what is going on with locales. Does
basic printf do locales on any platforms? The I flag is glibc 2.2. I'd
like to have the I flag in zsh and locales no used without it so that
users can rely on the output of printf. Unfortunately, every machine I
have access to seems to only have English locale data installed so it
is hard to work out what is happening.

Oliver

_____________________________________________________________________
This message has been checked for all known viruses by the 
MessageLabs Virus Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp


  reply	other threads:[~2001-11-01 18:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-30 16:23 printf Oliver Kiddle
2001-10-30 16:41 ` printf Peter Stephenson
2001-10-30 17:02   ` printf Oliver Kiddle
2001-11-01 17:16 ` printf Peter Stephenson
2001-11-01 18:17   ` Oliver Kiddle [this message]
2001-11-01 18:32     ` printf Peter Stephenson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3BE191B5.B4FDC8E8@yahoo.co.uk \
    --to=okiddle@yahoo.co.uk \
    --cc=zsh-workers@sunsite.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).