[go-nuts] Re: Can I say a stack overflow is a panic?

[T L]

According to what I know, there are some cases which will cause fatal 
errors instead of panic:
* start a new goroutine by call a nil function value
* out of memory
* unlock of unlocked mutex
* data races in map element access
* stack overflow

On Friday, January 4, 2019 at 10:43:24 AM UTC-5, 伊藤和也 wrote:
>
> I tried to recover a stack overflow but I couldn't.
>
> func main() {
>defer func() {
>   src := recover()
>   fmt.Println(src)
>}()
>main()
> }
>
>
>

-- 
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] A read-only value (not read-only type) proposal

[T L]

I made an immutable value proposal: 
https://github.com/golang/go/issues/29422
and I'm looking for feedback for it.
For example, are there any design flaws and shortcomings in it?
Any improvement ideas are also welcome.

-- 
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] golang for coding interviews

[Naveen Neelakanta]

Awesome, thanks for the info!

On Thu, Jan 10, 2019 at 6:37 PM Tyler Compton  wrote:

> Hi Naveen,
>
> Others may disagree but my take is that Go is not a great coding interview
> language. The lack of many built-in data structures is a big one, but those
> closing curly braces and other syntax can be a big pain when writing on a
> whiteboard. In cases where only general programming knowledge is being
> tested for, I would pick Python so long as you're comfortable in the
> language. It has more data structures available and is simply easier to
> write on a whiteboard. Other conveniences like all, any, and list
> comprehensions also come in handy when time to write code and available
> space for code is at a premium.
>
> Of course, traits that make a language better for interviews don't always
> make the language better for production use. Go is still my go-to language
> for many other things :)
>
> On Thu, Jan 10, 2019 at 4:56 PM Naveen Neelakanta <
> naveen.b.neelaka...@gmail.com> wrote:
>
>> Hi All,
>>
>> I wanted to use Golang for coding interviews, however, I can't import
>> basic data structures like stack, heap, the queue on to IDEs. Is there a
>> way to achieve this.
>>
>> Thanks,
>> Naveen
>>
>> --
>> 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.
>>
>

-- 
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] golang for coding interviews

[Tyler Compton]

Hi Naveen,

Others may disagree but my take is that Go is not a great coding interview
language. The lack of many built-in data structures is a big one, but those
closing curly braces and other syntax can be a big pain when writing on a
whiteboard. In cases where only general programming knowledge is being
tested for, I would pick Python so long as you're comfortable in the
language. It has more data structures available and is simply easier to
write on a whiteboard. Other conveniences like all, any, and list
comprehensions also come in handy when time to write code and available
space for code is at a premium.

Of course, traits that make a language better for interviews don't always
make the language better for production use. Go is still my go-to language
for many other things :)

On Thu, Jan 10, 2019 at 4:56 PM Naveen Neelakanta <
naveen.b.neelaka...@gmail.com> wrote:

> Hi All,
>
> I wanted to use Golang for coding interviews, however, I can't import
> basic data structures like stack, heap, the queue on to IDEs. Is there a
> way to achieve this.
>
> Thanks,
> Naveen
>
> --
> 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.
>

-- 
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] golang for coding interviews

[Naveen Neelakanta]

Hi All,

I wanted to use Golang for coding interviews, however, I can't import basic
data structures like stack, heap, the queue on to IDEs. Is there a way to
achieve this.

Thanks,
Naveen

-- 
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 to append nil using reflect

[Ian Lance Taylor]

On Thu, Jan 10, 2019 at 3:40 PM  wrote:
>
> I want to append a nil value using reflect.Append(), but I got a panic: 
> reflect: call of reflect.Value.Set on zero Value.
>
> This is my code.
>
> s := make([]interface{}, 10)
> v := reflect.ValueOf(nil)
> reflect.Append(reflect.ValueOf(s), v)
>
> So is there a way i can append nil? Currently I do this as workaround:
>
> s := make([]interface{}, 10)
> s0 := make([]interface{}, 1)
> r := reflect.AppendSlice(reflect.ValueOf(s), reflect.ValueOf(s0))
>
> It works but I think there must be a better way.

First you have to clearly distinguish between nil, an uninitialized
value with no type, and the value interface{}(nil), which is an
uninitialized value of type interface{}.  You want the latter.  Then,
it's always a bit awkward to work with interface types with the
reflect package, because the reflect package naturally tries to look
for the value stored in the interface type, whereas you actually want
the interface type.

Here is one way to do it:

https://play.golang.org/p/Qt5-AmYa9Mk

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] Algorithm question: reversing text/template.Template.Execute efficiently

[twpayne]

As part of chezmoi , I want to reverse 
text/template.Template.Execute, i.e. given some template output, and some 
data that was used to generate that output, I want to generate the best 
possible input template that given the data generates the same output. The 
problem is roughly specified here:
  https://github.com/twpayne/chezmoi/issues/97

I'm sure that there's a better way to do this. This seems like a classic 
algorithms interview question. Any ideas?

Cheers,
Tom

-- 
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 to append nil using reflect

[xinhu . liu90]

Hi everyone,

