alloc_system: don’t assume MIN_ALIGN for small sizes, fix #45955
The GNU C library (glibc) is documented to always allocate with an alignment
of at least 8 or 16 bytes, on 32-bit or 64-bit platforms:
https://www.gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.html
This matches our use of `MIN_ALIGN` before this commit.
However, even when libc is glibc, the program might be linked
with another allocator that redefines the `malloc` symbol and friends.
(The `alloc_jemalloc` crate does, in some cases.)
So `alloc_system` doesn’t know which allocator it calls,
and needs to be conservative in assumptions it makes.
The C standard says:
https://port70.net/%7Ensz/c/c11/n1570.html#7.22.3
> The pointer returned if the allocation succeeds is suitably aligned
> so that it may be assigned to a pointer to any type of object
> with a fundamental alignment requirement
https://port70.net/~nsz/c/c11/n1570.html#6.2.8p2
> A fundamental alignment is represented by an alignment less than
> or equal to the greatest alignment supported by the implementation
> in all contexts, which is equal to `_Alignof (max_align_t)`.
`_Alignof (max_align_t)` depends on the ABI and doesn’t seem to have
a clear definition, but it seems to match our `MIN_ALIGN` in practice.
However, the size of objects is rounded up to the next multiple
of their alignment (since that size is also the stride used in arrays).
Conversely, the alignment of a non-zero-size object is at most its size.
So for example it seems ot be legal for `malloc(8)` to return a pointer
that’s only 8-bytes-aligned, even if `_Alignof (max_align_t)` is 16.
2017-11-20 15:30:04 +01:00
|
|
|
#![feature(allocator_api)]
|
2021-12-23 22:03:12 +09:00
|
|
|
#![feature(alloc_layout_extra)]
|
2021-08-07 12:51:58 +01:00
|
|
|
#![feature(assert_matches)]
|
2015-03-10 23:58:16 -05:00
|
|
|
#![feature(box_syntax)]
|
2020-09-04 02:35:27 +02:00
|
|
|
#![feature(cow_is_borrowed)]
|
2021-12-23 22:03:12 +09:00
|
|
|
#![feature(const_box)]
|
|
|
|
#![feature(const_convert)]
|
2020-09-17 11:02:56 -07:00
|
|
|
#![feature(const_cow_is_borrowed)]
|
2021-12-23 22:03:12 +09:00
|
|
|
#![feature(const_heap)]
|
|
|
|
#![feature(const_mut_refs)]
|
|
|
|
#![feature(const_nonnull_slice_from_raw_parts)]
|
|
|
|
#![feature(const_ptr_write)]
|
|
|
|
#![feature(const_try)]
|
|
|
|
#![feature(core_intrinsics)]
|
2017-07-14 21:54:17 -04:00
|
|
|
#![feature(drain_filter)]
|
2016-11-22 23:31:31 +01:00
|
|
|
#![feature(exact_size_is_empty)]
|
2019-10-16 20:33:55 +02:00
|
|
|
#![feature(new_uninit)]
|
2015-06-10 13:33:52 -07:00
|
|
|
#![feature(pattern)]
|
2019-06-21 03:52:38 +02:00
|
|
|
#![feature(trusted_len)]
|
2021-07-23 16:40:43 +01:00
|
|
|
#![feature(try_reserve_kind)]
|
2015-03-10 23:58:16 -05:00
|
|
|
#![feature(unboxed_closures)]
|
2019-08-09 00:33:57 +02:00
|
|
|
#![feature(associated_type_bounds)]
|
2019-10-01 19:16:51 +09:00
|
|
|
#![feature(binary_heap_into_iter_sorted)]
|
|
|
|
#![feature(binary_heap_drain_sorted)]
|
2020-08-04 18:03:34 +02:00
|
|
|
#![feature(slice_ptr_get)]
|
2020-04-23 14:07:50 -05:00
|
|
|
#![feature(binary_heap_retain)]
|
2021-02-20 15:22:48 +02:00
|
|
|
#![feature(binary_heap_as_slice)]
|
2019-10-11 20:43:25 +02:00
|
|
|
#![feature(inplace_iteration)]
|
2021-07-12 21:40:38 +02:00
|
|
|
#![feature(iter_advance_by)]
|
2022-07-26 21:28:14 +02:00
|
|
|
#![feature(iter_next_chunk)]
|
2021-06-20 16:24:10 -04:00
|
|
|
#![feature(round_char_boundary)]
|
2020-12-10 10:16:29 +01:00
|
|
|
#![feature(slice_group_by)]
|
2021-03-15 20:24:35 +01:00
|
|
|
#![feature(slice_partition_dedup)]
|
2021-03-05 11:27:58 -05:00
|
|
|
#![feature(string_remove_matches)]
|
2021-07-26 14:04:55 +08:00
|
|
|
#![feature(const_btree_new)]
|
2021-08-14 16:35:12 +00:00
|
|
|
#![feature(const_default_impls)]
|
2021-07-26 14:04:55 +08:00
|
|
|
#![feature(const_trait_impl)]
|
2021-11-05 15:39:01 +03:00
|
|
|
#![feature(const_str_from_utf8)]
|
2021-12-23 22:03:12 +09:00
|
|
|
#![feature(nonnull_slice_from_raw_parts)]
|
2022-01-05 22:42:21 +01:00
|
|
|
#![feature(panic_update_hook)]
|
2022-08-19 13:26:37 +04:00
|
|
|
#![feature(pointer_is_aligned)]
|
2022-04-01 20:07:28 -04:00
|
|
|
#![feature(slice_flatten)]
|
2021-10-19 15:23:19 -07:00
|
|
|
#![feature(thin_box)]
|
2022-05-02 01:45:21 -07:00
|
|
|
#![feature(bench_black_box)]
|
|
|
|
#![feature(strict_provenance)]
|
|
|
|
#![feature(once_cell)]
|
2022-03-27 22:02:06 +04:00
|
|
|
#![feature(drain_keep_rest)]
|
2015-07-11 14:34:57 +03:00
|
|
|
|
2016-09-28 17:23:36 -07:00
|
|
|
use std::collections::hash_map::DefaultHasher;
|
|
|
|
use std::hash::{Hash, Hasher};
|
2015-08-11 17:27:05 -07:00
|
|
|
|
2018-07-06 19:30:09 +02:00
|
|
|
mod arc;
|
2020-04-22 14:16:21 -07:00
|
|
|
mod borrow;
|
2019-10-16 20:33:55 +02:00
|
|
|
mod boxed;
|
2020-08-14 16:38:53 +02:00
|
|
|
mod btree_set_hash;
|
2022-02-16 19:23:37 +08:00
|
|
|
mod c_str;
|
2021-07-26 14:04:55 +08:00
|
|
|
mod const_fns;
|
2016-11-04 01:07:00 +00:00
|
|
|
mod cow_str;
|
2015-03-10 23:58:16 -05:00
|
|
|
mod fmt;
|
alloc_system: don’t assume MIN_ALIGN for small sizes, fix #45955
The GNU C library (glibc) is documented to always allocate with an alignment
of at least 8 or 16 bytes, on 32-bit or 64-bit platforms:
https://www.gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.html
This matches our use of `MIN_ALIGN` before this commit.
However, even when libc is glibc, the program might be linked
with another allocator that redefines the `malloc` symbol and friends.
(The `alloc_jemalloc` crate does, in some cases.)
So `alloc_system` doesn’t know which allocator it calls,
and needs to be conservative in assumptions it makes.
The C standard says:
https://port70.net/%7Ensz/c/c11/n1570.html#7.22.3
> The pointer returned if the allocation succeeds is suitably aligned
> so that it may be assigned to a pointer to any type of object
> with a fundamental alignment requirement
https://port70.net/~nsz/c/c11/n1570.html#6.2.8p2
> A fundamental alignment is represented by an alignment less than
> or equal to the greatest alignment supported by the implementation
> in all contexts, which is equal to `_Alignof (max_align_t)`.
`_Alignof (max_align_t)` depends on the ABI and doesn’t seem to have
a clear definition, but it seems to match our `MIN_ALIGN` in practice.
However, the size of objects is rounded up to the next multiple
of their alignment (since that size is also the stride used in arrays).
Conversely, the alignment of a non-zero-size object is at most its size.
So for example it seems ot be legal for `malloc(8)` to return a pointer
that’s only 8-bytes-aligned, even if `_Alignof (max_align_t)` is 16.
2017-11-20 15:30:04 +01:00
|
|
|
mod heap;
|
2015-03-10 23:58:16 -05:00
|
|
|
mod linked_list;
|
2018-07-06 19:30:09 +02:00
|
|
|
mod rc;
|
2015-03-10 23:58:16 -05:00
|
|
|
mod slice;
|
|
|
|
mod str;
|
|
|
|
mod string;
|
2021-10-19 15:23:19 -07:00
|
|
|
mod thin_box;
|
2015-03-10 23:58:16 -05:00
|
|
|
mod vec;
|
|
|
|
mod vec_deque;
|
2015-08-11 17:27:05 -07:00
|
|
|
|
|
|
|
fn hash<T: Hash>(t: &T) -> u64 {
|
2016-09-28 17:23:36 -07:00
|
|
|
let mut s = DefaultHasher::new();
|
2015-08-11 17:27:05 -07:00
|
|
|
t.hash(&mut s);
|
|
|
|
s.finish()
|
|
|
|
}
|
2017-08-21 22:15:02 +08:00
|
|
|
|
2017-09-11 00:13:19 +08:00
|
|
|
// FIXME: Instantiated functions with i128 in the signature is not supported in Emscripten.
|
|
|
|
// See https://github.com/kripken/emscripten-fastcomp/issues/169
|
|
|
|
#[cfg(not(target_os = "emscripten"))]
|
2017-08-21 22:15:02 +08:00
|
|
|
#[test]
|
|
|
|
fn test_boxed_hasher() {
|
|
|
|
let ordinary_hash = hash(&5u32);
|
|
|
|
|
|
|
|
let mut hasher_1 = Box::new(DefaultHasher::new());
|
|
|
|
5u32.hash(&mut hasher_1);
|
|
|
|
assert_eq!(ordinary_hash, hasher_1.finish());
|
|
|
|
|
2018-07-13 14:25:22 +09:00
|
|
|
let mut hasher_2 = Box::new(DefaultHasher::new()) as Box<dyn Hasher>;
|
2017-08-21 22:15:02 +08:00
|
|
|
5u32.hash(&mut hasher_2);
|
|
|
|
assert_eq!(ordinary_hash, hasher_2.finish());
|
|
|
|
}
|