Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

floating point overflow #691

Closed
p5pRT opened this issue Oct 7, 1999 · 2 comments
Closed

floating point overflow #691

p5pRT opened this issue Oct 7, 1999 · 2 comments

Comments

@p5pRT
Copy link

@p5pRT p5pRT commented Oct 7, 1999

Migrated from rt.perl.org#1589 (status was 'resolved')

Searchable as RT1589$

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Oct 7, 1999

From aaron@caxton.com

I don't know if this counts exactly as a bug, since it
is arguably just a weird interaction with perl extensions that
arguably we shouldn't be making. Nonetheless it would
be helpful for us to get things to work the way we want.

We're building some SWIG extensions to perl to use it as a scripting
language for some numerical C code we're working on.

We used SWIG to add a perl function that changes the default handling
of ieee floating point exceptions. We do this in order to insure
failure in our other extension routines if we ever get an overflow or
invalid floating point result.

It appears that such an overflow occurs in the scan_num routine
in file toke.c, when asked to parse a floating point constant
expression with value greater than 2147483547.0

For regular perl this internal floating point overflow is ignored and
appears to have no effect.

Similarly if we invoke our extended perl on most programs there is no
problem. If however our program calls our function to change the
floating point handling and then again invokes the perl parser via do
or eval we get into trouble. The problem only occurs when do or eval
is asked to parse a floating point constant expression greater than
2147483547.0.

Our work-around is simply to wrap any calls to eval or do
with calls to turn off and back on the overflow trapping.

But we don't see why we need to do this.

If anybody decides to take this seriously I'd appreciate an email
as I don't check the Perl bug list with any frequency.

Thanks for any help,
Aaron

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Oct 8, 1999

From [Unknown Contact. See original ticket]

Aaron Sosnick writes​:

We used SWIG to add a perl function that changes the default handling
of ieee floating point exceptions.

AFAIU, you cannot do it in C. AFAIU C compilers assume a specific way
of handling FP exceptions to make conversions from FP to integers.

It appears that such an overflow occurs in the scan_num routine
in file toke.c, when asked to parse a floating point constant
expression with value greater than 2147483547.0

Please check whether the same happens with current development
releases. They use a different conversion logic on 32-bit machines.

Ilya

P.S. I often see similar problems on OS/2, when DLLs can be installed
  as "hooks" and are executed in context of another process (say,
  during screen right, or keyboard read). Some buggy DLLs reset
  FP flags, leading to problems.

  Perl code as simple as ~1 was causing a FP exception.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant