| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
| |
(MacOS support was removed from MakeMaker in 6.22, and merged to blead on
15th December 2004 with 5dca256ec738057dc331fb644a93eca44ad5fa14. After this
point MacOS wouldn't even have been able to build the perl binary, because it
would not have been able to build DynaLoader. If anyone wishes to resurrect
MacOS, start by reversing this commit and the relevant part of that commit.)
|
|
|
|
|
|
|
| |
This means it should run on anything that does not have a 64-bit
integer type available but does have a double. Presumably this
includes platforms that define PERL_MICRO, so we now use the
same extended time implementation for everything that runs Perl.
|
| |
|
|\ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All of the time64 functions are only visible within pp_sys.c and are not
part of the public API, so make them all static and give them the S_ prefix.
A side effect of this is that we now unambiguously use S_localtime64_r and
S_gmtime64_r and should no longer collide with system-supplied versions, if
any.
One possible future direction is that if and when Configure detects any
system-supplied *time64_r functions, their prototypes, and their valid
time ranges, we could optionally select those instead of the home-grown
ones.
Another possible future direction is that we could s/S_/Perl_/ and make
the *time64_r functions part of the public API in some post-5.10.x
release. Currently they are only exposed to the outside world via
Perl_pp_gmtime.
Also gave some TRACE macros more specific names.
|
|
|
|
|
|
|
| |
or gmtime
That way the overload warning won't be emitted for non-overflowing
floating point values.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The gr_gid member of struct group is being cast as an int even if
system uses an unsigned int. This patch tests for the use of an
unsigned int for the gr_gid member and casts the value as appropiate.
Created with Arthur Corliss <corliss@corliss@digitalmages.com>.
Signed-off-by: David M. Syzdek <david@syzdek.net>
|
|
|
|
|
|
|
|
|
|
| |
The y2038 code currently requires that a 64-bit integer type be available,
so the build falls down hard if we try to use it where there isn't one. A
better fix might be to try NV for time_t and a 32-bit integer for year.
N.B. We test for the definedness of Quad_t rather than HAS_QUAD since the
latter is explicitly undef'd in the case where 64-bit types are available
but are not being used for Perl's IV and UV.
|
|
|
|
| |
$tiedhandle, $buf
|
|
|
|
|
| |
As reported by Marcin Owsiany in <http://bugs.debian.org/512796>,
invoking setpgrp without any arguments could corrupt the stack.
|
|
|
|
|
|
|
| |
The change breaks the build on Windows as this function is really
only a mathom when PERL_DEFAULT_DO_EXEC3_IMPLEMENTATION is defined.
This reverts commit 06ba78de6df7f363272e855cc63710a634eb6100.
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
lib/Time/Local.pm
lib/Time/Local.t
reentr.h
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
stack. Neither POPn nor SvNVx work when casted to (Time64_T). Had to use a double and then cast.
Also POPq uses an SvIV so that's no good.
This causes an unfortunate loss in accuracy near 2**63 up to 8 minutes.
%lld is broken, it uses regular integers. Need to use doubles and %.0f
instead, again losing accuracy.
Now things can go out to 2**63-512.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
need is SvQV.
Fix list context with large years.
List context can now go to 2**63-513. I don't know why that's not 2**63-1
but I'll take it. Maybe double imprecision.
Scalar context with large years still busted. It appears to be something
inside Perl_newSVpvf().
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
LOCALTIME_MAX to 0x7fff573e.
Update from y2038.
Use the new TM64 struct so years can go out past y2**31
Defines a Year type to avoid converting years to ints.
Remove the TIMGM work around code, using timegm64() is fine and it
saves us from having to convert from TM to tm.
Make functions private with static rather than the _foo convention.
Even faster for distant dates.
|
| |
| |
| |
| | |
file isn't about just localtime() anymore.
|
| |
| |
| |
| | |
Fix the overflow warning to identify the right op.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
http://y2038.googlecode.com/ so Perl is no longer subject to the y2038 bug.
Use Quad_t for our 64 bit time_t replacement.
Temporarily through out the "broken localtime work around". That will
have to be integrated into localtime64_r().
Fix Time::Local to handle the new expanded date range. "use integer" had
to go as it pegged scalars to 32 bit integers which aren't large enough
to hold the new time range.
There are probably portability issues. timegm, for example, is not portable.
Also the assumption that "long" is 64 bits is probably wrong.
|
| |
| |
| |
| |
| | |
Message-ID: <20081210224524.GD18817@tytlal.topaz.cx>
p4raw-id: //depot/perl@35074
|
| |
| |
| |
| |
| | |
Message-ID: <20081127070141.GD17663@tytlal.topaz.cx>
p4raw-id: //depot/perl@35018
|
| |
| |
| | |
p4raw-id: //depot/perl@34904
|
| |
| |
| |
| |
| |
| | |
Message-ID: <25940.1225611819@chthon>
Date: Sun, 02 Nov 2008 01:43:39 -0600
p4raw-id: //depot/perl@34698
|
| |
| |
| |
| |
| |
| | |
This is mostly to silence gcc's warning, "format not a string
literal and no format arguments".
p4raw-id: //depot/perl@34694
|
| |
| |
| |
| |
| |
| | |
Can't easily do gv.h, as GvGP() (at least) needs to split into two
macros - one const for reading, one non-const for writing.
p4raw-id: //depot/perl@34679
|
| |
| |
| |
| |
| | |
erroneous const in dump.c.
p4raw-id: //depot/perl@34675
|
| |
| |
| |
| |
| |
| | |
that are not undef or "no". Take that into account when stacking them.
This fixes bug #60214.
p4raw-id: //depot/perl@34660
|
| |
| |
| | |
p4raw-id: //depot/perl@34654
|
| |
| |
| | |
p4raw-id: //depot/perl@34653
|
| |
| |
| | |
p4raw-id: //depot/perl@34647
|
| |
| |
| | |
p4raw-id: //depot/perl@34629
|
|/
|
| |
p4raw-id: //depot/perl@34585
|
|
|
|
|
| |
Message-ID: <20080628160017.GA81579@osiris.mauzo.dyndns.org>
p4raw-id: //depot/perl@34092
|
|
|
|
|
|
| |
From: "Vincent Pit" <perl@profvince.com>
Message-ID: <62186.92.128.43.82.1209554040.squirrel@92.128.43.82>
p4raw-id: //depot/perl@33770
|
|
|
|
|
|
| |
From: "Vincent Pit" <perl@profvince.com>
Message-ID: <63615.92.128.97.94.1209490401.squirrel@92.128.97.94>
p4raw-id: //depot/perl@33766
|
|
|
|
|
|
| |
a non-NULL stash. So change the parameter to NN.
* Fixed the one really obscure hitherto untested case.
p4raw-id: //depot/perl@33706
|
|
|
| |
p4raw-id: //depot/perl@33639
|
|
|
|
|
|
| |
use in order to get the do_spawn-related assert macros defined. Based
on suggestions by John Malmberg.
p4raw-id: //depot/perl@33343
|
|
|
|
|
|
|
|
|
|
|
|
| |
ability to create landmines that will explode under someone in the
future when they upgrade their compiler to one with better
optimisation. We've already done this at least twice.
(Yes, some of the assertions are after code that would already have
SEGVd because it already deferences a pointer, but they are put in
to make it easier to automate checking that each and every case is
covered.)
Add a tool, checkARGS_ASSERT.pl, to check that every case is covered.
p4raw-id: //depot/perl@33291
|
|
|
|
|
|
| |
(CXt_SUB and CXt_FORMAT were using some comon members, but some members
were only for one or the other.)
p4raw-id: //depot/perl@33014
|