-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
malloc, calloc, ... should use the #[allocator]
attribute
#108
Comments
#[allocator]
attribute#[allocator]
attribute
Ideally, yes, but this is unlikely to really benefit much in practice. Usage via |
AFAIK those attributes are only added to Also, |
That's correct, yeah. In general we're not too interested in adding all possible LLVM attributes to all possible functions, it's mainly just a stabilization headache/maintenance nightmare for very little benefit |
IIRC Fixing this would need some kind of stabilized
There is prior art for these attributes in both GCC and LLVM, and we are arguably already using them, so they must be solving some problem already. I can write an MVP RFC for this. Basically, we would introduce an
This would allow to specify most properties of the #[allocator(size = s, align = a)]
fn my_malloc(s: usize, a: usize) -> *mut u8;
#[allocator(size = s, number = n, align = a)]
fn my_calloc(s: usize, n: usize, a: align) -> *mut u8;
#[allocator(align = a, size = s)]
fn my_aligned_alloc(a: usize, s: usize) -> *mut u8;
#[allocator(size = s)]
fn my_realloc(ptr: *mut u8, s: usize) -> *mut u8; I'm not 100% sure, but IIRC |
@alexcrichton
malloc
,calloc
, etc. do not return anoalias
pointer, I think they should use the#[allocator]
attribute but that's currently super unstable. Any ideas ?The text was updated successfully, but these errors were encountered: