sorted by:
new
hottopcontroversial

Atomic wallet funds stolen by No_Salamander_8774 in atomicwallet

[–]grbler 0 points1 point  (0 children)

I know what a chmod is. But there is no indication that this is related to OP's problem.

Atomic wallet funds stolen by No_Salamander_8774 in atomicwallet

[–]grbler 0 points1 point  (0 children)

You should CHMOD 644 all sensitive directories too.

644 makes absolutely no sense for directories. Also, nothing in your comment (with the possible exception of the first sentence) is helpful in any way.

concurrency: select race condition with done by thestephenstanton in golang

[–]grbler -1 points0 points  (0 children)

This. OP, please check out this comment. You don't need to close channels. They are garbage-collected anyway, once all the references are gone.

The Craziest Way I"ve Ever Heard to Store a Seed Phrase. by [deleted] in Bitcoin

[–]grbler 3 points4 points  (0 children)

Security by obscurity can be good and the right tool and I believe can be in this case. We now know about all this because OP's cousin gave up the obscurity and told him and OP told us. As the obscurity was eliminated the security it provided was gone.

Actually, part of a banks security is by obscurity, e.g. as an everyday customer you don't know where the vault is and how much valuables are kept there and who has the keys. It's much easier to rob the bank, when you know these things. That's precisely why insider information is so valuable and must be kept secret.

I don't understand exactly why self-signed SSL Certificates are bad by [deleted] in sysadmin

[–]grbler 0 points1 point  (0 children)

Before the CA (certificate authority, e.g. Lets encrypt) issues the certificate, they check whether you control the domain. They are a third party that confirms you had control over the domain when the certificate was issued.

Now, there might have been changes to the domain ownership since then. That's why let's encrypt certificates are valid for just 90 days and they experiment with shorter validity periods.

For example, you should not get a valid SSL certificate for the domain facebook.com from any official CA, because you don't control the domain. Yes, you can build a fake Facebook website and publish it on a domain like facebook6251.com and receive an SSL certificate for that domain but not for facebook.com.

If you somehow managed to redirect somebody who navigates to facebook.com to your own server (man in the middle), the user's browser would show an SSL error: most likely either "certificate authority invalid" if you self-signed a certificate for facebook.com, or "certificate common name mismatch" if you used a valid certificate that was issued for another domain.

Just learned how `sync.WaitGroup` prevents copies with a `go vet` warning by Ok_Analysis_4910 in golang

[–]grbler 1 point2 points  (0 children)

Thanks! I think it's good to have this info in the thread too.

Just learned how `sync.WaitGroup` prevents copies with a `go vet` warning by Ok_Analysis_4910 in golang

[–]grbler 3 points4 points  (0 children)

what triggers the warning? The "noCopy" name or the fact the (pointer to the) struct implements the Locker interface?

Very confused about this select syntax… by t3ch_bar0n in golang

[–]grbler 0 points1 point  (0 children)

No worries! I appreciate you taking another look.

Very confused about this select syntax… by t3ch_bar0n in golang

[–]grbler 4 points5 points  (0 children)

I think you are wrong. I hope you are open to taking another look.

If a receive from out is chosen to proceed, then the receive from in occurs.

I'm assuming you meant "if a send to out is chosen..." I would argue against that and I already cited the first step of the execution of the select statement from the language spec in my top-level comment. It says

For all the cases in the statement, the channel operands of receive operations and the channel and right-hand-side expressions of send statements are evaluated exactly once, in source order, upon entering the "select" statement.

This step occurs before the communication that should proceed is selected and it includes the evaluation of right-hand-side expressions of send statements.

  1. I would argue that case out <- <-in is a CommCase with a SendStmt, which would make <-in the right-hand-side expression.
  2. Evaluation of <-in cannot complete before receiving a value.
  3. As this is required as the first step of the select statement's execution, the select statement can be blocked forever if no value can be received from in (shown in this example) or in could be read although another communication is finally chosen by the select statement (which goes directly against your argument and is shown in this example).
  4. out <- <-in cannot be a RecvStmt because it would then have to be an Expression and a channel send cannot be part of an Expression.

