Re: [go-nuts] Computing a hash over a uintptr ?

[Ian Lance Taylor]

On Thu, Jun 3, 2021 at 9:13 PM Robert Engels  wrote:
>
> Doesn’t that depend on what the uintptr refers to? Eg if it was allocated off 
> heap to begin with then it should be stable  and computing a hash on it is 
> valid.

That is true in current implementations, but Go, the language, does
not guarantee that pointers will never move.

Ian


> On Jun 3, 2021, at 9:42 AM, 'Axel Wagner' via golang-nuts 
>  wrote:
>
> 
> On Thu, Jun 3, 2021 at 4:19 PM christoph...@gmail.com 
>  wrote:
>>
>> The documentation doesn’t specify that we can cast an uintptr into a uint64.
>
>
> Both are integer types, so they can be converted. You might be worried about 
> their respective sizes and you are correct that the spec does not guarantee 
> that a uintptr is at most 64 bit. However, at least for any implementation I 
> know on any supported architecture, that's the case. If you *really* want to 
> make sure, you can do something like this:
>
> func toBytes(v uintptr) []byte {
> var out []byte
> mask := ^uintptr(0)
> for mask != 0 {
> out = append(out, uint8(v))
> v >>= 8
> mask >>= 8
> }
> return out
> }
>
> But really, you can just trust that a uintptr fits into a uint64. Or, if you 
> want to future-proof, assume it's uint64, but guard by build tags to known 
> architectures (so it at least fails to compile if that assumption ever 
> changes).
>
>> To give some context, the application is for a cache with the hash key 
>> computed over a pointer to a heap allocated struct. I need to store the 
>> pointer in the cache entry to test for matching, but this would prevent the 
>> struct to be garbage collected. Storing the pointer as an uintptr would do 
>> the trick.
>
>
> This is problematic. The address of a value can change, so the uintptr would 
> change as well. So there is no guarantee that your hash stays the same, in 
> subsequent calls.
> Today, that usually doesn't happen, but there is no guarantee it stays that 
> way. If you are willing to assume that it doesn't happen, you should 
> definitely also be willing to assume a uintptr fits into a uint64
>
>>
>>
>> --
>> 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/7983a13f-5bf6-4299-a598-1d023ec9a9e9n%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/CAEkBMfFsZNHLXcONF9C6Nadr6muUP_kgOJwM3QUXSZ0KxPnfYQ%40mail.gmail.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/35E8DBC1-E067-4717-BFFF-18732D77B987%40ix.netcom.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/CAOyqgcWY%3DS%3DtriGaYtNK_4v4Nw5AAZBCFOY2hKyTHQ9guaaiTw%40mail.gmail.com.

Re: [go-nuts] Computing a hash over a uintptr ?

[Robert Engels]

Doesn’t that depend on what the uintptr refers to? Eg if it was allocated off 
heap to begin with then it should be stable  and computing a hash on it is 
valid. 

> On Jun 3, 2021, at 9:42 AM, 'Axel Wagner' via golang-nuts 
>  wrote:
> 
> 
>> On Thu, Jun 3, 2021 at 4:19 PM christoph...@gmail.com 
>>  wrote:
> 
>> The documentation doesn’t specify that we can cast an uintptr into a uint64.
> 
> Both are integer types, so they can be converted. You might be worried about 
> their respective sizes and you are correct that the spec does not guarantee 
> that a uintptr is at most 64 bit. However, at least for any implementation I 
> know on any supported architecture, that's the case. If you *really* want to 
> make sure, you can do something like this:
> 
> func toBytes(v uintptr) []byte {
> var out []byte
> mask := ^uintptr(0)
> for mask != 0 {
> out = append(out, uint8(v))
> v >>= 8
> mask >>= 8
> }
> return out
> }
>  
> But really, you can just trust that a uintptr fits into a uint64. Or, if you 
> want to future-proof, assume it's uint64, but guard by build tags to known 
> architectures (so it at least fails to compile if that assumption ever 
> changes).
> 
>> To give some context, the application is for a cache with the hash key 
>> computed over a pointer to a heap allocated struct. I need to store the 
>> pointer in the cache entry to test for matching, but this would prevent the 
>> struct to be garbage collected. Storing the pointer as an uintptr would do 
>> the trick.
> 
> This is problematic. The address of a value can change, so the uintptr would 
> change as well. So there is no guarantee that your hash stays the same, in 
> subsequent calls.
> Today, that usually doesn't happen, but there is no guarantee it stays that 
> way. If you are willing to assume that it doesn't happen, you should 
> definitely also be willing to assume a uintptr fits into a uint64
>  
>> 
>> -- 
>> 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/7983a13f-5bf6-4299-a598-1d023ec9a9e9n%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/CAEkBMfFsZNHLXcONF9C6Nadr6muUP_kgOJwM3QUXSZ0KxPnfYQ%40mail.gmail.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/35E8DBC1-E067-4717-BFFF-18732D77B987%40ix.netcom.com.

[go-nuts] Go 1.16.5 and Go 1.15.13 are released

[David Chase]

Hello gophers,

We have just released Go versions 1.16.5 and 1.15.13, minor point releases.

These minor releases include security fixes according to the new security
policy (#44918 ).

The SetString and UnmarshalText methods of math/big.Rat
 may cause a panic or an unrecoverable
fatal error if passed inputs with very large exponents.
This is issue #45910  and
CVE-2021-33198.

Thanks to the OSS-Fuzz project for discovering this issue and to Emmanuel
Odeke for reporting it.

ReverseProxy in net/http/httputil  could
be made to forward certain hop-by-hop headers, including Connection. In
case the target of the ReverseProxy was itself a reverse proxy, this would
let an attacker drop arbitrary headers, including those set by the
ReverseProxy.Director.
This is issue #46313  and
CVE-2021-33197.

Thanks to Mattias Grenfeldt (https://grenfeldt.dev) and Asta Olofsson for
reporting this issue.

The LookupCNAME, LookupSRV, LookupMX, LookupNS, and LookupAddr functions in
net , and their respective methods on the Resolver
 type may return arbitrary values
retrieved from DNS which do not follow the established RFC 1035
rules for domain names. If
these names are used without further sanitization, for instance unsafely
included in HTML, they may allow for injection of unexpected content. Note
that LookupTXT may still return arbitrary values that could require
sanitization before further use.
This is issue #46241  and
CVE-2021-33195.

Thanks to Philipp Jeitner and Haya Shulman from Fraunhofer SIT for
reporting this issue.

The NewReader and OpenReader functions in archive/zip
 can cause a panic or an unrecoverable
fatal error when reading an archive that claims to contain a large number
of files, regardless of its actual size.
This is issue #46242  and
CVE-2021-33196.

Thanks to the OSS-Fuzz project for discovering this issue and to Emmanuel
Odeke for reporting it.

View the release notes for more information:
https://golang.org/doc/devel/release.html#go1.16.minor

You can download binary and source distributions from the Go web site:
https://golang.org/dl/

To compile from source using a Git clone, update to the release with
"git checkout go1.16.5" and build as usual.

Thanks to everyone who contributed to the releases.

Cheers,
David and Carlos for 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CABE21dZg1z%3D9HP_5rK2GvjA9FzXEZFfyPnZi-FG2qHgj-Zsn0A%40mail.gmail.com.

[go-nuts] Re: embedding files in tests

[Manlio Perillo]

Actually, if a file is embedded in the main package, go list will report it 
in the EmbedFiles field.
If a file is embedded in a test, the -test flag is required because the 
test binary is required.

Regards
Manlio

On Wednesday, June 2, 2021 at 5:56:42 PM UTC+2 peterGo wrote:

> "it seems a bug ... it should" Why?
>
> Why perform unnecessary disk directory I/O for a build to discover which 
> files satisfy the patterns for a test? Go tools are expected to be fast.
>
> Peter
>
> On Wednesday, June 2, 2021 at 5:49:41 AM UTC-4 manlio@gmail.com wrote:
>
>> Here is an example:  https://play.golang.org/p/ElnTtxHnF5I
>>
>> The output of `go list -json ./pkg` only reports `TestEmbedPatterns`.
>> The output of `go list -json -test ./pkg` reports TestEmbedFiles for the 
>> pkg package (it seems a bug, since it should also be reported without the 
>> -test flag).
>> The TestEmbedFiles is also present in the generated `pkg.test` package 
>> and the pkg [pkg.test] package.
>>
>> Thanks
>> Manlio
>>
>>
>> On Wednesday, June 2, 2021 at 4:23:32 AM UTC+2 nikolay.d...@gmail.com 
>> wrote:
>>
>>> I think the question is about `go:embed` directive in `_test.go` files 
>>> will be included in builds of non-test packages, right?
>>>
>>> Don't know for sure, but I think:
>>> - a) if you have `mypkg_test.go` and in it `package mypkg_test` then 
>>> `go:embed` will not get to your non test build as the package is different
>>> - b) if you have `mypkg_test.go` and in it `pakcage mypkg` then... less 
>>> clear. As above referenced in original docs `_test.go` will be excluded 
>>> from non test build regardless of package.
>>>
>>> My personal take, is to go:embed only in case a).
>>>
>>> Cheers,
>>> On Wednesday, June 2, 2021 at 8:09:20 AM UTC+8 peterGo wrote:
>>>
 On Tuesday, June 1, 2021 at 9:17:11 AM UTC-4 manlio@gmail.com 
 wrote:

> When a file is embedded in a test file, will the file be embedded only 
> in the test binary?
> The documentation says nothing about this case, but the data from go 
> list seems to confirm that the file is only embedded in the test binary.
>
> Thanks
> Manlio
>

 The documentation seems clear to me.

 Package testing
 https://golang.org/pkg/testing/

 To write a new test suite, create a file whose name ends _test.go that 
 contains the TestXxx functions as described here. Put the file in the same 
 package as the one being tested. The file will be excluded from regular 
 package builds but will be included when the "go test" command is run. 

 Peter

>>>

-- 
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/6894ae4e-7a2b-411c-a86a-d1401b149ff3n%40googlegroups.com.

[go-nuts] Fuzz testing is now beta ready!

[Katie Hockman]

Hi gophers!

Native fuzzing is ready for beta testing in its development branch,
dev.fuzz! Check out https://blog.golang.org/fuzz-beta for more details.

Fuzzing is a type of automated testing which continuously manipulates
inputs to a program to find issues such as panics or bugs. These
semi-random data mutations can discover new code coverage that existing
unit tests may miss, and uncover edge case bugs which would otherwise go
unnoticed. Since fuzzing can reach these edge cases, fuzz testing is
particularly valuable for finding security exploits and vulnerabilities.

See golang.org/s/draft-fuzzing-design for more details about this feature.

Best,
Katie on behalf of 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALvTBvd-MJY2PAoXn7jsXvZW-%2BbPr1MTRyzCmDJvYZ2wi2VRAg%40mail.gmail.com.

[go-nuts] Re: Ignore /vendor by default in polyglot repository

[Manlio Perillo]

On Thursday, June 3, 2021 at 6:04:21 PM UTC+2 Jacob Vosmaer wrote:

> Hi,
>
> In our organization we have a main code repository that contains 
> components written in different programming languages. One of these 
> components is written in Go. I would like to be able to have a single 
> go.mod file for the whole repository, in the root directory. This doesn't 
> work smoothly as of Go 1.16 because we have a /vendor directory in this 
> repository, which has nothing to do with our Go code.
>
> Because /vendor exists, commands like 'go build' and 'go test' complain 
> about the vendor directory being out of sync. I am aware that there are 
> workarounds with command line flags (such as -mod=mod) and that one can 
> avoid typing these over and over by setting GOFLAGS.
>
> However, this makes for a poor developer experience because every new 
> contributor has to run in this problem locally and then modify their local 
> development environment. It would be much more ergonomic if there was a way 
> to tell the go toolchain to ignore /vendor based on a file in the 
> repository. Because then everybody who clones the repository and tries to 
> run 'go test' or 'go build' gets the correct default behavior.
>
> I could have sworn I found an issue about this a while ago but I can't 
> find it anymore, and I also don't see this topic in the golang-nuts 
> archive. 
>
> Is there another workaround I'm overlooking? Should I open an issue for 
> this?
>
>
One possible solution is to have a GOENV file in the root directory of a 
repository.
This similar to git where, by default, the config file is first read from  
.git/config, then from ~/.gitconfig and finally from /etc/gitconfig.

The problem is how to handle a write to GOENV; probably the local env file 
should be ignored.

Regards
Manlio 

-- 
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/f90be255-d94e-49d9-ad26-6477bfcc60b2n%40googlegroups.com.

Re: [go-nuts] Golang calling Windows DLL function with more than 18 arguments

[Ian Lance Taylor]

On Thu, Jun 3, 2021 at 9:20 AM George Vanev  wrote:
>
> The function is from a Chinese  SDK and I don't have the source code:
> int HDAPI Hd_Rt_SendRealTimeText(int nSendType, void *pStrParams, int 
> nRealTimeAreaIndex, int nMaxPageCount, int nColor, int nGray, int nX, int nY, 
> int nWidth, int nHeight,
> void *pText, int nTextColor, int nBackGroupColor, int nStyle, void 
> *pFontName, int nFontHeight, int nShowEffect, int nShowSpeed,int nStayTime, 
> int nLiveTime,
> int bSaveToFlash, void *pDeviceGUID);

OK, well, that is fairly dreadful.

As far as I know the only workaround is to use cgo.

Please open an issue to ask for Syscall21 and Syscall24.  Thanks.

Ian


> On Thursday, June 3, 2021 at 7:10:05 PM UTC+3 Ian Lance Taylor wrote:
>>
>> On Thu, Jun 3, 2021 at 8:42 AM George Vanev  wrote:
>> >
>> > I have an external 64 bit .DLL and I have to pass 22 arguments to one of 
>> > the functions. Go (go1.16.4 windows/amd64) allows up to 18 arguments. Is 
>> > there any workaround?
>> > I've tried to make Syscall22 in dll_windows.go, link it with 
>> > syscall_Syscall22 in src/runtime/syscall_windows.go and rebuilt: go 
>> > install -a runtime. But it give me errors when trying to call the function
>>
>> There is currently no support for more than 18 arguments.
>>
>> What is the function you are trying to call?
>>
>> 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/afbc4719-6a81-4e3d-a888-8789b9b46c40n%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/CAOyqgcV%3DaFcHremESsqx-FCWUSH6HK8k2JdSAT_pvgH2mdjqdQ%40mail.gmail.com.

Re: [go-nuts] Golang calling Windows DLL function with more than 18 arguments

[George Vanev]

The function is from a Chinese  SDK and I don't have the source code:
int HDAPI Hd_Rt_SendRealTimeText(int nSendType, void *pStrParams, int 
nRealTimeAreaIndex, int nMaxPageCount, int nColor, int nGray, int nX, int 
nY, int nWidth, int nHeight, 
void *pText, int nTextColor, int nBackGroupColor, int nStyle, void 
*pFontName, int nFontHeight, int nShowEffect, int nShowSpeed,int nStayTime, 
int nLiveTime, 
int bSaveToFlash, void *pDeviceGUID); 

On Thursday, June 3, 2021 at 7:10:05 PM UTC+3 Ian Lance Taylor wrote:

> On Thu, Jun 3, 2021 at 8:42 AM George Vanev  wrote:
> >
> > I have an external 64 bit .DLL and I have to pass 22 arguments to one of 
> the functions. Go (go1.16.4 windows/amd64) allows up to 18 arguments. Is 
> there any workaround?
> > I've tried to make Syscall22 in dll_windows.go, link it with 
> syscall_Syscall22 in src/runtime/syscall_windows.go and rebuilt: go install 
> -a runtime. But it give me errors when trying to call the function
>
> There is currently no support for more than 18 arguments.
>
> What is the function you are trying to call?
>
> 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/afbc4719-6a81-4e3d-a888-8789b9b46c40n%40googlegroups.com.

Re: [go-nuts] Golang calling Windows DLL function with more than 18 arguments

[Ian Lance Taylor]

On Thu, Jun 3, 2021 at 8:42 AM George Vanev  wrote:
>
> I have an external 64 bit .DLL and I have to pass 22 arguments to one of the 
> functions. Go (go1.16.4 windows/amd64) allows up to 18 arguments. Is there 
> any workaround?
> I've tried to make Syscall22 in dll_windows.go, link it with 
> syscall_Syscall22 in src/runtime/syscall_windows.go and rebuilt: go install 
> -a runtime. But it give me errors when trying to call the function

There is currently no support for more than 18 arguments.

What is the function you are trying to call?

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/CAOyqgcWhqbZeM4N2SekbOXEk1bCC%3D_2HDV7ozu_OsTGAjVVcLA%40mail.gmail.com.

[go-nuts] Ignore /vendor by default in polyglot repository

['Jacob Vosmaer' via golang-nuts]

Hi,

In our organization we have a main code repository that contains components 
written in different programming languages. One of these components is 
written in Go. I would like to be able to have a single go.mod file for the 
whole repository, in the root directory. This doesn't work smoothly as of 
Go 1.16 because we have a /vendor directory in this repository, which has 
nothing to do with our Go code.

Because /vendor exists, commands like 'go build' and 'go test' complain 
about the vendor directory being out of sync. I am aware that there are 
workarounds with command line flags (such as -mod=mod) and that one can 
avoid typing these over and over by setting GOFLAGS.

However, this makes for a poor developer experience because every new 
contributor has to run in this problem locally and then modify their local 
development environment. It would be much more ergonomic if there was a way 
to tell the go toolchain to ignore /vendor based on a file in the 
repository. Because then everybody who clones the repository and tries to 
run 'go test' or 'go build' gets the correct default behavior.

I could have sworn I found an issue about this a while ago but I can't find 
it anymore, and I also don't see this topic in the golang-nuts archive. 

Is there another workaround I'm overlooking? Should I open an issue for 
this?

Thanks,

Jacob Vosmaer

-- 
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/523e6ad5-d325-4766-8232-de13a3a6881an%40googlegroups.com.

[go-nuts] Golang calling Windows DLL function with more than 18 arguments

[George Vanev]

I have an external 64 bit .DLL and I have to pass 22 arguments to one of 
the functions. Go (go1.16.4 windows/amd64) allows up to 18 arguments. Is 
there any workaround?
I've tried to make Syscall22 in dll_windows.go, link it with 
syscall_Syscall22 in src/runtime/syscall_windows.go and rebuilt: go install 
-a runtime. But it give me errors when trying to call the function

-- 
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/918a1099-14f2-4f08-a71a-81c48de7e783n%40googlegroups.com.

Re: [go-nuts] Re: Is this a bug ?

[tapi...@gmail.com]

Another runnable example:

package main

const x = 8
var y = 8

var a byte = 1 << x / 2
var b byte = 1 << y / 2

func main() {
  println(a) // 128
  println(b) // 0
}

On Thursday, June 3, 2021 at 10:42:32 AM UTC-4 peterGo wrote:

> Jan,
>
> The untyped constant 1 assumes the type of x, which is float64. With 
> explicit types:
>
> package main
>
> import "fmt"
>
> func main() {
> var a int = 0
> // invalid operation: float64(1) << a (shift of type float64)
> var x float64 = float64(1) << a
> fmt.Println(x)
> }
>
> https://play.golang.org/p/jQ4k5qrxcTu
>
> Peter
>
> On Thursday, June 3, 2021 at 5:52:23 AM UTC-4 Jan Mercl wrote:
>
>> On Thu, Jun 3, 2021 at 11:21 AM Brian Candler  wrote:
>> >
>> > Weird. It simplifies to this: https://play.golang.org/p/OsOhRMC6kBu
>>
>> I think this case is WAI.
>>
>> From https://golang.org/ref/spec#Operators
>>
>> " If the left operand of a non-constant shift expression is an untyped
>> constant, it is first implicitly converted to the type it would assume
>> if the shift expression were replaced by its left operand alone."
>>
>> The OP case is strange in that the constness of the RHS operator
>> somehow changes the interpretation of the above quotation
>> specification, but I cannot find that it should.
>>
>

-- 
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/cc7f17ce-25cf-4717-b063-98e4e18aae3fn%40googlegroups.com.

Re: [go-nuts] Re: Is this a bug ?

[peterGo]

Jan,

The untyped constant 1 assumes the type of x, which is float64. With 
explicit types:

package main

import "fmt"

func main() {
var a int = 0
// invalid operation: float64(1) << a (shift of type float64)
var x float64 = float64(1) << a
fmt.Println(x)
}

https://play.golang.org/p/jQ4k5qrxcTu

Peter

On Thursday, June 3, 2021 at 5:52:23 AM UTC-4 Jan Mercl wrote:

> On Thu, Jun 3, 2021 at 11:21 AM Brian Candler  wrote:
> >
> > Weird. It simplifies to this: https://play.golang.org/p/OsOhRMC6kBu
>
> I think this case is WAI.
>
> From https://golang.org/ref/spec#Operators
>
> " If the left operand of a non-constant shift expression is an untyped
> constant, it is first implicitly converted to the type it would assume
> if the shift expression were replaced by its left operand alone."
>
> The OP case is strange in that the constness of the RHS operator
> somehow changes the interpretation of the above quotation
> specification, but I cannot find that it should.
>

