Using stdlib functions in a ctor potentially unsound

[ids1024]

According to the README for ctor:

Rust's philosophy is that nothing happens before or after main and this library explicitly subverts that. The code that runs in the ctor and dtor functions should be careful to limit itself to libc functions and code that does not rely on Rust's stdlib services.

Looking at the generated code, this seems to use Vec in the constructor. As I understand the statement from ctor above, this could potentially segfault or be otherwise broken by a future change to std, or on a particular target, or perhaps with custom allocators.

[jdonszelmann]

Dear IDS, you are entirely right. However I honestly don't see a way around it. The crate which "defines" the label stores all the references to the functions annotated with the label, and we can't know in advance how many times the annotation will be used (so we need to use vec). The only reason around this is by limiting ourselfs to libc functions. Calling libc's malloc directly and implementing some sort of custom vec-like structure. Do you know of a better way to do this?

[ids1024]

Calling libc's malloc directly and implementing some sort of custom vec-like structure.

It's rather annoying to have to do it this way, but it shouldn't be to hard to wrap malloc/realloc here. Another not particularly satisfactory solution would be to just use a fixed length array.

Do you know of a better way to do this?

Maybe there's a better way to implement something like this, but unfortunately I don't know what it is.

[jdonszelmann]

The unfortunate thing about using a fixed size array is that it'd either make a huge empty array in the binary (every label you create will equal an array of (pointerwidth * max_labels) bytes long), or make it possible for the compilation to fail just by adding too many functions with labels on them.

[jdonszelmann]

Also, may I say that I am not sure if this library is fit to be used with gtk_rs as it depends on a nightly feature. I'm not entirely sure you want that. Unfortunately that's another thing I haven't found a way around yet. I need to find the path to the label definition which I can only find by parsing some of the source around the labelled function. It doesn't look like this will be stable any time soon.