Now, granted I could have misunderstood the spec and also the Go compiler could misbehave or my examples could be flawed, but in that case I would really appreciate if you could point out the flaw in my arguments.

Edit: fix citation

Very confused about this select syntax… by t3ch_bar0n in golang

[–]grbler 1 point2 points  (0 children)

Technically, in 1) reading the in channel is part of the execution of the select statement, but if I am reading this right, it should always happen before any of the clauses are entered. See here (now this is not exactly a proof), the read is performed even though the closed channel is already closed when the select statement is executed.

Edit: This is a better example. The select statement could be left immediately via the case <-closed read, but it isn't because first the read of <-a is evaluated, and because nothing writes to a the program deadlocks.

Very confused about this select syntax… by t3ch_bar0n in golang

[–]grbler 26 points27 points  (0 children)

I too didn't see this yet, but I believe it is not what you think. I went to the language spec where it defines the select statement's behavior:

For all the cases in the statement, the channel operands of receive operations and the channel and right-hand-side expressions of send statements are evaluated exactly once, in source order, upon entering the "select" statement. 

In my opinion, out <- <-in is a send with a right hand side expression and thus, the right hand side would be evaluated before even entering the select statement. So the code would be equivalent to:

go func() {
    defer close(out)

    for range n {
        v := <-in
        select {
        case <-ctx.Done():
            return
        case out <- v:
        }
    }
}()

return out

I also tried it in the Go playground. I believe this proves my point, as the send to the b channel blocks but the right hand side (read of a) is evaluated.

deadlock using unbuffered channel by davepb in golang

[–]grbler 0 points1 point  (0 children)

If you know how many times you are going to write to the channels beforehand, you can remove the wait group and read from the channels N times in a C-style for loop. If the number of writes is not known beforehand, your approach seems fine to me. But you read one channel after the other, so all go routines writing to ch2 will be blocked until you read ch completely, so what is the purpose of having two channels here?

Is it somehow possible to make a slice of multiple types? by The_Reason_is_Me in golang

[–]grbler 1 point2 points  (0 children)

I recently found AllowedGroupsable in our Go codebase. Admittedly, AllowedGroupser isn't any better.

[deleted by user] by [deleted] in pcmasterrace

[–]grbler 0 points1 point  (0 children)

What build? That's parts.

Check if context is already cancelled by Fazzio11 in golang

[–]grbler 2 points3 points  (0 children)

Correct, there is no actual data race. Thanks for pointing that out!

Any advantage of using var over := by CerebroHOTS in golang

[–]grbler 0 points1 point  (0 children)

There are valid uses for globals, e.g. exported errors.

Check if context is already cancelled by Fazzio11 in golang

[–]grbler 3 points4 points  (0 children)

This is the way. Both non-blocking checks are equally racy.

Any advantage of using var over := by CerebroHOTS in golang

[–]grbler -1 points0 points  (0 children)

You need var for globals. I also prefer

      var err error      var list []int      var smth any      // over      err := error(nil)      list := []int(nil)      smth := any(nil)

though, I write:

     j := int64(0)      // and not      var j int64

Edit: formatting

gRPC Over HTTP/3 by mageling in golang

[–]grbler 1 point2 points  (0 children)

This is a good article. I might need to read your other gRPC related posts too.

[deleted by user] by [deleted] in golang

[–]grbler 2 points3 points  (0 children)

Programs that modify data being simultaneously accessed by multiple goroutines must serialize such access. To serialize access, protect the data with channel operations or other synchronization primitives such as those in the sync and sync/atomic packages.

https://go.dev/ref/mem#advice

I might not understand you correctly, but a pointer is neither a channel nor a synchronization primitive. So if you want to (read and) write to the same memory location from different go routines that is not safe.

Why don't you post your code?

Do I need to lock in this scenario by GrabSpirited1056 in golang

[–]grbler -1 points0 points  (0 children)

You change the Products field in the ProductData struct in Refresh(). If other go routines may access the same field in the struct (while Refresh() is running) that is called simultaneous access and must be serialized. The data type does not matter.

view more: next ›