Front page | perl.perl5.porters |
Postings from March 2000
After looking over the sprintf code I've come to the conclusion that it is intended that %d etc. should not work correctly on quads unless the native int is 64 bits. While I don't necessarily think this is the way things *should* work (it would make more sense to me if users automatically got maximum precision and had to mask out/mod out extra bits, rather than having a C typecast do that for them, obvious exception being %c) it appears that the author of the sprintf code (or Perl_sv_vcatpvfn or whatever you want to call it) intended it work that way and I assume it would break things if it worked differently. I *still* think it's broken that if you are running a long long or otherwise 64-bit Perl and long long is your official "native" Perl integer type as a result, %d doesn't work, but whatever. So with that in mind, perlfunc.pod needs to be patched. Here's one approach: 4467c4467 < print quads, and they may optionally be preceded by --- > print quads when preceded by I don't have a native 64-bit architecture. If it's true that on 64-bit sparc or alpha or whatever that %d actually prints 5000000000 correctly, then maybe the change should be: 4467c4467 < print quads, and they may optionally be preceded by --- > print quads. Some non-native 64-bit architectures require you to prefix It might also be worthwhile to mention that %Vd (ouch! what a lousy choice of modifier) will print a quad correctly. Or at least that's the way it appears to work for me. But I don't know why %d doesn't do that in the first place. Is the problem that the internal sprintf is used by both perl ops and by perl internals itself? Maybe the "perlfunc sprintf" could be run through a different bottleneck that turned %d into %Vd. -josephThread Next