I don't see how we can change the existing cgo behavior. Existing code may be depending on it. And, as you say, there is no reasonable way that cgo can determine whether an arbitrary C function has succeeded or not.

So I think that all we can do here is documentation. Taking this out of the proposal process.

In general the cgo approach follows C language rules: only check the error if the function fails. In C the error is checked by looking at the errno variable. With cgo the error is checked by looking at the error result.

Existing code may be depending on [the existing cgo behavior].

That would be weird. The current cgo behavior is to return errno after a successful call. But since the content of errno is unspecified in this case, the current cgo behavior is effectively unspecified. Changing the spec to say it will return a nil error after a successful call would only break the current contract in the edge case of a non-standard C function that provides guarantees regarding errno content in case of success.

In general the cgo approach follows C language rules

I know. My whole point is that go developers expect go language rules, rather than C language rules. I believe the job of a bridge like cgo is precisely to translate the source behavior (in this case, C) into the target behavior (in this case, go).

This being said, while I had a slight hope that someone with a better C knowledge than myself would provide a generic mean to detect whether a function failed, as far as I know this is just not possible. So no matter what we think cgo should do, documenting the current behavior is probably our only option.

@EtienneMiret @ianlancetaylor can you add label of pkgsite