You may well be right I fear, though this is the first time I have encountered a problem with the apparent mismatch. I tracked the error using a debugger to an Rtl CriticalSection function.

And the following version which crudely approximates using fprintf() runs fine:

#! perl -slw
use strict;
use Inline 'FORCE';
use Inline C => 'DATA', NAME => 'IC_junk1', CLEAN_AFTER_BUILD => 0;

test( 'fred' );
test2( 'fred' );

__DATA__
__C__
//#include <stdio.h>

void test ( char* text ) {
    printf( "Got:'%s'\n", text );
    printf( "%x\n", stderr );
}

void test2 ( char* text ) {
    char buf[ 255 ];
    sprintf( buf, "%s", text );
    fputs( stderr, buf );
}
[download]

So it does look like some difference in the CRTs that is responsible. I'd swear that I've used fprintf() from inline C before, but a quick scan of my files revealed none and I found a couple that called Perl_warn(), so maybe I encountered and worked around it some time ago and forgot.

So it does look like some difference in the CRTs that is responsible

It need not exactly be a "difference in the CRTs". When perl uses one CRT and the compiler uses a different CRT, you can get situations where something (eg a handle) is created by one CRT and then passed to the other CRT (which knows nothing about that handle, and segfaults).

This problem arises when you try to build Win32::SharedFileOpen - which is the only example I know of, btw. A little surprising (at first glance) is the fact that you can build Win32::SharedFileOpen on ActivePerl using the MinGW compiler ... but it's not really surprising, because MinGW uses the same CRT as ActivePerl.

Fwiw, the original script you provided builds fine for me on ActivePerl using MinGW.

Cheers,
Rob

There does appear to be a bug in the impementation of fprintf(). Note how in the output of the following code, test() prints the value of stderr when fetched via the Perl macros, and directly from the OS and gets the same value. But then in test2(), when it tries to pass & use the directly accessed value with fprintf() it does in exactly the same way and at exactly the same point as when using it via the Perl macro.

However, when I pass the Perl macro derived value to vfprintf() in eprintf() it works fine. Indicative of something, though I'm not sure exactly what :)

#! perl -slw
use strict;
#use Inline 'FORCE';
use Inline C => 'DATA', NAME => 'IC_junk1', CLEAN_AFTER_BUILD => 0;

test( 'fred' );
test2( 'fred' );

__DATA__
__C__
#include <stdio.h>
#include <stdarg.h>

void eprintf (const char *template, ...) {
    va_list ap;

    va_start( ap, template );
    vfprintf( stderr, template, ap );
    va_end( ap );
}

void test ( char* text ) {
    printf( "Got:'%s'\n", text );
    printf( "stderr via PerlIO macro: %x\n", stderr );
    printf( "stderr via Win32_stderr: %x\n", win32_stderr() );
}

void test2 ( char* text ) {
//    eprintf( "Get:'%s'\n", text );
    fprintf( win32_stderr(), "Get:'%s'\n", text );
}

/*
    Outputs:

    C:\test>IC-junk1.pl
    Got:'fred'
    stderr via PerlIO macro: 77c5acc0
    stderr via Win32_stderr: 77c5acc0
    then segfaults when fprintf( stderr, .... ) is called.

*/
[download]

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."