Hey,

I am trying to build hybrid (C++, D) application (more here: http://forum.dlang.org/thread/ugkpqprobonorbdunxsx@forum.dlang.org) but I am now getting assertion failure from within writeln(). writeln() is called from a D function that has C++ linkage:

D definition:

extern (C++) void printSomething()
{
  writeln("hello from D");
}


usage from C++:

extern "C++" void printSomething();

int main()
{
  DRuntime druntime; // rt_init(), rt_term()
  printSomething();
}

this causes run-time assertion in fprintf() called from within writeln():

int __cdecl fprintf (
        FILE *str,
        const char *format,
        ...
        )
/*
 * 'F'ile (stream) 'PRINT', 'F'ormatted
 */
{
    va_list(arglist);
    FILE *stream;
    int buffing;
    int retval=0;

    _VALIDATE_RETURN( (str != NULL), EINVAL, -1); <=== assetion here

[...]
}

meaning that str arg passed is null. writelns()'s call site:

        enforce(fprintf(.stdout._p.handle, "%.*s\n",
                        cast(int) args[0].length, args[0].ptr) >= 0);

so for some reason .stdout._p.handle is null.

On Wednesday, 3 September 2014 at 09:55:55 UTC, Szymon Gatner wrote:
> Hey,
>
> I am trying to build hybrid (C++, D) application (more here: http://forum.dlang.org/thread/ugkpqprobonorbdunxsx@forum.dlang.org) but I am now getting assertion failure from within writeln(). writeln() is called from a D function that has C++ linkage:
>
> D definition:
>
> extern (C++) void printSomething()
> {
>   writeln("hello from D");
> }
>
>
> usage from C++:
>
> extern "C++" void printSomething();
>
> int main()
> {
>   DRuntime druntime; // rt_init(), rt_term()
>   printSomething();
> }
>
> this causes run-time assertion in fprintf() called from within writeln():
>
> int __cdecl fprintf (
>         FILE *str,
>         const char *format,
>         ...
>         )
> /*
>  * 'F'ile (stream) 'PRINT', 'F'ormatted
>  */
> {
>     va_list(arglist);
>     FILE *stream;
>     int buffing;
>     int retval=0;
>
>     _VALIDATE_RETURN( (str != NULL), EINVAL, -1); <=== assetion here
>
> [...]
> }
>
> meaning that str arg passed is null. writelns()'s call site:
>
>         enforce(fprintf(.stdout._p.handle, "%.*s\n",
>                         cast(int) args[0].length, args[0].ptr)
> >= 0);
>
> so for some reason .stdout._p.handle is null.

Any ideas why this happens?

I'm having an error related to yours: when I call writeln function in a closed stdout I will get a segfault message. Example:

import std.stdio;

void main() {
  stdout.close();
  write("hello\n");
}

The code above will crash with segfault buf the following code will raise an exception instead:

import std.stdio;

void main() {
  stdout.close();
  stdout.write("hello\n");
}

In one of the specializations of the write function in the std.stdio (the call site that you showed in your post) no check for closed stdout (when stdout._p is null) is done. I can't say if this is a bug in the write function or the desired behaviour (I'm a novice here).

On Wednesday, 3 September 2014 at 18:48:00 UTC, Szymon Gatner wrote:
> On Wednesday, 3 September 2014 at 09:55:55 UTC, Szymon Gatner wrote:
>> Hey,
>>
>> I am trying to build hybrid (C++, D) application (more here: http://forum.dlang.org/thread/ugkpqprobonorbdunxsx@forum.dlang.org) but I am now getting assertion failure from within writeln(). writeln() is called from a D function that has C++ linkage:
>>
>> D definition:
>>
>> extern (C++) void printSomething()
>> {
>>  writeln("hello from D");
>> }
>>
>>
>> usage from C++:
>>
>> extern "C++" void printSomething();
>>
>> int main()
>> {
>>  DRuntime druntime; // rt_init(), rt_term()
>>  printSomething();
>> }
>>
>> this causes run-time assertion in fprintf() called from within writeln():
>>
>> int __cdecl fprintf (
>>        FILE *str,
>>        const char *format,
>>        ...
>>        )
>> /*
>> * 'F'ile (stream) 'PRINT', 'F'ormatted
>> */
>> {
>>    va_list(arglist);
>>    FILE *stream;
>>    int buffing;
>>    int retval=0;
>>
>>    _VALIDATE_RETURN( (str != NULL), EINVAL, -1); <=== assetion here
>>
>> [...]
>> }
>>
>> meaning that str arg passed is null. writelns()'s call site:
>>
>>        enforce(fprintf(.stdout._p.handle, "%.*s\n",
>>                        cast(int) args[0].length, args[0].ptr)
>> >= 0);
>>
>> so for some reason .stdout._p.handle is null.
>
> Any ideas why this happens?

On Thu, 04 Sep 2014 15:10:21 +0000
"Jorge A. S. via Digitalmars-d-learn"
<digitalmars-d-learn@puremagic.com> wrote:

> In one of the specializations of the write function in the std.stdio (the call site that you showed in your post) no check for closed stdout (when stdout._p is null) is done. I can't say if this is a bug in the write function or the desired behaviour (I'm a novice here).
it's definitely a bug. writeln() should throw, not segfaulting.

On Thursday, 4 September 2014 at 15:25:59 UTC, ketmar via Digitalmars-d-learn wrote:
> On Thu, 04 Sep 2014 15:10:21 +0000
> "Jorge A. S. via Digitalmars-d-learn"
> <digitalmars-d-learn@puremagic.com> wrote:
>
>> In one of the specializations of the write function in the std.stdio (the call site that you showed in your post) no check for closed stdout (when stdout._p is null) is done. I can't say if this is a bug in the write function or the desired behaviour (I'm a novice here).
> it's definitely a bug. writeln() should throw, not segfaulting.