I want to append a nil value using reflect.Append(), but I got a panic: 
reflect: call of reflect.Value.Set on zero Value.

This is my code.

s := make([]interface{}, 10)
v := reflect.ValueOf(nil)
reflect.Append(reflect.ValueOf(s), v)

So is there a way i can append nil? Currently I do this as workaround:

s := make([]interface{}, 10)
s0 := make([]interface{}, 1)
r := reflect.AppendSlice(reflect.ValueOf(s), reflect.ValueOf(s0))

It works but I think there must be a better way.

Best regards,
Xinhu

-- 
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] Go 1.12 Beta 2 is released

[Dmitri Shuralyov]

Hello gophers,

We have just released go1.12beta2, a beta version of Go 1.12.
It is cut from the master branch at the revision tagged go1.12beta2.

Please try your production load tests and unit tests with the new version.
Your help testing these pre-release versions is invaluable.

Report any problems using the issue tracker:
https://golang.org/issue/new

If you have Go installed already, the easiest way to try go1.12beta2
is by using the go command:
$ go get golang.org/dl/go1.12beta2
$ go1.12beta2 download

You can download binary and source distributions from the usual place:
https://golang.org/dl/#go1.12beta2

To find out what has changed in Go 1.12, read the draft release notes:
https://tip.golang.org/doc/go1.12

Cheers,
The Go Team

-- 
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] Re: Wuffs: a new, memory-safe programming language

[Jesper Louis Andersen]

On Thu, Jan 10, 2019 at 9:00 PM Thomas Bushnell, BSG 
wrote:

>
> I think the paper you linked is exciting, and actually suggests that the
> hard work which needs to be done will solve the problem without a change of
> language. This fits my intuition: the things necessary to take advantage of
> type safety can only be automatically used with the same kind of proof work
> you need to do to establish the code was fine to begin with.
>
>
It is!

It is predated by another idea which is equally exciting but never ever
really tested in the large, namely proof carrying code.

in a PCC scheme, a program is accompanied with a proof of its behavior
according to some security policy. For instance that it is memory safe. The
proof is sent as an oracle stream: whenever the proof checker is in doubt
it consults the rule to apply from the oracle stream. This makes the proof
small. A program is checked before it is run. In particular, this avoids
the chain of trust by cryptographic signature. If the proof is correct, we
can run the program. The onus on constructing the proof is on the writer of
the program, or the code generator.

Whole classes of security bugs can be eliminated by updating the security
policy.

A simpler solution was one I somewhat haphazardly tried to suggest Russ Cox
on Twitter when he asked about solutions to the whole event-stream problem
we saw on NPM of node.js fame. Let software be able to drop certain
privileges after setup, in the style of OpenBSDs pledge(2) system call. If
a module pledges itself to only ever use limited functionality, and we
store this persistently, we solve many potential programming mistakes, and
we make life much harder for malicious injection. This is like a poor-mans
security policy, but it doesn't require the same attention to detail.

Another symbiosis solution I like is the idea that we should take old
software and run it, but next to a "contract checker", which is a piece of
software governing the potential unsafe software. Only if the checker
accepts the input, will it be passed to the potentially unsafe program.

-- 
J.

-- 
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] Building the gollvm on OSX

['Than McIntosh' via golang-nuts]

Hello,

Building the Gollvm compiler (llvm-goc) on OS-X is (probably) doable with
some hacking, but the bigger problem is that that the version of libgo (Go
runtime and standard packages) has not yet been ported to the Mac-- at the
moment only linux is supported. So even if you could compile things, you
would have no way to run them. It would be nice to have an OS-X port for
gollvm, but at the moment nobody has stepped up to contribute along those
lines.

Thanks, Than




On Thu, Jan 10, 2019 at 2:27 PM  wrote:

> Hello,
>
> has anyone managed to setup the GOLVVM on OSX (Mojave)?
>
> I'm following the instructions here https://go.googlesource.com/gollvm,
> but am stuck at:
>
> cmake -DCMAKE_BUILD_TYPE=Debug -DLLVM_USE_LINKER=gold -G Ninja ../llvm
>
>
> The error I get is:
>
>  Host compiler does not support '-fuse-ld=gold'
>
>
> I assume the Gold linker isn't for OSX, but I can't seem to find one that
> does, at least by setting the flags to cmake.
>
> If anyone has successfully built gollvm on an OSX machine, please share
> how you did it, or what am I doing wrong.
>
> Thanks a lot
>
> --
> 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.
>

-- 
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] Re: Wuffs: a new, memory-safe programming language

['Thomas Bushnell, BSG' via golang-nuts]

On Thu, Jan 10, 2019 at 10:49 AM Jesper Louis Andersen <
jesper.louis.ander...@gmail.com> wrote:

> On Thu, Jan 10, 2019 at 7:39 PM Thomas Bushnell, BSG 
> wrote:
>
>>
>>> The server crashes - that's how we handle "any other exception", as a
>> rule.
>>
>>
> I write Erlang for a living. We don't crash a server, ever, on a failure.
> Unless the failure is persistent :)
>

Sorry, Eric was talking about Go, not just "something". There may be other
choices that would solve the problem where Go would not.

I think the paper you linked is exciting, and actually suggests that the
hard work which needs to be done will solve the problem without a change of
language. This fits my intuition: the things necessary to take advantage of
type safety can only be automatically used with the same kind of proof work
you need to do to establish the code was fine to begin with.

Thomas
-- 

memegen delenda est

-- 
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] Building the gollvm on OSX

[vladimir . strackovski]

Hello,

has anyone managed to setup the GOLVVM on OSX (Mojave)?

I'm following the instructions here https://go.googlesource.com/gollvm, but 
am stuck at:

cmake -DCMAKE_BUILD_TYPE=Debug -DLLVM_USE_LINKER=gold -G Ninja ../llvm


The error I get is:

 Host compiler does not support '-fuse-ld=gold'


I assume the Gold linker isn't for OSX, but I can't seem to find one that 
does, at least by setting the flags to cmake.

If anyone has successfully built gollvm on an OSX machine, please share how 
you did it, or what am I doing wrong.

Thanks a lot 

-- 
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] Hiring full-time. Remote/Local/Re-Location

[chrispikul510]

Hi guys, 

We at Komolog are looking to hire new talent. We are located in Istanbul, 
if you aren't, that's fine. Remote positions, and re-location are 
available. Our primary usage with Go is our JSON API service, as well as 
gRPC servers, and other worker services. Will need to be able to work with 
PostgreSQL.

Check us out at Komolog.com 

If you are interested, or have further questions, you can email if you'd 
like at care...@komolog.com

Also, if you happen to have full-stack experience with React, and/or 
React-Native that would be *awesome*.

-- 
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] Re: Wuffs: a new, memory-safe programming language

[Jesper Louis Andersen]

On Thu, Jan 10, 2019 at 7:39 PM Thomas Bushnell, BSG 
wrote:

>
>> The server crashes - that's how we handle "any other exception", as a
> rule.
>
>
I write Erlang for a living. We don't crash a server, ever, on a failure.
Unless the failure is persistent :)

>
> I don't know what you mean by "just fork the process". First, if you're
> transpiling into Go, that's not a good strategy. Second, are you suggesting
> the transpiler would automatically rewrite the request handling loop to
> avoid the harm of crashes?
>
>
I wasn't specifically thinking about Go here. In particular, Go doesn't
have the properties I sketched out, so I'm not sure a C-to-Go compiler
would solve the problem.

Personally, I think C-to-C translation in the style of CCured is the most
likely successful path. But I still like the idea of embedding a C program
into another language, thus forming a symbiotic relationship between the
two.

-- 
J.

-- 
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] Re: Wuffs: a new, memory-safe programming language

[robert engels]

It was actually a different but related thread about converting C to Go…. the 
link I sent was https://www.doc.ic.ac.uk/~phjk/BoundsChecking.html 


> On Jan 10, 2019, at 12:20 PM, Jesper Louis Andersen 
>  wrote:
> 
> This must have been before I started reading this thread, but I know of the 
> CCured project by George Necula et.al , which is a C-to-C 
> translator:
> 
> https://web.eecs.umich.edu/~weimerw/p/p477-necula.pdf 
> 
> 
> On Thu, Jan 10, 2019 at 6:22 PM robert engels  > wrote:
> Again, what is wrong with the bounds checking/memory protection 
> library/technique for C I referred you to? Even a decrease in performance 
> will probably still be on par or better than the equivalent Go program.
> 
> Much simpler and efficient.
> 
>> On Jan 10, 2019, at 10:49 AM, Jesper Louis Andersen 
>> mailto:jesper.louis.ander...@gmail.com>> 
>> wrote:
>> 
>> On Wed, Jan 9, 2019 at 7:55 PM 'Thomas Bushnell, BSG' via golang-nuts 
>> mailto:golang-nuts@googlegroups.com>> wrote:
>> 
>> I'm curious about why transpilation would have significantly mitigated the 
>> Heartbleed bug.
>> 
>> 
>> Heartbleed is a bug which relies on two things:
>> 
>> - Failure to do proper bounds checking
>> - Allocation of a buffer which is not initialized to some zero-value, and 
>> which straddles memory it shouldn't.
>> 
>> Many programming languages are constructed such that they address both of 
>> the above problems at the semantics level, and thus they avoid the really 
>> dangerous part of the bug, which is the leak of information, downgrading the 
>> bug to a denial of service attack, or even also mitigating that part of the 
>> bug. Array access is checked against the arrays bounds, and buffer allocated 
>> memory is properly 0-initialized before use.
>> 
>> Compilation from one language to another might have the side-effect of 
>> changing the semantics of the program because of the above observations. 
>> Thus making a previously unsafe program safe. In principle we want to be 
>> clever: augment the program with new safety semantics, but without changing 
>> the meaning of the rest of the program in any way.
>> 
>> Given there is a very large body of C code out there, live, we want to take 
>> an approach like the above:
>> 
>> - A rewrite, into say Rust because it is currently popular, runs the risk of 
>> re-introducing faults in the programs which were removed through corrections 
>> over the years.
>> - We rewrite too much, where we should reuse.
>> - C is a remarkably stable programming language in that most older C code 
>> still runs in this day and age. More or less, there are some caveats, which 
>> the compilation idea ought to address. Many modern languages have a 
>> tremendous amount of bit-rot in the sense even 2-3 year old programs now 
>> utter fail to run.
>> 
>> 
>> 
>> -- 
>> 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 
>> .
> 
> 
> 
> -- 
> J.

