fstat st_size overflow #810
Comments
From chris@gouda.netmonger.net$ ls -l log.dat I'm afraid I don't have enough background to know what the correct In any case, I have some code that needs to know the right size in --- pp_sys.c 1999/05/02 14:18:18 1.1.1.2 I'm not sure if that's right even as a bandaid, and it will obviously Perl Info |
From @jhiChristopher Masto writes:
The next major release of Perl, called 5.6, will be able to handle If you want and you have the time you can try the latest developer release: http://www.cpan.org/src/5.0/perl5.005_62.tar.gz Do "./Configure -Duselargefiles -de;make all test" BUT DO NOT INSTALL into -- |
From [Unknown Contact. See original ticket]On Thu, Nov 04, 1999 at 02:42:20AM +0200, Jarkko Hietaniemi wrote:
Just for the record, 5.005_62 does seem to work properly with Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ |
From @jhiChristopher Masto writes:
Yay, indeed. So I have made some progress. Thanks for testing. -- |
From [Unknown Contact. See original ticket]Jarkko Hietaniemi <jhi@iki.fi> wrote
Can you expand on this? What's the compatibility problem? Or is it just a question of untested / experimental code? Mike Guy |
From @jhiM.J.T. Guy writes:
Wanting large files means that you also want 64 bits. Quadness can
Yes, it is.
That's a possibility.
-- |
From @AlanBurlisonJarkko Hietaniemi wrote:
I'm not sure that is entirely correct. On Solaris it's perfectly Alan Burlison |
From [Unknown Contact. See original ticket]
What is a "32 bit application"? Do you mean a program sizeof(int) == 4 And what's a "64 bit application"? One in which all of those is 8? Or is there some compiler or O/S flag that makes them different? Is it As you essentially pointed out, one should be able to have a 4-byte int It's so easy to make sizeof(int) == But "All the World's a VAX" really has to go away -- some day. :-) --tom |
From [Unknown Contact. See original ticket]
Me too. In fact, in PowerMAX OS, that is the only combo you can get. We |
From @jhiAlan Burlison writes:
What -Duselargefiles now does is that it implicitly switches on -Duse64bits,
-- |
From [Unknown Contact. See original ticket]At 12:14 PM 11/9/99 -0700, Tom Christiansen wrote:
Probably.
Depends. If any one of the above is true the marketroids call it 64-bit. In As Alan's pointed out, 64-bit ints are more useful, generally speaking,
Depends on the platform. Some, like the alphas, go full-blown 64-bit, both The big problem from the perl level is programs with use integer in effect
And it has. Well, at least for us VMS folks... :-) Dan ----------------------------------------"it's like this"------------------- |
From @jhi
In C, yes. In Perl, we have IVs and UVs, tucked into SVs, and unless -- |
From @jhi
And just don't get me started on the incestuous NV <=> IV stuffing :-) -- |
From @jhi
The 64 bit box I am mainly worried about is IRIX, they have all the three For example DEC^WDigital^WTru64 has no problems because everything is How about the places where gcc emulates long longs with software, like ix86? -- |
From [Unknown Contact. See original ticket]Jarkko Hietaniemi <jhi@iki.fi> writes:
There would be some merit in having 'long long' "available" but not the
|
From @jhiNick Ing-Simmons writes:
You mean like, say, "use quad;"? Yuckety. I'm not saying that would -- |
From [Unknown Contact. See original ticket]At 10:06 PM 11/9/99 +0200, Jarkko Hietaniemi wrote:
Well, you get 43 pins out of most Alpha CPUs, but the pointers are a full
It'd pretty much have to, I expect. The math'd all be done in software Dan ----------------------------------------"it's like this"------------------- |
From [Unknown Contact. See original ticket]At 10:31 PM 11/9/99 +0200, Jarkko Hietaniemi wrote:
Now, now, they are standardized. An int's guaranteed to be at least as big Dan ----------------------------------------"it's like this"------------------- |
From [Unknown Contact. See original ticket]
While 64-bit on demand (or perhaps even autoresizing (SV_tBIGINT, anyone?) -- BKS ______________________________________________________ |
From [Unknown Contact. See original ticket]"Benjamin Stuhl" <sho_pi@hotmail.com> writes:
The autopromote could promote to arbitrary precision arithmetic when Math::BigInt isn't up to the task since it's written in Perl only. Perhaps we could implement our own bigints in C and allow auto- Chip -- |
From @jhiJust to clarify my position: I've nothing against large files. -- |
From @jhi
Correct.
That, too.
Something like that is in the (very) long term plan, but I think
-- |
From [Unknown Contact. See original ticket]At 03:48 PM 11/9/99 -0500, Chip Turner wrote:
Autopromotion does hurt, though. You need to check every math operation to Dan ----------------------------------------"it's like this"------------------- |
From [Unknown Contact. See original ticket]
We already have lexical "use integer". Perhaps we could --tom |
From [Unknown Contact. See original ticket]At 02:04 PM 11/9/99 -0700, Tom Christiansen wrote:
I was thinking of that. We could, I suppose, have a second set of 'bigint' Dan ----------------------------------------"it's like this"------------------- |
From @gsarOn Tue, 09 Nov 1999 21:58:51 +0200, Jarkko Hietaniemi wrote:
Umm, according to my records, the following change (in 5.005_57) added [ 3311] By: gsar on 1999/05/06 05:37:55 I think it makes tons of sense to keep that support if people are not Sarathy |
From @gsarOn Tue, 09 Nov 1999 22:45:45 +0200, Jarkko Hietaniemi wrote:
We really can't decide until we have some numbers on how good/bad it gets, Sarathy |
From [Unknown Contact. See original ticket]Dan Sugalski writes:
Anyone ready for a bench? Ilya |
From @jhiGurusamy Sarathy writes:
According to my records, the most important of which is the current That patch *always* turned on largefileness if available. If that's
-- |
From [Unknown Contact. See original ticket]At 04:48 PM 11/9/99 -0500, Ilya Zakharevich wrote:
The results would certainly be interesting. Anyone know what version of gcc Dan ----------------------------------------"it's like this"------------------- |
From [Unknown Contact. See original ticket]Jarkko Hietaniemi writes:
Losing precision will not happen for many years to come, and if done Ilya |
From [Unknown Contact. See original ticket]On Tue, Nov 09, 1999 at 04:56:49PM -0700, Tom Christiansen wrote:
Size of a file is a *number*. And you are supposed to expect this. printf '%d', $number produces "wrong" results right and left. Ilya |
From @gsarOn Tue, 09 Nov 1999 23:44:07 GMT, Alan Burlison wrote:
But this hasn't stopped us from using NVs for all sorts of things
By all means, enable 64-bits if you are able. (You obviously seem to But let's not *prevent* people with 32-bit systems from accessing their I would agree with you if the "largefiles"-via-NVs was the only option. Sarathy |
From @gsarOn Tue, 09 Nov 1999 16:35:22 MST, Tom Christiansen wrote:
Sure, the above has been the case for over 10 years and people on The question here is actually something different: on 32-bit platforms, Sarathy |
From [Unknown Contact. See original ticket]Tom Christiansen writes:
I want to investigate this from a different POV: *why* should not '%d' Ilya |
From @gsarOn Tue, 09 Nov 1999 19:20:12 EST, Ilya Zakharevich wrote:
Backwardness aside, I don't see any good reason why not. Sarathy |
From [Unknown Contact. See original ticket]On Tue, Nov 09, 1999 at 04:31:37PM -0800, Gurusamy Sarathy wrote:
There is backward-compatibility on out-of-range NV->IV conversion H:\get\perl\perl5.005_62.my>perl -wle "printf '%.0f', (2**31)+0.6" So one should trunc() first. BTW, with my "cache NV->PV conversion" patch there less need for monk:~->perl -wle '$_ = 2**50 - 1; print' is acceptable any more. Who can find this thread in archives? Did we have archives that time? Ilya |
From @doughera88On Tue, 9 Nov 1999, Gurusamy Sarathy wrote:
Since *BSD platforms are already doing this in 5.005_0x, perhaps a check
I hesitate to ask you of all people, but are you sure about this? I don't There are some side issues about the IV -> NV conversion that also might Andy Dougherty doughera@lafayette.edu |
From @jhi
No, it isn't. I actually tried to fix the + - * / % to keep integers
-- |
From @AlanBurlisonIlya Zakharevich wrote:
If you have read the rest of the thread, you will see I'm not alone in
So what? I'm complaining about file offsets, not existing numeric
I've also just appreciated (again) why I stopped posting to p5p. Alan Burlison |
From [Unknown Contact. See original ticket]Benjamin Stuhl <sho_pi@hotmail.com> writes:
We already do all the printf-y % stuff ourselves. So all we need is The related idea of making %d render an NV as integer is much harder -- |
From [Unknown Contact. See original ticket]Jarkko Hietaniemi <jhi@iki.fi> wrote
I'd hope that the implementation, when converting from off64_t a) Choose whichever of NV or IV gave the greater range That way, I can't see that we're ever worse off than the current state Mike Guy |
From @jhiM.J.T. Guy writes:
Converting is relatively easy, it's the maddening arith ops that -- |
From @jhi
Hmmm, a flag that would have to contagious... ($new_offset = $old_offset + 42) -- |
From [Unknown Contact. See original ticket]Jarkko Hietaniemi <jhi@iki.fi> wrote
Let's not confuse the simple issue of conversion of off64_t with These more general issues ought to be tackled, but there's no reason for Mike Guy |
From @gsarOn Tue, 09 Nov 1999 18:50:46 EST, Ilya Zakharevich wrote:
In theory, yes, but in practice, DBL_DIG is usually 15, which Sarathy |
From @gsarOn Tue, 09 Nov 1999 21:25:46 EST, Andy Dougherty wrote:
My somewhat limited empirical tests around 5.005_57 didn't find any Sarathy |
From @doughera88On Wed, 10 Nov 1999, M.J.T. Guy wrote:
But "doing large files right" probably means allowing the user to do I know some of these things have come up before. A careful trip through -- |
From [Unknown Contact. See original ticket]On Wed, Nov 10, 1999 at 10:41:20AM +0200, Jarkko Hietaniemi wrote:
I do not think it is reasonable, and it will not save the above Ilya |
From [Unknown Contact. See original ticket]On Wed, Nov 10, 1999 at 08:45:47AM -0800, Gurusamy Sarathy wrote:
a) This should be fixed long time ago; Ilya |
From [Unknown Contact. See original ticket]Alan Burlison writes:
Oups, sorry if it offends you! This was not the intent... Ilya |
From [Unknown Contact. See original ticket]Andy Dougherty writes:
"Doing them right" is not the target. One can manually tune holy
Fortunately, behaviour at the corners should not enter the "practical" As I said before: show me an application which uses files greater than Ilya |
From @doughera88On Tue, 9 Nov 1999, Andy Dougherty wrote:
Ok, well a non-exhaustive (but still exhausting!) crawl through the Overall, I'm beginning to agree with Sarathy that perhaps we ought to I still maintain that the IV -> NV rollover can be a little tricky (sign 1999-03/msg00556: dubious pp_stat behavior Tom C. pointed out slews of (I32) casts which are now mostly gone, but PUSHs(sv_2mortal(newSViv(PL_statcache.st_size))); 1999-08/msg00423: [ID 19990810.001] Possible bug using stat w/large files This was just attempting to use the default print function. The user got 1999-07/msg00413: [ID 19990709.003] open and -e fail w/largefiles this was for 5.005_02, and may be fixed by -DLARGEFILES. In fact, this is probably a good argument for enabling large files 1999-04/msg00604: Re: Why (IV) U_V(d) ? Regarding storing file sizes in an NV, Nick observed that While that would suffice for large files up to 2**53 bytes, I don't know anything about this. It sounds potentially quite serious, -- |
From @jhi
Thanks for finding this. I'll double check the use of st_(size|uid|gid). -- |
Migrated from rt.perl.org#1738 (status was 'resolved')
Searchable as RT1738$
The text was updated successfully, but these errors were encountered: