Re: [go-nuts] Strange behaviour with loops #45192, #45175

[Sebastien Rosset]

That's a great idea. Thank you! I am doing that right now.

On Wed, Apr 7, 2021 at 5:05 PM 'Keith Randall' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> If you look at CL 304251, there's one place where we added "return false".
> Put a panic just before that line (in 1.15.11 or 1.16.3), rebuild the
> compiler, then rebuild your program and see if your program triggers that
> panic.
>
>
> On Wednesday, April 7, 2021 at 2:37:53 PM UTC-7 Ian Lance Taylor wrote:
>
>> On Wed, Apr 7, 2021 at 1:47 PM sro...@gmail.com 
>> wrote:
>> >
>> > Is there a way to analyze a go program and determine whether it is
>> susceptible to bug https://github.com/golang/go/issues/45175?
>> > While the obvious solution is to upgrade to 1.15.11 or 1.16.3, it would
>> still be useful to analyze existing programs, either as a compiled binary
>> or source code.
>>
>> There is no simple way to do this. It's an unfortunate bug, but it's
>> rare, and is dependent on the exact compilation process.
>>
>> The simplest way to detect a possible problem might be to compile the
>> package with both 1.15.10 and 1.15.11 and compare the generated
>> output.
>>
>> Ian
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/28J9lE4yoHI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/f3b69bbf-3a13-4786-924c-0e874c49ffd9n%40googlegroups.com
> 
> .
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAJsvqr1cc1ye6V%3DXLPi9qjWe5aa5%3DRkW0pLRM6vTsn-W_5u83Q%40mail.gmail.com.

Re: [go-nuts] Re: [generics] default type parameter

[Sebastien Rosset]

Did you reply to the wrong thread?

On Friday, June 26, 2020 at 3:09:42 PM UTC-7, Robert Engels wrote:
>
> What about an option to disable the signal on the thread as it crosses the 
> CGo boundary? This seems better than disabling the async preemption 
> entirely?
>
> On Jun 26, 2020, at 4:45 PM, Sebastien Rosset  > wrote:
>
> 
>
> Below are the publicly exposed asn1.ObjectIdentifier fields in the 
> golang/go repo. It has fairly limited exposure,
> but I'm sure some people will argue it's too much (maybe ok in go 2.x but 
> not 1.x?).
>
>1. encoding/asn1:
>   1. My guess is this would be primarily used by SNMP applications 
>   such as 
>   https://github.com/soniah/gosnmp/search?q=asn1&unscoped_q=asn1
>   2. crypto/x509/pkix package has 4 exported fields using asn1.
>ObjectIdentifier
>3. crypto/x509 package:
>   1. ECDSA keys
>   2. Used in the x509.Certificate struct:
>
> // A Certificate represents an X.509 certificate.
>
> type Certificate struct {
>
> ...
>
> UnhandledCriticalExtensions []asn1.ObjectIdentifier
>
> UnknownExtKeyUsage []asn1.ObjectIdentifier
>
> PolicyIdentifiers []asn1.ObjectIdentifier
>
> }
>
>
> I doubt there are many applications that actually inspect these 3 fields.
>
>
>
> On Friday, June 26, 2020 at 12:53:43 PM UTC-7, Sebastien Rosset wrote:
>>
>> As an aside, the most common use of the encoding/asn1 package is most 
>> likely crypto/x509. x509. Certificate exposes public fields that use the 
>> asn1.ObjectIdentifier, so asn1 ends up being exposed in a lot of 
>> applications, such as for TLS connection management.
>>
>> On Friday, June 26, 2020 at 12:04:09 PM UTC-7, Sebastien Rosset wrote:
>>>
>>> sure, thank you. I will go through the PR review process for asn1 and 
>>> x509, maybe some good ideas will come up. 
>>> Sebastien 
>>>
>>> On Friday, June 26, 2020 at 11:51:05 AM UTC-7, Ian Lance Taylor wrote:
>>>>
>>>> On Fri, Jun 26, 2020 at 11:03 AM Sebastien Rosset  
>>>> wrote: 
>>>> > 
>>>> > @ianlancetaylor , thank you for the quick reply. The reason I was 
>>>> asking is because potentially this could have been used to fix `type 
>>>> ObjectIdentifier []int` in the `encoding/asn1` package and the 
>>>> `crypto/x509` package. Currently these package are not fully compliant 
>>>> with 
>>>> the ASN.1 specification, which means in practice some certificates cannot 
>>>> be parsed. 
>>>> > 
>>>> > 
>>>> > I am trying to fix the encoding/asn1 and crypto/x509 package by 
>>>> adding support for OID values that are greater than 2^31. There are 
>>>> multiple ways to fix the issues, and unfortunately it won't be possible to 
>>>> simply change the ObjectIdentifier type because that would break too many 
>>>> applications. If it's not possible to change the type, then most 
>>>> alternatives seem to be somewhat cumbersome. For reference the PR is 
>>>> https://github.com/golang/go/pull/39795. 
>>>>
>>>> Thanks, understood. 
>>>>
>>>> Generics don't solve all problems.  I agree that there seems to be a 
>>>> way that we could modify generics to solve this particular problem. 
>>>> But it means introducing an idea that the rest of the language has 
>>>> decided to reject: default values for arguments.  I don't think it 
>>>> would be consistent with the language to permit default values for 
>>>> type arguments when we do not permit default values for non-type 
>>>> arguments.  While we don't have to be strictly consistent here, I 
>>>> think we need a good reason to break consistency.  And in the larger 
>>>> scheme of things I don't think that making it easier to make a 
>>>> backward compatible change to one specific package, a package that is 
>>>> not all that widely used, is a good enough reason. 
>>>>
>>>> I'm not claiming to have the final word, but that is my opinion. 
>>>>
>>>> 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 golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/39bf626a-ed31-4c89-bc0f-a685927e7046o%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/golang-nuts/39bf626a-ed31-4c89-bc0f-a685927e7046o%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8a0157a1-aea2-489e-99ce-42e5c135a61do%40googlegroups.com.

