Re: What is the equivalent type in GM2?

[Hưng Hưng]

The C version doesn't impose any max length. So I have to guest and put a value for max length that I found suitable? It's like we impose an imagination/artificial limitation to our binding with no reason at all.

Vào Th 7, 28 thg 3, 2020 vào lúc 14:47 Benjamin Kowarsch <address@hidden> đã viết:

A pointer to char in C is not equivalent to a pointer to CHAR in Modula-2.

In C a string may be either a char array or a pointer to a single char where the lack of type safety is then EXPLOITED to ignore the fact that the pointer type points to a single char, not a character string, and with DEVASTATING CONSEQUENCES !!!

By contrast, in Modula-2 a string is a character array with a maximum capacity associated to the type and type safety is enforced, thus a pointer to a singe character is always interpreted correctly as having a payload of only one single character.

Thus, the closest equivalent of

char* str;

in Modula-2 would be

POINTER TO ARRAY [0..MaxStrLen] OF CHAR;

where MaxStrLen must be a compile time constant, that is, it cannot be changed dynamically at runtime.

And if you have a static character array string in Modula-2, like

VAR str : ARRAY [0..80] OF CHAR;

then you can't just pass str to a char* parameter of a C function. Instead you need to pass a pointer to it.

TYPE Str80 = ARRAY [0..80] OF CHAR;

VAR str : Str80;

TYPE Str80Ptr = POINTER TO Str80;

VAR strPtr : Str80Ptr;

then

str := "the quick brown fox jumps over the lazy dog.";

strPtr := VAL(Str80Ptr, ADR(str));

then

passToC(strPtr);

assuming

void passToC(const char* s);

Although GM2 may already map an argument of a character array type to char* when using the DEFINITION MODULE FOR "C" syntax to map C functions. Even if it does, it likely won't do the same for char** and char***.

Thus, if the C function parameters are char** then you need

POINTER TO POINTER TO ARRAY [0..MaxStrLen] OF CHAR;

Likewise for char*** you need

POINTER TO POINTER TO POINTER TO ARRAY [0..MaxStrLen] OF CHAR;

As I have mentioned before, the best way to interface to C APIs is to use a layered approach where the lowest level interfaces directly with the C API and a user level provides a wrapped Modula-2 representation that is independent of the C API. In the lower level library you can then convert and cast types as needed to pass between C and Modula-2.

On Sat, 28 Mar 2020 at 03:27, Hưng Hưng <address@hidden> wrote:

Let me add additional information. If I use the pointer trick, e.g: PChar, PPChar, PPPChar, then I can't pass the M2 string into C function as it requires C string, if I try to do so the compiler will complain because it expect char to have only length 1. M2 and C have a very different way of processing string, as I see the equivalent pointer to char trick in C would not work on M2.

There is a procedure in module DynamicStrings allow to convert between M2 string and C string, but again, how to translate these data type correctly? If we go the pointer trick we will then have to figure out how to represent PPChar, PPPChar as the procedure in DynamicStrings only helps us up to here. It's circular reasoning. I feel my head as going to explode.

Vào Th 7, 28 thg 3, 2020 vào lúc 01:15 Hưng Hưng <address@hidden> đã viết:

The C function return or took a C string as parameter, with is an array of char or pointer to unsigned char.

Another function return or took an array of C string as parameter, which is an 2D array of char or pointer to pointer to unsigned char.

Another function return or took an array of array of C string as parameter, which is an 3D array of

char or pointer to pointer to pointer to unsigned char.

It's too complex. C code tends to abuse pointer too much.

e.g:

void      IupResetAttribute(Ihandle* ih, const char* name);

int       IupGetAllAttributes(Ihandle* ih, char** names, int n);

int       IupOpen          (int *argc, char ***argv);