code review 4528073: syscall: Added new functions to support os.user in Windows.

syscall: Added new functions to support os.user in Windows.

Contains the syscall functions required to implement issue 1789.
Also contains changes originally part of codereview issue 4521053.

[brainman, 2011-05-18 05:57:16]

Please, include changes to zsyscall_windows_386.go in this CL.

http://codereview.appspot.com/4528073/diff/2001/src/pkg/syscall/syscall_windo...
File src/pkg/syscall/syscall_windows.go (right):

http://codereview.appspot.com/4528073/diff/2001/src/pkg/syscall/syscall_windo...
src/pkg/syscall/syscall_windows.go:131: //sys	GetUserName(buf *uint16, n
*uint32) (success bool, errno int) = advapi32.GetUserNameW
Change all these functions to return (errno int), not (success bool, errno int).
Please see GetComputerName for an example.

http://codereview.appspot.com/4528073/diff/2001/src/pkg/syscall/syscall_windo...
src/pkg/syscall/syscall_windows.go:385: type SID []byte
Put this into ztypes_windows_386.go.

http://codereview.appspot.com/4528073/diff/2001/src/pkg/syscall/ztypes_window...
File src/pkg/syscall/ztypes_windows_386.go (right):

http://codereview.appspot.com/4528073/diff/2001/src/pkg/syscall/ztypes_window...
src/pkg/syscall/ztypes_windows_386.go:3: // TODO(brainman): autogenerate types
in ztypes_windows_386.go
Please, fix all end of lines. None of these lines you're going to change. Are
you?

http://codereview.appspot.com/4528073/diff/2001/src/pkg/syscall/ztypes_window...
src/pkg/syscall/ztypes_windows_386.go:554: const UNLEN = 256
I don't think you need this const.

[pjmlp, 2011-05-18 09:20:43]

http://codereview.appspot.com/4528073/diff/2001/src/pkg/syscall/syscall_windo...
File src/pkg/syscall/syscall_windows.go (right):

http://codereview.appspot.com/4528073/diff/2001/src/pkg/syscall/syscall_windo...
src/pkg/syscall/syscall_windows.go:131: //sys	GetUserName(buf *uint16, n
*uint32) (success bool, errno int) = advapi32.GetUserNameW
On 2011/05/18 05:57:16, brainman wrote:
> Change all these functions to return (errno int), not (success bool, errno
int).
> Please see GetComputerName for an example.

Why? They are supposed to return bool, and fail with the errno only signature.

http://codereview.appspot.com/4528073/diff/2001/src/pkg/syscall/syscall_windo...
src/pkg/syscall/syscall_windows.go:385: type SID []byte
On 2011/05/18 05:57:16, brainman wrote:
> Put this into ztypes_windows_386.go.

Done.

http://codereview.appspot.com/4528073/diff/2001/src/pkg/syscall/ztypes_window...
File src/pkg/syscall/ztypes_windows_386.go (right):

http://codereview.appspot.com/4528073/diff/2001/src/pkg/syscall/ztypes_window...
src/pkg/syscall/ztypes_windows_386.go:3: // TODO(brainman): autogenerate types
in ztypes_windows_386.go
On 2011/05/18 05:57:16, brainman wrote:
> Please, fix all end of lines. None of these lines you're going to change. Are
> you?

I have not done anything here.

A normal diff between both files does not show line ending differences, only hg
diff does show such a difference.

http://codereview.appspot.com/4528073/diff/2001/src/pkg/syscall/ztypes_window...
src/pkg/syscall/ztypes_windows_386.go:554: const UNLEN = 256
On 2011/05/18 05:57:16, brainman wrote:
> I don't think you need this const.

Done.

[pjmlp, 2011-05-18 09:21:05]

Hello golang-dev@googlegroups.com, brainman (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://go.googlecode.com/hg/

[brainman, 2011-05-18 12:08:23]

Please, include changes to zsyscall_windows_386.go in this CL.

http://codereview.appspot.com/4528073/diff/2001/src/pkg/syscall/syscall_windo...
File src/pkg/syscall/syscall_windows.go (right):

http://codereview.appspot.com/4528073/diff/2001/src/pkg/syscall/syscall_windo...
src/pkg/syscall/syscall_windows.go:131: //sys	GetUserName(buf *uint16, n
*uint32) (success bool, errno int) = advapi32.GetUserNameW
On 2011/05/18 09:20:43, pjmlp wrote:
> Why? ...

Because that is what other functions that return bool do. Please, see
GetComputerName for an example.

> ... They are supposed to return bool, and fail with the errno only signature.

How do they fail? Please, look at GetComputerName implementation in
zsyscall_windows_386.go - if Windows API returns true, GetComputerName returns
0, otherwise it returns error number.

http://codereview.appspot.com/4528073/diff/2001/src/pkg/syscall/ztypes_window...
File src/pkg/syscall/ztypes_windows_386.go (right):

http://codereview.appspot.com/4528073/diff/2001/src/pkg/syscall/ztypes_window...
src/pkg/syscall/ztypes_windows_386.go:3: // TODO(brainman): autogenerate types
in ztypes_windows_386.go
On 2011/05/18 09:20:43, pjmlp wrote:
> 
> I have not done anything here.
> 
> A normal diff between both files does not show line ending differences, only
hg
> diff does show such a difference.

I can't apply your patch. I get this message:

codereview issue 4528073 is out of date: patch and recent changes conflict
(2f0fa51fa2da->4ce4c75f9bb5)

I think you should update your patch to the tip.

[pjmlp, 2011-05-18 14:58:06]

If I use the errno as the only return value, the buffer returned by
GetUserNameEx is corrupted.

[pjmlp, 2011-05-18 15:01:33]

On 2011/05/18 14:58:06, pjmlp wrote:
> If I use the errno as the only return value, the buffer returned by
> GetUserNameEx is corrupted.

Forgot to say that I am looking at the stub generation, maybe something is wrong
with this function.

[pjmlp, 2011-05-18 15:07:46]

Isn't this file generated from mkall.sh script?

On 2011/05/18 12:08:23, brainman wrote:
> Please, include changes to zsyscall_windows_386.go in this CL.

[brainman, 2011-05-19 02:37:09]

On 2011/05/18 14:58:06, pjmlp wrote:
> If I use the errno as the only return value, the buffer returned by
> GetUserNameEx is corrupted.

I have no such problem. If you apply this change to current repo:

diff -r 5f12c225a82c src/pkg/syscall/syscall_windows.go
--- a/src/pkg/syscall/syscall_windows.go	Wed May 18 17:17:26 2011 -0700
+++ b/src/pkg/syscall/syscall_windows.go	Thu May 19 12:32:56 2011 +1000
@@ -167,6 +167,7 @@
 //sys	FlushViewOfFile(addr uintptr, length uintptr) (errno int)
 //sys	VirtualLock(addr uintptr, length uintptr) (errno int)
 //sys	VirtualUnlock(addr uintptr, length uintptr) (errno int)
+//sys	GetUserNameEx(format int32, buf *uint16, n *uint32) (errno int) =
secur32.GetUserNameExW
 
 // syscall interface implementation for other packages
 
diff -r 5f12c225a82c src/pkg/syscall/zsyscall_windows_386.go
--- a/src/pkg/syscall/zsyscall_windows_386.go	Wed May 18 17:17:26 2011 -0700
+++ b/src/pkg/syscall/zsyscall_windows_386.go	Thu May 19 12:32:56 2011 +1000
@@ -9,6 +9,7 @@
 	modkernel32 = loadDll("kernel32.dll")
 	modadvapi32 = loadDll("advapi32.dll")
 	modshell32  = loadDll("shell32.dll")
+	modsecur32  = loadDll("secur32.dll")
 	modwsock32  = loadDll("wsock32.dll")
 	modws2_32   = loadDll("ws2_32.dll")
 	moddnsapi   = loadDll("dnsapi.dll")
@@ -76,6 +77,7 @@
 	procFlushViewOfFile            = getSysProcAddr(modkernel32,
"FlushViewOfFile")
 	procVirtualLock                = getSysProcAddr(modkernel32, "VirtualLock")
 	procVirtualUnlock              = getSysProcAddr(modkernel32, "VirtualUnlock")
+	procGetUserNameExW             = getSysProcAddr(modsecur32, "GetUserNameExW")
 	procWSAStartup                 = getSysProcAddr(modwsock32, "WSAStartup")
 	procWSACleanup                 = getSysProcAddr(modwsock32, "WSACleanup")
 	procsocket                     = getSysProcAddr(modwsock32, "socket")
@@ -993,6 +995,20 @@
 	return
 }
 
