Conrad Ludgate
@conrad.cafe
Some edge cases would be macros that are lazily evaluated. You can't inspect the output to know if there's a struct that derives the facet traits
December 6, 2025 at 8:42 AM
Some edge cases would be macros that are lazily evaluated. You can't inspect the output to know if there's a struct that derives the facet traits
It would work, but I don't like the idea.
The attribute would parse all inner items, look for a mod or a struct/enum item and recursively apply.
When applying to a struct/enum, the attribute should do nothing but return the original tokens. If the derive is there, it will observe the attribute
The attribute would parse all inner items, look for a mod or a struct/enum item and recursively apply.
When applying to a struct/enum, the attribute should do nothing but return the original tokens. If the derive is there, it will observe the attribute
December 6, 2025 at 8:42 AM
It would work, but I don't like the idea.
The attribute would parse all inner items, look for a mod or a struct/enum item and recursively apply.
When applying to a struct/enum, the attribute should do nothing but return the original tokens. If the derive is there, it will observe the attribute
The attribute would parse all inner items, look for a mod or a struct/enum item and recursively apply.
When applying to a struct/enum, the attribute should do nothing but return the original tokens. If the derive is there, it will observe the attribute
Depends how exhausted I am. It starts off with numbers, but eventually turns into swearing
December 5, 2025 at 7:05 AM
Depends how exhausted I am. It starts off with numbers, but eventually turns into swearing
Yeah, it's impressive that even on O1 the compiler turned recursion into a loop
December 4, 2025 at 9:49 AM
Yeah, it's impressive that even on O1 the compiler turned recursion into a loop
Certainly not easy. But I've spent a lot of time reading and writing unsafe, and a lot of time debugging miri tests 😇
December 2, 2025 at 10:18 AM
Certainly not easy. But I've spent a lot of time reading and writing unsafe, and a lot of time debugging miri tests 😇
Two things look sus to me.
`(*ptr).cache_hit = false` is constructing a `&mut bool` to an uninit place. I usually use `(&raw mut (*ptr).cache_hit).write(false)`
The second is that your equality check is reading uninit bytes, because padding bytes are always uninit
`(*ptr).cache_hit = false` is constructing a `&mut bool` to an uninit place. I usually use `(&raw mut (*ptr).cache_hit).write(false)`
The second is that your equality check is reading uninit bytes, because padding bytes are always uninit
December 2, 2025 at 9:40 AM
Two things look sus to me.
`(*ptr).cache_hit = false` is constructing a `&mut bool` to an uninit place. I usually use `(&raw mut (*ptr).cache_hit).write(false)`
The second is that your equality check is reading uninit bytes, because padding bytes are always uninit
`(*ptr).cache_hit = false` is constructing a `&mut bool` to an uninit place. I usually use `(&raw mut (*ptr).cache_hit).write(false)`
The second is that your equality check is reading uninit bytes, because padding bytes are always uninit
Agreed. bsky.app/profile/conr...
At work I've got an extension function "lock_propagate_poison()" as the default when locking. I'd prefer if lock() automatically panicked by default, with lock_or_poison() as a separate function to expose the poison guard.
November 28, 2025 at 8:55 PM
Agreed. bsky.app/profile/conr...
It claims it's to prevent sending a retry packet if you didn't receive the initial packet. However the retry packet already has
> The server populates the Destination Connection ID with the connection ID that the client included in the Source Connection ID of the Initial packet.
> The server populates the Destination Connection ID with the connection ID that the client included in the Source Connection ID of the Initial packet.
November 24, 2025 at 1:18 PM
It claims it's to prevent sending a retry packet if you didn't receive the initial packet. However the retry packet already has
> The server populates the Destination Connection ID with the connection ID that the client included in the Source Connection ID of the Initial packet.
> The server populates the Destination Connection ID with the connection ID that the client included in the Source Connection ID of the Initial packet.
I can't tell why it even needs an integrity tag to begin with
November 24, 2025 at 1:14 PM
I can't tell why it even needs an integrity tag to begin with
The nonce-reuse attacks let you:
1. Recover the keystream
2. If AAD is known, recover the key to produce your own tags.
In both cases, the key is already known, so key recovery or keystream recovery are not significant.
1. Recover the keystream
2. If AAD is known, recover the key to produce your own tags.
In both cases, the key is already known, so key recovery or keystream recovery are not significant.
November 24, 2025 at 1:08 PM
The nonce-reuse attacks let you:
1. Recover the keystream
2. If AAD is known, recover the key to produce your own tags.
In both cases, the key is already known, so key recovery or keystream recovery are not significant.
1. Recover the keystream
2. If AAD is known, recover the key to produce your own tags.
In both cases, the key is already known, so key recovery or keystream recovery are not significant.
I don't think retry packets need to concern themselves with collisions. The state only exists between the time the client starts a connection and the server responds. Since there will never be 2^64 initial connections open between two peers, collisions are very much not a concern
November 24, 2025 at 12:57 PM
I don't think retry packets need to concern themselves with collisions. The state only exists between the time the client starts a connection and the server responds. Since there will never be 2^64 initial connections open between two peers, collisions are very much not a concern
At work I've got an extension function "lock_propagate_poison()" as the default when locking. I'd prefer if lock() automatically panicked by default, with lock_or_poison() as a separate function to expose the poison guard.
November 20, 2025 at 8:29 PM
At work I've got an extension function "lock_propagate_poison()" as the default when locking. I'd prefer if lock() automatically panicked by default, with lock_or_poison() as a separate function to expose the poison guard.
This lint is also allow-by-default.
November 19, 2025 at 4:57 PM
This lint is also allow-by-default.
What difference would it make for this to be in rustc?
November 19, 2025 at 3:30 PM
What difference would it make for this to be in rustc?
November 19, 2025 at 1:51 PM
I've disabled unwrap in my codebase at work, only expect() is allowed. For Mutex/JoinHandle I've added some ext helpers
github.com/neondatabase...
github.com/neondatabase...
github.com
November 19, 2025 at 1:50 PM
I've disabled unwrap in my codebase at work, only expect() is allowed. For Mutex/JoinHandle I've added some ext helpers
github.com/neondatabase...
github.com/neondatabase...
`#![feature(core_intrinsics)]`
November 17, 2025 at 4:32 PM
`#![feature(core_intrinsics)]`
I was inspired to write this because I remember people complaining that lightweight crypto doesn't make sense. Arguments like "crypto is either secure or it isn't" missed the point entirely
November 17, 2025 at 9:35 AM
I was inspired to write this because I remember people complaining that lightweight crypto doesn't make sense. Arguments like "crypto is either secure or it isn't" missed the point entirely
This is useful for embedded devices with less available memory.
Ascon, not needing addition like chacha20, is also easy to implement in hardware. It only needs bitshifts and xor. While this isn't important for off-the-shelf CPUs, this matters for an FPGA that wants to run encryption or hashing.
Ascon, not needing addition like chacha20, is also easy to implement in hardware. It only needs bitshifts and xor. While this isn't important for off-the-shelf CPUs, this matters for an FPGA that wants to run encryption or hashing.
November 17, 2025 at 9:35 AM
This is useful for embedded devices with less available memory.
Ascon, not needing addition like chacha20, is also easy to implement in hardware. It only needs bitshifts and xor. While this isn't important for off-the-shelf CPUs, this matters for an FPGA that wants to run encryption or hashing.
Ascon, not needing addition like chacha20, is also easy to implement in hardware. It only needs bitshifts and xor. While this isn't important for off-the-shelf CPUs, this matters for an FPGA that wants to run encryption or hashing.