From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9703 invoked from network); 25 Sep 2001 17:32:53 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 25 Sep 2001 17:32:53 -0000 Received: (qmail 9077 invoked by alias); 25 Sep 2001 17:32:46 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 15875 Received: (qmail 9065 invoked from network); 25 Sep 2001 17:32:46 -0000 X-VirusChecked: Checked Sender: kiddleo@cav.logica.co.uk Message-ID: <3BB0BC25.9BC2874F@yahoo.co.uk> Date: Tue, 25 Sep 2001 18:17:25 +0100 From: Oliver Kiddle X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.15 i686) X-Accept-Language: en MIME-Version: 1.0 To: Zsh hackers list Subject: Re: PATCH: printf builtin References: <87.1001328606@csr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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. 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