pacak
pacak
> However, when cross-compiling from ARM to x86-64, it still needs `--target-cpu=` Yeah, same problem when cross compiling from x86 to ARM. While I can pick some concrete processor for...
Yeah, probably. Will try to make something in a few days.
Those error messages are coming from `llvm-mca`. Probably it wants something different. Not sure how to debug it - I don't have access to a Windows machine.
According to documentation for `recvmsg`, `msg_name` is optional and it is valid for it to be NULL: > The `msg_name` field points to a caller-allocated buffer that is used to...
I guess API can/should be extended to be able to set and reset buffer length? My main use case was working with multicast streams so knowing source address is not...
A data point, I'm using fbdac70c78975fe7c75b882337bf9f40a639f51a, about to upgrade. Both before and after I'm seeing `msg_name: 0, msg_namelen: 0`. Off to upgrade to more recent version.
0.25 works, 0.26 does not - producing `msg_name: 1`, going though the changelog.
https://github.com/nix-rust/nix/pull/2041 - regression originates here
Reverting this "fixes" this problem by initializing address with a null pointer, not sure if things fixed by #2041 are still working after that. ```diff - (*p).msg_name = (*address).as_mut_ptr() as...
`core::mem::maybe_uninit::MaybeUninit` is a zero sized type, vec of them occupies zero space, iterating over each member gets mutable pointer with addr 1 and size 0. `recvmmsg` is not aware of...