Shouldn't writeln() work tho instead of throwing or segfaulting?

On Thursday, 4 September 2014 at 17:57:47 UTC, Szymon Gatner wrote:
> On Thursday, 4 September 2014 at 15:25:59 UTC, ketmar via Digitalmars-d-learn wrote:
>> On Thu, 04 Sep 2014 15:10:21 +0000
>> "Jorge A. S. via Digitalmars-d-learn"
>> <digitalmars-d-learn@puremagic.com> wrote:
>>
>>> In one of the specializations of the write function in the std.stdio (the call site that you showed in your post) no check for closed stdout (when stdout._p is null) is done. I can't say if this is a bug in the write function or the desired behaviour (I'm a novice here).
>> it's definitely a bug. writeln() should throw, not segfaulting.
>
> Shouldn't writeln() work tho instead of throwing or segfaulting?

No, if stdout is closed, how should it work? Throwing is the correct behaviour.

On Thursday, 4 September 2014 at 18:22:55 UTC, Marc Schütz wrote:
> On Thursday, 4 September 2014 at 17:57:47 UTC, Szymon Gatner wrote:
>> On Thursday, 4 September 2014 at 15:25:59 UTC, ketmar via Digitalmars-d-learn wrote:
>>> On Thu, 04 Sep 2014 15:10:21 +0000
>>> "Jorge A. S. via Digitalmars-d-learn"
>>> <digitalmars-d-learn@puremagic.com> wrote:
>>>
>>>> In one of the specializations of the write function in the std.stdio (the call site that you showed in your post) no check for closed stdout (when stdout._p is null) is done. I can't say if this is a bug in the write function or the desired behaviour (I'm a novice here).
>>> it's definitely a bug. writeln() should throw, not segfaulting.
>>
>> Shouldn't writeln() work tho instead of throwing or segfaulting?
>
> No, if stdout is closed, how should it work? Throwing is the correct behaviour.

Ah sorry, I totaly missed close() part.

Any idea why it is null in my case tho?

Maybe some module constructor wasn't run due to linking mess. So it remains uninitialized.

On Thursday, 4 September 2014 at 20:38:38 UTC, Kagamin wrote:
> Maybe some module constructor wasn't run due to linking mess. So it remains uninitialized.

Is there a way I can check if module c-tor run? rt_init() returned no error.

https://github.com/D-Programming-Language/druntime/blob/master/src/core/stdc/stdio.d#L457 see? It's null. Hmm... where is it initialized?