Please show us a complete standalone Go example. Thanks.

I don't understand what Lua has to do with this.

package main

/*
#include "stdio.h"

void my_print(float a)
{
char buff[32];
sprintf(buff,"%.14g",a);
printf("%s\n",buff);
}
*/
import "C"

func main() {
C.my_print(20.5)
}

When I run that program it prints "20.5", which is what I expect.

Are you saying that it prints something different on your system?

same issue with go 1.5 rc1 and mingw64 on Win7-64.

@lixin9311 What does the program print on your system?

@ianlancetaylor
g

printf works well. sprintf is misbehaving.

@lixin9311 Please provide a complete standalone program, please tell us what you expect it to do, and please tell us what it actually does do. Thanks.

same code as @xicheng provided.
it runs well under linux, but output 'g' in windows.

What does the equivalent C program print on Windows?

20.5

On Mon, Aug 10, 2015 at 4:12 PM, Ian Lance Taylor notifications@github.com
wrote:

What does the equivalent C program print on Windows?

—
Reply to this email directly or view it on GitHub
#12030 (comment).

I have reproduced this on a Windows machine. Nice.

This is kind of amazing. Here is a C program:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <windows.h>

DWORD WINAPI thread(LPVOID x) {
    char buf[128];
    double d = 1.0;

    printf("printf: d=%g\n", d);
    sprintf(buf, "sprintf: d=%g\n", d);
    printf("%s", buf);

    return 0;
}

int main(void)
{
    HANDLE h;
    h = CreateThread(NULL, 0, &thread, 0, 0, NULL);
    WaitForSingleObject(h, INFINITE);
    CloseHandle(h);
    return 0;
}

It prints:

printf: d=1
sprintf: d=1

Here is a very similar Go program:

package main

/*

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <windows.h>

DWORD WINAPI thread(LPVOID x) {
    char buf[128];
    double d = 1.0;

    printf("printf: d=%g\n", d);
    sprintf(buf, "sprintf: d=%g\n", d);
    printf("%s", buf);

    return 0;
}

int cmain(void)
{
    HANDLE h;
    h = CreateThread(NULL, 0, &thread, 0, 0, NULL);
    WaitForSingleObject(h, INFINITE);
    CloseHandle(h);
    return 0;
}

*/
import "C"
import "runtime"

func init() {
    runtime.LockOSThread()
}

func main() {
    C.cmain()
}

It prints:

printf: d=1
sprintf: d=g

The use of a separate thread to run the code was meant to make sure that Go execution had not somehow poisoned that thread. The thread running the code in this case was created by Windows and has never been used for anything but C. Even so sprintf doesn't work. No matter what you try, %g formats as "g". Similarly, %e formats as "e" and %f formats as "f".

I found that if you try to print 0 with %q (not valid) you get just "q" out, much like %g producing just "g". I wonder if the default case in this printf is to drop the %, as if %% were generalized. Then the question is just why %e, %f, %g are invalid like %q in a Go binary, but valid in a C binary. And why they are invalid in sprintf but valid in printf.

On 32-bit x86 systems Go changes the FPU mode at startup, but there is no such change on 64-bit systems. And again printf works while sprintf does not.

I also tried snprintf (fails the same way) and sprintf_s (returns -1, indicating some kind of error, but we knew that).

It's quite the mystery.

This appears to be caused by external linking. Compiling with -ldflags=-linkmode=internal makes sprintf start working again.

It's hard to say how serious this is. It seems like something very fundamental must be wrong; the question is how much it affects. If it really is serious then we could change the default link mode on windows back to internal linking (external linking support is new in this release).

How important is external linking?

/cc @alexbrainman @minux

Confirmed with git bisect that this program stopped working when external linking was added in CL 7534.

package main

/*

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <windows.h>

int cmain(void)
{
    char buf[128];
    double d = 1.0;

    printf("printf: d=%g\n", d);
    sprintf(buf, "sprintf: d=%g\n", d);
    printf("%s", buf);

    return 0;
}

*/
import "C"
import "runtime"

func init() {
    runtime.LockOSThread()
}

func main() {
    C.cmain()
}

We have resolved a lot of windows cgo issues with external linking. I think external linking is good default.

I think we need to understand what this problem is before deciding what to do about it. I am fighting with issue #10776 at this moment. I will try to debug this when I have time. I am sure Minux might have some ideas too.

Alex

The real cause is actually not that serious.

ntdll.dll also defines a sprintf function, during internal linking,
the sprintf is linked to msvcrt.dll, however, with external linking,
sprintf is linked to ntdll.dll (because we explicitly pass -lntdll to
external linker.)

Try this to reproduce the issue with C:

$ type b.c
#include <stdio.h>
int main() {
char buf[128];
sprintf(buf, "d=%g", 1.0);
puts(buf);
}
$ gcc -o b.exe b.c
$ b.exe
d=1
$ gcc -o b.exe b.c -lntdll
$ b.exe
d=XXX

(XXX is certain random garbage, it probably is system dependent.)

Good catch @minux . Do you know how to fix that?

Alex

And then something else will break. Can we supply dll names as part of obj file instead somehow?

Alex

I don't know if we can request a symbol from a specific dll in COFF.

How does ldpe function determines which dlls to call? Surely it is there in pe symbol table. Or maybe in import section.

... to remove the dependency on NtWaitForSingleObject. ...

As far as I remember rsc added call to NtWaitForSingleObject in usleep because he didn't have enough stack to call standard runtime.stdcall function (back in the days when runtime was written in C). It is also little bit quicker (because it does not need runtime.cgocall and friends). I wouldn't bother changing it.

Alex

CL https://golang.org/cl/14472 mentions this issue.

CL https://golang.org/cl/16966 mentions this issue.

CL https://golang.org/cl/30737 mentions this issue.