+func GetUserNameEx(format int32, buf *uint16, n *uint32) (errno int) {
+	r1, _, e1 := Syscall(procGetUserNameExW, 3, uintptr(format),
uintptr(unsafe.Pointer(buf)), uintptr(unsafe.Pointer(n)))
+	if int(r1) == 0 {
+		if e1 != 0 {
+			errno = int(e1)
+		} else {
+			errno = EINVAL
+		}
+	} else {
+		errno = 0
+	}
+	return
+}
+
 func WSAStartup(verreq uint32, data *WSAData) (sockerrno int) {
 	r0, _, _ := Syscall(procWSAStartup, 2, uintptr(verreq),
uintptr(unsafe.Pointer(data)), 0)
 	sockerrno = int(r0)

then this program

package main

import (
	"fmt"
	"log"
	"os"
	"syscall"
	"utf16"
)

func UserNameEx(format int32) (name string, err os.Error) {
	b := make([]uint16, 30)
	n := uint32(len(b))
	e := syscall.GetUserNameEx(int32(format), &b[0], &n)
	if e == syscall.ERROR_INSUFFICIENT_BUFFER {
		b = make([]uint16, n)
		e = syscall.GetUserNameEx(int32(format), &b[0], &n)
	}
	if e != 0 {
		return "", os.NewSyscallError("GetUserNameEx", e)
	}
	// trim terminating \0
	for ; n > 0 && b[n-1] == 0; n-- {
	}
	return string(utf16.Decode(b[:n])), nil
}

func main() {
	u, e := UserNameEx(3)
	if e != nil {
		log.Fatal(e)
	}
	fmt.Printf("%q\n", u)
}

prints my name, if run on my pc.

Alex

[brainman, 2011-05-19 02:43:32]

On 2011/05/18 15:07:46, pjmlp wrote:
> Isn't this file generated from mkall.sh script?
> 

It is. But it is not getting regenerated during the build, and have to be
included in CL. For a recent example, see http://tinyurl.com/3e6s6qj.

Alex

[pjmlp, 2011-05-19 11:52:06]

On 2011/05/19 02:37:09, brainman wrote:
> On 2011/05/18 14:58:06, pjmlp wrote:
> > If I use the errno as the only return value, the buffer returned by
> > GetUserNameEx is corrupted.
> 
> I have no such problem. If you apply this change to current repo:
> 
> diff -r 5f12c225a82c src/pkg/syscall/syscall_windows.go
> --- a/src/pkg/syscall/syscall_windows.go	Wed May 18 17:17:26 2011 -0700
> +++ b/src/pkg/syscall/syscall_windows.go	Thu May 19 12:32:56 2011 +1000
> @@ -167,6 +167,7 @@
>  //sys	FlushViewOfFile(addr uintptr, length uintptr) (errno int)
>  //sys	VirtualLock(addr uintptr, length uintptr) (errno int)
>  //sys	VirtualUnlock(addr uintptr, length uintptr) (errno int)
> +//sys	GetUserNameEx(format int32, buf *uint16, n *uint32) (errno int) =
> secur32.GetUserNameExW
>  
>  // syscall interface implementation for other packages
>  
> diff -r 5f12c225a82c src/pkg/syscall/zsyscall_windows_386.go
> --- a/src/pkg/syscall/zsyscall_windows_386.go	Wed May 18 17:17:26 2011 -0700
> +++ b/src/pkg/syscall/zsyscall_windows_386.go	Thu May 19 12:32:56 2011 +1000
> @@ -9,6 +9,7 @@
>  	modkernel32 = loadDll("kernel32.dll")
>  	modadvapi32 = loadDll("advapi32.dll")
>  	modshell32  = loadDll("shell32.dll")
> +	modsecur32  = loadDll("secur32.dll")
>  	modwsock32  = loadDll("wsock32.dll")
>  	modws2_32   = loadDll("ws2_32.dll")
>  	moddnsapi   = loadDll("dnsapi.dll")
> @@ -76,6 +77,7 @@
>  	procFlushViewOfFile            = getSysProcAddr(modkernel32,
> "FlushViewOfFile")
>  	procVirtualLock                = getSysProcAddr(modkernel32, "VirtualLock")
>  	procVirtualUnlock              = getSysProcAddr(modkernel32,
"VirtualUnlock")
> +	procGetUserNameExW             = getSysProcAddr(modsecur32,
"GetUserNameExW")
>  	procWSAStartup                 = getSysProcAddr(modwsock32, "WSAStartup")
>  	procWSACleanup                 = getSysProcAddr(modwsock32, "WSACleanup")
>  	procsocket                     = getSysProcAddr(modwsock32, "socket")
> @@ -993,6 +995,20 @@
>  	return
>  }
>  
> +func GetUserNameEx(format int32, buf *uint16, n *uint32) (errno int) {
> +	r1, _, e1 := Syscall(procGetUserNameExW, 3, uintptr(format),
> uintptr(unsafe.Pointer(buf)), uintptr(unsafe.Pointer(n)))
> +	if int(r1) == 0 {
> +		if e1 != 0 {
> +			errno = int(e1)
> +		} else {
> +			errno = EINVAL
> +		}
> +	} else {
> +		errno = 0
> +	}
> +	return
> +}
> +
>  func WSAStartup(verreq uint32, data *WSAData) (sockerrno int) {
>  	r0, _, _ := Syscall(procWSAStartup, 2, uintptr(verreq),
> uintptr(unsafe.Pointer(data)), 0)
>  	sockerrno = int(r0)
> 
> then this program
> 
> package main
> 
> import (
> 	"fmt"
> 	"log"
> 	"os"
> 	"syscall"
> 	"utf16"
> )
> 
> func UserNameEx(format int32) (name string, err os.Error) {
> 	b := make([]uint16, 30)
> 	n := uint32(len(b))
> 	e := syscall.GetUserNameEx(int32(format), &b[0], &n)
> 	if e == syscall.ERROR_INSUFFICIENT_BUFFER {
> 		b = make([]uint16, n)
> 		e = syscall.GetUserNameEx(int32(format), &b[0], &n)
> 	}
> 	if e != 0 {
> 		return "", os.NewSyscallError("GetUserNameEx", e)
> 	}
> 	// trim terminating \0
> 	for ; n > 0 && b[n-1] == 0; n-- {
> 	}
> 	return string(utf16.Decode(b[:n])), nil
> }
> 
> func main() {
> 	u, e := UserNameEx(3)
> 	if e != nil {
> 		log.Fatal(e)
> 	}
> 	fmt.Printf("%q\n", u)
> }
> 
> prints my name, if run on my pc.
> 
> Alex

Sorry for the confusion. Now it seems to work and the only differences between
our implementations is the for loop and the way n is initialized.

Don't know why I had problems, maybe some overseen error.

[pjmlp, 2011-05-19 11:53:38]

On 2011/05/19 02:43:32, brainman wrote:
> On 2011/05/18 15:07:46, pjmlp wrote:
> > Isn't this file generated from mkall.sh script?
> > 
> 
> It is. But it is not getting regenerated during the build, and have to be
> included in CL. For a recent example, see http://tinyurl.com/3e6s6qj.
> 
> Alex

Faire enough, I'll include it as well. Not sure if it plays well with the rest
of the code due to my mkerrors_windows.sh hack, but you can check it.

[pjmlp, 2011-05-19 12:18:06]

Hello golang-dev@googlegroups.com, alex.brainman@gmail.com (cc:
golang-dev@googlegroups.com),

Please take another look.

[pjmlp, 2011-05-19 12:22:29]

Hello golang-dev@googlegroups.com, alex.brainman@gmail.com (cc:
golang-dev@googlegroups.com),

Please take another look.

[brainman, 2011-05-20 02:21:03]

LGTM. But this might change depending where we going with 4521053.

Thank you.

Alex

[pjmlp, 2011-05-20 10:45:39]

On 2011/05/20 02:21:03, brainman wrote:
> LGTM. But this might change depending where we going with 4521053.
> 
> Thank you.
> 
> Alex

Thanks.

I am aware of it, actually I might still add a few more declarations because of
4521053, as you say.

[bradfitzgoog, 2011-05-20 15:51:32]

http://codereview.appspot.com/4528073/diff/7005/src/pkg/syscall/ztypes_window...
File src/pkg/syscall/ztypes_windows_386.go (right):

http://codereview.appspot.com/4528073/diff/7005/src/pkg/syscall/ztypes_window...
src/pkg/syscall/ztypes_windows_386.go:548: type SID []byte
this being mutable is a bit scary.  could this just be a string and turned into
a []byte if needed for system calls?

[pjmlp, 2011-05-20 16:28:39]

http://codereview.appspot.com/4528073/diff/7005/src/pkg/syscall/ztypes_window...
File src/pkg/syscall/ztypes_windows_386.go (right):

http://codereview.appspot.com/4528073/diff/7005/src/pkg/syscall/ztypes_window...
src/pkg/syscall/ztypes_windows_386.go:548: type SID []byte
On 2011/05/20 15:51:32, bradfitzgoog wrote:
> this being mutable is a bit scary.  could this just be a string and turned
into
> a []byte if needed for system calls?

Then you will pay the cost of converting every time it is needed.

[bradfitzgoog, 2011-05-20 16:33:13]

http://codereview.appspot.com/4528073/diff/7005/src/pkg/syscall/ztypes_window...
File src/pkg/syscall/ztypes_windows_386.go (right):

http://codereview.appspot.com/4528073/diff/7005/src/pkg/syscall/ztypes_window...
src/pkg/syscall/ztypes_windows_386.go:548: type SID []byte
On 2011/05/20 16:28:39, pjmlp wrote:
> On 2011/05/20 15:51:32, bradfitzgoog wrote:
> > this being mutable is a bit scary.  could this just be a string and turned
> into
> > a []byte if needed for system calls?
> 
> Then you will pay the cost of converting every time it is needed.
>

Well, looking up users isn't exactly a hot path.  Even if you looked up ever
user in a large company, that's not many calls.

I'd choose safety and peace of mind here over a negligible optimization that is
really the compiler's problem.

[brainman, 2011-05-21 02:49:30]

On 2011/05/20 15:51:32, bradfitzgoog wrote:
> ... type SID []byte
> this being mutable is a bit scary.  ...

It is as "mutable" as its "unix" contra-part. It is a number, just much bigger.
:-)

Alex

[pjmlp, 2011-05-22 19:00:03]

Hello golang-dev@googlegroups.com, alex.brainman@gmail.com, bradfitz@google.com
(cc: golang-dev@googlegroups.com),

Please take another look.

[bradfitz, 2011-05-22 22:44:08]

http://codereview.appspot.com/4528073/diff/19001/src/pkg/syscall/ztypes_windo...
File src/pkg/syscall/ztypes_windows_386.go (right):

http://codereview.appspot.com/4528073/diff/19001/src/pkg/syscall/ztypes_windo...
src/pkg/syscall/ztypes_windows_386.go:555: SidTypeGroup
these are all equal to 1.  I doubt that's what you meant?

[pjmlp, 2011-05-23 06:28:35]

http://codereview.appspot.com/4528073/diff/7005/src/pkg/syscall/ztypes_window...
File src/pkg/syscall/ztypes_windows_386.go (right):

http://codereview.appspot.com/4528073/diff/7005/src/pkg/syscall/ztypes_window...
src/pkg/syscall/ztypes_windows_386.go:548: type SID []byte
On 2011/05/20 16:33:14, bradfitzgoog wrote:
> On 2011/05/20 16:28:39, pjmlp wrote:
> > On 2011/05/20 15:51:32, bradfitzgoog wrote:
> > > this being mutable is a bit scary.  could this just be a string and turned
> > into
> > > a []byte if needed for system calls?
> > 
> > Then you will pay the cost of converting every time it is needed.
> >
> 
> Well, looking up users isn't exactly a hot path.  Even if you looked up ever
> user in a large company, that's not many calls.
> 
> I'd choose safety and peace of mind here over a negligible optimization that
is
> really the compiler's problem.

Ok, I'll do it as suggested.

http://codereview.appspot.com/4528073/diff/19001/src/pkg/syscall/ztypes_windo...
src/pkg/syscall/ztypes_windows_386.go:555: SidTypeDomain
On 2011/05/22 22:44:08, bradfitz wrote:
> these are all equal to 1.  I doubt that's what you meant?

I was expecting the same behavior as in most languages. SidTypeUser gets the
value 1 and the other auto-increment.

So it is not the case with Go, I imagine. I'll fix it.

[pjmlp, 2011-05-23 06:31:36]

Hello golang-dev@googlegroups.com, alex.brainman@gmail.com, bradfitz@google.com,
bradfitz@golang.org (cc: golang-dev@googlegroups.com),

Please take another look.

[pjmlp, 2011-06-07 14:18:05]

On 2011/05/23 06:31:36, pjmlp wrote:
> Hello mailto:golang-dev@googlegroups.com, mailto:alex.brainman@gmail.com,
mailto:bradfitz@google.com,
> mailto:bradfitz@golang.org (cc: mailto:golang-dev@googlegroups.com),
> 
> Please take another look.

Any update on this?

[pjmlp, 2011-06-12 21:41:19]

Hello golang-dev@googlegroups.com, alex.brainman@gmail.com, bradfitz@google.com,
bradfitz@golang.org (cc: golang-dev@googlegroups.com),

