pspp-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 3rd Party compatibility


From: John Darrington
Subject: Re: 3rd Party compatibility
Date: Sat, 21 May 2005 10:39:29 +0800
User-agent: Mutt/1.5.4i

On Fri, May 20, 2005 at 06:33:10PM -0700, Ben Pfaff wrote:
     John Darrington <address@hidden> writes:
     
     > All right.  I'll see how much effort it'll be to make it work.
     > But if it turns out to be a real nightmare, then I'm not going 
     > to spend a lot of time on it, unless there's a huge demand to 
     > be able to parse these files.
     
     If you don't feel like dealing with it, just go ahead and file a
     wishlist bug.  I'll take a look at it myself, later.

I've had a look and it's actually not too bad.  All the changes are 
confined to sfm-read.c The main implications are:

1) We have to use realloc, since we no longer know how many records to
   allocate.  This could be slower and lead to memory fragmentation.

2) I have to implement a new function buf_unread which calls fseek to 
   wind back the sysfile after it's found the last variable record.
   fseek makes me a bit worried.  I don't know how portable it is.


I suppose it would be possible to use the case_size value if it's valid
(case_size != -1) , and otherwise do it the nasty way.  But then who
knows if some product might come up with a system file which gives an
apparantly valid, but incorrect value ....

Ben, where did you get the information for the format descibed in
Appendix D of the manual?  Did you just reverse engineer it, or find it
written somewhere?

J'

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.


Attachment: pgp5OUnsJ931R.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]