danakj/openbox 557
Openbox Window Manager (OpenboxWM)
An experimental take on a safer, simpler C++ standard library.
Openbox configuration tool
A safe Rust API for the Playdate hand held gaming system.
android ndk
danakj/ACT.SpecialSpellTimer 4
ACTのFF14向けプラグイン 見た目を改善したスペルタイマーを提供します
Thoughts about C++, Memory Safety, Library Design, Memory Safety, Sharp Edges
A bot for the Chromium Slack server
A project template for building a game with craydate
An attribute macro to specify a path to a module dynamically.
push eventdanakj/subspace
commit sha 9d97a85abfef3c5dc828ad0c3ca311cca40dd0ac
Store using decls that point to concepts
commit sha 0935e401eaef8c1b1cbe9cdb00354e49dd0628b4
Allow visiting typedefs and using aliases
commit sha 08ef339b5bf7fc1896a2f922a7dbafbd0a36a34b
Store typedefs and using aliases into the database
commit sha b699e65a8f62557b2001327cd164f0277b4367d3
Model all alias types into a single AliasElement
commit sha c24966ec9fd2e0425a39c66fb8ac65feb8eae639
WIP: Generate HTML for aliases
push time in a day
push eventdanakj/subspace
commit sha 661195483bab764b6623b414c04e32bed637431b
Allow integer shifting by u64 Rust shift operators take a rhs value of u32, which we emulated, however this introduces a sharp edge in C++ where you shift by something like a `sizeof()` expression. That evaluates to a `size_t` which used to implicitly narrow to unsigned in order to shift. But with safer types there is no implicit narrowing and you need to write u32::try_from(shift).unwrap() Which is then fed to the shift operator which will check (again) that the shift amount is in range. Nowhere near the full range of values of `u32` is in range for a shift operation, so the size of the type is somewhat arbitrary. So the value inside must be checked regardless. By allowing u64/usize types to be used on the rhs of the shift, we avoid having to write conversions where they aren't holding weight. > This makes the C++ operators accept things that the Rust operators do > not. Why is C++ different here? The answer here is that 1) casting in rust is much simpler, a `sizeof<T>() as u32` expression is simpler than the noise introduced by conversions in C++ like `sus::cast<u23>(sizeof(T))` 2) we need to rewrite a lot of code that already assumes it's fine to shift by a size_t 3) Rust type deduction allows Rust code to avoid naming the type of things at all and it can pick a u32, whereas C++ will need to pick a type and it will often have picked a size_t/usize. > What mitigates this difference? And the extra expressivity does not allow C++ to do different things or change expectations wrt the behaviour of the shift operators.
push time in 2 days
push eventsubspace-cpp/docs
commit sha b8e37c09b163824ef7549f991a694411f7939c37
Update docs: 661195483bab764b6623b414c04e32bed637431b
push time in 3 days
push eventchromium/subspace
commit sha 661195483bab764b6623b414c04e32bed637431b
Allow integer shifting by u64 Rust shift operators take a rhs value of u32, which we emulated, however this introduces a sharp edge in C++ where you shift by something like a `sizeof()` expression. That evaluates to a `size_t` which used to implicitly narrow to unsigned in order to shift. But with safer types there is no implicit narrowing and you need to write u32::try_from(shift).unwrap() Which is then fed to the shift operator which will check (again) that the shift amount is in range. Nowhere near the full range of values of `u32` is in range for a shift operation, so the size of the type is somewhat arbitrary. So the value inside must be checked regardless. By allowing u64/usize types to be used on the rhs of the shift, we avoid having to write conversions where they aren't holding weight. > This makes the C++ operators accept things that the Rust operators do > not. Why is C++ different here? The answer here is that 1) casting in rust is much simpler, a `sizeof<T>() as u32` expression is simpler than the noise introduced by conversions in C++ like `sus::cast<u23>(sizeof(T))` 2) we need to rewrite a lot of code that already assumes it's fine to shift by a size_t 3) Rust type deduction allows Rust code to avoid naming the type of things at all and it can pick a u32, whereas C++ will need to pick a type and it will often have picked a size_t/usize. > What mitigates this difference? And the extra expressivity does not allow C++ to do different things or change expectations wrt the behaviour of the shift operators.
push time in 3 days
PR merged chromium/subspace
Rust shift operators take a rhs value of u32, which we emulated, however this introduces a sharp edge in C++ where you shift by something like a sizeof() expression. That evaluates to a size_t which used to implicitly narrow to unsigned in order to shift. But with safer types there is no implicit narrowing and you need to write
u32::try_from(shift).unwrap()
Which is then fed to the shift operator which will check (again) that the shift amount is in range.
Nowhere near the full range of values of u32 is in range for a shift operation, so the size of the type is somewhat arbitrary. So the value inside must be checked regardless.
By allowing u64/usize types to be used on the rhs of the shift, we avoid having to write conversions where they aren't holding weight.
This makes the C++ operators accept things that the Rust operators do not. Why is C++ different here?
The answer here is that
- casting in rust is much simpler, a
sizeof<T>() as u32expression is simpler than the noise introduced by conversions in C++ likesus::cast<u23>(sizeof(T)) - we need to rewrite a lot of code that already assumes it's fine to shift by a size_t
- Rust type deduction allows Rust code to avoid naming the type of things at all and it can pick a u32, whereas C++ will need to pick a type and it will often have picked a size_t/usize.
What mitigates this difference?
And the extra expressivity does not allow C++ to do different things or change expectations wrt the behaviour of the shift operators.
pr closed time in 3 days
PR opened chromium/subspace
Rust shift operators take a rhs value of u32, which we emulated, however this introduces a sharp edge in C++ where you shift by something like a sizeof() expression. That evaluates to a size_t which used to implicitly narrow to unsigned in order to shift. But with safer types there is no implicit narrowing and you need to write
u32::try_from(shift).unwrap()
Which is then fed to the shift operator which will check (again) that the shift amount is in range.
Nowhere near the full range of values of u32 is in range for a shift operation, so the size of the type is somewhat arbitrary. So the value inside must be checked regardless.
By allowing u64/usize types to be used on the rhs of the shift, we avoid having to write conversions where they aren't holding weight.
This makes the C++ operators accept things that the Rust operators do not. Why is C++ different here?
The answer here is that
- casting in rust is much simpler, a
sizeof<T>() as u32expression is simpler than the noise introduced by conversions in C++ likesus::cast<u23>(sizeof(T)) - we need to rewrite a lot of code that already assumes it's fine to shift by a size_t
- Rust type deduction allows Rust code to avoid naming the type of things at all and it can pick a u32, whereas C++ will need to pick a type and it will often have picked a size_t/usize.
What mitigates this difference?
And the extra expressivity does not allow C++ to do different things or change expectations wrt the behaviour of the shift operators.
pr created time in 4 days
push eventsubspace-cpp/docs
commit sha dd39d0c2d70bdee6010da65855a6ccc954130a9b
Update docs: e6e9821f110c55395813735dff5d8cfceb1a92c9
push time in 4 days
push eventsubspace-cpp/docs
commit sha 4b62c10896df429a402138fb4e9bb088e55a499f
Update docs: af5537050d3a657659753f1f98fdedd6fa3f60d6
push time in 4 days
push eventdanakj/subspace
commit sha e6e9821f110c55395813735dff5d8cfceb1a92c9
Mention indexing operations with std containers and signed ints
push time in 4 days
push eventchromium/subspace
commit sha e6e9821f110c55395813735dff5d8cfceb1a92c9
Mention indexing operations with std containers and signed ints
push time in 4 days
push eventdanakj/subspace
commit sha af5537050d3a657659753f1f98fdedd6fa3f60d6
Mention no uninit memory in collections
push time in 4 days
push eventchromium/subspace
commit sha af5537050d3a657659753f1f98fdedd6fa3f60d6
Mention no uninit memory in collections
push time in 4 days
push eventsubspace-cpp/docs
commit sha 06fd40bed2f25d2b551aecee71928451f6d8fc9c
Update docs: 76f08a75f6fbf4c47179919494f64a4255cee7c4
push time in 4 days
push eventdanakj/subspace
commit sha db4bb87cc7173fdff7019b7d2cb91329372dc5ad
Fix compile of float rounding function tests on MSVC and test for NaNs. I mistakenly thought fesetround() would return the previous mode, but it returns 0 for success. So we need to call fegetround() first to be able to restore the mode. Changing the fp environment does not produce a reliable output in tests so don't do it (no one changes the env anyway).
commit sha 76f08a75f6fbf4c47179919494f64a4255cee7c4
Limit float_round_to to round to signed integers Which the callers of it already are.
push time in 4 days
push eventchromium/subspace
commit sha 76f08a75f6fbf4c47179919494f64a4255cee7c4
Limit float_round_to to round to signed integers Which the callers of it already are.
push time in 4 days
push eventchromium/subspace
commit sha db4bb87cc7173fdff7019b7d2cb91329372dc5ad
Fix compile of float rounding function tests on MSVC and test for NaNs. I mistakenly thought fesetround() would return the previous mode, but it returns 0 for success. So we need to call fegetround() first to be able to restore the mode. Changing the fp environment does not produce a reliable output in tests so don't do it (no one changes the env anyway).
push time in 4 days
push eventsubspace-cpp/docs
commit sha 4c6e02b22c374f4fef2c795f31c7f1b9f00df298
Update docs: 7e61b56e4012feda33bf86903d131b6febce9916
push time in 5 days
push eventdanakj/subspace
commit sha 2e94fff640e325ba005c0d4d7fb843d79b7f5b76
Fix compile of float rounding function tests on MSVC and test for NaNs. I mistakenly thought fesetround() would return the previous mode, but it returns 0 for success. So we need to call fegetround() first to be able to restore the mode. Changing the fp environment does not produce a reliable output in tests so don't do it (no one changes the env anyway).
push time in 5 days
push eventdanakj/subspace
commit sha 1fd975944dcb3756098eb879c5862585e0fa7d11
Fix compile of float rounding function tests on MSVC and test for NaNs. I mistakenly thought fesetround() would return the previous mode, but it returns 0 for success. So we need to call fegetround() first to be able to restore the mode. Changing the fp environment does not produce a reliable output in tests so don't do it (no one changes the env anyway).
push time in 5 days
push eventdanakj/subspace
commit sha 1824fa4a564822a7c479f732265f656481e39232
Fix compile of float rounding function tests on MSVC and test for NaNs. I mistakenly thought fesetround() would return the previous mode, but it returns 0 for success. So we need to call fegetround() first to be able to restore the mode. Changing the fp environment does not produce a reliable output in tests so don't do it (no one changes the env anyway).
push time in 5 days
push eventdanakj/subspace
commit sha 5208bdfc91f23d32b546e491433ab291e347c8bc
Add round_ties and clarify the rounding behaviour of round The round methods will match the behaviour of Rust, which matches the C round() function except for also preserving the negative sign on zero. Add round_ties which will use the current rounding mode to round ties, which by default is to the nearest even number which is also what is specified by the IEEE 754 standard. Rust has an unstable round_ties_even which does the same thing, but does not need to worry about the user specifying a rounding mode, so it can always provide a single behaviour. For this reason and to avoid excessive calls to set the rounding mode, we provide a more general and C++-specific version that follows the mode and does not claim any one in particular. We document that round_ties is much faster than round and is usually preferable.
commit sha ed5181e45719ffc3d29186b41ea963d8b32ebfe5
Add round_to_iN() methods on f32 and f64 These methods perform the same thing as `round_ties()` and then a safe saturating cast. But that requires a separate instruction for the rounding and the casting. Some platforms have a single instruction that does both. So this gives access to that instruction while guarding for UB when the value is out of bounds for the target type and saturating, and returning 0 for NaN.
commit sha 7e61b56e4012feda33bf86903d131b6febce9916
Document the cmp namespace
push time in 5 days
push eventchromium/subspace
commit sha 7e61b56e4012feda33bf86903d131b6febce9916
Document the cmp namespace
push time in 5 days
push eventdanakj/subspace
commit sha 3e2e53552a60aa14c2e8555214681d942e55f209
Fix compile of float rounding function tests on MSVC and test for NaNs. I mistakenly thought fesetround() would return the previous mode, but it returns 0 for success. So we need to call fegetround() first to be able to restore the mode.
push time in 5 days
push eventdanakj/subspace
commit sha 04651df2aa1af3ea8d61370f2712de500b3894b3
Fix compile of float rounding function tests on MSVC and test for NaNs. I mistakenly thought fesetround() would return the previous mode, but it returns 0 for success. So we need to call fegetround() first to be able to restore the mode.
push time in 5 days
push eventdanakj/subspace
commit sha d26012456a28ceb2889b25c8c24a9d225866edf6
Fix compile of float rounding function tests on MSVC and test for NaNs. I mistakenly thought fesetround() would return the previous mode, but it returns 0 for success. So we need to call fegetround() first to be able to restore the mode.
push time in 5 days
push eventdanakj/subspace
commit sha e41ed12f849414ec00e72fd4a23670044d18c11a
Fix compile of float rounding function tests on MSVC and test for NaNs. I mistakenly thought fesetround() would return the previous mode, but it returns 0 for success. So we need to call fegetround() first to be able to restore the mode.
push time in 5 days