https://issues.dlang.org/show_bug.cgi?id=20532

DragonDePlatino@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Hardware|x86                         |x86_64

--

https://issues.dlang.org/show_bug.cgi?id=20532

Dennis <dkorpel@live.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dkorpel@live.nl

--- Comment #1 from Dennis <dkorpel@live.nl> ---
The problem is that stdout in the Microsoft C runtime is a macro for __acrt_iob_func(1), which in D is translated as a shared pointer that gets initialized along with the D runtime: The function `rt.dmain2: rt_init` calls `init_msvc` in rt/msvc.c where the pointers for stdin, stdout and stderr are set.

If you have an extern(C) main() (with or without -betterC), the runtime won't
be initialized so you will be calling fprintf with a FILE* that is just null.
putchar is simply a function calling `putc(c,stdout)`, hence the same issue.

The annoying part is that people probably use the FILE pointers from core.stdc.stdio precisely because their code is translated from C, where one expects to require no runtime initialization. So the workaround "just initialize them manually" doesn't help translated C programs from failing with an unhelpful error code.

I guess the fix would be to make stdout, stderr and stdin functions instead of globals in version (CRuntime_Microsoft), though that might break existing code that takes the address of the global variables. I doubt many programs do that however.

--

https://issues.dlang.org/show_bug.cgi?id=20532

Dennis <dkorpel@live.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #2 from Dennis <dkorpel@live.nl> ---


*** This issue has been marked as a duplicate of issue 19933 ***

--