This is a discussion on Re: gnutar was (Re: Porting Subversion to VMS) - VMS ; From: =?ISO-8859-1?Q?Jean-Fran=E7ois_Pi=E9ronne? > > Interesting test philosophy you have there. Some people would wait > > until _after_ they've tried it before becoming "definitively sure" about > > it. Compiling with _LARGEFILE defined does not ensure the use of 64-bit ...
> > Interesting test philosophy you have there. Some people would wait
> > until _after_ they've tried it before becoming "definitively sure" about
> > it. Compiling with _LARGEFILE defined does not ensure the use of 64-bit
> I know that Python on VMS correctly handle large file because it pass
> all the tests provide to check that large file support is present.
Do any of those tests involve a file bigger than 2GB? 8GB? As I
> I don't remember having mentionned that "compiling with _LARGEFILE" is
> what I have test.
True. You didn't actually provide much of a description of your
tests. What you did say was, "[...] Python is compile using 64 bits
file routines [...]", which, on VMS, means "[c]ompiling with _LARGEFILE
defined", which is what I said. As I also said, doing this is not a
guarantee of proper program operation on large files. If it were, one
could, for example, rebuild Zip 2.32 and UnZip 5.52 with that level of
large-file support, and save all the years of (part-time) work which
have gone into developing Zip 3.0 and UnZip 6.0. In the real world,
however, most people would prefer programs which actually work to
programs which someone believes are supposed to work.
> FYI, a test doesn't prove the correctness of a program, it can prove
> that there is a problem or just that the program pass this test when you
> run it. So until you provide an example showing it doesn't work it is
> suppose to work.
But _not_ running a test does let you _suppose_ that the program
works? Interesting (as before).
> > integers for a file size/offset. There's also a "tar" format limit at
> > 8GB (an 11-digit octal size field, as I recall). But if you're _that_
> > sure, well, that's good enough for me.
> So if it is a tar format limitation it is not a Python (or any program)
GNU "tar" uses a "tar" format extension to work around that limit.
It involves storing a binary value in what had been an 11-digit (ASCII)
octal size field. But don't worry about these details. I'm sure that
you can _suppose_ that everything works perfectly. I prefer to test
features like this before making such a claim. Call me old-fashioned.