-- 
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/b8061835-44fb-4bcf-9017-d2c9a6b58608n%40googlegroups.com.

Re: [go-nuts] Computing a hash over a uintptr ?

['Axel Wagner' via golang-nuts]

On Thu, Jun 3, 2021 at 4:19 PM christoph...@gmail.com <
christophe.mees...@gmail.com> wrote:

> The documentation doesn’t specify that we can cast an uintptr into a
> uint64.
>

Both are integer types, so they can be converted. You might be worried
about their respective sizes and you are correct that the spec does not
guarantee that a uintptr is at most 64 bit. However, at least for any
implementation I know on any supported architecture, that's the case. If
you *really* want to make sure, you can do something like this:

func toBytes(v uintptr) []byte {
var out []byte
mask := ^uintptr(0)
for mask != 0 {
out = append(out, uint8(v))
v >>= 8
mask >>= 8
}
return out
}

But really, you can just trust that a uintptr fits into a uint64. Or, if
you want to future-proof, assume it's uint64, but guard by build tags to
known architectures (so it at least fails to compile if that assumption
ever changes).

To give some context, the application is for a cache with the hash key
> computed over a pointer to a heap allocated struct. I need to store the
> pointer in the cache entry to test for matching, but this would prevent the
> struct to be garbage collected. Storing the pointer as an uintptr would do
> the trick.
>

This is problematic. The address of a value can change, so the uintptr
would change as well. So there is no guarantee that your hash stays the
same, in subsequent calls.
Today, that usually doesn't happen, but there is no guarantee it stays that
way. If you are willing to assume that it doesn't happen, you should
definitely also be willing to assume a uintptr fits into a uint64


>
> --
> 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/7983a13f-5bf6-4299-a598-1d023ec9a9e9n%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/CAEkBMfFsZNHLXcONF9C6Nadr6muUP_kgOJwM3QUXSZ0KxPnfYQ%40mail.gmail.com.

[go-nuts] Computing a hash over a uintptr ?

[christoph...@gmail.com]

The documentation specifies that a pointer can be cast into a uintptr 
integer. I assume that the uintptr is ignored by the garbage collector. 

I would like to compute a hash over the uintptr. How do I achieve that ? 

The documentation doesn’t specify that we can cast an uintptr into a 
uint64. The byte size may not match. What would be the idiomatic way to 
compute a hash over a uintpr ? Is it valid to do that ? 

To give some context, the application is for a cache with the hash key 
computed over a pointer to a heap allocated struct. I need to store the 
pointer in the cache entry to test for matching, but this would prevent the 
struct to be garbage collected. Storing the pointer as an uintptr would do 
the trick. 

-- 
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/7983a13f-5bf6-4299-a598-1d023ec9a9e9n%40googlegroups.com.

Re: [go-nuts] Re: Is this a bug ?

['Axel Wagner' via golang-nuts]

It is not a bug. The spec says
:

If the left operand of a *constant *shift expression is an untyped
> constant, the result is an integer constant; otherwise it is a constant of
> the same type as the left operand, which must be of integer type.



Any other operation on untyped constants results in an untyped constant of
> the same kind


(emphasis mine). Given that a is not a constant, 1:

The right operand in a shift expression must have integer type or be an
> untyped constant representable by a value of type uint. If the left operand
> of a non-constant shift expression is an untyped constant, it is first
> implicitly converted to the type it would assume if the shift expression
> were replaced by its left operand alone.


