What codepages supported by option "-Fc"?

Does anyone have a working link to the "Fast CGI" PASCAL implementation? The link on the Units page is dead, and I could really do with the units for a project I'm working on.

Alternatively, please feel free to send it here (
) if you have the files..

TIA

M

Hi,

I would apreciate if someone could give me some advice please. In this example:

cfunction = function(theparameter:cint):cint;cdecl;external'theclib';

It seems that this will not build unless I have the file: /usr/local/include/theclib.h

1-Is this true?
2-Does the FPC compiler read this .h file?
3-Does the linker read this file?

The C prototypes for the two functions that I want to use look like this:

plPlotterParams * pl_newplparams(void)

or:

plPlotterParams * pl_newplparams

and:

int pl_setplparam (plPlotterParams * plotter_params, const char *parameter, void *value)

or:

int pl_setplparam (plPlotterParams * plotter_params, const char *parameter, char *value)

The two set of prototypes exists because of a switch: "NO_VOID_SUPPORT" to accept different compilers.

1 - Does anyone knows which case my compiler uses? "void" or "no_void"?

The first function "pl_newplparams" is suposed to allocate a structure then return a handle. It seems that it returns something different than "nil" but I am not sure if it is valid however.

This pointer is used as a parameter for the second function "pl_setplparam".

ERR := pl_setplparam(plotter_param,'PAGESIZE','letter');

As soon as I call the function I get an "access" exception at the offset
000000000. Although the function has 3 parameters, it could be the first one (the pointer) that has the wrong type!

I have tried many things like this:

type
plplotterparams = record end;
function pl_newplparams:plplotterparams; cdecl; external 'plot';
function pl_setplparam (plotter_params:plplotterparams; const
parameter:PCHAR; value:PCHAR):cint; cdecl; external 'plot';

Can someone give me some hints on how to solve that problem. I have spent the whole week-end on these three lines and I am quite frustrated right now! The package is called "libplot" ("plotutils") and I was planning to put it on the web if I can get it to work. :(

May be there is a book, documentation or an example file that I could use and was not aware of?

Thank you for reading

Alain Michaud

take what i have to say with a HUGE grain of salt because i have no idea what i'm talking about.

not sure about that, i haven't done alot of work with external 'C' libs.

i have called DLL's written in 'C' before though ... and haven't had to worry about having the headers for them, as i've had Pascal files with the right stuff in them.

well ... i think that is some sort of 'C' pedantry having to do with whether you have to declare that your no-arg 'C' function takes 'void.

are you compiling this lib ? or is it already compiled for you ? or ?

i guess i should back up and ask the big question ... how are you trying to use this 'C' lib ?

as a shared library ?

i don't think Pascal should care about the void/no_void thingy.

your function, as you've written it here, appears to be returning a pointer to something of type 'plPlotterParams' ... presumably a struct.

i think you have a few issues :

a) you can't just make up your own record for the parameter type.

you've got to find the definition of plPlotterParams 'type' in the 'C' source, and then define a type in Pascal that matches it.

presumably, it is a 'C' struct, so you care going to define a Pascal "record" ... but you have to define the members of it properly.

once you've defined the "record" in Pascal to match the 'C' struct (assuming that is what it is) ... i think your Pascal code will go something like as follows :

Var my_params^ : pascal_plPlotterParams; // pointer to your pascal type
my_params := pl_newplparams();
pl_setplparams(my_params,....);

so yeah ...

as i've said ... i _think_ you have 2 primary problems :

a) you've got to define a type in Pascal that matches the "type" that your first function returns.
b) you've got to use Pascal "pointer" syntax when defining your "handle" in Pascal for the variable you are going to use to capture the pointer being return from your func.

btw ... i _suspect_ that, if you aren't going to _use_ the value being return from the first function, you could just use a "void" pointer type in pascal to retrieve the address of the thing being emitted from the first function ... and just pass it to the second.

Var my_point : Pointer;
my_point := firstfunction();
secondfunction(my_point);

... or something like that.

of course, if you actually want to manipulate the thing being returned, to modify it's members or something ... you will have to define stuff in Pascal so the compiler can generate the code needed to get at the members within.

Thank you for reading

all guesses ... but sure ...

Alain Michaud

Tony

Hi,

thank-you for the reply.

1 - I compile the C library myself. I even use it from a C program compiled by me. Therefore for the C part, I am sure that everything is OK. I also know that the path, and all that works.

I can also access a string constant (the version number) from the library using my pascal program.

This makes me think that it has to do with the parameters. This one has three. Unfortunately there is no other 'simple' function in the library:

int pl_setplparam (plPlotterParams * plotter_params, const char *parameter, void *value)

which I translate into:

function pl_setplparam (plotter_params:plplotterparams; const
parameter:PCHAR; value:PCHAR):cint; cdecl; external 'plot';

please look at the last two parameters: one is "const" while the other is not. Does that looks OK to you? Should I always use the same variable names as the .h file? What should I do with the f... "void"?

Is the "cint" type equivalent to C: "int" ? should I use "smallint" instead.

2 - Someone tells me that old compilers would accept " * int" while the new compilers would prefer a variable name: "variable * int" or "void * int". Unless this the other way around then I should not use the NO_VOID_SUPORT. So I guess I do not worry about that one any more.

3 - The file I have is "libplot.so" I think that this is a shared library. Does that coresponds to "cdecl; external 'plot';"? If not, then this is where my mistake was!!!!!!!

Is: external 'plot'; equivalent to: {$L liplot.so} or: {$Linklib liplot.so} ?

4 - The structure "plPlotterParams" is not defined in the .h file. Belive it or not, there is only one line:

struct plPlotterParamsStruct plPlotterParams

I understand that this is just a name change and plPlotterParamsStruct was the name used inside the library. Why is this not defined remains a mistery for me! Apparently the linker just assumes that it is a pointer!

You are right. The "user" is not supposed to access the "struct" directly. This is only a handle for the second function, therefore there was no need to define it in the .h file. I guess I can find the definition in the source code! However It seems to me that a "generic" pointer should do. (What if did not have the source code)

Is the pascal type "pointer" EQUIVALENT to the C operator: '*' to a struct?

Thank you so much for reading

Alain

ok.

I can also access a string constant (the version number) from the library using my pascal program.

ok.

i hope someone else on the list will jump in here ... but i'll stick my neck out ...

i'm doing this off the top of my head ... you should really read the doc for the compiler.

i think your first parameter should be declared as a _pointer_ to the type :

plotter_params : plplotterparams^;

and i think _technically_ that third param should be :

value : Pointer;

Is the "cint" type equivalent to C: "int" ? should I use "smallint" instead.

i'm not sure.

a smallint is a short in 'C' i think.

you really have to find out where cint is declared in your 'C' environment and then look that up in the pascal doc.

you could try guessing ... and maybe it won't segfault.

that sounds like it is a define to deal with old/new style function prototype stuff in 'C'.

i don't think this bit matters to Pascal.

3 - The file I have is "libplot.so" I think that this is a shared library. Does that coresponds to "cdecl; external 'plot';"? If not, then this is where my mistake was!!!!!!!

cdecl is a directive that declares the "calling convention" for the function i think.

this makes it so that the pascal compiler knows how to generate code to invoke the 'C' function and/or pass variables to the 'C' function.

the external is telling the pascal compiler that the function implementation is "external" ... somewhere ... later.

i'm honestly not sure how the "name" thing works. i'd need to look that up.

i think the name ties to the "linker directive" in some way.

Is: external 'plot'; equivalent to: {$L liplot.so} or: {$Linklib liplot.so} ?

well ... i think "external 'plot'" says "find this function in the 'plot' library".

i think the {$L libplot.so} says, link the libplot.so library.

i think there is some magic here ... in that the linker does some things with these names.

so ... i think "plot" for your external declaration works, because the linker, when it processes your {$L} directive, matches the "plot" with "libplot.so" by stripping the "lib" and the ".so" portions to match the names.

or something like that ...

its those two pieces though that tie everything together for the linker, so that the linker knows that there is going to be a function in an external library first, and then later, it tells the linker to actually link the library, and during the link phase, the linker is going to make sure it can "resolve externals" ... which is to say that it makes sure that it can find all of the functions you declared "extern" in the libraries you've told it to link.

there has to be more to this somewhere.

keep poking around in your header files.

I understand that this is just a name change and plPlotterParamsStruct was the name used inside the library. Why is this not defined remains a mistery for me! Apparently the linker just assumes that it is a pointer!

i don't think this is right.

in order for you to use the 'struct' ... you have to know how it is composed.

well ... i _think_ in Pascal :

"Pointer" in pascal is equivalent to "void*" in 'C'.

this is reffered to as a a "void pointer" or an "untyped pointer".

"typed" pointers are pointers that point at a known type of thing, rather than just being known to point to an address :

Pascal : Var foo : Integer^;
'C' : int* foo;

i think that is how that works.

Thank you so much for reading

sure.

Alain

Tony

Aleksey Y. Ulasevich wrote

What codepages supported by option "-Fc"?

If I read the code right: utf8, cp437,cp850,8859_1 (files cp437.pas cp850.pas cp8859_1.pas).

Martin

В пн, 2006-01-16 в 23:07 -0500, Alain Michaud написа:

The proper function declarations should be:

type
  PPlPlotterParams = Pointer;
function pl_newplparams: PPlPlotterParams; cdecl; external 'plot';
function pl_setplparam(plotter_params: PPlPlotterParams; parameter:
PChar; value: PChar): longint; cdecl; external 'plot';

note that PPlPlotterParams is declared as pointer. It's easiest way when you don't care what is the structure it is pointing to. Also notice that the second parameter is desclared without const this is due to pascal tranforming const parameters into pointers which is equivalent as declaring second parameter as "parameter: PPChar".

please look at the last two parameters: one is "const" while the other is not. Does that looks OK to you? Should I always use the same variable names as the .h file? What should I do with the f... "void"?

parameters names (even procedure names when using name) does not matter. it only matters the parameters' types and calling convention.

you don't have to worry because in both ways the resulting lib is compatible with your declaration.

3 - The file I have is "libplot.so" I think that this is a shared library. Does that coresponds to "cdecl; external 'plot';"? If not, then this is where my mistake was!!!!!!!

yes it is a shared library it corresponds to "cdecl; external 'plot';"

Is: external 'plot'; equivalent to: {$L liplot.so} or: {$Linklib liplot.so} ?

external 'plot' - tells the linker in which lib to search for the function while using {$L} or {$linklib} adds the library and when you declare a function as external without specifying where it is located the linker searches for the name in all libraries

Also please see the program h2pas in the utils section of free pascal. It makes translation from headers to pascal very easy,

TIA,
Geno Roupsky

You can load any code page file available from the unicode forum. However, this code page is _only_ used for string constant to widestring conversions, nothing else.

Florian Klaempfl пишет:

How I can use it? Where I can get more information (documentations, tutorials, examples). Is it in FreePascal documentation?

I writing my sources in koi8-r code page, and I must convert my strings
to UCS2 (for example: x:=UTF8Decode(AnsiToUTF8('some koi8-r text '))).
Is it correct? May be I must write x:='some koi8-r text' and add '-FcXXXX'?

PS. Sorry for my English.

Hi,

Thank you to you all. After I wrote the declaration just like given below, I had the library linked to my pascal program, and did not even need to spend the week end on it! :)

Thanks again to you all.

Alain Michaud