Re: NCurses

willett wrote:

Frank,

Thanks very much for the helpful info on location of fpc copying rights and on location of current version.

That was Marco actually. I only forwarded his mail, as he isn't suscribed to the list.

One construction I'm not sure on translation of is:

 function beep:longint; cdecl;external libncurses;
 function can_change_color:bool; cdecl;external libncurses;
 function cbreak:longint; cdecl;external libncurses;

The fpc "cdecl;' makes the calling sequence of Pascal match that of c. (see the table from FPC manual at end of this email; its a graphic file, sorry, I couldn't get a good text cut.) It appears 'cdecl' is the default for gpc (true?),

Yes.

thus, for gpc I think these could be declared, somewhat like the external variables were, as, e.g.:

 function beep:longint; external libncurses;

However, gpc does not like the library name after external and gives the error

 ... error: syntax error before `libncurses'

So I can resolve the syntax error by shortening it to just:

function beep:longint; external;

But I'm left wondering why the prior author thought he needed to specify the libncurses...

I don't know FPC so well. I remember in BP you had to specify the library for each declaration. Under Unix this seems unnecessary (independent of the compiler, as long as it uses a standard linker, which they all do AFAIK), since the linker figures it out by itself.

Also note that `longint' is probably wrong. Apparently FPC sticks to the BP sizes where it's 32 bit.

In GPC, we have exact counterparts for all C types. Since the C result type of `beep' is `int', you should use `CInteger' here. If it was `long', it would be `MedInt'. (See the GPC manual for a translation table.)

If the FPC unit translates both to `longint' (because both happen to be 32 bit on IA32), you'll have to look at the C code to find the correct type, otherwise the unit won't be portable.

Frank