[ooc-compiler] Understanding system flags

[Frank C. <fj...@th...>]

I'm trying to get a deeper understanding of how system flags affect the
behaviour of types, particularly types equivalent to C strings, structures
and arrays. I need to know this to implement interface modules for C
libraries and Oberon modules manipulating C types such as strings.

SymbolTable.Mod gives the following list of flags:

NO_COPY, ABSTRACT, NO_LENGTH_INFO, NO_DESCRIPTOR, NOT_EXTENSIBLE,
EXTENSIBLE, UNCHECKED_EXCEPTION, CSTRING, NIL_COMPAT, UNION, READ_ONLY,
NO_RETURN, DEPRECATED, OOC_EXTENSIONS, ALIGN1, ALIGN2, ALIGN4, ALIGN8,
VTABLE, NO_TRACED_POINTERS

It would be good to have a description of these flags like the one in OOCRef 
for OOC v1. However, the ones I believe are relevant to me are:

NO_LENGTH_INFO, NO_DESCRIPTOR, CSTRING, NIL_COMPAT, UNION

I'm pretty sure I grok NIL_COMPAT and UNION. I'm less sure of the 
interaction of NO_LENGTH_INFO, NO_DESCRIPTOR and CSTRING.

For example, how is a C string declared? Module RT0 has these declarations:

TYPE
   charPtr1d* = POINTER TO ARRAY [NO_LENGTH_INFO, NO_DESCRIPTOR] OF CHAR;
   charPtr2d* = POINTER TO ARRAY [NO_LENGTH_INFO, NO_DESCRIPTOR] OF charPtr1d;

These types represent the arguments passed to a C program in the 'argv' 
parameter of the 'main' function. The C declaration varies, but is usually 
either:

   char * argv[];

or

   char ** argv;

On the other hand, Module C declares a C string as:

TYPE
   char* = CHAR;
   string* = POINTER [CSTRING] TO ARRAY OF char;

The equivalent C declaration would be:

   char * whatever

In theory C.string and RT0.charPtr1d should be equivalent but the compiler 
understandably treats them as different types. Which one is correct?

-- 

> When there isn't sufficient virtual memory, the compiler bails out,
> giving an internal error message. When I kill some processes, the
> error goes away.

And what is the compiler supposed to do instead? Go shopping for you
and buy more memory?

                 -- Falk Hueffner, on the GNU C++ compiler