-- 
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] Re: Wuffs: a new, memory-safe programming language

['Thomas Bushnell, BSG' via golang-nuts]

>
>
> * Even if we did this, the bug only turns into a packet of death. A packet
>> of death on this scale is of almost the same level of annoyance and chaos.
>> (Witness this week's firestorm about an email packet of death on some Cisco
>> something or other.)
>>
>>
> I did address this. If each request is bounds checked and memory isolated,
> then a failure is just an exception of some kind and we handle this as we
> would any other exception. You could also just fork the process for each
> incoming request and obtain the same semantics.
>

The server crashes - that's how we handle "any other exception", as a rule.

That's a lot of work to convert "leaking session keys" into "crashes the
server".

Especially since you turn "maybe leaks a session key on repeated tries"
into "crashes the server immediately with a single packet". Maybe the
result actually makes things worse. :)

I don't know what you mean by "just fork the process". First, if you're
transpiling into Go, that's not a good strategy. Second, are you suggesting
the transpiler would automatically rewrite the request handling loop to
avoid the harm of crashes?

Thomas
-- 

memegen delenda est

-- 
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] Re: Wuffs: a new, memory-safe programming language

[Jesper Louis Andersen]

On Thu, Jan 10, 2019 at 6:26 PM Thomas Bushnell, BSG 
wrote:

> I'm not sure the second one here is right. Heartbleed does not depend on
> unitialized memory as far as I can tell. It works to copy whatever lies
> after the incoming request buffer back to the attacker. It happens that in
> the actual openssl code the thing it's copying is a reused buffer that
> might have stuff in it (IIRC), but that's not essential to the operation of
> the bug. If it were an exactly sized buffer the same shape of problem would
> occur.
>
>
Well, if there is no way to reuse a buffer in the language, then things
will work out. More or less any functional language will do.

> You left unaddressed:
> * How would this magical translation going to occur, given the actual code
> of openssl? The obvious *human *translation is to allocate a request
> buffer, and then use the encoding/binary package to pull values. The
> attempt to read indexes greater than the size of the buffer would fault.
> But I don't see a way to take code like openssl and automatically make it
> use encoding/binary. The only clear way I can see to do it *automatically
> *is to use unsafe.Pointer, which simply turns off all the bounds checking
> you wanted.
>
>
I think the problem is a good research question. I don't think we have a
good solution at the moment. But there is a lot of value in pushing the
research forward in the area. So the answer to this question is: "I don't
know, but I do have ideas where I would start".



> * Even if we did this, the bug only turns into a packet of death. A packet
> of death on this scale is of almost the same level of annoyance and chaos.
> (Witness this week's firestorm about an email packet of death on some Cisco
> something or other.)
>
>
I did address this. If each request is bounds checked and memory isolated,
then a failure is just an exception of some kind and we handle this as we
would any other exception. You could also just fork the process for each
incoming request and obtain the same semantics.

-- 
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] Re: Wuffs: a new, memory-safe programming language

[Jesper Louis Andersen]

This must have been before I started reading this thread, but I know of the
CCured project by George Necula et.al, which is a C-to-C translator:

https://web.eecs.umich.edu/~weimerw/p/p477-necula.pdf

On Thu, Jan 10, 2019 at 6:22 PM robert engels  wrote:

> Again, what is wrong with the bounds checking/memory protection
> library/technique for C I referred you to? Even a decrease in performance
> will probably still be on par or better than the equivalent Go program.
>
> Much simpler and efficient.
>
> On Jan 10, 2019, at 10:49 AM, Jesper Louis Andersen <
> jesper.louis.ander...@gmail.com> wrote:
>
> On Wed, Jan 9, 2019 at 7:55 PM 'Thomas Bushnell, BSG' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>>
>> I'm curious about why transpilation would have significantly mitigated
>> the Heartbleed bug.
>>
>>
> Heartbleed is a bug which relies on two things:
>
> - Failure to do proper bounds checking
> - Allocation of a buffer which is not initialized to some zero-value, and
> which straddles memory it shouldn't.
>
> Many programming languages are constructed such that they address both of
> the above problems at the semantics level, and thus they avoid the really
> dangerous part of the bug, which is the leak of information, downgrading
> the bug to a denial of service attack, or even also mitigating that part of
> the bug. Array access is checked against the arrays bounds, and buffer
> allocated memory is properly 0-initialized before use.
>
> Compilation from one language to another might have the side-effect of
> changing the semantics of the program because of the above observations.
> Thus making a previously unsafe program safe. In principle we want to be
> clever: augment the program with new safety semantics, but without changing
> the meaning of the rest of the program in any way.
>
> Given there is a very large body of C code out there, live, we want to
> take an approach like the above:
>
> - A rewrite, into say Rust because it is currently popular, runs the risk
> of re-introducing faults in the programs which were removed through
> corrections over the years.
> - We rewrite too much, where we should reuse.
> - C is a remarkably stable programming language in that most older C code
> still runs in this day and age. More or less, there are some caveats, which
> the compilation idea ought to address. Many modern languages have a
> tremendous amount of bit-rot in the sense even 2-3 year old programs now
> utter fail to run.
>
>
>
> --
> 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.
>
>
>

