An immutable, statically allocated Vector class keeps track of the strings.
Sanitizer dependencies are used to avoid linkage problems for users.
Details
Diff Detail
- Repository
- rCRT Compiler Runtime
- Build Status
Buildable 17200 Build 17200: arc lint + arc unit
Event Timeline
lib/xray/xray_interface.cc | ||
---|---|---|
71 | Couple of things:
| |
lib/xray/xray_unique_string_table.cc | ||
21–24 | I suspect you may not actually need these, if you're already in the __xray namespace. | |
38 | Do we not have this yet in the sanitizer_common/... library? And do we actually need this? | |
99 | Consider using __sanitizer::InternalAlloc(...) then placement-new. That's a bit more friendly than calling new directly and relying on the implementation's allocator, which may not be the same as the allocator being used by the sanitizer libraries. | |
lib/xray/xray_unique_string_table.h | ||
29 | Probably use the sanitizer-local typedefs for some of these values -- say u16 instead of uint16_t, etc. | |
36 | Do you really need to use the pimpl idiom? |
Haven't made any changes yet. Thanks for the comments Dean.
lib/xray/xray_interface.cc | ||
---|---|---|
71 |
| |
lib/xray/xray_unique_string_table.cc | ||
38 |
| |
99 | Cool. Didn't know about that method until recently. | |
lib/xray/xray_unique_string_table.h | ||
29 | What's the difference between these? When and why should I prefer sanitizer types? | |
36 | No, but the class must have a known size, which will uglify the header. |
lib/xray/xray_unique_string_table.cc | ||
---|---|---|
38 | We should be able to hoist out the existing implementation into a header in sanitizer_common/ if it's already in the sanitizer implementation(s). We can either do that in this change, or in a separate one which this will depend on. I agree that for the purposes of implementing an efficient string intern table which only really gets looked up very infrequently (i.e. using registration of types) then we shouldn't be over-thinking this data structure/implementation for now. |
Couple of things: