Strictly speaking this has never been valid code. The C specification doesn't require stdout, stderr and stdin to be lvalues, that is, they don't have to be assignable to. For example, if you used musl instead of glibc, assigning to stdout would fail to compile even in ordinary C code.

CC: @ianlancetaylor @hirochachacha

As a (non-portable) workaround, you can probably put the address operation in the cgo preamble.

#include <stdint.h>
#include <stdio.h>

static FILE** p_stdout = &stdout;
static FILE** p_stderr = &stderr;

This is unfortunate but I don't think it's a bug. As @dominikh says, you were relying on specific behavior of your library, which is not guaranteed by the C standard and does not work with other libraries. We've changed cgo to support stdout and stderr in a way that we believe will work with all libraries. It's unfortunate that it broke your specific use case, but that use case was already nonportable. As @bcmills says, there is a workaround that should work with your specific library. Finally I will note that cgo is not covered by the Go 1 compatibility guarantee.

I'm going to close this issue. Please comment if you disagree.

@bcmills Thanks for the suggestion!

In case anyone else has a similar hack... I needed to explicitly close stdout/stderr prior to modifying the pointers to get things working with the pointer-defined-in-C approach. Apparently Go was clever enough to close the files for me when directly referencing them in Go?

@sean-jc, you might supposedly could employ an approach which is (and always was, IIUC) correct for C:

1. On the Go side, call .Fd() to get an OS descriptor referring to the Go's stdout. Note that this is not a pointer—it's an uintptr.
2. Pass that value to the C side, then close(2) the stdout and then immediately dup(2) that FD to effectively retarget the C's stdout to the FD returned by Go.

The "trick" making this work is due to this feature of dup(2):

The dup() system call creates a copy of the file descriptor oldfd, using the lowest-numbered unused file descriptor for the new descriptor.

Since stdout always uses FD 1, (with stdin using 0 and stderr—2), when you close stdout and immediately dup(2) another FD, the new FD gets the number previously occupied by stdout, so the latter gets redirected.

Note that you must be sure these jumps around redirecting FDs are not done concurrently—to avoid races between close(2) and dup(2).

One caveat about this is that calling Fd() on an os.File value switches the underlying descriptor into synchronous I/O mode. I think that this makes no difference for the standard I/O streams but YMMV.

The standard way of doing this on the C side is via freopen. Assigning to stdin is a GNU extension.

@kostix Your advice regarding dup has a race condition. The runtime can create new file descriptors at any time. You need to use dup2 or dup3 instead, and you must not close the old descriptor explicitly.

@fweimer IIUC, freopen(3) requires the pathname which might not be available (say, for a stream connected to a pipe). Thanks for pointing out dup2.