Hi,
I found that
https://github.com/golang/go/blob/07fc59199b9522bfe0d14f35c4391394efc336c9/src/cmd/go/internal/script/cmds_posix.go
has the build tag
//go:build unix || windows
Is windows really needed here? (I suppose not)
isETXTBSY is also defined in
https://github.com/golang/go/blob/07fc59199
Hiroaki,
go/src/syscall/zerrors_windows.go
// Invented values to support what package os and others expects.
const (
...
ETXTBSY
...
)
peter
On Monday, May 13, 2024 at 4:32:38 AM UTC-4 hnak...@gmail.com wrote:
> Hi,
> I found that
>
> https://github.com/golang/go/blob/07fc59199b9522bfe0d14f35c4
Hiroaki,
go/src/cmd/go/internal/test/test_nonunix.go
//go:build !unix
package test
func isETXTBSY(err error) bool {
// syscall.ETXTBSY is only meaningful on Unix platforms.
return false
}
peter
On Monday, May 13, 2024 at 4:32:38 AM UTC-4 hnak...@gmail.com wrote:
> Hi,
> I found that
>
> http
Is there a way in go to find whether a go binary is built with -cover flag ?
--
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.
try debug.ReadBuildInfo(), then iterate the pair in the buildinfo.Settings
在2024年5月13日星期一 UTC+8 20:56:51 写道：
> Is there a way in go to find whether a go binary is built with -cover flag
> ?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To un
I am writing an external go program that will take the path to another go
binary as argument, and checks if the binary was built with cover flag.
`debug.ReadBuildInfo()` is meant for getting build info embedded in the
running binary as
> ReadBuildInfo returns the build information embedded in t
Great suggestion Jason - adding `git status` took me in a very unexpected
direction, and ultimately a solution.
tl;dr if your build's base container image does not use root/uid 0, git
commands won't work unless you add the `--chown=` flag to your `COPY`
instruction. Go builds need this if you want
I forgot to add one more detail - the go-toolset image defaults to running
as user "default" (UID 1001).
Adding `USER root` right after the `FROM` declaration is another way to
work around the issue I described, but from a security perspective I would
advise against it.
On Mon, May 13, 2024 at 12
runtime/debug.ReadBuildInfo is a good source of truth:
$ strings bin/godeb|grep '^build\s'
build -buildmode=exe
build -compiler=gc
build
DefaultGODEBUG=httplaxcontentlength=1,httpmuxgo121=1,panicnil=1,tls10server=1,tlsrsakex=1,tlsunsafeekm=1
build CGO_ENABLED=1
build CGO_CFLAGS=
build
I'm not 100% sure if this is a good idea but it's been knocking around
in my head all week so I thought I'd share in case it has any merit:
Introduce bitsN types for N=8, 16, 32, 64, 128, 256, and 512.
These are similar to uintN but they are unordered and have no
arithmetic operations defined.
T
How about just allowing bitwise operations on byte arrays (of the same
length)?
On Monday, May 13, 2024 at 2:51:19 PM UTC-6 jimmy frasche wrote:
> I'm not 100% sure if this is a good idea but it's been knocking around
> in my head all week so I thought I'd share in case it has any merit:
>
> Int
Sorry, sent too early.
Obviously that doesn't support the bitwise type conversion you mentioned; I
don't really have an opinion on that one, I don't really convert from float
to bits very often.
It seems like the compiler optimizations you mention could happen with or
without these extra types
12 matches
Mail list logo