Please take another look.

[bradfitz, 2011-06-14 17:55:23]

http://codereview.appspot.com/4528073/diff/21001/src/pkg/syscall/ztypes_windo...
File src/pkg/syscall/ztypes_windows_386.go (right):

http://codereview.appspot.com/4528073/diff/21001/src/pkg/syscall/ztypes_windo...
src/pkg/syscall/ztypes_windows_386.go:554: NameFullyQualifiedDN = 1
did you mean for the rest of these to be int32 too?  currently it's an int, not
int32.

[pjmlp, 2011-06-14 19:29:40]

http://codereview.appspot.com/4528073/diff/21001/src/pkg/syscall/ztypes_windo...
File src/pkg/syscall/ztypes_windows_386.go (right):

http://codereview.appspot.com/4528073/diff/21001/src/pkg/syscall/ztypes_windo...
src/pkg/syscall/ztypes_windows_386.go:554: NameFullyQualifiedDN = 1
On 2011/06/14 17:55:23, bradfitz wrote:
> did you mean for the rest of these to be int32 too?  currently it's an int,
not
> int32.

That was the idea. So it seems I have to redeclare int32 everywhere, since these
constants are part of a C enum. Or would it fit inside an int?

[bradfitzgoog, 2011-06-14 19:44:25]

On Tue, Jun 14, 2011 at 12:29 PM, <paulo.jpinto@gmail.com> wrote:

>
> http://codereview.appspot.com/**4528073/diff/21001/src/pkg/**
>
syscall/ztypes_windows_386.go<http://codereview.appspot.com/4528073/diff/21001/src/pkg/syscall/ztypes_windows_386.go>
> File src/pkg/syscall/ztypes_**windows_386.go (right):
>
> http://codereview.appspot.com/**4528073/diff/21001/src/pkg/**
>
syscall/ztypes_windows_386.go#**newcode554<http://codereview.appspot.com/4528073/diff/21001/src/pkg/syscall/ztypes_windows_386.go#newcode554>
> src/pkg/syscall/ztypes_**windows_386.go:554: NameFullyQualifiedDN = 1
> On 2011/06/14 17:55:23, bradfitz wrote:
>
>> did you mean for the rest of these to be int32 too?  currently it's an
>>
> int, not
>
>> int32.
>>
>
> That was the idea. So it seems I have to redeclare int32 everywhere,
> since these constants are part of a C enum. Or would it fit inside an
> int?
>

An int32 fits in an int.

I don't know what your question is, though.  I was just pointing out that it
was unlikely the code did what it looks like you meant.

[pjmlp, 2011-06-14 20:33:36]

On 2011/06/14 19:44:25, bradfitzgoog wrote:
> On Tue, Jun 14, 2011 at 12:29 PM, <mailto:paulo.jpinto@gmail.com> wrote:
> 
> >
> > http://codereview.appspot.com/**4528073/diff/21001/src/pkg/**
> >
>
syscall/ztypes_windows_386.go<http://codereview.appspot.com/4528073/diff/21001/src/pkg/syscall/ztypes_windows_386.go>
> > File src/pkg/syscall/ztypes_**windows_386.go (right):
> >
> > http://codereview.appspot.com/**4528073/diff/21001/src/pkg/**
> >
>
syscall/ztypes_windows_386.go#**newcode554<http://codereview.appspot.com/4528073/diff/21001/src/pkg/syscall/ztypes_windows_386.go#newcode554>
> > src/pkg/syscall/ztypes_**windows_386.go:554: NameFullyQualifiedDN = 1
> > On 2011/06/14 17:55:23, bradfitz wrote:
> >
> >> did you mean for the rest of these to be int32 too?  currently it's an
> >>
> > int, not
> >
> >> int32.
> >>
> >
> > That was the idea. So it seems I have to redeclare int32 everywhere,
> > since these constants are part of a C enum. Or would it fit inside an
> > int?
> >
> 
> An int32 fits in an int.
> 
> I don't know what your question is, though.  I was just pointing out that it
> was unlikely the code did what it looks like you meant.

You were right. I still make the error to think that the data type, when
declared, applies to the whole constant section.

I will remove it, since as you point out int is actually correct.

[pjmlp, 2011-06-14 20:42:06]

Hello golang-dev@googlegroups.com, alex.brainman@gmail.com, bradfitz@google.com,
bradfitz@golang.org (cc: golang-dev@googlegroups.com),

Please take another look.