Most marshal/unmarshal functions are unwilling to marshal/unmarshal
structs with pointer fields. Changing them to direct values fixes this.
Example:
https://go.dev/play/p/ykmpBm0bXqn
I do not think there is any other simple alternative.
J Liu:
I understand this problem. My real program uses expo
The binary stores a lot of ancillary data for runtime access. This
(mostly?) spans out from runtime.pclntab and runtime.firstmoduledata and
all the structures referenced by them. This is uniform across all
platforms too, with the runtime doing the same operations across
different OS-es and exec
an do "go
tool objdump module.a" and get the assembly for your module.
On Tue, Jan 23, 2024 at 4:14 PM Def Ceb <mailto:mikk.mar...@gmail.com>> wrote:
Interesting proposition, though from what I can tell, you're just going
to end up with goobj files, a
chive
(go build -buildmode=archive) and then disassemble/decompile the library.
On Tue, Jan 23, 2024 at 3:18 PM Def Ceb <mailto:mikk.mar...@gmail.com>> wrote:
No, this is not possible. This is the case for practically every other
language, even C. Unless you intend on inspecting as
Is there any particular reason to compare with %T fmt.Sprintf(?) values
in the first place? If not, then you could just use type assertions. And
the reflect package if really needed.
notevenhere:
I have some types defined within their respective packages deep inside
my project folder structur
No, this is not possible. This is the case for practically every other
language, even C. Unless you intend on inspecting assembly text instead
of a real working binary.
The symbol table + debug symbols built into the binary by default should
make finding the `main.main` function trivial with jus
The Go blog does indeed say this.
> The go tool no longer relies on pre-compiled standard library package
archives in the $GOROOT/pkg directory, and they are no longer shipped
with the distribution, resulting in smaller downloads. Instead, packages
in the standard library are built as needed an
I downloaded and ran `go env` with both the 32-bit and 64-bit Go
toolchains from go.dev, and the GOGCCFLAGS results were:
64-bit: GOGCCFLAGS='-fPIC -pthread -Wl,--no-gc-sections
-fmessage-length=0
-ffile-prefix-map=/tmp/go-build2828356582=/tmp/go-build
-gno-record-gcc-switches'
32-bit: GOGC
rue. I was working off of go.dev/s/regabi and it seemed to
imply that there's a lot less padding at the end of a struct.
> If there is a real performance difference, then, sure.
Fair enough, I'll try and check.
On Tuesday, April 18, 2023 at 7:56:07 PM UTC Ian Lance Taylor wrote:
O
come prominent.
>
> On Tuesday, April 18, 2023 at 7:54:17 PM UTC+2 Def Ceb wrote:
>
>> Hello.
>> This is a request for comments on an idea I had.
>>
>> While working on a personal project, I noticed that quite a few structs
>> in the standard library, exported
Hello.
This is a request for comments on an idea I had.
While working on a personal project, I noticed that quite a few structs in
the standard library, exported or otherwise, could have their memory
footprint reduced by simply reordering their members so that padding
required for alignment is
11 matches
Mail list logo
