«

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;
}

talan wrote:
> 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 (VS9 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.

[A complimentary Cc of this posting was sent to
talan
<>], who wrote in article < .com>:
> 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

Ilya Zakharevich wrote:
> <>], who wrote in article < .com>:
>> 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.

[A complimentary Cc of this posting was sent to
Mirco Wahab
<wahab->], who wrote in article <evu9pj$bnd$>:
> > 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).

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

Ilya Zakharevich wrote:
> Mirco Wahab wrote in article <evu9pj$bnd$>:
>> 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).

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