cc @ianlancetaylor

I think the likely resolution of this is to say that C.malloc is an exception.

Is there any reason that it is important to get an errno result from C.malloc? It has no defined errno results anyhow, and in practice the only one it ever returns is ENOMEM.

@ianlancetaylor If C.malloc changes as an exception, https://golang.org/cmd/cgo/ should be modified to specify that C.malloc is an exception.

I'm think differently. Whether C.malloc may support comma error return or not has something with consistency. There are a lot of C functions that has no defined or uesless errno such as C.malloc, C.free, .... It is consistency to support comma error return regardless of advantage of that errno. I think unnecessary consistency is a consistency for consistency.

I think C.malloc should be an exception, if that's ok I can make a patch to the docs.

Please explain the rationale for excepting C.malloc from the documented CGO multi-valued return behavior. errno==ENOMEM is part of how malloc(3) is documented to signal failure. The multi-valued return makes the Go idiom of checking for err != nil possible:

cptr, err := C.malloc(C.sizeof_struct_foo)
if err != nil {

return nil, fmt.Errorf("allocating memory exempt from GC: %v", err)

}
// ... use cptr

If there is an overriding concern, I don't yet understand it. If possible, please explain it.

While the case is certainly obscure, it seems reasonable to me to make C.malloc consistent with other functions and keep the documentation simple. Arguably, the obscurity of the case even supports keeping the documentation simple.

Is there some technical reason why this isn't easy to fix?

This would be a breaking change to the API

How is that a breaking change? It is already the case that Cgo code may call C functions with either a single or a single plus error result. Code that is already written to not "request" the error result from C.malloc will continue to work just the same as other code for C language functions that don't care to pick up the error result. Code that currently won't work if written as documented, would become compilable.

Please explain how this is an incompatible change?

Supporting code that previously didn't compile, without changing behavior for code that did previously compile, doesn't seem like a breaking change to me.

This would be a breaking change to the API

How so? Currently the only way to call C.malloc is with zero or one return values. I don't think anyone's proposing changing the behavior in this case (including the panic behavior). This just adds the possibility to call it with two return values. The only oddity would be that, presumably, we would still want it to panic in the zero or one case, and not panic in the two case. This is different from other C functions, but not without precedent in the language (e.g., one- versus two-assignment type assertions).

ok calm yourself I misunderstood apologies

Ok. That's understandable. If it were true, the "breaks API compatibility" card would clearly trump the desire to avoid gratuitous one-off, contrary-to-documented behavior. That's why the (mistaken?) claim of incompatible change comes across as such a big deal.

and when I say "gratuitous one-off, contrary-to-documented" behavior, I would be glad to be proved wrong. I just don't think the conversation thus far on this issue has demonstrated that it's not a gratuitous deviation from documented behavior. Maybe it's the search for that answer that will bring about a satisfactory closing of this issue. Or, maybe it is what I think it is, and should be fixed to support calling the same way other Cgo functions can be called.

I'm fine with handling an errno return from C.malloc. It seems pointless to me but I'll review the CL if someone wants to do the work.

@ianlancetaylor help? I don't recognize the CL initials. I would be glad to roll up my sleeves and dig into this, because gratuitous inconsistency consistently bugs me. I'm reading https://golang.org/doc/contribute.html now as a first step.

CL = "change list". Think "PR" (Pull request) or "patch".

You found the right contributing docs.

C.malloc is special because we guarantee it can never fail. I will send a CL documenting this.

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

@rsc @ianlancetaylor thank you both for this. The CL https://golang.org/cl/31811 LGTM assuming https://golang.org/cl/31768 also is accepted at the same release.

@sh4m1l65 Both changes will be in the Go 1.8 release.