perl.h seems to interfere with fopen or stdio.h

[talan]

Hi. I'm using ActivePerl and Visual Studio C++ on a win32 machine.
I'm starting to work with embedded perl (in my C++ program). I get a
run-time error on the line with "fopen". Any clues? Thanks:

#include "EXTERN.h"
#include "perl.h"
#pragma comment(lib, "perl58.lib") //link with perl library

int main(int argc, char* argv[]) {
FILE* fp = fopen("showtime.pl", "w");
fclose(fp);
return 0;
}

 

[Mirco Wahab]

Hi. I'm using ActivePerl and Visual Studio C++ on a win32 machine.
I'm starting to work with embedded perl (in my C++ program). I get a
run-time error on the line with "fopen". Any clues? Thanks:

#include "EXTERN.h"
#include "perl.h"
#pragma comment(lib, "perl58.lib") //link with perl library

int main(int argc, char* argv[]) {
FILE* fp = fopen("showtime.pl", "w");
fclose(fp);
return 0;
}

I linked perl58 into executables in several projects
produced by VC++6 (VS98) and VS2005. Never ever
there was any problem mit MS' stdio, so I guess
you should check for the existence or writeability
of "showtime.pl".

What exactly are you trying to do on
write-opening a perl script?


Regards

M.

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
talan

Hi. I'm using ActivePerl and Visual Studio C++ on a win32 machine.
I'm starting to work with embedded perl (in my C++ program). I get a
run-time error on the line with "fopen". Any clues? Thanks:

#include "EXTERN.h"
#include "perl.h"
#pragma comment(lib, "perl58.lib") //link with perl library

int main(int argc, char* argv[]) {
FILE* fp = fopen("showtime.pl", "w");
fclose(fp);
return 0;
}

One is expected to not work with StdIO under influence of perl.h -
these calls are redirected to PerlIO instead. Use separate
compilation units for the stuff which uses StdIO and perl.h.

Hope this helps,
Ilya

 

[Mirco Wahab]

Hi. I'm using ActivePerl and Visual Studio C++ on a win32 machine.
I'm starting to work with embedded perl (in my C++ program). I get a
run-time error on the line with "fopen". Any clues? Thanks:

#include "EXTERN.h"
#include "perl.h"
#pragma comment(lib, "perl58.lib") //link with perl library

int main(int argc, char* argv[]) {
FILE* fp = fopen("showtime.pl", "w");
fclose(fp);
return 0;
}

One is expected to not work with StdIO under influence of perl.h -
these calls are redirected to PerlIO instead. Use separate
compilation units for the stuff which uses StdIO and perl.h.

After reading this, I waded through embed.h and perl.h
but couldn't find anything related (one spot mentioned
a broken fflush on Solaris).

I have some programs which read/write through stdio
under perl.h (which is included *after* stdio) in the
same compilation unit. (Win32, console program, Visual
Studio/98 and /2005).

Can you help me out here in what exactly is
the weak point?

Thanks & Regards

M.

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Mirco Wahab

After reading this, I waded through embed.h and perl.h
but couldn't find anything related (one spot mentioned
a broken fflush on Solaris).

I have some programs which read/write through stdio
under perl.h (which is included *after* stdio) in the
same compilation unit. (Win32, console program, Visual
Studio/98 and /2005).

Why do you think they go through stdio? Did you check the names in
the object file? I would expect them work through PerlIO (unless some
magic #define is done); but this might have been changed in recent
Perls - AFAIU, this was just a protective measure during transition to
PerlIO (to break things coded to a wrong standard as early as
possible).

Can you help me out here in what exactly is
the weak point?

I do not know anything about any "weak point". With gcc, one can see
redefinitions via -E -dD.

Hope this helps,
Ilya

 

[Mirco Wahab]

Why do you think they go through stdio? Did you check the names in
the object file? I would expect them work through PerlIO (unless some
magic #define is done); but this might have been changed in recent
Perls - AFAIU, this was just a protective measure during transition to
PerlIO (to break things coded to a wrong standard as early as
possible).

You are right, I missed some #defines at one point,
and checked the application now.

Plain stdio calls like fopen *do go* through the perl
layer, under conditions mentioned above, its win32_fopen()
from /win32/win32.c which contains the replacement.

But that layer seems rather thin ( #define PERLIO_NOT_STDIO 0 ),
it does some checks and goes straight into something denoted
by [__imp__fopen(123)] (Win32?) then (at least here,
stock 32bit Activeperl/820).

Thanks & Regards

Mirco