Add more C lib methods #49550
Add more C lib methods #49550
Conversation
|
Looks like there's still an import problem in Random? |
|
Just a heads up, I'm still getting some test errors locally. |
|
I think I caught all the import and got testing to work locally at this point. |
|
Should these methods be usable from the native compiler since "array.jl" and "substring.jl" use them or do we want to keep the native compiler as small as possible here? |
Some ccalls remain in order to accomodate bootstraps still
Co-authored-by: Jameson Nash <vtjnash@gmail.com>
Co-authored-by: Jameson Nash <vtjnash@gmail.com>
The Libc module contains some code that we might not care to have as part of bootstrapping. However, the C-memory methods are directly called throughout bootstrapping so these are now defined in a seperate "cmem.jl" file that is defined in Base then imported into `Libc` for the public interface.
pointer_to_objref(::Array) is not same as unsafe_convert(Ptr, ::Array)
Co-authored-by: Jameson Nash <vtjnash@gmail.com>
|
@Tokazama, before 1.10 is released shouldn't those ideally be named memcpy!, memset!, memmove!, memcmp!, to conform to Julia naming conversion (even though not used in C)? I don't think we should commit to supporting without !. If that is needed/wanted we should support as synonym, or at least if this is forgotten and 1.10 released, but I would prefer to not have both. If changed remember to backport to 1.10. And about the GC_reserve stuff, I'm not sure, but should it be defined in those functions not their callers? |
|
The methods here are barebones bindings to C and don't keep with the norms in most Julia code. These methods don't reflect Julia conventions in name or design and probably can't fully follow Julia's conventions. For example, I'm not sure how we'd appropriately make My personal understanding is the code here only exists to help move C functionality into Julia code, not as something people should use under most circumstances. I'm not sure at what point we care more about being consistent with Julia's conventions or reflecting the C method so it's easy to find and use. |
|
You have a point with realloc already there. It and these new are mutating, and maybe should be known to (intended) users, at least to all using C (a dying breed). We can keep C's naming, there are pros and cons, but maybe then explicitly document as mutating, and breaking Julia convention? Is it too excessive to do it on all the functions, rather than somewhere globally? If this where used from Julia code, then some users would be blind to the mutation, so do you support changing; also realloc -> realloc!, but keep older names as a synonym (to not break; still deprecate?)? Maybe only a synonym for realloc, since 1.10 is not stable yet... |
|
It would probably be a good idea to document that these methods are generally considered unsafe memory operations and also document which ones mutate memory.
At this point the syntax is consistent at least within the This might be worth bringing up in triage because it should probably get more input than me. |
|
I or you could open an issue or PR. I don't participate in triage, not sure where and when (is it one Slack?). This is merged on 1.10, so I thought time-critical to change. It could even be done without resize!, since 1.10 is not yet released as stable (seemingly will be any day now), but it would be inconsistent (still ok, and in some sense better), so likely not wanted unless all (relevant) changed in Libc, subsequently, i.e. adding synonym. |
|
There's a triage channel on slack and I think the zoom call is on scheduled+linked on the community calendar |
No description provided.