Therefore, the untyped constant 1 in float64(1,
which says:

A constant value x can be converted to type T if x is representable by a
> value of T.


That seems to read as "1 stays an untyped constant and is then converted".
On the other hand, the section on constants
 says:

A constant may be given a type explicitly by a constant declaration or
> conversion, […]


This says that the untyped constant is given a type, which seems to imply
that "1 is given the type float64 by the conversion".

So, it can be argued that the spec is insufficiently clear here.
Personally, I tend to think that the behavior is reasonably clear - at
least the part where float64(1) gives 1 the type float64. We generally
accept that an untyped constant is given the type of the context it appears
in. So it does take a while to chase down why it behaves this way, but it's
in the spec.

But either way: If anything, this is a bug in the spec, not a bug in the
implementation. At this point (more than ten years after Go 1), if
something requires as subtle a reading of the spec as this, it's the
implementation that is right, unless implementations disagree.

On Thu, Jun 3, 2021 at 11:21 AM Brian Candler  wrote:

> Weird.  It simplifies to this: https://play.golang.org/p/OsOhRMC6kBu
>
> On Thursday, 3 June 2021 at 10:08:22 UTC+1 Jamil Djadala wrote:
>
>>
>> https://groups.google.com/g/golang-nuts
>>
>> package main
>>
>> import (
>> "fmt"
>> )
>>
>> func main() {
>> const aa int = 0
>> var a int
>> fmt.Println(float64(1<> fmt.Println(float64(1<> 1 << a (shift of type float64)
>> }
>> ./prog.go:11:21: invalid operation: 1 << a (shift of type float64)
>>
> --
> 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/87ee9f5f-6db2-48e8-86cc-de0b88511a65n%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/CAEkBMfHs_0BXEHbUGhnZ8bcKyQU-iQ%2BaoL5SA9%2BDtiFju2%2Bxbw%40mail.gmail.com.

Re: [go-nuts] Re: Is this a bug ?

[Jan Mercl]

On Thu, Jun 3, 2021 at 11:21 AM Brian Candler  wrote:
>
> Weird.  It simplifies to this: https://play.golang.org/p/OsOhRMC6kBu

I think this case is WAI.

>From https://golang.org/ref/spec#Operators

" If the left operand of a non-constant shift expression is an untyped
constant, it is first implicitly converted to the type it would assume
if the shift expression were replaced by its left operand alone."

The OP case is strange in that the constness of the RHS operator
somehow changes the interpretation of the above quotation
specification, but I cannot find that it should.

-- 
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/CAA40n-VQ544KsSc4vOMXMGRLHdwF17rSpyWFyTq%2Bjc40PiwWxg%40mail.gmail.com.

[go-nuts] Re: Is this a bug ?

[Brian Candler]

Weird.  It simplifies to this: https://play.golang.org/p/OsOhRMC6kBu

On Thursday, 3 June 2021 at 10:08:22 UTC+1 Jamil Djadala wrote:

>
> https://groups.google.com/g/golang-nuts
>
> package main
>
> import (
> "fmt"
> )
>
> func main() {
> const aa int = 0
> var a int
> fmt.Println(float64(1< fmt.Println(float64(1< << a (shift of type float64)
> }
> ./prog.go:11:21: invalid operation: 1 << a (shift of type float64)
>

-- 
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/87ee9f5f-6db2-48e8-86cc-de0b88511a65n%40googlegroups.com.

[go-nuts] Is this a bug ?

[Jamil Djadala]

https://groups.google.com/g/golang-nuts

package main

import (
"fmt"
)

func main() {
const aa int = 0
var a int
fmt.Println(float64(1

[go-nuts] Re: json unmarshalling troubles

[natxo....@gmail.com]

hi all,

thanks for your insights. The Value interface{}  type does work nicely.

I had tried as well the map[string]interface{} route, and it works as well, 
so now I have two solutions which is kind of a luxury position.

Regards,
Natxo


On Thursday, June 3, 2021 at 7:41:21 AM UTC+2 Amnon wrote:

> No, whoever designed the schema of this API has lost their marbles,
> (or lacks any kind of consideration for the unfortunate souls who need to 
> use this API).
>
> Unmarshalling a value whose type is not fixed is a pain in Go.
> But handling a value of unknown type will be a headache in any language.
>
>
>
> On Wednesday, 2 June 2021 at 19:55:40 UTC+1 rob...@glonek.co.uk wrote:
>
>> I think I'm loosing my marbles. Nevermind what I said.
>>
>> On Wednesday, 2 June 2021 at 16:22:34 UTC+1 Brian Candler wrote:
>>
>>> > If you try using switch value.(type) instead of using reflect, bool 
>>> will be reported as int, fyi, so using reflect here.
>>>
>>> Could you explain that a bit further please?  A type switch seems to 
>>> work OK for me, with no reflect.
>>> https://play.golang.org/p/TBH5zKYnG4G
>>>
>>>

-- 
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/e527006a-23d7-4139-abb0-0754531beb9cn%40googlegroups.com.