> For example, is this program guaranteed to print "1 1"?
> https://go.dev/play/p/PeBEXKp1deH
Yes, because the range iteration loop does not add/delete any items.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group an
None of the conditions specified in that clause applies for updating key
in-place. The way I read it, a new entry is not added, so the iteration
should visit every entry only once. Thus, the program always prints "1 1".
On Tue, Aug 2, 2022 at 9:20 PM Kevin Chowski wrote:
> Hello Go gurus,
>
> I
On Tue, Aug 2, 2022 at 7:59 PM burak serdar wrote:
> What exactly do you mean by "read/write 5 different keys"?
>
> If you have a map[int]*SomeStruct, for instance, and if you initialize
> this map with some entries, and then if you have multiple goroutines all
> performing lookups of distinct ke
Hello Go gurus,
I think there is some ambiguity in the language spec about what happens
when a map entry is updated during iteration. Quoting the spec
(https://go.dev/ref/spec#For_range):
3. The iteration order over maps is not specified and is not guaranteed to
be the same from one iteration
What exactly do you mean by "read/write 5 different keys"?
If you have a map[int]*SomeStruct, for instance, and if you initialize this
map with some entries, and then if you have multiple goroutines all
performing lookups of distinct keys and modifying the contents of
*SomeStruct, it would be safe
Go maps are only concurrent safe if all accesses are reads (lookups) after
the map is initialized. So your scenario is not safe and can result in a
panic as well as other undefined behavior. The Go standard library has a
concurrent safe map implementation (see https://pkg.go.dev/sync#Map). There
ar
Hi! If I have several 5 goroutines read/write 5 different keys in map
independently without a Mutex/RWMutex. Each goroutine just read/write their
own corresponding key. No intersection.
In such a case, no goroutines will operate on the same key, does that mean
it's safe?
Or maybe each goroutin
When looking at hashing algorithms there's a whole lot of factors to
consider.
A few of the common considerations are:
1. performance.
2. cryptographic or not.
3. collision rate including avalanche effect and bit-size.
There are a bunch of other considerations but those are some high-level
conce
package mod
import (
"testing"
)
func TestEncrypt(t *testing.T) {
password := []byte("*RTFUGIHOD&TUGGIYKl")
data := []byte("This encryption algorithm is faster than aes256 up to 40kb
but how secure is it?")
for x, _ := range data {
p := (password[x%len(password)])
data[x] = data[x] + byte(p)
}
p
CGO_CFLAGS_ALLOW=".*"
CGO_LDFLAGS_ALLOW=".*"
CFLAGS = $(pkg-config --cflags libdpdk)
LDFLAGS = $(pkg-config --static --libs libdpdk)
CGO_ENABLED=1 CC=gcc CGO_CFLAGS=$CFLAGS CGO_LDFLAGS=$LD_FLAGS go build -o
app
When I try to use these commands, the compilation is failing with errors
"multiple de
go 1.19 has just been released and the problem is gone!
--
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.
To view this dis
Hello gophers,
We have just released Go 1.19.
To find out what has changed in Go 1.19, read the release notes:
https://go.dev/doc/go1.19
You can download binary and source distributions from our download page:
https://go.dev/dl/#go1.19
If you have Go installed already, an easy way to try go1.19
I am getting the below error when i am trying to build using gomobile
The build command is : GOARCH=arm64 CGO_ENABLED=0 GOOS="android"
GOSUMDB=off gomobile bind -target android -v
Please suggest any solution
bitbucket.org/exium-c2/exue/common
exue
gobind/gobind
# gobind/gobind
exue_android.c:729
13 matches
Mail list logo
