aboutsummaryrefslogtreecommitdiff
path: root/core
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #5432 from FourteenBrush/masterLaytan2025-07-041-0/+19
|\ | | | | Add `slice.suffix_length`
| * Add `slice.suffix_length`FourteenBrush2025-07-031-0/+19
| |
* | Add documentation to Bit_Field_Field when parsingBrad Lewis2025-07-031-1/+8
|/
* Fix incorrect type for FONTENUMPROCWJamie Dennis2025-07-011-1/+1
|
* Merge branch 'master' into args-leakJeroen van Rijn2025-06-27352-6990/+25626
|\
| * testing: Make test state changes its own featureFeoramund2025-06-261-2/+4
| | | | | | | | | | | | | | This patch takes the former debug message output of a test changing its state and makes it its own feature, toggleable with the `ODIN_TEST_LOG_STATE_CHANGES` configurable. The output will be at the info level and is disabled by default.
| * Expand `self_cleanup` documentation.Jeroen van Rijn2025-06-241-12/+24
| |
| * sys/linux: Unify IPC_Flags and IPC_Mode bitsetsSunagatov Denis2025-06-242-23/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In #5399 it was noticed, that IPC_Mode isn't being used within SystemV IPC procedures, even though it was designed this way, which lead to a weird API where in order to call SystemV IPC procedures multiple transmutes and a bitwise-OR are needed. This unifies IPC_Mode and IPC_Flags bitsets, making it possible to call the SystemV IPC procedures without extra casts, and rearranges the flags in a way that hopefully makes it easier to see when they are not colliding and should not be mixed. The explanation, explaining this arrangement of the enum was added. The IPC_Perm structure is modified, so that the flags can be re-used between the calls. It's probably not as good as keeping them separate, but should work... hopefully. Kept the "old" style of documentation for consistency. Signed-off-by: Sunagatov Denis <thebumboni@gmail.com>
| * Merge pull request #5391 from blob1807/masterJeroen van Rijn2025-06-221-0/+2
| |\ | | | | | | Fix memory leak in `core:math/big.internal_rat_norm`
| | * Fix memory leak in `internal_rat_norm`blob18072025-06-231-0/+2
| | |
| * | Fix issue parsing `vendor/stb/image` with the `core:odin/parser` parserBrad Lewis2025-06-221-4/+2
| |/
| * added IS_SUPPORTED to core:sys/posixRaphGL2025-06-213-0/+17
| |
| * Fix early join after start.Jeroen van Rijn2025-06-212-13/+13
| |
| * Merge pull request #5329 from JackMordaunt/jfm-fix_chan_try_sendLaytan2025-06-201-17/+33
| |\ | | | | | | chan: fix try_send and send
| | * core/sync/chan: (unbuffered) ack readsJack Mordaunt2025-06-131-3/+11
| | | | | | | | | | | | | | | | | | This fixes an issue where a call to close could intercept the dance between send and recv, causing send to report incorrectly that a value was not transmitted (when it actually was).
| | * core/sync/chan.send: return false if channel is closed while blockedJack Mordaunt2025-06-121-8/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit makes send behave the same as recv: that the call will return false if the channel is closed while a thread is waiting on the blocking operation. Prior logic would have send return true even if the channel was actually closed rather than read from. Docs adjusted to make this clear. Tests added to lock in this behaviour.
| | * core/sync/chan.try_send: avoid blocking if no reader is availableJack Mordaunt2025-06-121-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changes the semantics of try_send to be consistently non-blocking. That is, if the buffered is full OR there are no readers it returns false. The previous behaviour was such that it would block in the latter case of no reader, and it would wait for a reader. That is problematic because it produces inconsistent behaviour between buffered and unbuffered channels which is astonishing and adds complexity to the caller. To illustrate the problem with the old behaviour, consider the try_select operation: if a send-channel happens to be unbuffered the try_select (which wants to never block) can now block, that unbuffered send channel is selected (at random) and there is no reader on the other side. Thus we have unpredictable blocking behaviour, which breaks the guarantee that try_select never blocks. If you want a blocking send you can just call "send" (the blocking variant). In addition, there is some reader/writer math done inside can_{send,recv} such that they only report true if there is sufficient reader/writer capacity. If there is contention we need to ensure that each reader is paired to exactly one writer. Consider try_send: if there is a single reader we can send. If there is a single reader and a single writer, then we cannot send, as that reader will be paired with the existing writer. Therefore can_send is only true if there are more readers than writers at the time of check. NOTE: The original tests don't need to use wait-looping with thread.yield() or heuristic sleep. Instead we can just use blocking channel operations rather than non-blocking operations.
| * | Merge branch 'master' into tiocgwinsz_timeRaph2025-06-20296-5234/+16972
| |\ \
| | * | sys/posix: Correct reference to `core:text/regex`Feoramund2025-06-201-1/+1
| | | |
| | * | text/regex: Remove old docmentation and unneeded flagFeoramund2025-06-201-4/+0
| | | | | | | | | | | | | | | | | | | | `Unsupported_Flag` was used back when the iterator did not handle `.Multiline`.
| | * | mem: Guard against `Buddy_Allocator` overwriting metadataFeoramund2025-06-201-0/+1
| | | |
| | * | mem: Don't print `Buddy_Allocator.tail`Feoramund2025-06-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | This is always a pointer past the end of the buffer given to `buddy_allocator_init`, which could be an invalid address. Printing may result in a segmentation violation.
| | * | mem: Forbid construction of `Buddy_Allocator` with insufficient spaceFeoramund2025-06-191-0/+1
| | | | | | | | | | | | | | | | This takes into account eventual alignment.
| | * | mem: Fix `Buddy_Allocator` size calculation to truly include alignmentFeoramund2025-06-191-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This didn't take into account the size of the header plus the size of the allocation itself by virtue of `align_forward_uint`; this could result in no change if `size` was equal to `b.alignment` because the number is aligned, and if `actual_size` and `size` ended up being equal, no additional space would be requested. This meant that a block would end up being allocated on top of its buddy's head. Fixes #3435
| | * | mem: Fix inverted condition in `buddy_allocator_alloc_bytes_non_zeroed`Feoramund2025-06-191-1/+1
| | | | | | | | | | | | | | | | | | | | This was causing the procedure to find a block, then find one again, or to not find a block and not try again.
| | * | Fix #5366Jeroen van Rijn2025-06-191-0/+4
| | | |
| | * | Merge pull request #5344 from Feoramund/fix-2694Jeroen van Rijn2025-06-195-249/+373
| | |\ \ | | | | | | | | | | Review `core/mem/allocators.odin`
| | | * | Disable usage of AddressSanitizer (pt. 2)Feoramund2025-06-151-4/+4
| | | | |
| | | * | Merge branch 'master' into fix-2694Feoramund2025-06-158-53/+179
| | | |\ \
| | | * | | Disable usage of AddressSanitizer pending a per-allocator reviewFeoramund2025-06-155-85/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It has been discovered that AddressSanitizer does not keep a 1:1 mapping of which bytes are poisoned and which are not. This can cause issues for allocations less than 8 bytes and where addresses straddle 8-byte boundaries. See the following link for more information: https://github.com/google/sanitizers/wiki/AddressSanitizerAlgorithm#mapping
| | | * | | mem: Standardize panic messagesFeoramund2025-06-151-14/+14
| | | | | |
| | | * | | mem: Review all documentation commentsFeoramund2025-06-151-129/+140
| | | | | |
| | | * | | mem: Poison memory for `Buddy_Allocator`Feoramund2025-06-151-7/+15
| | | | | |
| | | * | | mem: Guard against size 0 in `dynamic_arena_resize_*`Feoramund2025-06-151-0/+8
| | | | | |
| | | * | | mem: Poison memory for `Dynamic_Arena`Feoramund2025-06-151-0/+7
| | | | | |
| | | * | | mem: Make `dynamic_arena_alloc` not privateFeoramund2025-06-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | None of the other `*_alloc` procs are private, and this proc is even referenced in public documentation comments.
| | | * | | mem: Remove bogus commentsFeoramund2025-06-151-12/+0
| | | | | | | | | | | | | | | | | | | | | | | | There is no `dynamic_arena_free`; the mode is not implemented
| | | * | | mem: Remove comment about calling `panic`Feoramund2025-06-151-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | The behavior is codified in the comment as returning `Invalid_Pointer`.
| | | * | | mem: Remove trailing whitespaceFeoramund2025-06-151-1/+1
| | | | | |
| | | * | | mem: Panic when passing invalid pointers to small stack free/resizeFeoramund2025-06-151-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | This is consistent with `Stack_Allocator`.
| | | * | | mem: Correct wrong error messageFeoramund2025-06-151-1/+1
| | | | | |
| | | * | | mem: Check if `alignment` matches on `Small_Stack` resizeFeoramund2025-06-151-0/+10
| | | | | |
| | | * | | mem: Make `small_stack_resize*` free if `size` is 0Feoramund2025-06-151-1/+1
| | | | | |
| | | * | | mem: Clarify what happens when you free out-of-order in a `Small_Stack`Feoramund2025-06-151-1/+4
| | | | | |
| | | * | | mem: Replace `auto_cast`Feoramund2025-06-151-1/+1
| | | | | |
| | | * | | mem: Don't unpoison the header of a `Small_Stack` allocationFeoramund2025-06-151-2/+4
| | | | | |
| | | * | | mem: Poison unused memory more thoroughlyFeoramund2025-06-141-0/+3
| | | | | |
| | | * | | mem: Check if `alignment` matches on `Stack_Allocator` resizeFeoramund2025-06-141-0/+10
| | | | | |
| | | * | | mem: Actually resize when resizing for `Stack_Allocator`Feoramund2025-06-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Changed the check from `bytes` to `err` for safety's sake, too. This will prevent the potential bug of allocating non-zero memory, then doing a zeroed resize, which will result in having garbage data in the initial half.
| | | * | | mem: Correct wrong error messageFeoramund2025-06-141-1/+1
| | | | | |
generated by cgit v1.2.3 (git 2.39.1) at 2026-02-15 09:26:12 +0000