-- 
J.

-- 
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] Re: Wuffs: a new, memory-safe programming language

['Thomas Bushnell, BSG' via golang-nuts]

On Thu, Jan 10, 2019 at 8:50 AM Jesper Louis Andersen <
jesper.louis.ander...@gmail.com> wrote:

> On Wed, Jan 9, 2019 at 7:55 PM 'Thomas Bushnell, BSG' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>>
>> I'm curious about why transpilation would have significantly mitigated
>> the Heartbleed bug.
>>
>>
> Heartbleed is a bug which relies on two things:
>
> - Failure to do proper bounds checking
> - Allocation of a buffer which is not initialized to some zero-value, and
> which straddles memory it shouldn't.
>
> Many programming languages are constructed such that they address both of
> the above problems at the semantics level, and thus they avoid the really
> dangerous part of the bug, which is the leak of information, downgrading
> the bug to a denial of service attack, or even also mitigating that part of
> the bug. Array access is checked against the arrays bounds, and buffer
> allocated memory is properly 0-initialized before use.
>

I'm not sure the second one here is right. Heartbleed does not depend on
unitialized memory as far as I can tell. It works to copy whatever lies
after the incoming request buffer back to the attacker. It happens that in
the actual openssl code the thing it's copying is a reused buffer that
might have stuff in it (IIRC), but that's not essential to the operation of
the bug. If it were an exactly sized buffer the same shape of problem would
occur.

I don't think you responded to my email very successfully.

You left unaddressed:
* How would this magical translation going to occur, given the actual code
of openssl? The obvious *human *translation is to allocate a request
buffer, and then use the encoding/binary package to pull values. The
attempt to read indexes greater than the size of the buffer would fault.
But I don't see a way to take code like openssl and automatically make it
use encoding/binary. The only clear way I can see to do it *automatically *is
to use unsafe.Pointer, which simply turns off all the bounds checking you
wanted.

* Even if we did this, the bug only turns into a packet of death. A packet
of death on this scale is of almost the same level of annoyance and chaos.
(Witness this week's firestorm about an email packet of death on some Cisco
something or other.)

Thomas

-- 

memegen delenda est

-- 
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] Re: Wuffs: a new, memory-safe programming language

[robert engels]

Again, what is wrong with the bounds checking/memory protection 
library/technique for C I referred you to? Even a decrease in performance will 
probably still be on par or better than the equivalent Go program.

Much simpler and efficient.

> On Jan 10, 2019, at 10:49 AM, Jesper Louis Andersen 
>  wrote:
> 
> On Wed, Jan 9, 2019 at 7:55 PM 'Thomas Bushnell, BSG' via golang-nuts 
> mailto:golang-nuts@googlegroups.com>> wrote:
> 
> I'm curious about why transpilation would have significantly mitigated the 
> Heartbleed bug.
> 
> 
> Heartbleed is a bug which relies on two things:
> 
> - Failure to do proper bounds checking
> - Allocation of a buffer which is not initialized to some zero-value, and 
> which straddles memory it shouldn't.
> 
> Many programming languages are constructed such that they address both of the 
> above problems at the semantics level, and thus they avoid the really 
> dangerous part of the bug, which is the leak of information, downgrading the 
> bug to a denial of service attack, or even also mitigating that part of the 
> bug. Array access is checked against the arrays bounds, and buffer allocated 
> memory is properly 0-initialized before use.
> 
> Compilation from one language to another might have the side-effect of 
> changing the semantics of the program because of the above observations. Thus 
> making a previously unsafe program safe. In principle we want to be clever: 
> augment the program with new safety semantics, but without changing the 
> meaning of the rest of the program in any way.
> 
> Given there is a very large body of C code out there, live, we want to take 
> an approach like the above:
> 
> - A rewrite, into say Rust because it is currently popular, runs the risk of 
> re-introducing faults in the programs which were removed through corrections 
> over the years.
> - We rewrite too much, where we should reuse.
> - C is a remarkably stable programming language in that most older C code 
> still runs in this day and age. More or less, there are some caveats, which 
> the compilation idea ought to address. Many modern languages have a 
> tremendous amount of bit-rot in the sense even 2-3 year old programs now 
> utter fail to run.
> 
> 
> 
> -- 
> 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 
> .

-- 
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] Re: Wuffs: a new, memory-safe programming language

[Jesper Louis Andersen]

On Wed, Jan 9, 2019 at 7:55 PM 'Thomas Bushnell, BSG' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

>
> I'm curious about why transpilation would have significantly mitigated the
> Heartbleed bug.
>
>
Heartbleed is a bug which relies on two things:

- Failure to do proper bounds checking
- Allocation of a buffer which is not initialized to some zero-value, and
which straddles memory it shouldn't.

Many programming languages are constructed such that they address both of
the above problems at the semantics level, and thus they avoid the really
dangerous part of the bug, which is the leak of information, downgrading
the bug to a denial of service attack, or even also mitigating that part of
the bug. Array access is checked against the arrays bounds, and buffer
allocated memory is properly 0-initialized before use.

Compilation from one language to another might have the side-effect of
changing the semantics of the program because of the above observations.
Thus making a previously unsafe program safe. In principle we want to be
clever: augment the program with new safety semantics, but without changing
the meaning of the rest of the program in any way.

Given there is a very large body of C code out there, live, we want to take
an approach like the above:

- A rewrite, into say Rust because it is currently popular, runs the risk
of re-introducing faults in the programs which were removed through
corrections over the years.
- We rewrite too much, where we should reuse.
- C is a remarkably stable programming language in that most older C code
still runs in this day and age. More or less, there are some caveats, which
the compilation idea ought to address. Many modern languages have a
tremendous amount of bit-rot in the sense even 2-3 year old programs now
utter fail to run.

-- 
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] Re: gccgo: go tool: no such tool "vet"

[Jan Mercl]

On Thu, Jan 10, 2019 at 5:42 PM Than McIntosh  wrote:

> meaning that it's in a malformed state. Not sure how it is being
constructed, but I think you might want to get in touch with the package
maintainer to let them know there is an issue.

Thank you. I'll try to raise an issue if I can find where to do that.

-- 

-j

-- 
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] Re: gccgo: go tool: no such tool "vet"

['Than McIntosh' via golang-nuts]

Thanks.

I downloaded what looks like your package from

http://download.opensuse.org/repositories/openSUSE:/Leap:/15.0:/Update/standard/x86_64/gcc8-go-8.2.1+r264010-lp150.2.3.x86_64.rpm
This package doesn't actually contain the "vet" command:

$ rpm -q -filesbypkg -p gcc8-go-8.2.1+r264010-lp150.2.3.x86_64.rpm | fgrep
vet
warning: gcc8-go-8.2.1+r264010-lp150.2.3.x86_64.rpm: Header V3 RSA/SHA256
Signature, key ID 3dbdc284: NOKEY
$

meaning that it's in a malformed state. Not sure how it is being
constructed, but I think you might want to get in touch with the package
maintainer to let them know there is an issue.

Cheers, Than


On Thu, Jan 10, 2019 at 11:33 AM Jan Mercl <0xj...@gmail.com> wrote:

> On Thu, Jan 10, 2019 at 5:16 PM Than McIntosh  wrote:
>
> Thanks for the help. Comments inline.
>
> > Can you send a link to the specific RPM you installed? Perhaps it is
> putting the "vet" tool in the wrong location.
>
> The package was installed using YAST (openSUSE GUI package manager).
> Package name is gcc8-go, package version is 8.2.1+r264010-lp150.2.3. I was
> not able to find the URL of the package.
>
> > Something to try:
> > % go test
> > ...
> > % strace -f -o trace.txt go test
> >
> > Then examine the trace output to locate the error ("no such tool"), walk
> back to see where it is trying to locate it, e.g. something like
>
> Here it goes:
>
> 684   rt_sigaction(SIGSTKFLT, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1],
> sa_flags=SA_RESTORER|SA_ONSTACK|SA_RESTART|SA_SIGINFO,
> sa_restorer=0x7f256b1a9160},  
> 675   stat("/usr/lib64/gcc/x86_64-suse-linux/8/vet",  
> 684   <... rt_sigaction resumed> NULL, 8) = 0
> 664   <... select resumed> )= 0 (Timeout)
> 684   rt_sigaction(SIGCHLD, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1],
> sa_flags=SA_RESTORER|SA_ONSTACK|SA_RESTART|SA_SIGINFO,
> sa_restorer=0x7f256b1a9160},  
> 675   <... stat resumed> 0xc4203a2ac8)  = -1 ENOENT (No such file or
> directory)
> 684   <... rt_sigaction resumed> NULL, 8) = 0
> 664   clock_gettime(CLOCK_MONOTONIC,  
> 684   rt_sigaction(SIGURG, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1],
> sa_flags=SA_RESTORER|SA_ONSTACK|SA_RESTART|SA_SIGINFO,
> sa_restorer=0x7f256b1a9160},  
> 664   <... clock_gettime resumed> {tv_sec=20734, tv_nsec=365171602}) = 0
> 684   <... rt_sigaction resumed> NULL, 8) = 0
> 684   rt_sigaction(SIGXCPU, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1],
> sa_flags=SA_RESTORER|SA_ONSTACK|SA_RESTART|SA_SIGINFO,
> sa_restorer=0x7f256b1a9160},  
> 675   rt_sigprocmask(SIG_BLOCK, NULL,  
> 684   <... rt_sigaction resumed> NULL, 8) = 0
> 675   <... rt_sigprocmask resumed> [], 8) = 0
> 684   rt_sigaction(SIGXFSZ, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1],
> sa_flags=SA_RESTORER|SA_ONSTACK|SA_RESTART|SA_SIGINFO,
> sa_restorer=0x7f256b1a9160},  
> 675   write(2, "go tool: no such tool \"vet\"\n", 28 
> 684   <... rt_sigaction resumed> NULL, 8) = 0
>
>
> --
>
> -j
>

-- 
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] Re: gccgo: go tool: no such tool "vet"

[Jan Mercl]

On Thu, Jan 10, 2019 at 5:16 PM Than McIntosh  wrote:

Thanks for the help. Comments inline.

> Can you send a link to the specific RPM you installed? Perhaps it is
putting the "vet" tool in the wrong location.

The package was installed using YAST (openSUSE GUI package manager).
Package name is gcc8-go, package version is 8.2.1+r264010-lp150.2.3. I was
not able to find the URL of the package.

> Something to try:
> % go test
> ...
> % strace -f -o trace.txt go test
>
> Then examine the trace output to locate the error ("no such tool"), walk
back to see where it is trying to locate it, e.g. something like

Here it goes:

684   rt_sigaction(SIGSTKFLT, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1],
sa_flags=SA_RESTORER|SA_ONSTACK|SA_RESTART|SA_SIGINFO,
sa_restorer=0x7f256b1a9160},  
675   stat("/usr/lib64/gcc/x86_64-suse-linux/8/vet",  
684   <... rt_sigaction resumed> NULL, 8) = 0
664   <... select resumed> )= 0 (Timeout)
684   rt_sigaction(SIGCHLD, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1],
sa_flags=SA_RESTORER|SA_ONSTACK|SA_RESTART|SA_SIGINFO,
sa_restorer=0x7f256b1a9160},  
675   <... stat resumed> 0xc4203a2ac8)  = -1 ENOENT (No such file or
directory)
684   <... rt_sigaction resumed> NULL, 8) = 0
664   clock_gettime(CLOCK_MONOTONIC,  
684   rt_sigaction(SIGURG, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1],
sa_flags=SA_RESTORER|SA_ONSTACK|SA_RESTART|SA_SIGINFO,
sa_restorer=0x7f256b1a9160},  
664   <... clock_gettime resumed> {tv_sec=20734, tv_nsec=365171602}) = 0
684   <... rt_sigaction resumed> NULL, 8) = 0
684   rt_sigaction(SIGXCPU, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1],
sa_flags=SA_RESTORER|SA_ONSTACK|SA_RESTART|SA_SIGINFO,
sa_restorer=0x7f256b1a9160},  
675   rt_sigprocmask(SIG_BLOCK, NULL,  
684   <... rt_sigaction resumed> NULL, 8) = 0
675   <... rt_sigprocmask resumed> [], 8) = 0
684   rt_sigaction(SIGXFSZ, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1],
sa_flags=SA_RESTORER|SA_ONSTACK|SA_RESTART|SA_SIGINFO,
sa_restorer=0x7f256b1a9160},  
675   write(2, "go tool: no such tool \"vet\"\n", 28 
684   <... rt_sigaction resumed> NULL, 8) = 0


-- 

-j

-- 
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] Re: Wuffs: a new, memory-safe programming language

[Jesper Louis Andersen]

On Wed, Jan 9, 2019 at 7:07 PM Eric S. Raymond  wrote:

>
> I agree.  The class of old C program I am interested in is, however,
> not generally limited by CPU but by network and (less commonly) disk
> stalls.  Again bear in mind that my type examples are NTP and DNS service.
> A lot of other legacy infrastructure code fits this pattern.
>
>
Can I get a -vv flag on this one?

That the PLL of NTP is network-latency sensitive, I understand. But a DNS
service, to me, should never ever touch the disk, or you are doing
something really wrong. I'm more inclined to guess that these services are
bound by memory bandwidth and latency more than CPU execution speed.

So I'm curious what insight you might have on this subject?

-- 
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] Re: gccgo: go tool: no such tool "vet"

['Than McIntosh' via golang-nuts]

Can you send a link to the specific RPM you installed? Perhaps it is
putting the "vet" tool in the wrong location.

Something to try:
% go test
...
% strace -f -o trace.txt go test

Then examine the trace output to locate the error ("no such tool"), walk
back to see where it is trying to locate it, e.g. something like

198961 stat("/mumble/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/vet",

198961 <... stat resumed> 0xc0001ace08) = -1 ENOENT (No such file or
directory)
198951 futex(0xc91120, FUTEX_WAIT_PRIVATE, 0, NULL 
198961 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
198961 write(2, "go tool: no such tool \"vet\"\n", 28) = 28

Regards, Than


On Thu, Jan 10, 2019 at 10:49 AM Jan Mercl <0xj...@gmail.com> wrote:

> On Thu, Jan 10, 2019 at 4:46 PM Jan Mercl <0xj...@gmail.com> wrote:
>
> Copy/paste error: s/go test/go-8 test/, the output is shown correctly in
> the OP. (Verified. Twice now.)
>
> --
>
> -j
>
> --
> 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.
>

-- 
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] Re: gccgo: go tool: no such tool "vet"

