[go-nuts] Can vet report useless assignments in method?
Hi go nuts, https://play.golang.org/p/ylYlbVMQ24- I recently hit an error where I had been calling methods on a struct. Originally, the fields in the struct were never changed, but after some iterations, i added some state to my struct. The methods which modified the state were always working on a copy (like in the example above), which caused the resulting modification to be thrown away. Would it be possible to make such assignments be a vet warning? For cases like _ = foo, the intent of the programmer is clear to throw a value away). But in the case of the example, its more likely a bug. In fact, I can't see any legitimate reason to assign to a struct value, (unless it is read later). -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] syscall/js: How to pass data from the browser back into Go?
While trying out the Wasm compiler, I noticed that the syscall/js mainly has helper functions for converting Go types to Js types, but not the other way around. I am trying to read the data from an HTML . I add an event listener for the `change` event and want to read the file contents. The problem is that there doesn't seem to be a way to convert between any dataformat window.FileReader (such as ArrayBuffer, or a UInt8Array), and a []byte. My work around for now is calling js.Value.String(), and parsing the comma separated decimal numbers. What is the correct way to do this? -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Unsafe Pointer rules
The answer must be more nuanced than that, because it is possible to take a
nil pointer and construct an unsafe.Pointer from it.
The reason I am interested in this is (and please don't judge too early) is
I'm toying around with implementing some atomic primitives. In particular,
I would like to play around with with the cmpxchg16b instruction which
needs 16 byte alignment. Go does not provide a way to enforce a data
structure has such alignment, so I am attempting to define a struct that I
can index into. (assume 64bit words). For example, the datastructure I
want is this:
// alignment of foo is 16
type foo struct {
uintptr
unsafe.Pointer
}
But I can't assert this. The next best thing is to make a struct 2x the
size, and make a pointer to the first aligned part:
type foo struct {
[4]uintptr
}
This way I can get an aligned address pointing into the middle of this
array for using cmpxchg16b. The problem with this is that if any of the
interior values are not seen a pointers by the GC. In order to keep the
values alive they need to be unsafe.Pointer:
type foo struct {
[4]unsafe.Pointer
}
Now this is a problem. There is really only one pointer in here, the other
value is just some arbitrary bytes. Since the GC now things the addresses
are real, it will crash. What is the correct way to get an aligned struct
that contains pointers?
On Tuesday, August 21, 2018 at 3:40:55 PM UTC-7, Ian Lance Taylor wrote:
>
> On Tue, Aug 21, 2018 at 1:19 PM, 'Carl Mastrangelo' via golang-nuts
> > wrote:
> >
> > If I create an unsafe.Pointer that points to an invalid memory address,
> but
> > I never deference it or otherwise pass it along, what happens to it?
>
> If you never deference it and never do anything with it, then in
> practice it most likely gets eliminated by the compiler. That said:
>
> > Is it a valid go program to just create such a pointer?
>
> No. The only way you could create such a Pointer is by converting
> from uintptr, or, essentially equivalently, by calling C or assembler
> code. The unsafe package docs explain all the cases in which it is
> permitted to convert a uintptr to an unsafe.Pointer. Using any other
> mechanism is invalid. The permitted mechanisms never produce an
> unsafe.Pointer that contains an invalid memory address.
>
> > The main reason I ask is
> > that I know the GC treats unsafe.Pointer values differently than
> uintptr.
> > If the GC were to chase this invalid pointer, it would likely get a
> > segfault. This means that either the GC knows not to chase such a
> pointer,
> > or it would chase it and gracefully recover.
>
> In practice, in the current implementation, what will happen is that
> the GC will attempt to find the object to which the pointer points,
> will fail, and will crash with a "pointer to unallocated span" error.
>
> > Additionally, if the unsafe.Pointer is pointing to a incorrectly aligned
> > address, the GC could potentially misunderstand and try to walk it. I'm
> > sure this has been thought of before, but it isn't called out in the
> docs.
>
> This isn't an issue with the current implementation. The current GC
> doesn't care about the type of the pointer, so pointers have no
> alignment requirements as far as the GC is concerned. Every pointer
> is effectively a *byte for GC purposes.
>
> 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Unsafe Pointer rules
(to short circuit any question, I have already read https://golang.org/pkg/unsafe/ ) If I create an unsafe.Pointer that points to an invalid memory address, but I never deference it or otherwise pass it along, what happens to it? Is it a valid go program to just create such a pointer? The main reason I ask is that I know the GC treats unsafe.Pointer values differently than uintptr. If the GC were to chase this invalid pointer, it would likely get a segfault. This means that either the GC knows not to chase such a pointer, or it would chase it and gracefully recover. Additionally, if the unsafe.Pointer is pointing to a incorrectly aligned address, the GC could potentially misunderstand and try to walk it. I'm sure this has been thought of before, but it isn't called out in the docs. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Puzzle: make a sync.Once fire more than once
Hi gophers,
I was playing around with a puzzle trying to break the sync package and
found something cool. Can you think of a definition for f that causes
once.Do to execute the argument more than once?
package main
import (
"sync"
)
func main() {
var once sync.Once
var f = // ...
once.Do(f)
}
HIGHLIGHT BELOW FOR ANSWER
package main
import (
"fmt"
"sync"
)
func main() {
var once sync.Once
var f func()
times := 9
f = func() {
if times == 0 {
return
}
times--
fmt.Println("Called")
oldonce := once
* = sync.Once{}
once.Do(f)
once = oldonce
}
once.Do(f)
}
HIGHLIGHT ABOVE FOR ANSWER
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] [ANN] HTTP/2 Plaintext Server
Hi all, If you have ever wanted to use the Go httputil.ReverseProxy with HTTP/2, or do HTTP/2 over Unix Domain Sockets, or do gRPC over plaintext, I made a package that makes it easy to do: https://github.com/carl-mastrangelo/h2c I added some examples to show how to do it, comments welcome! (Still to do is http/1.1 upgrade, but so far I don't know any clients that do that) -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Wrong order for float64 conversion
https://play.golang.org/p/iZTogUaWWl In the program above, foo and bar compile but baz does not. It fails with the message: "invalid operation: 1 << b (shift of type float64)". This seems to be wrong on the surface, since the order of operations should imply the shift takes precedence. In the bar function, using a temporary variable without specifying the type shows that the compiler does know what to do. What am I missing? -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Is SizedReaderAt coming back in 1.8?
It seems that io.SizedReaderAt was added temporarily during the 1.7 cycle, but promptly removed. I see an standing github issue for it (15822) but it doesn't seem to have much activity. I would like to express my hope that it comes back (and hopefully others will to). A use case that I am interested in is turning a ReaderAt into a Reader, which is currently non-trivial to convert. The io package has a SectionReader, but to create one of those you need to know the size, which a plain ReaderAt won't provide. There are some other places in the API that would benefit from such a class, such as the archive/zip package. Currently, it is not possible to read from an in memory Zip file, because the only method to open zips is OpenReader(name string) !? I understand that the index is at the back of the file, so a plain reader can't be passed in. However, a SizedReaderAt would conveniently fit as a zip Reader, since it know the size in advance. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] How long are the results from runtime.Callers valid?
Cgo is not in use; thank you for the quick response! On Saturday, August 6, 2016 at 11:49:22 AM UTC-7, Ian Lance Taylor wrote: > > On Sat, Aug 6, 2016 at 10:08 AM, Carl Mastrangelo > <carl.mas...@gmail.com > wrote: > > TL;DR: Is the uintptr slice returned from runtime.Callers always valid? > > > > Reading the docs* for runtime.Callers says: "Callers fills the slice pc > with > > the return program counters of function invocations on the calling > > goroutine's stack. " Does this imply that once the goroutine is gone, > or > > all the functions have returned, the uintptrs could be pointing to > garbage? > > > > I ask because I would like a cheap-ish stacktrace for some error > handling > > code I am writing, and I don't want to turn the stack frame into a full > > string. If I can capture the functions on the stack and maybe turn them > > into an error message later that would be ideal. > > The pointers are always valid. All executable code is created at > compilation time, and the function pointers returned by > runtime.Callers always point into executable code that is always > present. > > (An exception would be if you used runtime.SetCgoTraceback to collect > a C function address that happens to be in a shared library that you > happened to dlclose. But if you don't use SetCgoTraceback or you > don't dlopen and then dlclose C shared libraries, this won't be a > problem.) > > 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] How long are the results from runtime.Callers valid?
TL;DR: Is the uintptr slice returned from runtime.Callers always valid? Reading the docs* for runtime.Callers says: "Callers fills the slice pc with the return program counters of function invocations on the calling goroutine's stack. " Does this imply that once the goroutine is gone, or all the functions have returned, the uintptrs could be pointing to garbage? I ask because I would like a cheap-ish stacktrace for some error handling code I am writing, and I don't want to turn the stack frame into a full string. If I can capture the functions on the stack and maybe turn them into an error message later that would be ideal. Example (requires 1.7): https://play.golang.org/p/bfZBvcLzje * https://tip.golang.org/pkg/runtime/#Callers -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
