Skip to content

Conversation

@ld-kerley
Copy link
Contributor

As part of the work to make adopting MaterialX easier for us and lowering the number of internal patches we have to carry for security and performance reasons, this PR proposes a method we could use to avoid the global constructor/destructor calls for std::string constants.

There are actually two different possible approaches here - the other is in #2693

This PR only applies the change to a single source file Property.cpp/h, but if/when one of the two options is selected it would be my intention to apply the same pattern at least to the rest of MaterialXCore, and then eventually elsewhere.

I think I prefer the other option, but this uses const char* instead of const std::string, it needs no other core API changes, it needs no other changes as std::string has a constructor that accepts const char*. Also some changes were necessary in the Javascript bindings, which I'm not familiar with - hoping experts there can highlight any problems, if they exist.

@kwokcb
Copy link
Contributor

kwokcb commented Nov 26, 2025

Similar comment to the string_view alternative. Again it is unsafe to use for Python and Javascript public APIS so must you must add safety wrappers and requires additional copies. In addition it have issues since there is no length provided. Both can have issues without when strings are not explicitly null-terminated.

For detection of unsafe uses can use clang-tidy?. We'd also want WASM heap detection turned on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants