Hello,

is there a secure way to redirect/copy all error messages like "Access violation" (including all other error information) to a file?

The program is a cgi script (Linux), so I can't redirect the output using shell commands like "program 2>>errors.log" would do.

Thanks,
Udo

Creating a wrapper script that calls the real cgi is ofcourse possible.

But a more pascal solution that you can try is to close the stderr filehandle (2) and open it again but with a filename as output.

Udo Giacomozzi wrote

Hello, is there a secure way to redirect/copy all error messages like "Access violation" (including all other error information) to a file?

Yes. Close stderr and reopen it with another filename.

  Close(StdErr);
  Assign(StdErr,'/dev/null');
  Rewrite(StdErr);

After this, all error messages will be written to '/dev/null'...

Michael.

Yes.

Jonas

Should it work under DOS/ GO32V2, too ?

Dirk

Another brain teaser:

Page 47 of PROG.PDF refers to external variables. I am trying to create a shared library if FPC
and also trying to access those variables from executables in linux.

FPC Linux->

var
 arg1 : integer ; cvar ; external ;

Spits compiler error that

Fatal: Syntax Error, : expected but ; found

Does the reference to external variables work under Linux work?

Can variables be exported out of shared libraries under linux?

Mark

The brain teaser related to the use of external variables stems from the fact
that certain compilation modes require the use of {$MODE FPC} while other modes require {$DELPHI}

This is what is causing some variables declared as external to spit the compiler error.

Is it possible to use the ($MODE FPC} compiler switch to change the compilation mode on the fly?

Thanks,

Mark Diener

The solution is the -Sd compiler switch does not allow for the external variables to compile correctly.

I will just turn it off and then back on for a short bit

Please disregard all previous references to compiler problems of external variables.

This is an FPC 1.0.2 problem under Linux.

What I have noticed is that the ($MODE FPC} switch is global and cannot be toggled
during the compilation of a given pascal unit.

The compiler mode regulates whether the following line will compile properly:

{$LINKLIB CMLB}
Var
 test : integer ; cvar ; external ;

This will not compile under DELPHI mode, but it will under FPC mode. (COMMAND LINE)

My workaround would be to use {$MODE} to switch ON the FPC mode and off immediately after the code
for the external variable. What happens in fact is the compiler mode seems locked to either one mode or another
for a given compile and cannot be changed on the fly.

Thus, delphi mode compilations of a given unit fail while FPC mode compilations succeed. This appears to be a bug
by not allowing a given compilation of units to compile under different modes.

Some example code:

Var
{$MODE FPC}  //Turn FPC compiler mode on
test : integer ; cvar ; external ;
{$MODE DEFAULT}//Restore original compiler mode
{$MODE FPC}  //Turn FPC compiler mode on
test2 : integer ; external name 'test2' ;   ///(NAMED VERSION)
{$MODE DEFAULT}//Restore original compiler mode

It spits a compiler error about: Syntax error, : expected but ; found.

or for the named version of the declaration

It spits a compiler error about: Syntax error, : expected but NAME found.

Any help appreciated,

Mark Diener

No. A unit as a whole is compiled in 1 mode. The solution is to declare the variable in the interface of a small separate unit, which is then compiled with the correct mode.

Michael.

It won't compile either under Delphi, so it's refused in delphi mode.

That is not possible and will only leed to problems. Becuase the size of integer can change per mode.

md wrote

The brain teaser related to the use of external variables stems from the fact that certain compilation modes require the use of {$MODE FPC} while other modes require {$DELPHI}

Peter already explained why it's imposible to switch compilation modes on-the-fly. One solution to your problem may be to use {$mode objfpc}. This will allow you to compine Delphi- and FPC-style programming.

Jonas

I would even say: Don't create shared libraries yet, becuase FPC doesn't support PIC code.

That is your personal opinion. FPC mode is more restrictive and forces you to create much cleaner code.

If you know how delphi allows to export variables will add support for it.

This is an update for all FPC developers using FPC under Linux.

If you ever need to create FPC coded shared library (XXX.SO) make use of variables which are also used by either a pascal or C application using the shared library, make sure you provide a function to pass pointers to storage allocation to the library so that the library uses pointers to the variables while the application can access them directly.

Avoid "EXTERNAL" and "CVAR" like the plague.

The {$MODE} compiler switch causes all sorts of headaches when trying to create a shared library with exported
variables in the shared library. Delphi mode does not allow for it, only FPC mode. But most of the code is
in delphi mode anyway.

Finally, when you get to the point of trying to use the shared library from both pascal and C, you will never get the compilation just right to satisfy all the type sizes and so forth.

You could of course create the shared library in C and all the above problems go away, but this is for libraries compiled under FPC.

So again, use pointers to variables inside the shared library, provide a function to initialize those pointers to the addresses of variables inside the application. Happy FPCing.

Mark Diener

Peter, the reason I make this statement is that there was no guidance on how
to build the shared library except the fact that I had a concept that I wanted
to implement.

But hitting so many gotchas forced me to change things around a good bit.

This update served to inform other developers of those headaches. If things change
and FPC does support external, PIC, and cvar a bit better, then maybe the considerations might change.

The point being that I want to share my gotchas with others to contribute to the now, FPC 1.0.2 developers should consider structuring shared libraries a certain way.

The shared library seems to work very nicely, so I do not know why you would argue against shared libraries
at this point.

I like the delphi mode with its automatic dereferencing of structure pointers instead of requiring ^.
There are more reasons. Much of my windows code moves over to linux without "cleaning" up all of it.

Mark Diener

md wrote

I like the delphi mode with its automatic dereferencing of structure pointers instead of requiring ^.

In that case, simply use {$mode objfpc} to get the best of both worlds! This will only fail in places where FPC and Delphi are incompatible, like the procvar handling and nested comments.

Jonas