Re: [Chicken-janitors] #1272: string->number crash

[Chicken Trac]

#1272: string->number crash
-----------------------------+----------------------------
  Reporter:  mario           |      Owner:
      Type:  defect          |     Status:  new
  Priority:  critical        |  Milestone:  4.11.0
 Component:  core libraries  |    Version:  4.10.x
Resolution:                  |   Keywords:  string->number
-----------------------------+----------------------------

Comment (by sjamaan):

 Oh my, this is nasty!

 We first call {{{C_strow()}}} to attempt a conversion (and if it fails we
 roll our own). This is either {{{strol()}}} or {{{stroll()}}} depending on
 platform.

 And what does the glibc manual state?

  RETURN VALUE
        The  strtol() function returns the result of the conversion, unless
 the value would underflow or over‐
        flow.  If an underflow occurs, strtol() returns LONG_MIN.  If an
 overflow  occurs,  strtol()  returns
        LONG_MAX.   In  both  cases,  errno  is  set  to ERANGE.  Precisely
 the same holds for strtoll() (with
        LLONG_MIN and LLONG_MAX instead of LONG_MIN and LONG_MAX).

  ERRORS
        EINVAL (not in C99) The given base contains an unsupported value.

        ERANGE The resulting value was out of range.

        The implementation may also set errno to EINVAL in case no
 conversion was performed (no  digits  seen,
        and 0 returned).


 So this breaks the spec (because {{{ERANGE}}} isn't supported by C99), and
 we only check for errno {{{EINVAL}}}. If errno has any other value, we
 dereference {{{eptr}}}, the end pointer which will have an unspecified
 value if it returned an error!

 I'm not sure what the correct fix would be here.  I suppose we should just
 ignore {{{errno}}}, or bail out if we see an unexpected one with {{{(n ==
 C_LONG_MAX || n == C_LONG_MIN)}}}.  But what if the return value just
 happens to actually be that value?

 Also, if we're using {{{stroll}}}, we should actually be checking for
 {{{C_LLONG_MAX}}} or {{{C_LLONG_MIN}}} instead of
 {{{C_LONG_MAX}}}/{{{C_LONG_MIN}}}.

 In CHICKEN 5, this problem should be gone because this function has been
 completely replaced by a full numeric tower-aware version.

--
Ticket URL: <http://bugs.call-cc.org/ticket/1272#comment:1>
CHICKEN Scheme <http://www.call-cc.org/>
CHICKEN Scheme is a compiler for the Scheme programming language.