And then, it also occurs to me that perhaps I can answer my own question.
Taking advantage of three aspects of the ecosystem.
#1) Most open source Go libraries are on GitHub
#2) Many (most?) CVEs for open source projects will include a reference
back to the project, and these references can be
Some related discussion in https://github.com/golang/go/issues/24031 and
linked issues.
On Tue, 13 Aug 2019 at 10:32, Steve Mynott wrote:
> I've been introduced to https://rubysec.com/ which has a database
> which easily integrates with builds to check for known security
> vulnerabilities in
It would be great to hear of an answer to this question. I suspect there
isn't one, though.
The trouble is, one of the first hurdles is to identify Go libraries that
have CVEs against them. It is very easy to find CVEs for the Go standard
library, but I cannot see any easy way to scan the
Hi Joe, to my current understanding of things i would say that both ways
are the same and without further context it seems similar.
Using a pointer reciever it seems more object-oriented to me, as i have
spend many years working in Java.
I know this:
type S struct {}
func (s S) pepe () {}
Hi gophers,
We have just released Go 1.12.8 and Go 1.11.13 to address recently reported
security issues. We recommend that all users update to one of these
releases (if you’re not sure which, choose Go 1.12.8).
- net/http: Denial of Service vulnerabilities in the HTTP/2
implementation
On Tuesday, 13 August 2019 17:03:36 UTC+2, jochen...@gmx.de wrote:
>
> type X Y is a type declaration, you have to cast between the types
> type X=Y is a type alias, where X can be used as Y without casting
>
There are no type cast in Go. Only type conversions.
V.
--
You received this message
Hello gophers,
I am not sure where or how to report this problem, but all of the links
from the following blog
https://blog.golang.org/upcoming-google-io-go-events
are 404. Some of examples,
* http://code.google.com/events/io/2010/
* http://code.google.com/events/io/2010/bootcamp.html
type X Y is a type declaration, you have to cast between the types
type X=Y is a type alias, where X can be used as Y without casting
Am Dienstag, 13. August 2019 06:53:20 UTC+2 schrieb Sathish VJ:
>
> And what is the difference between each of these: type alias, type
> redefinition, type
Hi,
Thanks for the heads-up.
I also see what you're seeing for my build, and this is a mystery for me as
well.
The libgo makefile generates "sysinfo.go" by running the C compiler on a
source that includes various system headers, so as to capture Go versions
of C-specific constants and types.
On Fri, Aug 9, 2019 at 8:34 PM wrote:
> The current Go implementation smells of cooperative multitasking. Not a
> bad thing, per se, but makes it hard to stop in certain degenerate cases.
> Have I missed a way to deal with some of the discussed issues?
>
>
My spider sense (intuition) says you
On Tue, Aug 13, 2019 at 8:10 AM Sathish VJ wrote:
> So doing *type X Y* is just a type declaration then?
>
>
In a certain sense
type X Y
and
type X = Y
are both type declarations. They differ in that the first is generative,
whereas the other is a synonym. In a generative pattern, you
I've been introduced to https://rubysec.com/ which has a database
which easily integrates with builds to check for known security
vulnerabilities in third party libraries and was wondering whether
anything similar exists for go packages?
A quick search finds https://snyk.io/vuln?type=golang which
check this https://groups.google.com/forum/#!topic/golang-nuts/1YvP-5V6xSI
when we code golang with c, some c code used * sigwait sigwaitinfo*
function to wait signal.
sometime this signal is caught by golang runtime, and this cause cash.
we want the signal continue to be handled by
On Tuesday, 13 August 2019 09:43:05 UTC+2, Jan Mercl wrote:
>
> On Tue, Aug 13, 2019 at 9:24 AM Volker Dobler
> > wrote:
>
> > Yes, of course. It declares a new named type X, the underlying
> > type is Y which can be some predeclared type like int, some
> > other named declared type (like
in other words
we need a *go runtime signal mask .*
just google, no such api provided by go yet .
I want know why ?
any workaround?
--
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
On Tue, Aug 13, 2019 at 9:24 AM Volker Dobler
wrote:
> Yes, of course. It declares a new named type X, the underlying
> type is Y which can be some predeclared type like int, some
> other named declared type (like MyFooType) or a "type literal"
> (a term I made up) like struct{X,Y float64; T
On Tuesday, 13 August 2019 08:10:56 UTC+2, Sathish VJ wrote:
>
> So doing *type X Y* is just a type declaration then?
>
Yes, of course. It declares a new named type X, the underlying
type is Y which can be some predeclared type like int, some
other named declared type (like MyFooType) or a "type
I found the case is like this
c code
IgnoreSignal(42);
while(1) {
GoSleep(10);//simulate some call in go runtime , the runtime call stack is
in last mail
int signo = sigwaitinfo(_set, _info); //will use this signo
to do something
// usleep(1000*1000);
printf("sleep 10s \n");
// raise(42);
}
So doing *type X Y* is just a type declaration then?
Meanwhile, I wrote a small example to help me figure out the differences
between some of these based on the specs. Leaving it here in case it is
useful for somebody.
package main
import "fmt"
type X struct {}
func (X) f() {}
type Y X //
19 matches
Mail list logo
