Re: [go-nuts] Re: "\x7f"

2022-03-30 Thread Rob Pike
It's odd, and the oddness comes from the strconv package. But it's not incorrect. It happens because \x7f is kinda sort not ASCII, at least as far as strconv thinks. It's trivial to "fix", though, if a fix is necessary. https://github.com/golang/go/issues/52062 -rob On Thu, Mar 31, 2022 at 4:40

Re: [go-nuts] Re: "\x7f"

2022-03-30 Thread peterGo
Unicode Standard http://www.unicode.org/versions/latest/ C0 Controls and Basic Latin Range: –007F https://unicode.org/charts/PDF/U.pdf Control character 007F  = DELETE Peter On Thursday, March 31, 2022 at 1:40:53 AM UTC-4 zachmc...@gmail.com wrote: > 9 years in the future: > > This is

Re: [go-nuts] Re: autoremove unviolated precondition checks at compile time

2022-03-30 Thread Jan Mercl
On Thu, Mar 31, 2022 at 5:27 AM Henry wrote: > // +build debug > > package mypkg > > func init() { >Debug = true > } Doing here instead const Debug = true removes (DCE) the runtime checks in other files. -- You received this message because you are subscribed to the Google Groups "golan

Re: [go-nuts] Re: "\x7f"

2022-03-30 Thread Zachary Collier
9 years in the future: This is why I cared: https://go.dev/play/p/F4GlQBQL7UC It's the only ASCII character showing as Unicode. When testing, I was alarmed thinking I had an error, but it was inaccurately represented as Unicode. The length is accurate. fmt.Printf("Byte 127 len: %d\n", len

[go-nuts] Re: autoremove unviolated precondition checks at compile time

2022-03-30 Thread Henry
You will need a build tag for that. For example: In a separate file, define the build tag ``` // +build debug package mypkg func init() { Debug = true } ``` Then, in other files, use the tag ``` package mypkg var Debug bool func DoWork() { if Debug { // perform validation } }

Re: [go-nuts] TODO comments in net/lookup_windows.go

2022-03-30 Thread Ian Lance Taylor
On Wed, Mar 30, 2022 at 12:00 PM John Dreystadt wrote: > > Being a newbie to Go, I spent some time reading some of the standard packages > and noticed a large number of TODO comments in lookup_windows.go. So I > decided to see if I could resolve these comments. I now have a working proof > of

Re: [go-nuts] HTTP/2 client creating multiple TCP Connections

2022-03-30 Thread Neeraj Vaidya
Hi All, Any comments on my post ? Regards, Neeraj > On 28 Mar 2022, at 9:17 am, envee wrote: > > I have a telecom client application which connects to an HTTP/2 server (5G > telecom application server, to be exact). > At startup, I create an HTTP/2 client using the net/http2 Transport. > It

Re: [go-nuts] Allow a TCP connection, but not a TLS connection based on an ACL

2022-03-30 Thread John
Just as a follow-up, I think the answer to this question is to fork the net/http library to add a line that handles an error type ErrIgnore without the ramifications of a temporary error. With all the good and bad that it entails (for this use case, it should be fine). This is just a niche use

[go-nuts] TODO comments in net/lookup_windows.go

2022-03-30 Thread John Dreystadt
Being a newbie to Go, I spent some time reading some of the standard packages and noticed a large number of TODO comments in lookup_windows.go. So I decided to see if I could resolve these comments. I now have a working proof of concept for lookupIP standalone and maybe I should be working to

[go-nuts] autoremove unviolated precondition checks at compile time

2022-03-30 Thread Toon Knapen
I like to check the preconditions of a function explicitly by means of code (instead of only documenting them). Of course this incurs a time-penalty. When being extremely cautious every function in a call-chain will always check its preconditions. But for a function down in the call-chain, the

[go-nuts] Re: Better replacement for strings.Title?

2022-03-30 Thread 'Kevin Chowski' via golang-nuts
Someone replied off-list and suggested using the cases.NoLower option while initializing the Caser. And it worked! Thanks! On Wednesday, March 30, 2022 at 10:15:40 AM UTC-6 Kevin Chowski wrote: > I guess "Better" is not really what I mean... maybe more accurately I need > something "closer" to

[go-nuts] Re: Better replacement for strings.Title?

2022-03-30 Thread 'Kevin Chowski' via golang-nuts
I guess "Better" is not really what I mean... maybe more accurately I need something "closer" to strings.Title. On Wednesday, March 30, 2022 at 9:59:24 AM UTC-6 Kevin Chowski wrote: > strings.Title is newly deprecated >

[go-nuts] Better replacement for strings.Title?

2022-03-30 Thread 'Kevin Chowski' via golang-nuts
strings.Title is newly deprecated