Zsh Mailing List Archive
Messages sorted by:
Re: PATCH: printf builtin
- X-seq: zsh-workers 15875
- From: Oliver Kiddle <okiddle@xxxxxxxxxxx>
- To: Zsh hackers list <zsh-workers@xxxxxxxxxx>
- Subject: Re: PATCH: printf builtin
- Date: Tue, 25 Sep 2001 18:17:25 +0100
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <87.1001328606@xxxxxxx>
- Sender: kiddleo@xxxxxxxxxxxxxxxx
Peter Stephenson wrote:
> It does seem to be that, since everything looks OK up to the call to
> printf. As a test, I got it to work with a nasty hack using a void * and
> separate variables for different types.
Could you please send me this `nasty hack'. I'd prefer to get something
which works and has all the features required by POSIX, commit it and
then worry about the many possible improvements as and when I have time
and feel inclined to do them.
> One problem I can see is that val has an element `zlong'. Unfortunately on
> 32-bit machines with the default --enable-lfs, whether or not actual large
> file support is available, that's usually a long long, i.e. 64-bits. This
> will certainly confuse printf with a simple `%d' --- Solaris supports
Right. I should have just used an int then it seems.
> `%lld' but that's unlikely to be completely portable. I'm afraid that's
> another argument for handling the printf codes internally. However, if we
I don't dispute that handling printf codes internally would be a good
thing to be doing eventually but my initial aim was just to have the
POSIX functionality and it shouldn't be necessary for that.
Judging by certain aspects of their behaviour I suspect other printf(1)
implementations are using the underlying printf(3) (with the possible
exception of bash).
> use matheval(), the only basic numeric types we need to handle are doubles
> and zlongs, plus some casting to unsigned: check Src/Builtins/rlimits.c for
Would you then suggest that in the final implementation, `%d' would
format a zlong and that we wouldn't bother with any size modifiers (or
just ignore them). It would seem sensible because C only needs size
modifiers because the parameters can be of various types.
> However, there seems to be another problem, since changing that to long or
> int (which are supposed to be the same here but I'm paranoid --- although
> strictly we should enforce %ld if we pass on a long) doesn't help.
Sorry. Are you saying that it still doesn't work with an int? That
wouldn't make sense.
This message has been checked for all known viruses by the
MessageLabs Virus Scanning Service. For further information visit
Messages sorted by: