Hi List,
And greets to all, wide and far.
I conjured up a C program that uses an instance of a Perl
Interpreter, hence had to include the perl56.lib. Spilling some more,
the program is a DLL and has a method which is being called by a Java
program. This method uses the Perl Interpreter instance to execute some
Perl statements. The C function does some file writing ops in C as
well.
The problem, is that until I include the Perl Interpreter
instance and the associated libraries, the file ops perform real smooth
and ok, but once i include the Perl handling code, the program again
compiles and links well, but crashes at the file opening op. And that's
it, the start of my worries, and before it becomes the end, I want to
be led by some answers.
Thanks in advance to whomever reads this post and even who
answer it. I can provide more details if you want.
My hunch is that maybe the perl56 library has some
implementation of fopen() or something like that ...
Bless,
Big and Blue - 05 Oct 2005 19:18 GMT
> The problem, is that until I include the Perl Interpreter
> instance and the associated libraries, the file ops perform real smooth
> and ok, but once i include the Perl handling code, the program again
> compiles and links well, but crashes at the file opening op. And that's
> it, the start of my worries, and before it becomes the end, I want to
> be led by some answers.
Use cc -E to see what the pre-processor does to fopen()?

Signature
Just because I've written it doesn't mean that
either you or I have to believe it.
Ilya Zakharevich - 06 Oct 2005 08:43 GMT
[A complimentary Cc of this posting was sent to
krg
<gkumarrahul@gmail.com>], who wrote in article <1128494128.856379.9760@f14g2000cwb.googlegroups.com>:
> The problem, is that until I include the Perl Interpreter
> instance and the associated libraries, the file ops perform real smooth
> and ok, but once i include the Perl handling code, the program again
> compiles and links well, but crashes at the file opening op. And that's
> it, the start of my worries, and before it becomes the end, I want to
> be led by some answers.
You need a DMZ.
http://en.wikipedia.org/wiki/Demilitarized_zone_%28computing%29
In its baby years, Perl interpeter was using FILE* for its buffered
I/O model. Now it uses PerlIO * instead of FILE *; to simplify
transition from old XSUBs, there is a translation which maps FILE*
operations to be replaced by PerlIO* operations. This translation is
enabled, IIRC, by inclusion of "XSUB.h".
If you need FILE* (e.g., to cooperate to external libraries), you need
to proceed using the normal rules of engagement when an include
conflict arises: use different .c files. Make wrappers for your FILE*
functions in wrappers.c, expose the signature (which now uses no FILE*
stuff) in wrappers.h. Include wrappers.h into wrappers.c (for
consistency checking), and in your .xs. Call the wrappers from your
.xs.
Actually, there may be a layer of helpers in XSUB.h to simplify
working around this common problem. Maybe somebody has more specific
advice than one I gave? Maybe also :stdio IO discipline would somehow
help here?
Hope this helps,
Ilya
krg - 22 Oct 2005 13:39 GMT
> [A complimentary Cc of this posting was sent to
> krg
[quoted text clipped - 30 lines]
> Hope this helps,
> Ilya
Hi List,
And Thank you Ilya, it really helped. Since I went too far with the
FILE* management
stuff, I instead developed wrappers to Perl funcs and put them in a
separate file.
Ensured that either of FILE* or PerlInterpreter won't have to see each
other's face ever,
atleast in this program ... thank you again, and thanks to all who read
and replied.
<<<<<<<<<<<<<Discussion Closed>>>>>>>>>>>>>>>