You are logging the same error many times and then trying to solve that in
the logs.
Try this:
Only log the error where it is handled, otherwise wrap it and return it
without logging. At some point, you will log it as either an error if there
is nothing you can do about it, or a warning if
https://github.com/google/nftables/blob/main/binaryutil/binaryutil.go ...
could give you some bad ideas; we need it for Linux nftables that encodes
stuff in host endianess.
On Thursday, August 10, 2023 at 3:27:49 PM UTC+2 Stephen Illingworth wrote:
> Thanks. Although I'm not worried about the
Thanks. Although I'm not worried about the native byte order of my machine
I'm writing an ARM emulator. The endianness of the ARM I'm taking to be
whatever the endianess is in the ELF file from which I'm loading the
program. I'm using the debug/elf package in the standard library which in
turn
First read
https://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html
then see
https://go.dev/play/p/4ESm6nOwgtY
-rob
On Thu, Aug 10, 2023 at 8:46 PM Stephen Illingworth <
stephen.illingwo...@gmail.com> wrote:
> Hello,
>
> I want to detect the implementation of binary.ByteOrder.
Hi all,
I've adopted slog and I am really loving the library. As I have used this
on my team, I've noticed a repetitive problem with error wrapping and I am
curious how other folks have handled this problem.
Lets say you are calling a sequence of functions where one function depends
on the
Hello,
I want to detect the implementation of binary.ByteOrder. ie. whether it is
Little Endian or Big Endian.
Normally, you would do this with a type assertion or a type switch but in
the case of the binary package the little/big endian implementations are
not exported.
The only way that I
I have a project that uses CGO. After compiling on an ubuntu 20.04
compilation machine, it is distributed to other machines for execution, but
many of these machines have very low ubuntu versions, which may be ubuntu
16.04 or ubuntu 18.04.
In this way, when executing the binary file, an error
