FAQ
Hah, I am happy to report that the just released Go 1.5 beta seems to fix
the problem.

Thanks to the Go team!
On Wednesday, July 8, 2015 at 5:19:39 PM UTC+2, Alexander Neumann wrote:

Go 1.4 introduced new runtime behavior that affects code that stores
pointers in uintptr variables. The walk [1] and win [2] packages on Github
are examples of such code.

Efforts [3] to work around this in those two packages have been
unsuccessful so far.

Does anybody know of a good way to debug this problem?
Will Go 1.5 fix this or at least help debug it?

There seems to be a GODEBUG environment variable that supports an
invalidptr option, but I have not been able to make Go pick it up.

This is on a 64 bit Windows 7 system, with Go 1.4.2 x86.

[1]: https://github.com/lxn/walk
[2]: https://github.com/lxn/win
[3]: https://github.com/lxn/walk/issues/134#issuecomment-119569596
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Brad Fitzpatrick at Jul 8, 2015 at 5:04 pm
    You might just be getting lucky.

    You still can't safely put pointers in uintptr. The GC will ignore them and
    might free memory that you're still trying to use.
    On Jul 8, 2015 9:50 AM, "Alexander Neumann" wrote:

    Hah, I am happy to report that the just released Go 1.5 beta seems to fix
    the problem.

    Thanks to the Go team!
    On Wednesday, July 8, 2015 at 5:19:39 PM UTC+2, Alexander Neumann wrote:

    Go 1.4 introduced new runtime behavior that affects code that stores
    pointers in uintptr variables. The walk [1] and win [2] packages on Github
    are examples of such code.

    Efforts [3] to work around this in those two packages have been
    unsuccessful so far.

    Does anybody know of a good way to debug this problem?
    Will Go 1.5 fix this or at least help debug it?

    There seems to be a GODEBUG environment variable that supports an
    invalidptr option, but I have not been able to make Go pick it up.

    This is on a 64 bit Windows 7 system, with Go 1.4.2 x86.

    [1]: https://github.com/lxn/walk
    [2]: https://github.com/lxn/win
    [3]: https://github.com/lxn/walk/issues/134#issuecomment-119569596
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Alexander Neumann at Jul 9, 2015 at 8:21 am
    I'm afraid you're right. Things just crash later now.

    So if anybody has an idea on how to debug this, I would be happy to hear
    about it.
    On Wednesday, July 8, 2015 at 7:05:29 PM UTC+2, bradfitz wrote:

    You might just be getting lucky.

    You still can't safely put pointers in uintptr. The GC will ignore them
    and might free memory that you're still trying to use.
    On Jul 8, 2015 9:50 AM, "Alexander Neumann" <an2...@googlemail.com
    <javascript:>> wrote:
    Hah, I am happy to report that the just released Go 1.5 beta seems to fix
    the problem.

    Thanks to the Go team!
    On Wednesday, July 8, 2015 at 5:19:39 PM UTC+2, Alexander Neumann wrote:

    Go 1.4 introduced new runtime behavior that affects code that stores
    pointers in uintptr variables. The walk [1] and win [2] packages on Github
    are examples of such code.

    Efforts [3] to work around this in those two packages have been
    unsuccessful so far.

    Does anybody know of a good way to debug this problem?
    Will Go 1.5 fix this or at least help debug it?

    There seems to be a GODEBUG environment variable that supports an
    invalidptr option, but I have not been able to make Go pick it up.

    This is on a 64 bit Windows 7 system, with Go 1.4.2 x86.

    [1]: https://github.com/lxn/walk
    [2]: https://github.com/lxn/win
    [3]: https://github.com/lxn/walk/issues/134#issuecomment-119569596
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at Jul 9, 2015 at 10:20 am

    On Thu, Jul 9, 2015 at 1:21 AM, Alexander Neumann wrote:
    I'm afraid you're right. Things just crash later now.

    So if anybody has an idea on how to debug this, I would be happy to hear
    about it.
    I'm not sure what you are trying to debug. You can not store pointer
    values in variables of type uintptr. That was never safe. Now it is
    even less safe.

    If you are trying to find the places in your code where you do this,
    go vet may help; I'm not sure.

    Ian

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Mateusz Czapliński at Jul 15, 2015 at 4:36 pm

    On Thursday, July 9, 2015 at 12:20:32 PM UTC+2, Ian Lance Taylor wrote:
    On Thu, Jul 9, 2015 at 1:21 AM, Alexander Neumann <an2...@googlemail.com
    <javascript:>> wrote:
    I'm afraid you're right. Things just crash later now.

    So if anybody has an idea on how to debug this, I would be happy to hear
    about it.
    I'm not sure what you are trying to debug. You can not store pointer
    values in variables of type uintptr. That was never safe. Now it is
    even less safe.
    Umm; not exactly? If I understand correctly, in 1.4 you can store pointers
    in uintptr, *as long as there are other references on heap*. (They must be
    specifically on heap so that they're not moved together with pointee during
    stack copying.) I'm trying to make sure to enforce that in my
    https://github.com/akavel/winq package ("Package winq provides functions
    for quick & dirty WinAPI calls, with easy errors capturing."), by keeping a
    slice of syscall args (which sometimes are pointers) in []interface{} form
    over a call to sub-function converting them to uintptr.

    I believe in 1.5, the GC is still non-moving, so this should still be
    valid. (Or am I wrong?)

    On the other hand, 1.4 seems to have a bug in callbacks on Windows, where
    doing a syscall from inside a syscall callback (i.e.: Go -> WinAPI -> Go ->
    WinAPI) can result in some bad behavior of the program (all the times I saw
    that it seemed to manifest via the first WinAPI function returning
    unexpected 0 with GetLastError()==S_OK). This seems to be fixed in 1.5 (see
    http://golang.org/issue/10406, although I haven't 100% confirmed if that's
    really the bug I've seen, but I don't see it occurring any more).

    If you are trying to find the places in your code where you do this,
    go vet may help; I'm not sure.
    It was said it should help detect those places, but neither am I sure if
    that's really working well.

    /Mateusz.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at Jul 15, 2015 at 4:51 pm

    On Wed, Jul 15, 2015 at 9:36 AM, Mateusz Czapliński wrote:
    On Thursday, July 9, 2015 at 12:20:32 PM UTC+2, Ian Lance Taylor wrote:

    On Thu, Jul 9, 2015 at 1:21 AM, Alexander Neumann <an2...@googlemail.com>
    wrote:
    I'm afraid you're right. Things just crash later now.

    So if anybody has an idea on how to debug this, I would be happy to hear
    about it.
    I'm not sure what you are trying to debug. You can not store pointer
    values in variables of type uintptr. That was never safe. Now it is
    even less safe.
    Umm; not exactly? If I understand correctly, in 1.4 you can store pointers
    in uintptr, *as long as there are other references on heap*. (They must be
    specifically on heap so that they're not moved together with pointee during
    stack copying.) I'm trying to make sure to enforce that in my
    https://github.com/akavel/winq package ("Package winq provides functions for
    quick & dirty WinAPI calls, with easy errors capturing."), by keeping a
    slice of syscall args (which sometimes are pointers) in []interface{} form
    over a call to sub-function converting them to uintptr.
    I'm using "safe" in the sense of what we expect to work today and to
    continue working tomorrow.

    In 1.4 we had partial stack copying, so if you stored a pointer to a
    stack address on the stack as a uintptr, the wrong thing would happen.
    I agree that in 1.4, as well as 1.5, you can store a pointer to a heap
    address as a uintptr and get away with it as long as there are other
    pointers to that heap address. But it is not safe. We make
    absolutely no promises that it will continue working in the future.

    Ian

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jon Forums at Jul 15, 2015 at 5:12 pm

    In 1.4 we had partial stack copying, so if you stored a pointer to a
    stack address on the stack as a uintptr, the wrong thing would happen.
    I agree that in 1.4, as well as 1.5, you can store a pointer to a heap
    address as a uintptr and get away with it as long as there are other
    pointers to that heap address. But it is not safe. We make
    absolutely no promises that it will continue working in the future.
    Do the uintptr and GC usage considerations need to be made more visible?

    I've very recently started investigating the multi-platform FFI usage of
    the syscall and unsafe packages. This thread has shown me I'm doing things
    incorrectly. I haven't found anything as helpful as this thread in the
    "first look" docs at

       http://tip.golang.org/pkg/builtin/#uintptr
       http://tip.godoc.org/unsafe#Pointer
       http://tip.golang.org/ref/spec#Numeric_types
       http://tip.golang.org/ref/spec#System_considerations

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Matt Harden at Jul 15, 2015 at 5:21 pm
    I do think this needs to be more clear. Part of the problem is we don't
    have a good answer for how to do it "correctly" in all cases, AFAIK.
    On Wed, Jul 15, 2015 at 12:12 PM wrote:

    In 1.4 we had partial stack copying, so if you stored a pointer to a
    stack address on the stack as a uintptr, the wrong thing would happen.
    I agree that in 1.4, as well as 1.5, you can store a pointer to a heap
    address as a uintptr and get away with it as long as there are other
    pointers to that heap address. But it is not safe. We make
    absolutely no promises that it will continue working in the future.
    Do the uintptr and GC usage considerations need to be made more visible?

    I've very recently started investigating the multi-platform FFI usage of
    the syscall and unsafe packages. This thread has shown me I'm doing things
    incorrectly. I haven't found anything as helpful as this thread in the
    "first look" docs at

    http://tip.golang.org/pkg/builtin/#uintptr
    http://tip.godoc.org/unsafe#Pointer
    http://tip.golang.org/ref/spec#Numeric_types
    http://tip.golang.org/ref/spec#System_considerations

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Daniel Eloff at Jul 15, 2015 at 5:37 pm
    The gotchas around unsafe.Pointer and uintptr conversion should definitely
    be documented better, with some examples of how GC and stack copying can
    move things out from under you. It's an open-source project, so anyone can
    write that up and do whatever is the blessed Go way of submitting a "pull
    request". If someone does that, please post a draft of the changes here so
    we can review it, contribute examples, etc.

    However, the other part of the problem is that Go does not specify what
    exactly is safe, other than to say "be sensible" which is deliberately a
    vague at-your-own-risk kind of warning. The reason for that is what has
    been safe is steadily shrinking. Stack copying and precise GC have made
    these conversions a lot more fraught than they already were.

    Some things *have* to keep working in a "sensible" Go. Converting to
    uintptr and back to do address manipulation (e.g. the Go equivalent of
    pointer[i]) if done without named variable uintptr intermediaries or
    function calls must always work in a "sensible" world.

    fooi := (*Foo)(unsafe.Pointer((uintptr)(unsafe.Pointer(p)) + i)) // Safe

    fooi := (*Foo)(unsafe.Pointer((uintptr)(unsafe.Pointer(p)) +
    some_function(i))) // Potentially unsafe

    addr := (uintptr)(unsafe.Pointer(p))
    fooi := (*Foo)(unsafe.Pointer(addr + i)) // Unsafe, even if you can promise
    p points to the heap, and a strong reference to p exists, it can still
    break in the future

    Anything else is not guaranteed to be safe by Go. It is currently unsafe
    unless you can prove that the object is on the heap and an anchored pointer
    exists to it. And it won't be safe at all in the future if a moving GC is
    introduced.
    On Wednesday, July 15, 2015 at 12:12:12 PM UTC-5, jon.f...@gmail.com wrote:

    In 1.4 we had partial stack copying, so if you stored a pointer to a
    stack address on the stack as a uintptr, the wrong thing would happen.
    I agree that in 1.4, as well as 1.5, you can store a pointer to a heap
    address as a uintptr and get away with it as long as there are other
    pointers to that heap address. But it is not safe. We make
    absolutely no promises that it will continue working in the future.
    Do the uintptr and GC usage considerations need to be made more visible?

    I've very recently started investigating the multi-platform FFI usage of
    the syscall and unsafe packages. This thread has shown me I'm doing things
    incorrectly. I haven't found anything as helpful as this thread in the
    "first look" docs at

    http://tip.golang.org/pkg/builtin/#uintptr
    http://tip.godoc.org/unsafe#Pointer
    http://tip.golang.org/ref/spec#Numeric_types
    http://tip.golang.org/ref/spec#System_considerations
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Matt Harden at Jul 15, 2015 at 6:18 pm
    A workaround is to use unmanaged memory when passing pointers to/from
    non-Go.
    On Wed, Jul 15, 2015 at 12:37 PM Daniel Eloff wrote:

    The gotchas around unsafe.Pointer and uintptr conversion should definitely
    be documented better, with some examples of how GC and stack copying can
    move things out from under you. It's an open-source project, so anyone can
    write that up and do whatever is the blessed Go way of submitting a "pull
    request". If someone does that, please post a draft of the changes here so
    we can review it, contribute examples, etc.

    However, the other part of the problem is that Go does not specify what
    exactly is safe, other than to say "be sensible" which is deliberately a
    vague at-your-own-risk kind of warning. The reason for that is what has
    been safe is steadily shrinking. Stack copying and precise GC have made
    these conversions a lot more fraught than they already were.

    Some things *have* to keep working in a "sensible" Go. Converting to
    uintptr and back to do address manipulation (e.g. the Go equivalent of
    pointer[i]) if done without named variable uintptr intermediaries or
    function calls must always work in a "sensible" world.

    fooi := (*Foo)(unsafe.Pointer((uintptr)(unsafe.Pointer(p)) + i)) // Safe

    fooi := (*Foo)(unsafe.Pointer((uintptr)(unsafe.Pointer(p)) +
    some_function(i))) // Potentially unsafe

    addr := (uintptr)(unsafe.Pointer(p))
    fooi := (*Foo)(unsafe.Pointer(addr + i)) // Unsafe, even if you can
    promise p points to the heap, and a strong reference to p exists, it can
    still break in the future

    Anything else is not guaranteed to be safe by Go. It is currently unsafe
    unless you can prove that the object is on the heap and an anchored pointer
    exists to it. And it won't be safe at all in the future if a moving GC is
    introduced.


    On Wednesday, July 15, 2015 at 12:12:12 PM UTC-5, jon.f...@gmail.com
    wrote:
    In 1.4 we had partial stack copying, so if you stored a pointer to a
    stack address on the stack as a uintptr, the wrong thing would happen.
    I agree that in 1.4, as well as 1.5, you can store a pointer to a heap
    address as a uintptr and get away with it as long as there are other
    pointers to that heap address. But it is not safe. We make
    absolutely no promises that it will continue working in the future.
    Do the uintptr and GC usage considerations need to be made more visible?

    I've very recently started investigating the multi-platform FFI usage of
    the syscall and unsafe packages. This thread has shown me I'm doing things
    incorrectly. I haven't found anything as helpful as this thread in the
    "first look" docs at

    http://tip.golang.org/pkg/builtin/#uintptr
    http://tip.godoc.org/unsafe#Pointer
    http://tip.golang.org/ref/spec#Numeric_types
    http://tip.golang.org/ref/spec#System_considerations
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Mateusz Czapliński at Jul 15, 2015 at 6:37 pm

    On Wednesday, July 15, 2015 at 8:18:55 PM UTC+2, Matt Harden wrote:
    A workaround is to use unmanaged memory when passing pointers to/from
    non-Go.

    On Wed, Jul 15, 2015 at 12:37 PM Daniel Eloff <dan....@gmail.com
    <javascript:>> wrote:
    [...] It is currently unsafe unless you can prove that the object is on
    the heap and an anchored pointer exists to it. And it won't be safe at all
    in the future if a moving GC is introduced.

    In 1.4 we had partial stack copying, so if you stored a pointer to a
    stack address on the stack as a uintptr, the wrong thing would happen.
    I agree that in 1.4, as well as 1.5, you can store a pointer to a heap
    address as a uintptr and get away with it as long as there are other
    pointers to that heap address. But it is not safe. We make
    absolutely no promises that it will continue working in the future.
    For what it's worth, I intend to try evolving
    https://github.com/akavel/winq to keep it correct as the GC evolves with
    future Go versions. (Potentially with build tag guards in the
    implementation for various versions of Go.) I can't 100% guarantee anything
    (esp. given what's summarized in the above discussion), but I'll try hard.

    Also, I strongly intend to keep the winq API backwards-compatible in future
    (to the extent described at http://gopkg.in).

    /Mateusz.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jon Forums at Jul 15, 2015 at 6:42 pm
    While fully reviewed doco may make sense in the long term, I also think
    something more surgical adds value. Specifically, update the existing docs
    with relevant summary and any generally applicable recommendations

       http://tip.golang.org/pkg/builtin/#uintptr
       http://tip.godoc.org/unsafe#Pointer
       http://tip.golang.org/ref/spec#System_considerations

    This is timely with the upcoming 1.5 release, and hoists the visibility of
    the issue rather than leaving it to just golang-nuts threads. Any other
    deep dive, full featured doco can proceed in parallel.

    My concern is that with the ongoing GC enhancements, it might be too early
    to expect a 100% bullet proof recommendation that covers all scenario. But
    Ian, Brad, and other's comments look like there's enough understanding of
    the issue to warrant quick, value add comments to the above docs.



    The gotchas around unsafe.Pointer and uintptr conversion should definitely
    be documented better, with some examples of how GC and stack copying can
    move things out from under you. It's an open-source project, so anyone can
    write that up and do whatever is the blessed Go way of submitting a "pull
    request". If someone does that, please post a draft of the changes here so
    we can review it, contribute examples, etc.

    However, the other part of the problem is that Go does not specify what
    exactly is safe, other than to say "be sensible" which is deliberately a
    vague at-your-own-risk kind of warning. The reason for that is what has
    been safe is steadily shrinking. Stack copying and precise GC have made
    these conversions a lot more fraught than they already were.

    Some things *have* to keep working in a "sensible" Go. Converting to
    uintptr and back to do address manipulation (e.g. the Go equivalent of
    pointer[i]) if done without named variable uintptr intermediaries or
    function calls must always work in a "sensible" world.

    fooi := (*Foo)(unsafe.Pointer((uintptr)(unsafe.Pointer(p)) + i)) // Safe

    fooi := (*Foo)(unsafe.Pointer((uintptr)(unsafe.Pointer(p)) +
    some_function(i))) // Potentially unsafe

    addr := (uintptr)(unsafe.Pointer(p))
    fooi := (*Foo)(unsafe.Pointer(addr + i)) // Unsafe, even if you can
    promise p points to the heap, and a strong reference to p exists, it can
    still break in the future

    Anything else is not guaranteed to be safe by Go. It is currently unsafe
    unless you can prove that the object is on the heap and an anchored pointer
    exists to it. And it won't be safe at all in the future if a moving GC is
    introduced.

    On Wednesday, July 15, 2015 at 12:12:12 PM UTC-5, jon.f...@gmail.com
    wrote:
    In 1.4 we had partial stack copying, so if you stored a pointer to a
    stack address on the stack as a uintptr, the wrong thing would happen.
    I agree that in 1.4, as well as 1.5, you can store a pointer to a heap
    address as a uintptr and get away with it as long as there are other
    pointers to that heap address. But it is not safe. We make
    absolutely no promises that it will continue working in the future.
    Do the uintptr and GC usage considerations need to be made more visible?

    I've very recently started investigating the multi-platform FFI usage of
    the syscall and unsafe packages. This thread has shown me I'm doing things
    incorrectly. I haven't found anything as helpful as this thread in the
    "first look" docs at

    http://tip.golang.org/pkg/builtin/#uintptr
    http://tip.godoc.org/unsafe#Pointer
    http://tip.golang.org/ref/spec#Numeric_types
    http://tip.golang.org/ref/spec#System_considerations
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Brainman at Jul 10, 2015 at 12:32 am

    On Thursday, 9 July 2015 18:21:09 UTC+10, Alexander Neumann wrote:

    So if anybody has an idea on how to debug this, I would be happy to hear
    about it.
    I don't know of any special way. If you have some broken program, I would
    just try to understand why it is broken. I looked at your issues, and
    https://github.com/lxn/walk/issues/139 seems to be working on current go
    tip. I am not sure what is broken for you.

    Alex

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Brainman at Jul 8, 2015 at 11:43 pm
    Welcome back :-)

    Alex

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Alexander Neumann at Jul 9, 2015 at 8:17 am
    Thanks :-)
    On Thursday, July 9, 2015 at 1:43:40 AM UTC+2, brainman wrote:

    Welcome back :-)

    Alex
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJul 8, '15 at 3:50p
activeJul 15, '15 at 6:42p
posts15
users8
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase