[Top][All Lists]
[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.
pgp5OUnsJ931R.pgp
Description: PGP signature