Skip to content
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

Add support for fully qualified names in C language to avoid name pollution #380

Closed
nertpinx opened this issue Aug 16, 2019 · 2 comments
Closed

Comments

@nertpinx
Copy link

C++ does use namespaces which help avoiding name pollution. However in C the usual way to do this is just using the "namespaces" as prefixes of the names. For functions and other ABI exports this cannot really be changed unless the export name is changed as well. However for types (typedefs, enums, structs) this can be prefixed by cbindgen so that the actual items do not need to have these extra prefixes in the Rust code. I tried looking at the code and added an option for it, but then I got lost because there was no way to extract the path to the item. An example could be something like:

mod Size {
    pub enum Type {
        Small,
        Large,
    }
}

mod Performance {
    pub enum Type {
        Slow,
        Medium,
        Fast,
    }
}

This would (with the proper settings) result in:

typedef enum AsdfSizeType {
    ASDF_SIZE_TYPE_SMALL,
    ASDF_SIZE_TYPE_LARGE,
} AsdfSizeType;

typedef enum AsdfPerformanceType {
    ASDF_PERFORMANCE_TYPE_SLOW,
    ASDF_PERFORMANCE_TYPE_MEDIUM,
    ASDF_PERFORMANCE_TYPE_FAST,
} AsdfPerformanceType;

where asdf is the name of the crate. This would make all the types and values uniquely identifiable the same way it is usually done in C libraries. That would help us with libraries that should be usable from C code and also porting some existing C code to Rust for which we currently need to write the header files manually.

This does look similar to #7 although I do not see this particular thing mentioned there. If that is supposed to be a part of it, then feel free to close this.

Also it looks like #214 keeps this in mind separately from the issue above, but again, haven't seen this spelled out as part of it.

@emilio
Copy link
Collaborator

emilio commented Aug 25, 2019

This is related to the long-standing issue that cbindgen is not properly namespace-aware.

@emilio
Copy link
Collaborator

emilio commented Aug 25, 2019

I think this is effectively #7, yeah. Let's close as a dupe of that.

@emilio emilio closed this as completed Aug 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants