From dive@mokimaki.ethereal.net

Created by dive@dragon.ender.com

i have noticed that on several FreeBSD machines that if you do
something such as print 65536 ** 65536 . "\n"; or calculate 65536**65536 in
any manner that it causes perl to core with a floating exception. I have tried
this on some linux machines also, and the linux machines just return 'inf' for
the result of that calculation. both the freebsd and linux machines use perl
5.005_03. I am not sure as to whether this is a bug in perl itself or in some
element of FreeBSD.

Site configuration information for perl 5.00503:

Configured by markm at $Date: 1999/05/05 19:42:40 $.

Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
  Platform:
    osname=freebsd, osvers=4.0-current, archname=i386-freebsd
    uname='freebsd freefall.freebsd.org 4.0-current freebsd 4.0-current #0: $Date: 1999/05/05 19:42:40 $'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef useperlio=undef d_sfio=undef
  Compiler:
    cc='cc', optimize='undef', gccversion=egcs-2.91.66 19990314 (egcs-1.1.2 release)
    cppflags=''
    ccflags =''
    stdchar='char', d_stdstdio=undef, usevfork=true
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    alignbytes=4, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='cc', ldflags ='-Wl,-E'
    libpth=/usr/lib
    libs=-lm -lc -lcrypt
    libc=/usr/lib/libc.so, so=so, useshrplib=true, libperl=libperl.so.3
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
    cccdlflags='-DPIC -fpic', lddlflags='-shared'

Locally applied patches:
    


@INC for perl 5.00503:
    /usr/libdata/perl/5.00503/mach
    /usr/libdata/perl/5.00503
    /usr/local/lib/perl5/site_perl/5.005/i386-freebsd
    /usr/local/lib/perl5/site_perl/5.005
    .


Environment for perl 5.00503:
    HOME=/z/dive
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/z/dive/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/bin:/usr/X11R6/bin
    PERL_BADLANG (unset)
    SHELL=/usr/local/bin/tcsh

From [Unknown Contact. See original ticket]

you klingon bastard <dive@​mokimaki.ethereal.net> wrote

i have noticed that on several FreeBSD machines that if you do
something such as print 65536 ** 65536 . "\n"; or calculate 65536**65536 in
any manner that it causes perl to core with a floating exception. I have tried
this on some linux machines also, and the linux machines just return 'inf' for
the result of that calculation. both the freebsd and linux machines use perl
5.005_03. I am not sure as to whether this is a bug in perl itself or in some
element of FreeBSD.

More a feature than a bug. Perl simply does whatever the underlying
C arithmetic does, which will be platform-dependent.

You could always trap SIGFPE, but it's not clear what you could usefully
do next, except die().

Mike Guy

From [Unknown Contact. See original ticket]

i traced the bug/feature/whatever to the fact that perl on freebsd does
not call fpsetmask to disable the exception handlers so that perl can do
it on it's own. this patch will resolve the problem.

*** perl5.005_03/unixish.h Thu Feb 24 23​:00​:18 2000
--- perl5.005_03-orig/unixish.h Fri Feb 12 00​:06​:20 1999
***************
*** 7,10 ****
! #ifdef __FreeBSD__
! # include <floatingpoint.h>
! # define PERL_SYS_INIT(c,v) fpsetmask(0); MALLOC_INIT;
! #endif
--- 7 ----
!

On Thu, 17 Feb 2000, M.J.T. Guy wrote​:

you klingon bastard <dive@​mokimaki.ethereal.net> wrote

i have noticed that on several FreeBSD machines that if you do
something such as print 65536 ** 65536 . "\n"; or calculate 65536**65536 in
any manner that it causes perl to core with a floating exception. I have tried
this on some linux machines also, and the linux machines just return 'inf' for
the result of that calculation. both the freebsd and linux machines use perl
5.005_03. I am not sure as to whether this is a bug in perl itself or in some
element of FreeBSD.

More a feature than a bug. Perl simply does whatever the underlying
C arithmetic does, which will be platform-dependent.

You could always trap SIGFPE, but it's not clear what you could usefully
do next, except die().

Mike Guy