[Jan Mercl]

On Thu, Jan 10, 2019 at 4:46 PM Jan Mercl <0xj...@gmail.com> wrote:

Copy/paste error: s/go test/go-8 test/, the output is shown correctly in
the OP. (Verified. Twice now.)

-- 

-j

-- 
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] gccgo: go tool: no such tool "vet"

[Jan Mercl]

I've installed gccgo using the distro package manager. It seems to work
just fine except that I cannot run any tests.

 jnml@e5-1650:~/src/modernc.org/crt> go-8 version
go version go1.10.3 gccgo (SUSE Linux) 8.2.1 20180831 [gcc-8-branch
revision 264010] linux/amd64
 jnml@e5-1650:~/src/modernc.org/crt> go test
go tool: no such tool "vet"
=== jnml@e5-1650:~/src/modernc.org/crt> go-8 env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/jnml/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/jnml"
GORACE=""
GOROOT="/usr"
GOTMPDIR=""
GOTOOLDIR="/usr/lib64/gcc/x86_64-suse-linux/8"
GCCGO="/usr/bin/gccgo-8"
CC="gcc-8"
CXX="g++-8"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0
-fdebug-prefix-map=/tmp/go-build374301587=/tmp/go-build
-gno-record-gcc-switches -funwind-tables"
 jnml@e5-1650:~/src/modernc.org/crt>

The operating system here is openSUSE Leap 15.0/amd64. Gccgo was installed
using package gcc8-go, version 8.2.1+r264010-lp150.2.3.

Does anybody know hot to get 'go-8 test' working?

Thanks in advance for any and all answers.

-- 

-j

-- 
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] Re: how do I make my function always run at exit in `go test`?

[Justin Israel]

On Thu, Jan 10, 2019, 9:14 PM 김용빈  wrote:

> Hi, Justin. Thank you for the response.
>
> But it didn't work for me. that means when I terminate it with Ctrl+C, it
> doesn't print CLEANUP.
>
> I am using linux (manjaro) terminal now.
>

I am not sure why it wouldn't work. I confirmed it on an Ubuntu distro.


> 2019년 1월 10일 목요일 오후 2시 41분 24초 UTC+9, Justin Israel 님의 말:
>>
>> Oh, I see. Well also adding a signal handler for SIGINT/SIGTERM also
>> works for me:
>> https://play.golang.org/p/93VmTTgE4YB
>>
>> Justin
>>
>>
>> On Thu, Jan 10, 2019 at 6:29 PM 김용빈  wrote:
>>
>>> Sorry I didn't clarify but I mean when it is killed/terminated.
>>>
>>> 2019년 1월 10일 목요일 오후 2시 24분 35초 UTC+9, 김용빈 님의 말:
>>>
 I tried signal.Notify but it seems it doesn't work.

 Then I find this:
 https://github.com/golang/go/issues/15553#issuecomment-217162874

 So what should I do to make my function always run at exit in test?

>>> --
>>> 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...@googlegroups.com.
>>
>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> 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.
>

-- 
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 do I make my function always run at exit in `go test`?

[김용빈]

Yes, I am using TestMain. But signal.Notify is not helping me.

2019년 1월 10일 목요일 오후 2시 28분 10초 UTC+9, Justin Israel 님의 말:
>
>
>
> On Thu, Jan 10, 2019 at 6:24 PM 김용빈 > 
> wrote:
>
>> I tried signal.Notify but it seems it doesn't work.
>>
>> Then I find this: 
>> https://github.com/golang/go/issues/15553#issuecomment-217162874
>>
>> So what should I do to make my function always run at exit in test?
>>
>
> A custom TestMain() is a good way to add setup and teardown functionality 
> around the entire test process:
> https://golang.org/pkg/testing/#hdr-Main
>
> It won't help you if you kill the "go test" process though. In that case 
> you would need a SIGTERM handler via signal.Notify() 
>
>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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] Re: how do I make my function always run at exit in `go test`?

[김용빈]

Hi, Justin. Thank you for the response.

But it didn't work for me. that means when I terminate it with Ctrl+C, it 
doesn't print CLEANUP.

I am using linux (manjaro) terminal now.

2019년 1월 10일 목요일 오후 2시 41분 24초 UTC+9, Justin Israel 님의 말:
>
> Oh, I see. Well also adding a signal handler for SIGINT/SIGTERM also works 
> for me:
> https://play.golang.org/p/93VmTTgE4YB
>
> Justin
>
>
> On Thu, Jan 10, 2019 at 6:29 PM 김용빈 > 
> wrote:
>
>> Sorry I didn't clarify but I mean when it is killed/terminated.
>>
>> 2019년 1월 10일 목요일 오후 2시 24분 35초 UTC+9, 김용빈 님의 말:
>>
>>> I tried signal.Notify but it seems it doesn't work.
>>>
>>> Then I find this: 
>>> https://github.com/golang/go/issues/15553#issuecomment-217162874
>>>
>>> So what should I do to make my function always run at exit in test?
>>>
>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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.