code review 104020044: pkg/syscall: document that the Windows DLL call methods...

pkg/syscall: document that the Windows DLL call methods call SetLastError(0)

A common question when diagnosing problems with the Windows API is whether the programmer is sure the error return came from that function or not, as not all Windows API functions are guaranteed to set the last error code in all cases. The runtime already calls SetLastError(0) (for instance, http://tip.golang.org/src/pkg/runtime/sys_windows_amd64.s#L8), but it would help if this behavior was documented explicitly.

[Pietro Gagliardi (andlabs), 2014-06-10 19:13:13]

Hello golang-codereviews@googlegroups.com,

I'd like you to review this change to
https://code.google.com/p/go

[brainman, 2014-06-11 05:42:23]

I think speaking of SetLastError here is confusing.

SetLastError only have meaning when speaking of a particular Windows thread.
Since go programs generally have no control over thread switching, it is wrong
to use SetLastError Windows API. Instead, SetLastError value is always returned
as lastErr return value of (*Proc).Call.

I don't see your proposed change making anything clearer.

Alex

[Pietro Gagliardi (andlabs), 2014-06-11 21:55:11]

On 2014/06/11 05:42:23, brainman wrote:
> I think speaking of SetLastError here is confusing.
> 
> SetLastError only have meaning when speaking of a particular Windows thread.
> Since go programs generally have no control over thread switching, it is wrong
> to use SetLastError Windows API. Instead, SetLastError value is always
returned
> as lastErr return value of (*Proc).Call.
> 
> I don't see your proposed change making anything clearer.
> 
> Alex

Do you have any suggestion for better phrasing then?

[peterGo, 2014-06-11 23:40:27]

Pietro,

It's reasonable to assume that people have read the relevant Microsoft Windows
API documentation.

Last-Error Code
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680347.aspx

Why should we say more? Why are you confused?

Peter

On 2014/06/11 21:55:11, Pietro Gagliardi (andlabs) wrote:
> On 2014/06/11 05:42:23, brainman wrote:
> > I think speaking of SetLastError here is confusing.
> > 
> > SetLastError only have meaning when speaking of a particular Windows thread.
> > Since go programs generally have no control over thread switching, it is
wrong
> > to use SetLastError Windows API. Instead, SetLastError value is always
> returned
> > as lastErr return value of (*Proc).Call.
> > 
> > I don't see your proposed change making anything clearer.
> > 
> > Alex
> 
> Do you have any suggestion for better phrasing then?

[brainman, 2014-06-12 07:21:32]

On 2014/06/11 21:55:11, Pietro Gagliardi (andlabs) wrote:
> 
> Do you have any suggestion for better phrasing then?

I don't know what your problem is. Would you like to describe your problem?
Perhaps, create an issue here http://code.google.com/p/go/issues/entry.

Alex

[r, 2014-08-11 18:44:34]

NOT LGTM

No changes to this package please.  Wait until go.sys is opened for edits.

[gobot, 2014-12-19 05:08:40]

R=close

To the author of this CL:

The Go project has moved to Gerrit Code Review.

If this CL should be continued, please see the latest version of
https://golang.org/doc/contribute.html for instructions on
how to set up Git and the Go project's Gerrit codereview plugin,
and then create a new change with your current code.

If there has been discussion on this CL, please give a link to it
(golang.org/cl/104020044 is best) in the description in your
new CL.

Thanks very much.