Re: [go-nuts] [ANN] 99c

some of them are possibly easy to add. Also, IIRC, one or two are already > there, just disabled by default, so adding support of the -std flag can > make them available. > > On Sun, Oct 8, 2017, 01:37 Devon H. O'Dell <devon.od...@gmail.com> wrote: > >> Is there any desire to supp

Re: [go-nuts] [ANN] 99c

Is there any desire to support c11? On Sat, Oct 7, 2017 at 1:01 PM Jan Mercl <0xj...@gmail.com> wrote: > Command 99c is a c99 compiler targeting a virtual machine: > https://github.com/cznic/99c > > > > -- > > -j > > -- > You received this message because you are subscribed to the Google Groups >

Re: [go-nuts] [ANN] 99c

(I’d love to contribute, mostly “99c is a c99 compiler” made me wonder if c99 was a requirement. Sorry for inbox spam.) On Sat, Oct 7, 2017 at 7:45 PM Devon H. O'Dell <devon.od...@gmail.com> wrote: > More curiosity than anything, was just wondering whether patches to make > it

Re: [go-nuts] Re: Go could really use a while statement

Interesting. I've never had that experience in the past 15ish years doing POSIXish systems stuff. I've always found it the more natural expression for handling EINTR from syscalls like read/write. I've also never seen anyone seriously discourage its use in ##c on freenode over the same-ish

Re: [go-nuts] Re: [ANN] reverse proxy with ssl in less than 100 lines of code

The best way (currently) to do http->https redirects is to use HSTS: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security You may want to investigate HPKP as well. —dho On Fri, Dec 29, 2017 at 5:10 AM

[go-nuts] Experience report on coming to Go from a C perspective

Hi all, It's been some time since I really contributed much of anything to the project (sorry!), but after 8 years, I'm finally writing Go outside of the project itself (and outside of porting efforts). I was lamenting to some coworkers about the lack of a comparable feature to C's "malloc idiom"

Re: [go-nuts] Re: Experience report on coming to Go from a C perspective

> > On Thursday, February 22, 2018 at 3:03:13 PM UTC-5, Devon H. O'Dell wrote: >> >> Hi all, >> >> It's been some time since I really contributed much of anything to the >> project (sorry!), but after 8 years, I'm finally writing Go outside of >> the proj

Re: [go-nuts] Experience report on coming to Go from a C perspective

(Re-adding list in here with Bakul's okay.) 2018-02-22 12:27 GMT-08:00 Bakul Shah <ba...@bitblocks.com>: > On Thu, 22 Feb 2018 12:02:35 -0800 "Devon H. O'Dell" <devon.od...@gmail.com> > wrote: >> Hi all, >> >> It's been some time since I really

Re: [go-nuts] Experience report on coming to Go from a C perspective

gt; a channel literal.) > > On Thursday, February 22, 2018 at 5:32:40 PM UTC-5, Devon H. O'Dell wrote: >> >> 2018-02-22 14:19 GMT-08:00 Caleb Spare <ces...@gmail.com>: >> > I occasionally run into this, but in my experience it's exclusively with >> > maps: >> &

Re: [go-nuts] Experience report on coming to Go from a C perspective

l is definitely what you want since the nested type may or may not have > a valid zero value. > > On Thu, Feb 22, 2018 at 12:02 PM, Devon H. O'Dell <devon.od...@gmail.com> > wrote: >> >> Hi all, >> >> It's been some time since I really contributed much o

Re: [go-nuts] Go += Package Versioning

2018-02-20 13:02 GMT-08:00 David Anderson : > [snip] > > I also believe the tooling around vgo should encourage/make default this > behavior for binary modules (and maybe for library modules as well, though > that's less clear to me). The default behavior when writing Go programs

Re: [go-nuts] Go += Package Versioning

With regards to minimum version selection, if I depend on some feature present, this comes with two implicit dependencies: correctness and safety. My knee-jerk reaction here is that the time folks spend "telling the package manager, 'no, use at least Y,'" will largely be in response to these sorts

Re: [go-nuts] Go += Package Versioning

2018-02-20 11:39 GMT-08:00 Russ Cox <r...@golang.org>: > On Tue, Feb 20, 2018 at 2:35 PM, Devon H. O'Dell <devon.od...@gmail.com> > wrote: >> >> With regards to minimum version selection, if I depend on some feature >> present, this comes with two implicit dep

Re: [go-nuts] Re: The &(*x) idiom for copying.

CopyExplicitDeref gets a pointer to the struct in its receiver. If you have a pointer to T, then taking a pointer to the dereferenced T is a no-op: you get the pointer of the thing you just dereferenced. Any statement &*whatever will always yield the value of whatever. Copy happens on assignment,

Re: [go-nuts] Re: The &(*x) idiom for copying.

2018-03-28 9:39 GMT-07:00 Devon H. O'Dell <devon.od...@gmail.com>: > CopyExplicitDeref gets a pointer to the struct in its receiver. If you > have a pointer to T, then taking a pointer to the dereferenced T is a > no-op: you get the pointer of the thing you just dereferenced.

Re: [go-nuts] Re: Would this race condition be considered a bug?

hat is not guaranteed to halt when specified in pure Go, non-determinism in both other examples occurs due to racing on data. "Any race is a bug" is not true, and that was really the only point I was trying to make. > - Dave --dho > On Sun, Mar 18, 2018 at 1:19 AM, Dev

Re: [go-nuts] Re: Would this race condition be considered a bug?

'd really like the ability to do this in Go...) --dho [1] https://queue.acm.org/detail.cfm?id=2492433 "Nonblocking Algorithms and Scalable Multicore Programming", Samy Al Bahra, 2013 > On Sun, Mar 18, 2018 at 2:30 AM, Devon H. O'Dell <devon.od...@gmail.com> > wrote: >> >

Re: [go-nuts] Re: Would this race condition be considered a bug?

2018-03-18 10:27 GMT-07:00 Jan Mercl <0xj...@gmail.com>: > On Sun, Mar 18, 2018 at 6:21 PM Devon H. O'Dell <devon.od...@gmail.com> > wrote: > >> * There is no way to force at least 16 byte alignment of data per the > language spec, so there is no way to implement DCA

Re: [go-nuts] Re: Would this race condition be considered a bug?

uot;atomic.LoadInt32() == 0" and use atomic.StoreInt32(, 1) as your signal. Is the program still racy? Yep. Is either version of this program buggy? That just depends. It's not too hard to think of cases where this behavior might be desirable; even lossy counters are a thing. --dho 2018-03-18 0

Re: [go-nuts] Is this a valid way of implementing a mutex?

I like to think of a channel as a concurrent messaging queue. You can do all sorts of things with such constructs, including implementing mutual exclusion constructs, but that doesn't mean that one is the other. Your playground example is a bit weird and very prone to various kinds of race

Re: [go-nuts] Is this a valid way of implementing a mutex?

Op zo 17 mrt. 2019 om 15:28 schreef Louki Sumirniy : > As my simple iterative example showed, given the same sequence of events, > channels are deterministic, so this is an approach that is orthogonal but in > the same purpose - to prevent multiple concurrent agents from desynchronising >

Re: [go-nuts] Re: Interesting public commentary on Go...

Maybe this story about suggesting the murder of a colleague is supposed to be a tongue-in-cheek joke, but I want to push back heavily against it. And I’m sorry that this is devolving significantly from the original topic, but I don’t think this should slide by. Though my professional experience

Re: [go-nuts] Standard library ETag/Last-Modified conditional request logic and best practices?

Hi Mark, Whether or not your proxy is caching, you may find RFC7234[1] relevant in addressing some of your questions (as well as many you may later encounter). I think you may find section 5.2 to be of particular interest, though any proxy author should be familiar with the full text. Op di 6

Re: [go-nuts] Standard library ETag/Last-Modified conditional request logic and best practices?

Op di 6 aug. 2019 om 09:10 schreef : > > Thanks Devon! You're welcome! > So just to clarify our request flow is: > > Client > CDN > Go Reverse Proxy > Origin > > Our Go Reverse Proxy has historically been responsible for adding caching > headers (e.g. Cache-Control and Surrogate-Control) when

Re: [go-nuts] prevent alteration of binaries once distributed in the wild?

The signature would probably be computed only over data segments (or equivalent) in the executable file format, and stored outside of those sections. This approach doesn't work when the person with the binary can write to the binary (which is usually always). They can just change the signature to

Re: [go-nuts] tcp/ip stack for bare metal

Hi Steve, You might take a look at the stack implemented in https://github.com/google/gvisor. —dho On Wed, Jan 1, 2020 at 13:16 Steve Simon wrote: > hi, > > please forgive a newbie question but is there a production ready tcp/ip > stack written in go? > > i would like to run go on bare metal

Re: [go-nuts] How to use atomic_int in cgo?

Forgot to reply to the list. Oops. Sorry for the second delivery, Changkun. On Mon, Feb 15, 2021 at 12:39 changkun wrote: > Hi Ian, > > Thanks for the hint, but I have some follow-up questions: > > >> Even if there were a way to do this, an atomic variable is not a good >> synchronization