if you try to print out the timezone via %Z using strftime on SunOS 4.1.3
compiled by gcc, you get a coredump. As reported by me in April 95,
this is a long story, but the bottom line is that this dumps core:
use POSIX 'strftime';
$ENV{TZ} = "MET";
$date = strftime '%A, %d %B %Y at %l:%M%p %Z', localtime;
print "$date\n";
The configure bits here are screwed up on Suns:
#ifdef HAS_TZNAME
extern char *tzname[];
#else
char *tzname[] = { "" , "" };
#endif
Because tzname doesn't get set, and we get a coredump. It's still
not fixed, and I guess I'm not convinced I know how to fix it
given the discussion below.
No matter what else happens, this Should Not Dump Core.
--tom
#! /bin/sh
# This is a shell archive. Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file". To overwrite existing
# files, type "sh file -c". You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g.. If this archive is complete, you
# will see the following message at the end:
# "End of shell archive."
# Contents: 884 885 886 887 888 889
# Wrapped by tchrist@mox on Fri Nov 3 08:21:49 1995
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f '884' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'884'\"
else
echo shar: Extracting \"'884'\" \(6626 characters\)
sed "s/^X//" >'884' <<'END_OF_FILE'
XReturn-Path: owner-perl5-porters@nicoh.com
XReceived: from africa.nicoh.com (daemon@africa.nicoh.com [198.60.251.1]) by mox.perl.com (8.6.10/8.6.10) with ESMTP id KAA13460 for <tchrist@perl.com>; Wed, 12 Apr 1995 10:40:47 -0600
XReceived: by africa.nicoh.com
X (1.37.109.15/16.2) id AA023212585; Wed, 12 Apr 1995 12:03:05 -0400
XTo: Larry Wall <lwall@scalpel.netlabs.com>,
X The Perl Porters Mailing List <perl5-porters@africa.nicoh.com>
XSubject: broken time stuff plus flagrant breach of POSIX contract
XReply-To: tchrist@perl.com
XDate: Wed, 12 Apr 95 09:58:15 MDT
XMessage-Id: <12660.797702295@mox>
XFrom: Tom Christiansen <tchrist@mox.perl.com>
XSender: owner-perl5-porters@nicoh.com
XList-Name: perl5-porters
XPrecedence: bulk
X
XPerl's localtime doesn't really 'work', and POSIX::localtime()
Xdoesn't help:
X
X/src/perl/ext/POSIX/POSIX.pm:
X
X package POSIX;
X ....
X sub localtime {
X usage "localtime(time)" if @_ != 1;
X localtime($_[0]);
X }
X
XI'm somewhat annoyed by the POSIX routines that just jump
Xback into Perl. That means if Perl's broken, you're still hosed
Xand you can't escape into POSIX.
X
XHow is it broken?
X
XI asked for a struct tm, and I want one. I'm being cheated
Xof the last two fields in struct tm: tm_zone and tm_gmtoff,
Xand they're the ones I really want!
X
XI don't see why not to add this patch
X
X*** pp_sys.c Fri Mar 10 22:09:30 1995
X--- /tmp/pp_sys.c Wed Apr 12 09:27:55 1995
X***************
X*** 2973,2978 ****
X--- 2973,2980 ----
X PUSHs(sv_2mortal(newSViv((I32)tmbuf->tm_wday)));
X PUSHs(sv_2mortal(newSViv((I32)tmbuf->tm_yday)));
X PUSHs(sv_2mortal(newSViv((I32)tmbuf->tm_isdst)));
X+ PUSHs(sv_2mortal(newSVpv(tmbuf->tm_zone, strlen(tmbuf->tm_zone)));
X+ PUSHs(sv_2mortal(newSViv((I32)tmbuf->tm_gmtoff)));
X }
X RETURN;
X }
X
XAs well as of course this one:
X
X*** perlfunc.pod Sat Mar 11 22:34:42 1995
X--- /tmp/perlfunc.pod Wed Apr 12 09:30:19 1995
X***************
X*** 1327,1336 ****
X with the time analyzed for the local timezone. Typically used as
X follows:
X
X! ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =
X localtime(time);
X
X! All array elements are numeric, and come straight out of a struct tm.
X In particular this means that $mon has the range 0..11 and $wday has
X the range 0..6. If EXPR is omitted, does localtime(time).
X
X--- 1327,1336 ----
X with the time analyzed for the local timezone. Typically used as
X follows:
X
X! ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst,$zone,$gmtoff) =
X localtime(time);
X
X! All array elements except for $zone are numeric, and come straight out of a struct tm.
X In particular this means that $mon has the range 0..11 and $wday has
X the range 0..6. If EXPR is omitted, does localtime(time).
X
X
XIs the problem that not all sizes support tm_zone and tm_gmtoff?
XThat would be wretched. Even if so, I guess that we could use
Xthe same thing as with pp_stat in USE_STAT_BLOCKS.
X
XThis all came up beause I was trying to call POSIX::strftime and
Xalways getting coredumps. It seems that on
X
X SunOS mox 4.1.3_U1 4 sun4m
X
XYou can't get away with letting tm_zone be (char *)0. It *HAS* to be
Xat least "", or you get a core dump. So what do you set it to?
XWell, the obvious thing is to let them pass it in, but you can't,
Xbecause perl has this idea that struct tm's don't even *have* one.
XHere's another case where I can't quiet really get at the
Xhonest to goodness POSIX::strftime function because even though
Xin C it's
X
X int strftime(buf, bufsize, fmt, tm)
X
Xin perl's POSIX.xs it's
X
X char *
X strftime(fmt, sec, min, hour, mday, mon, year,
X wday = 0, yday = 0, isdst = 0)
X
Xwhich means there's *NO PLACE* for me to pass in the
Xrest of struct tm, and if I can't do that, I not only
Xcan't use strftime for certain things, I *CAN'T USE IT AT ALL*
Xbecause it core dumps!!
X
XAnd I can't possibly figure out the real values for tm_zone
Xand tm_gmtoff to pass it because they aren't given to me from
Xperl's localtime() function!!
X
XI tend to think that this patch should be applied:
X
X*** POSIX.xs Sat Mar 11 22:30:03 1995
X--- /tmp/POSIX.xs Wed Apr 12 09:40:26 1995
X***************
X*** 3092,3098 ****
X RETVAL
X
X char *
X! strftime(fmt, sec, min, hour, mday, mon, year, wday = 0, yday = 0, isdst = 0)
X char * fmt
X int sec
X int min
X--- 3092,3099 ----
X RETVAL
X
X char *
X! strftime(fmt, sec, min, hour, mday, mon, year,
X! wday = 0, yday = 0, isdst = 0, zone = "", gmtoff = 0)
X char * fmt
X int sec
X int min
X***************
X*** 3103,3108 ****
X--- 3104,3111 ----
X int wday
X int yday
X int isdst
X+ char * zone
X+ int gmtoff
X CODE:
X {
X char tmpbuf[128];
X***************
X*** 3117,3122 ****
X--- 3120,3127 ----
X mytm.tm_wday = wday;
X mytm.tm_yday = yday;
X mytm.tm_isdst = isdst;
X+ mytm.tm_zone = zone;
X+ mytm.tm_gmtoff = zone;
X len = strftime(tmpbuf, sizeof tmpbuf, fmt, &mytm);
X ST(0) = sv_2mortal(newSVpv(tmpbuf, len));
X }
X
X t->tm_zone == (char *)0
X
XAnd similarly for POSIX::mktime() right before it.
X
XAs for good old POSIX::tzname(), I'm not quite sure all it's supported to
Xdo (SunOS doens't even doc it), but it loks like it must be returning the
X
X extern char *tzname[2]
X
Xvariable. Well, it doesn't do that on my system. Why? Cause in
Xhints/sunos_4_1.sh is has
X
X d_tzname='undef'
X
Xfor no apparent reason (Configure found it, but I was running
XConfigure -d and blindly took its work for it.) So then perl
Xturns around and does this in POSIX.xs:
X
X #ifdef HAS_TZNAME
X extern char *tzname[];
X #else
X char *tzname[] = { "" , "" };
X #endif
X
XAnd I am reminded why it was that I thought the POSIX module
Xwas broken. I said
X
X use POSIX;
X
XI even said
X
X use POSIX 'tzname';
X
XAnd all was well, but then what happens? When I call POSIX::tzname it
Xgives me the bogosity of a successful return -- of 2 empty string. It's
Xbroken its contract with me by lying about what it has and giving
Xme something entirely bogus while making me thing it's fine. It's in
Xclear and obvious breach of contract, and needs fixing.
X
XIf I say
X
X use POSIX;
X
Xand *ESPECIALLY*
X
X use POSIX some_function;
X
XI bloody well expect POSIX::some_function to be there, and
Xproperly so. Anything else is a dirty lie.
X
X--tom
X
END_OF_FILE
if test 6626 -ne `wc -c <'884'`; then
echo shar: \"'884'\" unpacked with wrong size!
fi
# end of '884'
fi
if test -f '885' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'885'\"
else
echo shar: Extracting \"'885'\" \(3511 characters\)
sed "s/^X//" >'885' <<'END_OF_FILE'
XReplied: Wed, 12 Apr 95 14:16:47 MDT
XReplied: tchrist
XReplied: roehrich@ironwood-fddi.cray.com (Dean Roehrich)
XReplied: perl5-porters@africa.nicoh.com
XReturn-Path: owner-perl5-porters@nicoh.com
XReceived: from africa.nicoh.com (daemon@africa.nicoh.com [198.60.251.1]) by mox.perl.com (8.6.10/8.6.10) with ESMTP id NAA17680 for <tchrist@perl.com>; Wed, 12 Apr 1995 13:55:30 -0600
XReceived: by africa.nicoh.com
X (1.37.109.15/16.2) id AA004814170; Wed, 12 Apr 1995 15:16:10 -0400
XFrom: roehrich@ironwood-fddi.cray.com (Dean Roehrich)
XMessage-Id: <9504121912.AA03714@poplar027>
XDate: Wed, 12 Apr 1995 14:12:04 -0500
XTo: perl5-porters@africa.nicoh.com
XSubject: Re: broken time stuff plus flagrant breach of POSIX contract
XContent-Length: 2698
XSender: owner-perl5-porters@nicoh.com
XList-Name: perl5-porters
XPrecedence: bulk
X
X> From: Tom Christiansen <tchrist@mox.perl.com>
X
X> How is it broken?
X>
X> I asked for a struct tm, and I want one. I'm being cheated
X> of the last two fields in struct tm: tm_zone and tm_gmtoff,
X> and they're the ones I really want!
X
XThose fields aren't part of POSIX, so I guess I don't believe you're being
Xcheated. The module is, afterall, POSIX.
X
XPOSIX 1003.1b-1993, Annex C, <time.h>, line 384 says the structure elements
Xfor struct tm are:
X tm_hour, tm_mday, tm_mon, tm_wday, tm_year,
X tm_isdst, tm_min, tm_sec, tm_yday
X
XNothing about tm_zone and tm_gmtoff.
X
X> I don't see why not to add this patch
X
Xbecause it will break on solaris&unicos, which have POSIX localtime...
X
X> Is the problem that not all sizes support tm_zone and tm_gmtoff?
X> That would be wretched. Even if so, I guess that we could use
X> the same thing as with pp_stat in USE_STAT_BLOCKS.
X
Xmaybe, but that just creates new script portability problems.
X
X> which means there's *NO PLACE* for me to pass in the
X> rest of struct tm, and if I can't do that, I not only
X> can't use strftime for certain things, I *CAN'T USE IT AT ALL*
X> because it core dumps!!
X
XI have a script which uses POSIX::strftime, doesn't core dump....
X
X> And I can't possibly figure out the real values for tm_zone
X> and tm_gmtoff to pass it because they aren't given to me from
X> perl's localtime() function!!
X
XI didn't have enough time to continue my search through the POSIX manual,
Xbut I have to believe there's something in there which will give you the
Xsame information.
X
X> I tend to think that this patch should be applied:
X
Xthat, of course, will break on a system which has POSIX strftime...
X
X> As for good old POSIX::tzname(), I'm not quite sure all it's supported to
X> do (SunOS doens't even doc it), but it loks like it must be returning the
X>
X> extern char *tzname[2]
X
XThat is POSIX. Specified in POSIX 1003.1b-1993, Annex C, <time.h>, line
X403. Also mentioned in section 8.3.2.2 in the description of the tzset()
Xfunction, where it is mentioned that "the tzset() function shall set the
Xexternal variable tzname...." The POSIX interpretation of "shall" is
X"must", as I understand it.
X
X> It's in
X> clear and obvious breach of contract, and needs fixing.
X
XThere are other breach-of-contract areas, it's not worth getting hot under
Xthe collar about just one of them. Note that there are lots of not_here's
Xin POSIX.xs.
X
XMaybe the parts of the POSIX module which are ifdef'd or not_here'd should
Xbe split out into a POSIX::NotGuaranteed module. Then the rest of the POSIX
Xmodule would be POSIX::Guaranteed, and the POSIX module would just pull in
Xboth of them.
X :-)
X
XWe can't blame Perl for the operating system.
X
XDean
X
END_OF_FILE
if test 3511 -ne `wc -c <'885'`; then
echo shar: \"'885'\" unpacked with wrong size!
fi
# end of '885'
fi
if test -f '886' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'886'\"
else
echo shar: Extracting \"'886'\" \(4226 characters\)
sed "s/^X//" >'886' <<'END_OF_FILE'
XReturn-Path: tchrist@mox.perl.com
XReceived: from localhost.perl.com (Warm-Fuzzies@localhost.perl.com [127.0.0.1]) by mox.perl.com (8.6.10/8.6.10) with SMTP id OAA18188; Wed, 12 Apr 1995 14:16:45 -0600
XTo: roehrich@ironwood-fddi.cray.com (Dean Roehrich)
Xcc: perl5-porters@africa.nicoh.com, tchrist@mox.perl.com
XSubject: Re: broken time stuff plus flagrant breach of POSIX contract
XIn-reply-to: Dean Roehrich's message <9504121912.AA03714@poplar027> of Wed, 12 Apr 95 14:12:04 CDT.
XReferences: <9504121912.AA03714@poplar027>
XDate: Wed, 12 Apr 95 14:16:44 MDT
XMessage-ID: <18185.797717804@mox>
XFrom: Tom Christiansen <tchrist@mox.perl.com>
X
X> > I asked for a struct tm, and I want one. I'm being cheated
X> > of the last two fields in struct tm: tm_zone and tm_gmtoff,
X> > and they're the ones I really want!
X
X> Those fields aren't part of POSIX, so I guess I don't believe you're being
X> cheated. The module is, afterall, POSIX.
X
XOK. Should we deny people the extra non-posix stat fields then?
XI don't have a 1003.1 book, nor a URL to one, but I'd be surprised
Xif the blocksize were mandatory -- after all, it would offend the
Xoldstyle SysV filesystems.
X
X> > I don't see why not to add this patch
X
X> because it will break on solaris&unicos, which have POSIX localtime...
X
XIt can be ifdeffed.
X
X> > Is the problem that not all sizes support tm_zone and tm_gmtoff?
X> > That would be wretched. Even if so, I guess that we could use
X> > the same thing as with pp_stat in USE_STAT_BLOCKS.
X
X> maybe, but that just creates new script portability problems.
X
Xok.
X
X> > which means there's *NO PLACE* for me to pass in the
X> > rest of struct tm, and if I can't do that, I not only
X> > can't use strftime for certain things, I *CAN'T USE IT AT ALL*
X> > because it core dumps!!
X
X> I have a script which uses POSIX::strftime, doesn't core dump....
X
X> > And I can't possibly figure out the real values for tm_zone
X> > and tm_gmtoff to pass it because they aren't given to me from
X> > perl's localtime() function!!
X
X> I didn't have enough time to continue my search through the POSIX manual,
X> but I have to believe there's something in there which will give you the
X> same information.
X
X> > I tend to think that this patch should be applied:
X
X> that, of course, will break on a system which has POSIX strftime...
X
X> > As for good old POSIX::tzname(), I'm not quite sure all it's supported to
X> > do (SunOS doens't even doc it), but it loks like it must be returning the
X> >
X> > extern char *tzname[2]
X
X> That is POSIX. Specified in POSIX 1003.1b-1993, Annex C, <time.h>, line
X> 403. Also mentioned in section 8.3.2.2 in the description of the tzset()
X> function, where it is mentioned that "the tzset() function shall set the
X> external variable tzname...." The POSIX interpretation of "shall" is
X> "must", as I understand it.
X
XWell, then the SunOS hints file is wrong. Maybe the problem
Xis you're only going to get that if you link with sysV environment.
XI dunno. But it ought to be there!
X
XIt certainly shoudln't get bogified into what's currently
Xhappening with tzname.
X
X> > It's in
X> > clear and obvious breach of contract, and needs fixing.
X
X> There are other breach-of-contract areas, it's not worth getting hot under
X> the collar about just one of them. Note that there are lots of not_here's
X> in POSIX.xs.
X
X> Maybe the parts of the POSIX module which are ifdef'd or not_here'd should
X> be split out into a POSIX::NotGuaranteed module. Then the rest of the POSIX
X> module would be POSIX::Guaranteed, and the POSIX module would just pull in
X> both of them.
X> :-)
X
XI'm sorry, but I'm hot under the color again then. If I say
XPOSIX, I want to get it, take an exception.
X
XAt the very least, I should be able to do this:
X
Xeval { require POSIX } || warn "something's missing....$@";
Xif (!defined &POSIX::tzname) { ... }
X
X> We can't blame Perl for the operating system.
X
XPerhaps not, but I still think thing that if you want
Xto tolerate mendacious contractual guarantees, you should
Xbe forced to type:
X
X use As_Much_of_POSIX_as_I_Can_Get;
X
Xif they want the
X
X BEGIN { eval "require POSIX" }
X
Xbehaviour, but for
X
X use POSIX;
X
Xand of course
X
X use POSIX qw(tzname);
X
Xto really mean something.
X
X--tom
X
END_OF_FILE
if test 4226 -ne `wc -c <'886'`; then
echo shar: \"'886'\" unpacked with wrong size!
fi
# end of '886'
fi
if test -f '887' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'887'\"
else
echo shar: Extracting \"'887'\" \(1851 characters\)
sed "s/^X//" >'887' <<'END_OF_FILE'
XReturn-Path: owner-perl5-porters@nicoh.com
XReceived: from africa.nicoh.com (daemon@africa.nicoh.com [198.60.251.1]) by mox.perl.com (8.6.10/8.6.10) with ESMTP id PAA19264 for <tchrist@perl.com>; Wed, 12 Apr 1995 15:11:15 -0600
XReceived: by africa.nicoh.com
X (1.37.109.15/16.2) id AA029859854; Wed, 12 Apr 1995 16:50:54 -0400
XDate: Wed, 12 Apr 1995 16:47:31 -0400 (EDT)
XFrom: Andy Dougherty <doughera@lafcol.lafayette.edu>
XSubject: Re: broken time stuff plus flagrant breach of POSIX contract
XTo: perl5-porters@africa.nicoh.com
XIn-Reply-To: <18185.797717804@mox>
XMessage-Id: <Pine.3.89.9504121645.A20528-0100000@lafcol>
XMime-Version: 1.0
XContent-Type: TEXT/PLAIN; charset=US-ASCII
XSender: owner-perl5-porters@nicoh.com
XList-Name: perl5-porters
XPrecedence: bulk
X
XOn Wed, 12 Apr 1995, Tom Christiansen wrote:
X
X>
X> > > As for good old POSIX::tzname(), I'm not quite sure all it's supported to
X> > > do (SunOS doens't even doc it), but it loks like it must be returning the
X> > >
X> > > extern char *tzname[2]
X>
X> > That is POSIX. Specified in POSIX 1003.1b-1993, Annex C, <time.h>, line
X> > 403. Also mentioned in section 8.3.2.2 in the description of the tzset()
X> > function, where it is mentioned that "the tzset() function shall set the
X> > external variable tzname...." The POSIX interpretation of "shall" is
X> > "must", as I understand it.
X>
X> Well, then the SunOS hints file is wrong. Maybe the problem
X> is you're only going to get that if you link with sysV environment.
X> I dunno. But it ought to be there!
X
XI suspect this particular problem is actually one of dynamic loading of
Xdata (as opposed to functions) and is an ld.so problem rather than a
Xbreach of POSIX. I seem to recall that if you load POSIX statically
Xwithout the d_tzname hint it still works on SunOS 4.1.3.
X
X Andy Dougherty doughera@lafcol.lafayette.edu
X
X
END_OF_FILE
if test 1851 -ne `wc -c <'887'`; then
echo shar: \"'887'\" unpacked with wrong size!
fi
# end of '887'
fi
if test -f '888' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'888'\"
else
echo shar: Extracting \"'888'\" \(1665 characters\)
sed "s/^X//" >'888' <<'END_OF_FILE'
XReturn-Path: owner-perl5-porters@nicoh.com
XReceived: from africa.nicoh.com (daemon@africa.nicoh.com [198.60.251.1]) by mox.perl.com (8.6.10/8.6.10) with ESMTP id XAA00216 for <tchrist@perl.com>; Mon, 17 Apr 1995 23:52:01 -0600
XReceived: by africa.nicoh.com
X (1.37.109.15/16.2) id AA192053357; Tue, 18 Apr 1995 01:35:57 -0400
XMessage-Id: <199504180451.OAA12898@fulcrum.com.au>
XTo: Andy Dougherty <doughera@lafcol.lafayette.edu>
XCc: perl5-porters@africa.nicoh.com
XSubject: Re: broken time stuff plus flagrant breach of POSIX contract
XFrom: matthew green <mrg@fulcrum.com.au>
XIn-Reply-To: Andy Dougherty's message <Pine.3.89.9504121645.A20528-0100000@lafcol> of Wed, 12 Apr 1995 16:47:31 -0400.
XReferences: <Pine.3.89.9504121645.A20528-0100000@lafcol>
XDate: Tue, 18 Apr 1995 14:51:38 +1000
XSender: owner-perl5-porters@nicoh.com
XList-Name: perl5-porters
XPrecedence: bulk
X
X > Well, then the SunOS hints file is wrong. Maybe the problem
X > is you're only going to get that if you link with sysV environment.
X > I dunno. But it ought to be there!
X
X I suspect this particular problem is actually one of dynamic loading of
X data (as opposed to functions) and is an ld.so problem rather than a
X breach of POSIX. I seem to recall that if you load POSIX statically
X without the d_tzname hint it still works on SunOS 4.1.3.
X
Xyup. here's a perl with tzname defined:
X
Xsleepy src/perl/perl5.001> ./perl -I./lib -e 'use POSIX;'
Xld.so: Undefined symbol: _tzname
Xsleepy src/perl/perl5.001>
X
Xmemory is hazy, but doesn't this mean we need a POSIX.sa for
Xsunos 4 systems ? i mostly forget how all this works...
X
Xnick ? do you know ?
X
X.mrg.
X
END_OF_FILE
if test 1665 -ne `wc -c <'888'`; then
echo shar: \"'888'\" unpacked with wrong size!
fi
# end of '888'
fi
if test -f '889' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'889'\"
else
echo shar: Extracting \"'889'\" \(1930 characters\)
sed "s/^X//" >'889' <<'END_OF_FILE'
XReturn-Path: owner-perl5-porters@nicoh.com
XReceived: from africa.nicoh.com (daemon@africa.nicoh.com [198.60.251.1]) by mox.perl.com (8.6.10/8.6.10) with ESMTP id DAA26786 for <tchrist@perl.com>; Wed, 19 Apr 1995 03:12:01 -0600
XReceived: by africa.nicoh.com
X (1.37.109.15/16.2) id AA205351278; Wed, 19 Apr 1995 04:47:58 -0400
XFrom: Nick.Ing-Simmons@tiuk.ti.com
XDate: Wed, 19 Apr 95 09:44:09 BST
XMessage-Id: <9504190844.AA20900@pluto>
XTo: mrg@fulcrum.com.au
XCc: Andy Dougherty <doughera@lafcol.lafayette.edu>
XCc: perl5-porters@africa.nicoh.com
XSubject: Re: broken time stuff plus flagrant breach of POSIX contract
XSender: owner-perl5-porters@nicoh.com
XList-Name: perl5-porters
XPrecedence: bulk
X
XIn <199504180451.OAA12898@fulcrum.com.au>
XOn Tue, 18 Apr 1995 14:51:38 +1000
XMatthew Green <mrg@fulcrum.com.au> writes:
X>
X> > Well, then the SunOS hints file is wrong. Maybe the problem
X> > is you're only going to get that if you link with sysV environment.
X> > I dunno. But it ought to be there!
X>
X> I suspect this particular problem is actually one of dynamic loading of
X> data (as opposed to functions) and is an ld.so problem rather than a
X> breach of POSIX. I seem to recall that if you load POSIX statically
X> without the d_tzname hint it still works on SunOS 4.1.3.
X>
X> yup. here's a perl with tzname defined:
X>
X> sleepy src/perl/perl5.001> ./perl -I./lib -e 'use POSIX;'
X> ld.so: Undefined symbol: _tzname
X> sleepy src/perl/perl5.001>
X>
X> memory is hazy, but doesn't this mean we need a POSIX.sa for
X> sunos 4 systems ? i mostly forget how all this works...
X>
X> nick ? do you know ?
X
XI have always managed to avoid .sa files, but then exporting data is
Xnot my 'style' so I may have been lucky.
X
XI think we can work round it somehow, but things are a bit weird here
Xat the moment (whole site is moving this week), so I don't have any time
Xto look into it.
X
X>
X> .mrg.
X
END_OF_FILE
if test 1930 -ne `wc -c <'889'`; then
echo shar: \"'889'\" unpacked with wrong size!
fi
# end of '889'
fi
echo shar: End of shell archive.
exit 0
compiled by gcc, you get a coredump. As reported by me in April 95,
this is a long story, but the bottom line is that this dumps core:
use POSIX 'strftime';
$ENV{TZ} = "MET";
$date = strftime '%A, %d %B %Y at %l:%M%p %Z', localtime;
print "$date\n";
The configure bits here are screwed up on Suns:
#ifdef HAS_TZNAME
extern char *tzname[];
#else
char *tzname[] = { "" , "" };
#endif
Because tzname doesn't get set, and we get a coredump. It's still
not fixed, and I guess I'm not convinced I know how to fix it
given the discussion below.
No matter what else happens, this Should Not Dump Core.
--tom
#! /bin/sh
# This is a shell archive. Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file". To overwrite existing
# files, type "sh file -c". You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g.. If this archive is complete, you
# will see the following message at the end:
# "End of shell archive."
# Contents: 884 885 886 887 888 889
# Wrapped by tchrist@mox on Fri Nov 3 08:21:49 1995
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f '884' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'884'\"
else
echo shar: Extracting \"'884'\" \(6626 characters\)
sed "s/^X//" >'884' <<'END_OF_FILE'
XReturn-Path: owner-perl5-porters@nicoh.com
XReceived: from africa.nicoh.com (daemon@africa.nicoh.com [198.60.251.1]) by mox.perl.com (8.6.10/8.6.10) with ESMTP id KAA13460 for <tchrist@perl.com>; Wed, 12 Apr 1995 10:40:47 -0600
XReceived: by africa.nicoh.com
X (1.37.109.15/16.2) id AA023212585; Wed, 12 Apr 1995 12:03:05 -0400
XTo: Larry Wall <lwall@scalpel.netlabs.com>,
X The Perl Porters Mailing List <perl5-porters@africa.nicoh.com>
XSubject: broken time stuff plus flagrant breach of POSIX contract
XReply-To: tchrist@perl.com
XDate: Wed, 12 Apr 95 09:58:15 MDT
XMessage-Id: <12660.797702295@mox>
XFrom: Tom Christiansen <tchrist@mox.perl.com>
XSender: owner-perl5-porters@nicoh.com
XList-Name: perl5-porters
XPrecedence: bulk
X
XPerl's localtime doesn't really 'work', and POSIX::localtime()
Xdoesn't help:
X
X/src/perl/ext/POSIX/POSIX.pm:
X
X package POSIX;
X ....
X sub localtime {
X usage "localtime(time)" if @_ != 1;
X localtime($_[0]);
X }
X
XI'm somewhat annoyed by the POSIX routines that just jump
Xback into Perl. That means if Perl's broken, you're still hosed
Xand you can't escape into POSIX.
X
XHow is it broken?
X
XI asked for a struct tm, and I want one. I'm being cheated
Xof the last two fields in struct tm: tm_zone and tm_gmtoff,
Xand they're the ones I really want!
X
XI don't see why not to add this patch
X
X*** pp_sys.c Fri Mar 10 22:09:30 1995
X--- /tmp/pp_sys.c Wed Apr 12 09:27:55 1995
X***************
X*** 2973,2978 ****
X--- 2973,2980 ----
X PUSHs(sv_2mortal(newSViv((I32)tmbuf->tm_wday)));
X PUSHs(sv_2mortal(newSViv((I32)tmbuf->tm_yday)));
X PUSHs(sv_2mortal(newSViv((I32)tmbuf->tm_isdst)));
X+ PUSHs(sv_2mortal(newSVpv(tmbuf->tm_zone, strlen(tmbuf->tm_zone)));
X+ PUSHs(sv_2mortal(newSViv((I32)tmbuf->tm_gmtoff)));
X }
X RETURN;
X }
X
XAs well as of course this one:
X
X*** perlfunc.pod Sat Mar 11 22:34:42 1995
X--- /tmp/perlfunc.pod Wed Apr 12 09:30:19 1995
X***************
X*** 1327,1336 ****
X with the time analyzed for the local timezone. Typically used as
X follows:
X
X! ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =
X localtime(time);
X
X! All array elements are numeric, and come straight out of a struct tm.
X In particular this means that $mon has the range 0..11 and $wday has
X the range 0..6. If EXPR is omitted, does localtime(time).
X
X--- 1327,1336 ----
X with the time analyzed for the local timezone. Typically used as
X follows:
X
X! ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst,$zone,$gmtoff) =
X localtime(time);
X
X! All array elements except for $zone are numeric, and come straight out of a struct tm.
X In particular this means that $mon has the range 0..11 and $wday has
X the range 0..6. If EXPR is omitted, does localtime(time).
X
X
XIs the problem that not all sizes support tm_zone and tm_gmtoff?
XThat would be wretched. Even if so, I guess that we could use
Xthe same thing as with pp_stat in USE_STAT_BLOCKS.
X
XThis all came up beause I was trying to call POSIX::strftime and
Xalways getting coredumps. It seems that on
X
X SunOS mox 4.1.3_U1 4 sun4m
X
XYou can't get away with letting tm_zone be (char *)0. It *HAS* to be
Xat least "", or you get a core dump. So what do you set it to?
XWell, the obvious thing is to let them pass it in, but you can't,
Xbecause perl has this idea that struct tm's don't even *have* one.
XHere's another case where I can't quiet really get at the
Xhonest to goodness POSIX::strftime function because even though
Xin C it's
X
X int strftime(buf, bufsize, fmt, tm)
X
Xin perl's POSIX.xs it's
X
X char *
X strftime(fmt, sec, min, hour, mday, mon, year,
X wday = 0, yday = 0, isdst = 0)
X
Xwhich means there's *NO PLACE* for me to pass in the
Xrest of struct tm, and if I can't do that, I not only
Xcan't use strftime for certain things, I *CAN'T USE IT AT ALL*
Xbecause it core dumps!!
X
XAnd I can't possibly figure out the real values for tm_zone
Xand tm_gmtoff to pass it because they aren't given to me from
Xperl's localtime() function!!
X
XI tend to think that this patch should be applied:
X
X*** POSIX.xs Sat Mar 11 22:30:03 1995
X--- /tmp/POSIX.xs Wed Apr 12 09:40:26 1995
X***************
X*** 3092,3098 ****
X RETVAL
X
X char *
X! strftime(fmt, sec, min, hour, mday, mon, year, wday = 0, yday = 0, isdst = 0)
X char * fmt
X int sec
X int min
X--- 3092,3099 ----
X RETVAL
X
X char *
X! strftime(fmt, sec, min, hour, mday, mon, year,
X! wday = 0, yday = 0, isdst = 0, zone = "", gmtoff = 0)
X char * fmt
X int sec
X int min
X***************
X*** 3103,3108 ****
X--- 3104,3111 ----
X int wday
X int yday
X int isdst
X+ char * zone
X+ int gmtoff
X CODE:
X {
X char tmpbuf[128];
X***************
X*** 3117,3122 ****
X--- 3120,3127 ----
X mytm.tm_wday = wday;
X mytm.tm_yday = yday;
X mytm.tm_isdst = isdst;
X+ mytm.tm_zone = zone;
X+ mytm.tm_gmtoff = zone;
X len = strftime(tmpbuf, sizeof tmpbuf, fmt, &mytm);
X ST(0) = sv_2mortal(newSVpv(tmpbuf, len));
X }
X
X t->tm_zone == (char *)0
X
XAnd similarly for POSIX::mktime() right before it.
X
XAs for good old POSIX::tzname(), I'm not quite sure all it's supported to
Xdo (SunOS doens't even doc it), but it loks like it must be returning the
X
X extern char *tzname[2]
X
Xvariable. Well, it doesn't do that on my system. Why? Cause in
Xhints/sunos_4_1.sh is has
X
X d_tzname='undef'
X
Xfor no apparent reason (Configure found it, but I was running
XConfigure -d and blindly took its work for it.) So then perl
Xturns around and does this in POSIX.xs:
X
X #ifdef HAS_TZNAME
X extern char *tzname[];
X #else
X char *tzname[] = { "" , "" };
X #endif
X
XAnd I am reminded why it was that I thought the POSIX module
Xwas broken. I said
X
X use POSIX;
X
XI even said
X
X use POSIX 'tzname';
X
XAnd all was well, but then what happens? When I call POSIX::tzname it
Xgives me the bogosity of a successful return -- of 2 empty string. It's
Xbroken its contract with me by lying about what it has and giving
Xme something entirely bogus while making me thing it's fine. It's in
Xclear and obvious breach of contract, and needs fixing.
X
XIf I say
X
X use POSIX;
X
Xand *ESPECIALLY*
X
X use POSIX some_function;
X
XI bloody well expect POSIX::some_function to be there, and
Xproperly so. Anything else is a dirty lie.
X
X--tom
X
END_OF_FILE
if test 6626 -ne `wc -c <'884'`; then
echo shar: \"'884'\" unpacked with wrong size!
fi
# end of '884'
fi
if test -f '885' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'885'\"
else
echo shar: Extracting \"'885'\" \(3511 characters\)
sed "s/^X//" >'885' <<'END_OF_FILE'
XReplied: Wed, 12 Apr 95 14:16:47 MDT
XReplied: tchrist
XReplied: roehrich@ironwood-fddi.cray.com (Dean Roehrich)
XReplied: perl5-porters@africa.nicoh.com
XReturn-Path: owner-perl5-porters@nicoh.com
XReceived: from africa.nicoh.com (daemon@africa.nicoh.com [198.60.251.1]) by mox.perl.com (8.6.10/8.6.10) with ESMTP id NAA17680 for <tchrist@perl.com>; Wed, 12 Apr 1995 13:55:30 -0600
XReceived: by africa.nicoh.com
X (1.37.109.15/16.2) id AA004814170; Wed, 12 Apr 1995 15:16:10 -0400
XFrom: roehrich@ironwood-fddi.cray.com (Dean Roehrich)
XMessage-Id: <9504121912.AA03714@poplar027>
XDate: Wed, 12 Apr 1995 14:12:04 -0500
XTo: perl5-porters@africa.nicoh.com
XSubject: Re: broken time stuff plus flagrant breach of POSIX contract
XContent-Length: 2698
XSender: owner-perl5-porters@nicoh.com
XList-Name: perl5-porters
XPrecedence: bulk
X
X> From: Tom Christiansen <tchrist@mox.perl.com>
X
X> How is it broken?
X>
X> I asked for a struct tm, and I want one. I'm being cheated
X> of the last two fields in struct tm: tm_zone and tm_gmtoff,
X> and they're the ones I really want!
X
XThose fields aren't part of POSIX, so I guess I don't believe you're being
Xcheated. The module is, afterall, POSIX.
X
XPOSIX 1003.1b-1993, Annex C, <time.h>, line 384 says the structure elements
Xfor struct tm are:
X tm_hour, tm_mday, tm_mon, tm_wday, tm_year,
X tm_isdst, tm_min, tm_sec, tm_yday
X
XNothing about tm_zone and tm_gmtoff.
X
X> I don't see why not to add this patch
X
Xbecause it will break on solaris&unicos, which have POSIX localtime...
X
X> Is the problem that not all sizes support tm_zone and tm_gmtoff?
X> That would be wretched. Even if so, I guess that we could use
X> the same thing as with pp_stat in USE_STAT_BLOCKS.
X
Xmaybe, but that just creates new script portability problems.
X
X> which means there's *NO PLACE* for me to pass in the
X> rest of struct tm, and if I can't do that, I not only
X> can't use strftime for certain things, I *CAN'T USE IT AT ALL*
X> because it core dumps!!
X
XI have a script which uses POSIX::strftime, doesn't core dump....
X
X> And I can't possibly figure out the real values for tm_zone
X> and tm_gmtoff to pass it because they aren't given to me from
X> perl's localtime() function!!
X
XI didn't have enough time to continue my search through the POSIX manual,
Xbut I have to believe there's something in there which will give you the
Xsame information.
X
X> I tend to think that this patch should be applied:
X
Xthat, of course, will break on a system which has POSIX strftime...
X
X> As for good old POSIX::tzname(), I'm not quite sure all it's supported to
X> do (SunOS doens't even doc it), but it loks like it must be returning the
X>
X> extern char *tzname[2]
X
XThat is POSIX. Specified in POSIX 1003.1b-1993, Annex C, <time.h>, line
X403. Also mentioned in section 8.3.2.2 in the description of the tzset()
Xfunction, where it is mentioned that "the tzset() function shall set the
Xexternal variable tzname...." The POSIX interpretation of "shall" is
X"must", as I understand it.
X
X> It's in
X> clear and obvious breach of contract, and needs fixing.
X
XThere are other breach-of-contract areas, it's not worth getting hot under
Xthe collar about just one of them. Note that there are lots of not_here's
Xin POSIX.xs.
X
XMaybe the parts of the POSIX module which are ifdef'd or not_here'd should
Xbe split out into a POSIX::NotGuaranteed module. Then the rest of the POSIX
Xmodule would be POSIX::Guaranteed, and the POSIX module would just pull in
Xboth of them.
X :-)
X
XWe can't blame Perl for the operating system.
X
XDean
X
END_OF_FILE
if test 3511 -ne `wc -c <'885'`; then
echo shar: \"'885'\" unpacked with wrong size!
fi
# end of '885'
fi
if test -f '886' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'886'\"
else
echo shar: Extracting \"'886'\" \(4226 characters\)
sed "s/^X//" >'886' <<'END_OF_FILE'
XReturn-Path: tchrist@mox.perl.com
XReceived: from localhost.perl.com (Warm-Fuzzies@localhost.perl.com [127.0.0.1]) by mox.perl.com (8.6.10/8.6.10) with SMTP id OAA18188; Wed, 12 Apr 1995 14:16:45 -0600
XTo: roehrich@ironwood-fddi.cray.com (Dean Roehrich)
Xcc: perl5-porters@africa.nicoh.com, tchrist@mox.perl.com
XSubject: Re: broken time stuff plus flagrant breach of POSIX contract
XIn-reply-to: Dean Roehrich's message <9504121912.AA03714@poplar027> of Wed, 12 Apr 95 14:12:04 CDT.
XReferences: <9504121912.AA03714@poplar027>
XDate: Wed, 12 Apr 95 14:16:44 MDT
XMessage-ID: <18185.797717804@mox>
XFrom: Tom Christiansen <tchrist@mox.perl.com>
X
X> > I asked for a struct tm, and I want one. I'm being cheated
X> > of the last two fields in struct tm: tm_zone and tm_gmtoff,
X> > and they're the ones I really want!
X
X> Those fields aren't part of POSIX, so I guess I don't believe you're being
X> cheated. The module is, afterall, POSIX.
X
XOK. Should we deny people the extra non-posix stat fields then?
XI don't have a 1003.1 book, nor a URL to one, but I'd be surprised
Xif the blocksize were mandatory -- after all, it would offend the
Xoldstyle SysV filesystems.
X
X> > I don't see why not to add this patch
X
X> because it will break on solaris&unicos, which have POSIX localtime...
X
XIt can be ifdeffed.
X
X> > Is the problem that not all sizes support tm_zone and tm_gmtoff?
X> > That would be wretched. Even if so, I guess that we could use
X> > the same thing as with pp_stat in USE_STAT_BLOCKS.
X
X> maybe, but that just creates new script portability problems.
X
Xok.
X
X> > which means there's *NO PLACE* for me to pass in the
X> > rest of struct tm, and if I can't do that, I not only
X> > can't use strftime for certain things, I *CAN'T USE IT AT ALL*
X> > because it core dumps!!
X
X> I have a script which uses POSIX::strftime, doesn't core dump....
X
X> > And I can't possibly figure out the real values for tm_zone
X> > and tm_gmtoff to pass it because they aren't given to me from
X> > perl's localtime() function!!
X
X> I didn't have enough time to continue my search through the POSIX manual,
X> but I have to believe there's something in there which will give you the
X> same information.
X
X> > I tend to think that this patch should be applied:
X
X> that, of course, will break on a system which has POSIX strftime...
X
X> > As for good old POSIX::tzname(), I'm not quite sure all it's supported to
X> > do (SunOS doens't even doc it), but it loks like it must be returning the
X> >
X> > extern char *tzname[2]
X
X> That is POSIX. Specified in POSIX 1003.1b-1993, Annex C, <time.h>, line
X> 403. Also mentioned in section 8.3.2.2 in the description of the tzset()
X> function, where it is mentioned that "the tzset() function shall set the
X> external variable tzname...." The POSIX interpretation of "shall" is
X> "must", as I understand it.
X
XWell, then the SunOS hints file is wrong. Maybe the problem
Xis you're only going to get that if you link with sysV environment.
XI dunno. But it ought to be there!
X
XIt certainly shoudln't get bogified into what's currently
Xhappening with tzname.
X
X> > It's in
X> > clear and obvious breach of contract, and needs fixing.
X
X> There are other breach-of-contract areas, it's not worth getting hot under
X> the collar about just one of them. Note that there are lots of not_here's
X> in POSIX.xs.
X
X> Maybe the parts of the POSIX module which are ifdef'd or not_here'd should
X> be split out into a POSIX::NotGuaranteed module. Then the rest of the POSIX
X> module would be POSIX::Guaranteed, and the POSIX module would just pull in
X> both of them.
X> :-)
X
XI'm sorry, but I'm hot under the color again then. If I say
XPOSIX, I want to get it, take an exception.
X
XAt the very least, I should be able to do this:
X
Xeval { require POSIX } || warn "something's missing....$@";
Xif (!defined &POSIX::tzname) { ... }
X
X> We can't blame Perl for the operating system.
X
XPerhaps not, but I still think thing that if you want
Xto tolerate mendacious contractual guarantees, you should
Xbe forced to type:
X
X use As_Much_of_POSIX_as_I_Can_Get;
X
Xif they want the
X
X BEGIN { eval "require POSIX" }
X
Xbehaviour, but for
X
X use POSIX;
X
Xand of course
X
X use POSIX qw(tzname);
X
Xto really mean something.
X
X--tom
X
END_OF_FILE
if test 4226 -ne `wc -c <'886'`; then
echo shar: \"'886'\" unpacked with wrong size!
fi
# end of '886'
fi
if test -f '887' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'887'\"
else
echo shar: Extracting \"'887'\" \(1851 characters\)
sed "s/^X//" >'887' <<'END_OF_FILE'
XReturn-Path: owner-perl5-porters@nicoh.com
XReceived: from africa.nicoh.com (daemon@africa.nicoh.com [198.60.251.1]) by mox.perl.com (8.6.10/8.6.10) with ESMTP id PAA19264 for <tchrist@perl.com>; Wed, 12 Apr 1995 15:11:15 -0600
XReceived: by africa.nicoh.com
X (1.37.109.15/16.2) id AA029859854; Wed, 12 Apr 1995 16:50:54 -0400
XDate: Wed, 12 Apr 1995 16:47:31 -0400 (EDT)
XFrom: Andy Dougherty <doughera@lafcol.lafayette.edu>
XSubject: Re: broken time stuff plus flagrant breach of POSIX contract
XTo: perl5-porters@africa.nicoh.com
XIn-Reply-To: <18185.797717804@mox>
XMessage-Id: <Pine.3.89.9504121645.A20528-0100000@lafcol>
XMime-Version: 1.0
XContent-Type: TEXT/PLAIN; charset=US-ASCII
XSender: owner-perl5-porters@nicoh.com
XList-Name: perl5-porters
XPrecedence: bulk
X
XOn Wed, 12 Apr 1995, Tom Christiansen wrote:
X
X>
X> > > As for good old POSIX::tzname(), I'm not quite sure all it's supported to
X> > > do (SunOS doens't even doc it), but it loks like it must be returning the
X> > >
X> > > extern char *tzname[2]
X>
X> > That is POSIX. Specified in POSIX 1003.1b-1993, Annex C, <time.h>, line
X> > 403. Also mentioned in section 8.3.2.2 in the description of the tzset()
X> > function, where it is mentioned that "the tzset() function shall set the
X> > external variable tzname...." The POSIX interpretation of "shall" is
X> > "must", as I understand it.
X>
X> Well, then the SunOS hints file is wrong. Maybe the problem
X> is you're only going to get that if you link with sysV environment.
X> I dunno. But it ought to be there!
X
XI suspect this particular problem is actually one of dynamic loading of
Xdata (as opposed to functions) and is an ld.so problem rather than a
Xbreach of POSIX. I seem to recall that if you load POSIX statically
Xwithout the d_tzname hint it still works on SunOS 4.1.3.
X
X Andy Dougherty doughera@lafcol.lafayette.edu
X
X
END_OF_FILE
if test 1851 -ne `wc -c <'887'`; then
echo shar: \"'887'\" unpacked with wrong size!
fi
# end of '887'
fi
if test -f '888' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'888'\"
else
echo shar: Extracting \"'888'\" \(1665 characters\)
sed "s/^X//" >'888' <<'END_OF_FILE'
XReturn-Path: owner-perl5-porters@nicoh.com
XReceived: from africa.nicoh.com (daemon@africa.nicoh.com [198.60.251.1]) by mox.perl.com (8.6.10/8.6.10) with ESMTP id XAA00216 for <tchrist@perl.com>; Mon, 17 Apr 1995 23:52:01 -0600
XReceived: by africa.nicoh.com
X (1.37.109.15/16.2) id AA192053357; Tue, 18 Apr 1995 01:35:57 -0400
XMessage-Id: <199504180451.OAA12898@fulcrum.com.au>
XTo: Andy Dougherty <doughera@lafcol.lafayette.edu>
XCc: perl5-porters@africa.nicoh.com
XSubject: Re: broken time stuff plus flagrant breach of POSIX contract
XFrom: matthew green <mrg@fulcrum.com.au>
XIn-Reply-To: Andy Dougherty's message <Pine.3.89.9504121645.A20528-0100000@lafcol> of Wed, 12 Apr 1995 16:47:31 -0400.
XReferences: <Pine.3.89.9504121645.A20528-0100000@lafcol>
XDate: Tue, 18 Apr 1995 14:51:38 +1000
XSender: owner-perl5-porters@nicoh.com
XList-Name: perl5-porters
XPrecedence: bulk
X
X > Well, then the SunOS hints file is wrong. Maybe the problem
X > is you're only going to get that if you link with sysV environment.
X > I dunno. But it ought to be there!
X
X I suspect this particular problem is actually one of dynamic loading of
X data (as opposed to functions) and is an ld.so problem rather than a
X breach of POSIX. I seem to recall that if you load POSIX statically
X without the d_tzname hint it still works on SunOS 4.1.3.
X
Xyup. here's a perl with tzname defined:
X
Xsleepy src/perl/perl5.001> ./perl -I./lib -e 'use POSIX;'
Xld.so: Undefined symbol: _tzname
Xsleepy src/perl/perl5.001>
X
Xmemory is hazy, but doesn't this mean we need a POSIX.sa for
Xsunos 4 systems ? i mostly forget how all this works...
X
Xnick ? do you know ?
X
X.mrg.
X
END_OF_FILE
if test 1665 -ne `wc -c <'888'`; then
echo shar: \"'888'\" unpacked with wrong size!
fi
# end of '888'
fi
if test -f '889' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'889'\"
else
echo shar: Extracting \"'889'\" \(1930 characters\)
sed "s/^X//" >'889' <<'END_OF_FILE'
XReturn-Path: owner-perl5-porters@nicoh.com
XReceived: from africa.nicoh.com (daemon@africa.nicoh.com [198.60.251.1]) by mox.perl.com (8.6.10/8.6.10) with ESMTP id DAA26786 for <tchrist@perl.com>; Wed, 19 Apr 1995 03:12:01 -0600
XReceived: by africa.nicoh.com
X (1.37.109.15/16.2) id AA205351278; Wed, 19 Apr 1995 04:47:58 -0400
XFrom: Nick.Ing-Simmons@tiuk.ti.com
XDate: Wed, 19 Apr 95 09:44:09 BST
XMessage-Id: <9504190844.AA20900@pluto>
XTo: mrg@fulcrum.com.au
XCc: Andy Dougherty <doughera@lafcol.lafayette.edu>
XCc: perl5-porters@africa.nicoh.com
XSubject: Re: broken time stuff plus flagrant breach of POSIX contract
XSender: owner-perl5-porters@nicoh.com
XList-Name: perl5-porters
XPrecedence: bulk
X
XIn <199504180451.OAA12898@fulcrum.com.au>
XOn Tue, 18 Apr 1995 14:51:38 +1000
XMatthew Green <mrg@fulcrum.com.au> writes:
X>
X> > Well, then the SunOS hints file is wrong. Maybe the problem
X> > is you're only going to get that if you link with sysV environment.
X> > I dunno. But it ought to be there!
X>
X> I suspect this particular problem is actually one of dynamic loading of
X> data (as opposed to functions) and is an ld.so problem rather than a
X> breach of POSIX. I seem to recall that if you load POSIX statically
X> without the d_tzname hint it still works on SunOS 4.1.3.
X>
X> yup. here's a perl with tzname defined:
X>
X> sleepy src/perl/perl5.001> ./perl -I./lib -e 'use POSIX;'
X> ld.so: Undefined symbol: _tzname
X> sleepy src/perl/perl5.001>
X>
X> memory is hazy, but doesn't this mean we need a POSIX.sa for
X> sunos 4 systems ? i mostly forget how all this works...
X>
X> nick ? do you know ?
X
XI have always managed to avoid .sa files, but then exporting data is
Xnot my 'style' so I may have been lucky.
X
XI think we can work round it somehow, but things are a bit weird here
Xat the moment (whole site is moving this week), so I don't have any time
Xto look into it.
X
X>
X> .mrg.
X
END_OF_FILE
if test 1930 -ne `wc -c <'889'`; then
echo shar: \"'889'\" unpacked with wrong size!
fi
# end of '889'
fi
echo shar: End of shell archive.
exit 0