Allô,
I must apologize for my forgetfulness. I went through this six months ago. Peter Bex helped me with this problem. The conclusion was that there is a bad interaction between the locale (I am in Canada) and low level string & number handling. The conclusion was as follows.
> I think the underlying problem (at least, for reading of numbers)
> has been fixed in CHICKEN 5; it will no longer use strtod or strtol[l]
> once we recompile and remove backwards bootstrap compatibility.
The whole story is on the Chicken Hackers mailing list. Using a 64-bit version of MinGW is also involved in this. Since everything works well with 32-bit MinGW, it's easiest to wait for Chicken 5.
Thank you.
On 2017-02-15, Evan Hanson wrote:
> On 2017-02-14 21:44, Claude Marinier wrote:
> > I am trying to reproduce the error with the intent of poking around.
> > How can I tell 'csc' to keep the generated C?
>
> Use `csc -k` (for "keep").
>
> > By the way, right after building, I notice 'csi' behaves oddly.
> >
> > address@hidden MINGW64 ~/chicken-4.11.1/tests
> > $ csi
> > (* 1 2 3 4 5)
> > (exit)
> >
> > CHICKEN
> > (c) 2008-2016, The CHICKEN Team
> > (c) 2000-2007, Felix L. Winkelmann
> > Version 4.11.1 ((detached from 4.11.1)) (rev 116f42e)
> > windows-mingw32-x86-64 [ 64bit manyargs dload ptables ]
> > compiled 2016-09-12 on waldrop (Linux)
> >
> > 120
> >
> > address@hidden MINGW64 ~/chicken-4.11.1/tests
> > $
> >
> > This is unexpected. It looks like a terminal I/O problem. Is this known?
>
> Yeah, and I have a hunch it might be caused by the same underlying
> issue, but I'm not really sure. In short, `##sys#tty-port?`, which is
> used by by csi(1) to detect whether it's running in a terminal or not,
> fails from within the MSYS shell: peeking the leading byte of the port
> gives a non-zero value, which is unexpected.
--