Re: Interfacing with C - macros and stuff

On Mon, 10 Jan 2011, Marek Janukowicz wrote:

> Date: Mon, 10 Jan 2011 01:02:14 +0100
> From: Marek Janukowicz <[email protected]>
> To: [email protected]
> Subject: Interfacing with C - macros and stuff
>
> Hello
>
> Specification p. 15.2. reads: "Constants of external C types are interpreted
> as C constants or macros.".

Marek, if you are still there months later: I think you may be quoting
from memory from Doc/Sather-1.1.ps, page 71, where I find:

"Attributes may be placed in external C classes; they are interpreted
as fields of a C struct.  Similarly shareds are interpreted as C global
variables.  Constants are interpreted as C constants or macros."

>
> Am I misreading it or does it mean I should be able to do smth like:
>
> external C class C_SMTH is
>   const AI_PASSIVE : C_INT;
> end;

On my interpretation, no, you can't do that.

>
> and then (given I'd include netdb.h somewhere) C_SMTH::AI_PASSIVE would
> contain the value of this C macro? Because I can't do that: I can't create a
> constant and not init it immediately and if I init it, it doesn't contain C
> value, but Sather value I provided, right?

Heh.  Assignment of a literal from netdb.h to a Sather constant?  :-)

>
> So to sum it up - either it's poorly specified or not implemented
> (partially/completely) or I'm reading it wrong.
>

I think a bit of both.  The writer has written "interpreted", several
times, where "implemented" might be better.

You may be able to access the replacement texts of CPP identifiers
with shareds in the external C class, but I'd be a little surprised if
that worked.  I think there has to be a declared C language
identifier.  And my interpretation of that passage is that the Sather
declaration of a shared would be implemented as a C global variable.
I don't know if the C code you write needs to declare such a global
variable.  I suspect not.  It just needs to write to it or read from
it.

The C code might then assign to that global, and (but I seem to find,
only if it is a shared INT or C_INT, not a shared EXT_OB) the shared
would return that value when "called" or accessed by the Sather code.

(If you want to access an EXT_OB it seems you can't to it with a
shared, you need to call a function which will return it.  Accessing a
shared of type EXT_OB seems to cause a segfault.  Perhaps because one
is not supposed to store pointers.)

For a pointer as to one way of accessing cpp constants, look at the files
c_interface.sa and c_interface.c in Library/System/TclTk, and the way
they access tcl.h constants.  In the first, note in the external C
class the lines:

   ConstTclOk: INT;
   ConstTclError: INT;
   ConstTclVolatile: EXT_OB;

Those are routine signatures without bodies, indicating the return
types INT, INT and EXT_OB.  The implementations are in c_interface.c,
specifically:

int ConstTclOk() {
  return TCL_OK;
}

int ConstTclError() {
  return TCL_ERROR;
}

void *ConstTclVolatile() {
  return TCL_VOLATILE;
}

Of course, following preprocessing, as seen by the C compiler, these
would be

int ConstTclOk() {
  return 0;
}

etc.

Regards,
Mike

-- 
Michael Talbot-Wilson