Re: [go-nuts] Re: [generics] default type parameter

[Sebastien Rosset]

Below are the publicly exposed asn1.ObjectIdentifier fields in the 
golang/go repo. It has fairly limited exposure,
but I'm sure some people will argue it's too much (maybe ok in go 2.x but 
not 1.x?).

   1. encoding/asn1:
  1. My guess is this would be primarily used by SNMP applications such 
  as https://github.com/soniah/gosnmp/search?q=asn1&unscoped_q=asn1
  2. crypto/x509/pkix package has 4 exported fields using asn1.
   ObjectIdentifier
   3. crypto/x509 package:
  1. ECDSA keys
  2. Used in the x509.Certificate struct:
   
// A Certificate represents an X.509 certificate.

type Certificate struct {

...

UnhandledCriticalExtensions []asn1.ObjectIdentifier

UnknownExtKeyUsage []asn1.ObjectIdentifier

PolicyIdentifiers []asn1.ObjectIdentifier

}


I doubt there are many applications that actually inspect these 3 fields.



On Friday, June 26, 2020 at 12:53:43 PM UTC-7, Sebastien Rosset wrote:
>
> As an aside, the most common use of the encoding/asn1 package is most 
> likely crypto/x509. x509. Certificate exposes public fields that use the 
> asn1.ObjectIdentifier, so asn1 ends up being exposed in a lot of 
> applications, such as for TLS connection management.
>
> On Friday, June 26, 2020 at 12:04:09 PM UTC-7, Sebastien Rosset wrote:
>>
>> sure, thank you. I will go through the PR review process for asn1 and 
>> x509, maybe some good ideas will come up. 
>> Sebastien 
>>
>> On Friday, June 26, 2020 at 11:51:05 AM UTC-7, Ian Lance Taylor wrote:
>>>
>>> On Fri, Jun 26, 2020 at 11:03 AM Sebastien Rosset  
>>> wrote: 
>>> > 
>>> > @ianlancetaylor , thank you for the quick reply. The reason I was 
>>> asking is because potentially this could have been used to fix `type 
>>> ObjectIdentifier []int` in the `encoding/asn1` package and the 
>>> `crypto/x509` package. Currently these package are not fully compliant with 
>>> the ASN.1 specification, which means in practice some certificates cannot 
>>> be parsed. 
>>> > 
>>> > 
>>> > I am trying to fix the encoding/asn1 and crypto/x509 package by adding 
>>> support for OID values that are greater than 2^31. There are multiple ways 
>>> to fix the issues, and unfortunately it won't be possible to simply change 
>>> the ObjectIdentifier type because that would break too many applications. 
>>> If it's not possible to change the type, then most alternatives seem to be 
>>> somewhat cumbersome. For reference the PR is 
>>> https://github.com/golang/go/pull/39795. 
>>>
>>> Thanks, understood. 
>>>
>>> Generics don't solve all problems.  I agree that there seems to be a 
>>> way that we could modify generics to solve this particular problem. 
>>> But it means introducing an idea that the rest of the language has 
>>> decided to reject: default values for arguments.  I don't think it 
>>> would be consistent with the language to permit default values for 
>>> type arguments when we do not permit default values for non-type 
>>> arguments.  While we don't have to be strictly consistent here, I 
>>> think we need a good reason to break consistency.  And in the larger 
>>> scheme of things I don't think that making it easier to make a 
>>> backward compatible change to one specific package, a package that is 
>>> not all that widely used, is a good enough reason. 
>>>
>>> I'm not claiming to have the final word, but that is my opinion. 
>>>
>>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/39bf626a-ed31-4c89-bc0f-a685927e7046o%40googlegroups.com.

Re: [go-nuts] Re: [generics] default type parameter

[Sebastien Rosset]

As an aside, the most common use of the encoding/asn1 package is most 
likely crypto/x509. x509. Certificate exposes public fields that use the 
asn1.ObjectIdentifier, so asn1 ends up being exposed in a lot of 
applications, such as for TLS connection management.

On Friday, June 26, 2020 at 12:04:09 PM UTC-7, Sebastien Rosset wrote:
>
> sure, thank you. I will go through the PR review process for asn1 and 
> x509, maybe some good ideas will come up. 
> Sebastien 
>
> On Friday, June 26, 2020 at 11:51:05 AM UTC-7, Ian Lance Taylor wrote:
>>
>> On Fri, Jun 26, 2020 at 11:03 AM Sebastien Rosset  
>> wrote: 
>> > 
>> > @ianlancetaylor , thank you for the quick reply. The reason I was 
>> asking is because potentially this could have been used to fix `type 
>> ObjectIdentifier []int` in the `encoding/asn1` package and the 
>> `crypto/x509` package. Currently these package are not fully compliant with 
>> the ASN.1 specification, which means in practice some certificates cannot 
>> be parsed. 
>> > 
>> > 
>> > I am trying to fix the encoding/asn1 and crypto/x509 package by adding 
>> support for OID values that are greater than 2^31. There are multiple ways 
>> to fix the issues, and unfortunately it won't be possible to simply change 
>> the ObjectIdentifier type because that would break too many applications. 
>> If it's not possible to change the type, then most alternatives seem to be 
>> somewhat cumbersome. For reference the PR is 
>> https://github.com/golang/go/pull/39795. 
>>
>> Thanks, understood. 
>>
>> Generics don't solve all problems.  I agree that there seems to be a 
>> way that we could modify generics to solve this particular problem. 
>> But it means introducing an idea that the rest of the language has 
>> decided to reject: default values for arguments.  I don't think it 
>> would be consistent with the language to permit default values for 
>> type arguments when we do not permit default values for non-type 
>> arguments.  While we don't have to be strictly consistent here, I 
>> think we need a good reason to break consistency.  And in the larger 
>> scheme of things I don't think that making it easier to make a 
>> backward compatible change to one specific package, a package that is 
>> not all that widely used, is a good enough reason. 
>>
>> I'm not claiming to have the final word, but that is my opinion. 
>>
>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a34c936f-b68e-4f63-aad2-47c0869f71e0o%40googlegroups.com.

Re: [go-nuts] Re: [generics] default type parameter

[Sebastien Rosset]

sure, thank you. I will go through the PR review process for asn1 and x509, 
maybe some good ideas will come up. 
Sebastien 

On Friday, June 26, 2020 at 11:51:05 AM UTC-7, Ian Lance Taylor wrote:
>
> On Fri, Jun 26, 2020 at 11:03 AM Sebastien Rosset  > wrote: 
> > 
> > @ianlancetaylor , thank you for the quick reply. The reason I was asking 
> is because potentially this could have been used to fix `type 
> ObjectIdentifier []int` in the `encoding/asn1` package and the 
> `crypto/x509` package. Currently these package are not fully compliant with 
> the ASN.1 specification, which means in practice some certificates cannot 
> be parsed. 
> > 
> > 
> > I am trying to fix the encoding/asn1 and crypto/x509 package by adding 
> support for OID values that are greater than 2^31. There are multiple ways 
> to fix the issues, and unfortunately it won't be possible to simply change 
> the ObjectIdentifier type because that would break too many applications. 
> If it's not possible to change the type, then most alternatives seem to be 
> somewhat cumbersome. For reference the PR is 
> https://github.com/golang/go/pull/39795. 
>
> Thanks, understood. 
>
> Generics don't solve all problems.  I agree that there seems to be a 
> way that we could modify generics to solve this particular problem. 
> But it means introducing an idea that the rest of the language has 
> decided to reject: default values for arguments.  I don't think it 
> would be consistent with the language to permit default values for 
> type arguments when we do not permit default values for non-type 
> arguments.  While we don't have to be strictly consistent here, I 
> think we need a good reason to break consistency.  And in the larger 
> scheme of things I don't think that making it easier to make a 
> backward compatible change to one specific package, a package that is 
> not all that widely used, is a good enough reason. 
>
> I'm not claiming to have the final word, but that is my opinion. 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/551cacb5-8bef-439d-bb17-2fc8d6b8c357o%40googlegroups.com.

[go-nuts] Re: [generics] default type parameter

[Sebastien Rosset]

@ianlancetaylor , thank you for the quick reply. The reason I was asking is 
because potentially this could have been used to fix `type ObjectIdentifier 
[]int` in the `encoding/asn1` package and the `crypto/x509` package. 
Currently these package are not fully compliant with the ASN.1 
specification, which means in practice some certificates cannot be parsed.

I am trying to fix the encoding/asn1 and crypto/x509 package by adding support 
for OID values that are greater than 2^31. There are multiple ways to fix 
the issues, and unfortunately it won't be possible to simply change the 
ObjectIdentifier type because that would break too many applications. If 
it's not possible to change the type, then most alternatives seem to be 
somewhat cumbersome. For reference the PR is 
https://github.com/golang/go/pull/39795.


Sebastien



On Friday, June 26, 2020 at 10:55:39 AM UTC-7, Sebastien Rosset wrote:
>
> First apologies for initially bringing up the topic as a github issue 
> rather than golang-nuts. I am copy-pasting my question here with 
> @ianlancetaylor 
> response.
>
>
> A default type value can be specified in C++ templates. I was asking if a 
> similar construct been considered for go generic type parameters. 
> Potentially this would make it possible to retrofit existing types without 
> breaking existing code.
>
> For example, consider the existing asn1.ObjectIdentifier type which is a 
> []int. One problem with this type is it's not compliant with the ASN.1 
> specification, which states each sub-oid may be an INTEGER of arbitrary 
> length (e.g. *big.Int). Potentially ObjectIdentifier could be modified to 
> accept a generic parameter, but that would break a lot of existing code. If 
> there was a way to specify int is the default parameter value, maybe that 
> would make it possible to retrofit existing code.
>
> type SignedInteger interface {
>   type int, int32, int64, *big.Int
> }type ObjectIdentifier(type T SignedInteger) []T// type ObjectIdentifier(type 
> T SignedInteger=int) []T  // `int` would be the default instantiation type.
> // New code with generic awareness would compile in go2.var oid1 
> ObjectIdentifier(int) = ObjectIdentifier(int){1, 2, 3}
> // But existing code would fail to compile:var oid1 ObjectIdentifier = 
> ObjectIdentifier{1, 2, 3}
>
> Just to be clear, the above asn1.ObjectIdentifier is just an example. I'm 
> not saying using generics is the only way or the best way to solve the 
> ASN.1 compliance issue.
>
>
>
> > @sebastien-rosset We have not considered default types for generic type 
> parameters. The language does not have default values for function 
> arguments, and it's not obvious why generics would be different. In my 
> opinion, the ability to make existing code compatible with a package that 
> adds generics is not a priority. If a package is rewritten to use generics, 
> it's OK to require existing code to change, or to simply introduce the 
> generic code using new names.
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b29e342c-bcd1-4fc3-baf9-431d96120674o%40googlegroups.com.

[go-nuts] [generics] default type parameter

[Sebastien Rosset]

First apologies for initially bringing up the topic as a github issue 
rather than golang-nuts. I am copy-pasting my question here with 
@ianlancetaylor 
response.


A default type value can be specified in C++ templates. I was asking if a 
similar construct been considered for go generic type parameters. 
Potentially this would make it possible to retrofit existing types without 
breaking existing code.

For example, consider the existing asn1.ObjectIdentifier type which is a 
[]int. One problem with this type is it's not compliant with the ASN.1 
specification, which states each sub-oid may be an INTEGER of arbitrary 
length (e.g. *big.Int). Potentially ObjectIdentifier could be modified to 
accept a generic parameter, but that would break a lot of existing code. If 
there was a way to specify int is the default parameter value, maybe that 
would make it possible to retrofit existing code.

type SignedInteger interface {
type int, int32, int64, *big.Int
}type ObjectIdentifier(type T SignedInteger) []T// type ObjectIdentifier(type T 
SignedInteger=int) []T  // `int` would be the default instantiation type.
// New code with generic awareness would compile in go2.var oid1 
ObjectIdentifier(int) = ObjectIdentifier(int){1, 2, 3}
// But existing code would fail to compile:var oid1 ObjectIdentifier = 
ObjectIdentifier{1, 2, 3}

Just to be clear, the above asn1.ObjectIdentifier is just an example. I'm 
not saying using generics is the only way or the best way to solve the 
ASN.1 compliance issue.



> @sebastien-rosset We have not considered default types for generic type 
parameters. The language does not have default values for function 
arguments, and it's not obvious why generics would be different. In my 
opinion, the ability to make existing code compatible with a package that 
adds generics is not a priority. If a package is rewritten to use generics, 
it's OK to require existing code to change, or to simply introduce the 
generic code using new names.

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/cfe946b9-2ce9-4b7a-acf7-0b45e3a4bf32o%40googlegroups.com.