Is freadi broken in 64-bit Clean?

[Maks Verver]

Hi everyone,

I'm trying to do some simple I/O with Clean and I've run into some very
strange behaviour which I think is a bug in the 64-bit edition of Clean.

Consider this program (Test.icl):

   module Test

   import StdEnv

   doCase :: *File Int -> *File
   doCase fp c
   # (ok, n, fp) = freadi fp
   = fwrites ("Case #" +++ toString c +++ ": "
               +++ toString n +++ " (" +++ toString ok +++ ")\n") fp

   Start world
   # (fp, world) = stdio world
   = fclose (do (freadi fp)) world
   where
       do (False, _, fp) = fp
       do (True,  n, fp) = foldl doCase fp [1..n]

And the following data file (test.in):

   3
   123
   456
   789

When I try to compile and run this, the result is as follows:

   $ clm Test
   Compiling Test
   Warning [StdFile.abc,11,stdio;33]: no inline code for this rule
   Warning [StdFile.abc,11,fclose;30]: no inline code for this rule
   Generating code for Test
   Linking Test

   $ ./a.out < test.in
   Case #1: 140733193388155 (True)
   Case #2: 456 (True)
   Case #3: 789 (True)
   (True,65536)
   Execution: 0.00  Garbage collection: 0.00  Total: 0.00

Of course this is very strange: I expected Case #1 to print 123. As you
can see, reading does succeed, and the following values are read
correctly. Now, 140733193388155 is 0x7fff0000007b and 0x7b is indeed
123, so it appears that freadi actually only reads a 32-bit integer and
leaves garbage in the upper 32 bits of the resulting integer.

Is this a known problem? Any suggestions on how to fix this or work
around it?

Kind regards,
Maks Verver.
_______________________________________________
clean-list mailing list
clean-list@...
http://mailman.science.ru.nl/mailman/listinfo/clean-list

[John van Groningen]

Maks Verver wrote:
>..
>Of course this is very strange: I expected Case #1 to print 123. As you can see, reading does succeed, and the following values are read correctly. Now, 140733193388155 is 0x7fff0000007b and 0x7b is indeed 123, so it appears that freadi actually only reads a 32-bit integer and leaves garbage in the upper 32 bits of the resulting integer.

On the 64 bit linux version only the least significand 32 bits are correct.
This happens because the C function that is used to implement freadi uses
int* instead of long*. I have fixed this in the source code.

>Is this a known problem? Any suggestions on how to fix this or work around it?

If 32 bit numbers are sufficient, shift the result 32 bits to the left and
then 32 bits to the right, or if it is unsigned, 'bitand' with 0xffffffff.

If you need more bits, you can implement freadi using freadc.

Kind regards,

John van Groningen
_______________________________________________
clean-list mailing list
clean-list@...
http://mailman.science.ru.nl/mailman/listinfo/clean-list