[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gm2] Interfacing to C -- How do we map size_t to Modula-2?

From: Gaius Mulley
Subject: Re: [Gm2] Interfacing to C -- How do we map size_t to Modula-2?
Date: Wed, 26 Jul 2017 11:34:49 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Benjamin Kowarsch <address@hidden> writes:

>     On Jul 22, 2017, at 08:05, Gaius Mulley wrote:
>     I've added CSIZE_T, CSSIZE_T data types to SYSTEM.def which map
>     onto
>     size_t and ssize_t in C.
> Thanks, that is very useful.
> I updated the GM2 POSIX interfaces of M2PP accordingly. I post the
> links below, in case somebody else wants to reuse them
> stdio still needs two separate versions for PIM and ISO because of LOC
> vs BYTE but these will eventually be generated from a common template
> using M2PP itself.
> Also of interest beyond this project may be the two libraries
> BasicFileIO and BasicFileSys for which there are implementations based
> on PIM, ISO, POSIX and vendor specific libraries, making them portable
> across PIM3, PIM4, ISO dialects on at least 13 compilers, with Aglet
> and Clarion still on the to do list.
> the latter has two versions, one defining type FileSize as CARDINAL
> the other as LONGINT.

Hi Benjamin,

all interesting - I have been wondering if we need a build script to
determine configuration constants.  Ie

FROM configure IMPORT off_t ;

and resolve off_t in autoconf?  I suspect there would be a few options
which modula-2 projects could use.

> The build configuration script determines which files are needed and
> places renamed copies in the build directory accordingly.

this looks similar!

> I am probably going to spin off the IO libraries into a portable IO
> library project with its own repo.
> The license is LGPL2.1, so you can do whatever you want with it but if
> you fix a bug, you'll have to share the fix.

many thanks - this sounds very useful and will incorporate it.

> As an aside, we are also using this library for the M2-hosted R10
> Bootstrap Kit, which was the primary motivation for M2PP in the first
> place. This means we're going to actively maintain this portable IO
> library.

generating a preprocessor is a good way to start I think - it allows for
fast prototyping and debugging


reply via email to

[Prev in Thread] Current Thread [Next in Thread]