🚀 go-pugleaf

Peter P. Eiserloh <Peter_Eyes_Eiserloh@wssagw.chinalake.navy.mil> wrote:
>In article <45aanm$2s9@stork.qut.edu.au> John Gough,
>gough@dstc.qut.edu.au writes:
>>In essence we have a new type HUGEINT which is 64-bit and signed.  You
>
>Why do we need a new type HUGEINT, when we could use LONGCARD, and
>LONGINT.
>That is what they are there for!  With the current GPM compilers the 

Well, the problem is that LONGINT and LONGCARD _aren't_ there, as far as
the ISO standard is concerned.  In any case, my feeling is that people
expect the size of INTEGER to vary, but expect LONGXXX to be 32-bits.

> [snip]
>future machines).  The original GPM abitrarily decided to not support 
>longer ordinal type.  Another problem with HUGEINT, is that there is no
>support for HUGECARD (unsigned 64 bit word).

We made a commitment to go with ISO (for better or worse) and they did away
with long types.  We provided the <Types> definition to give easy backward
compatibility.  Of course, as far as the short types are concerned there 
is never a problem, since subranges always do it for you.  (BTW we did think
about doing the long types by allowing the definition of "subranges" which 
were larger than their base types,  but relative sanity prevailed...)

>We also need some portability interfaces.  The <Types> module is
>a step in the right direction.  You need some method of determining 
>the machines endian order, and byte swapping routines.
>
>While you are adding things to the GPM interfaces consider adding
>FileLength() to <UxFiles>, or a real SEEK function where I can position 
>the mark at the EOF and then get the file offset of the EOF that way.
>SetPos() does not suffice for this purpose.  

Good idea, we will consider it for future releases.

>One of the worst problems that I have with the GPM interfaces is that
>the low level modules do not provide an interface to the OS.  I don't
>care how dirty the OS interface is, it is the OS.  The high level library 
>modules are supposed to hide the OS details from the casual programmer,
>but when you want access to the OS, now I have to implement a non-standard
>(not released with the compiler) interface module and link in the 
>libc library.

Yep, that is so.  We have modules which have dramaticallly different 
implementations between different OS, but we have been very reluctant to
release modules for which even the definitions are different.  

Cheers
John Gough