On Tue, Aug 23, 2022 at 8:27 PM Frank Schröder
wrote:
>
> Is it possible to write a generic function which converts a slice of a
> concrete type to a slice of an interface that type implements? Something like
> this...
I don't think so, at least not for any interface type. Sorry.
Ian
--
On Tue, Aug 23, 2022 at 2:23 PM Robert Engels wrote:
>
> Doesn’t a different structure as per the Go FAQ imply a specialized loader
> /runtime linker? I just assumed it did.
Go has a different program linker that generates the statically linked
executable, but a statically linked executable
i'm still trying to learn golang when i chance upon the code below. i'm
aware of function return types like int or float, and such but not a
function. how does one interpret the return value of below code?
*package mainimport "fmt"// fibonacci is a function that returns// a
Is it possible to write a generic function which converts a slice of a
concrete type to a slice of an interface that type implements? Something
like this...
// generic version of []*x -> []X (does not compile)
func gslice[From interface{ ~To }, To any](from []From) []To {
var to []To
Should a knife maker be held liable and required to 'fix' their knives when
their knives are used in criminal acts? If the knives are made specifically
with the sole purpose of breaking the laws, then yes, the knife maker
should be held liable. If the knives are general purpose tools, then no,
Hi! Yes that works perfectly. I've added the bounds checking.
Thanks and cheers!
Sincerely,
David
On Tuesday, August 23, 2022 at 3:51:39 AM UTC-4 progl...@gmail.com wrote:
> Assuming that `p.privateKey = *((*C.private_key)(key))` is making a full
> copy, not shallow. I think you could avoid
Doesn’t a different structure as per the Go FAQ imply a specialized loader
/runtime linker? I just assumed it did.
> On Aug 23, 2022, at 1:47 PM, Ian Lance Taylor wrote:
>
> On Tue, Aug 23, 2022 at 9:29 AM Robert Engels wrote:
>>
>> I did not read the analysis - just the thread here and
On Tuesday, August 23, 2022 at 8:47:11 PM UTC+2 Ian Lance Taylor wrote:
> On Tue, Aug 23, 2022 at 9:29 AM Robert Engels
> wrote:
> >
> > I did not read the analysis - just the thread here and earlier threads
> on this subject. My understanding that even though Go is statically linked
>
On Tue, Aug 23, 2022 at 8:40 PM Nihan Khan wrote:
> How golang runtime detect deadlock internally?
I haven't checked the runtime sources about this, but my guess is
something like is done when the scheduler looks for something to do:
'if numberOfGoroutinesBlocked() != 0 &&
On Tue, Aug 23, 2022 at 9:29 AM Robert Engels wrote:
>
> I did not read the analysis - just the thread here and earlier threads on
> this subject. My understanding that even though Go is statically linked the
> loader does relocations that confuse virus scanners.
I'm not sure precisely what
*How golang runtime detect deadlock internally? *
--
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
To this day the most prevalent, evasive and destructive malware is developed
in C/C++... So may as well ban those languages too!!
Seriously, if your answer to 'stopping malware written in Go' is to ban all
applications written in Go, your security team needs some more training budget
or you
Doesn't this article in fact argue that it is the *security teams* that have to
get smarter about what kind of threads they will be faced with and figure out
how to deal with them?
> On Aug 22, 2022, at 6:15 AM, 'Gopher-Insane' via golang-nuts
> wrote:
>
> Hi
>
> So our security team has
I did not read the analysis - just the thread here and earlier threads on this
subject. My understanding that even though Go is statically linked the loader
does relocations that confuse virus scanners.
> On Aug 23, 2022, at 11:05 AM, Brian Candler wrote:
>
>
>> On Tuesday, 23 August 2022
On Tuesday, 23 August 2022 at 16:49:57 UTC+1 ren...@ix.netcom.com wrote:
> I think what is being suggested that if the sec team bans all applications
> that exhibit dynamic code loading behavior they’d be safer - which would
> catch a lot of apps in the net.
>
But the article quoted makes the
On Tue, Aug 23, 2022 at 4:31 PM 'Gopher-Insane' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> The issue is not a vulnerability in the language itself but the use of
> that language to embed malware so AV signatures do not detect it. The
> feeling is that our InfoSec will be wanting to
I think what is being suggested that if the sec team bans all applications that
exhibit dynamic code loading behavior they’d be safer - which would catch a lot
of apps in the net.
> On Aug 23, 2022, at 10:44 AM, Brian Candler wrote:
>
>
>> On Tuesday, 23 August 2022 at 15:30:49 UTC+1
On Tuesday, 23 August 2022 at 15:30:49 UTC+1 Gopher-Insane wrote:
> The issue is not a vulnerability in the language itself but the use of
> that language to embed malware so AV signatures do not detect it. The
> feeling is that our InfoSec will be wanting to restrict obscure languages
> (Go,
The issue is not a vulnerability in the language itself but the use of that
language to embed malware so AV signatures do not detect it. The feeling is
that our InfoSec will be wanting to restrict obscure languages (Go, Rust
etc...).
On Tuesday, 23 August 2022 at 15:22:39 UTC+1
On Tue, Aug 23, 2022 at 2:58 PM 'Gopher-Insane' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> They are suggesting that Go is being more widely used than others, making
> it more of a risk.
>
>
Is their position "we shouldn't write Go in our organization, because it's
being used by
On Tue, Aug 23, 2022, 5:58 AM 'Gopher-Insane' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> They are suggesting that Go is being more widely used than others,
Could be true.
making it more of a risk.
>
I don't see how this follows. What is the risk? It's not a risk to any
They are suggesting that Go is being more widely used than others, making
it more of a risk.
On Tuesday, 23 August 2022 at 13:15:06 UTC+1 jesper.lou...@gmail.com wrote:
> On Mon, Aug 22, 2022 at 3:30 PM 'Gopher-Insane' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> Hi
>>
>> So our
On Mon, Aug 22, 2022 at 3:30 PM 'Gopher-Insane' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> Hi
>
> So our security team has raised a concern with Go and malware. The link
> that was sent to me was
>
I'm aware of why the JSON unmarshal overwrites contents of the pointer, as
I followed the code. I'm also aware of how to pass the slice argument
"correctly".
There's a problem with section (2) because that's not exactly what happens
> during append. There was a proposition to re-initialize
Assuming that `p.privateKey = *((*C.private_key)(key))` is making a full
copy, not shallow. I think you could avoid using `C.CBytes`.
You can get the address of the start of the backing array via [0] as
per https://pkg.go.dev/cmd/cgo
So maybe something like this:
p.privateKey =
>From unmarshal doc:
1. To unmarshal JSON into a pointer, Unmarshal first handles the case
of the JSON being the JSON literal null. In that case, Unmarshal sets the
pointer to nil. Otherwise, Unmarshal unmarshals the JSON *into the value
pointed at by the pointer*. *If the pointer is nil,
26 matches
Mail list logo
