From: "ioquatix (Samuel Williams)" Date: 2021-09-23T20:13:14+00:00 Subject: [ruby-core:105400] [Ruby master Bug#18189] `rb_cString` can be NULL during `Init_Object` Issue #18189 has been updated by ioquatix (Samuel Williams). @nobu that makes total sense. I also had one other idea. We obviously have a lot of: ``` VALUE rb_cString; ``` We initialize this dynamically. Why not initialize it statically? ``` struct RClass _cString = ...; VALUE rb_cString = & _cString; ``` It seems (1) performance improvement and (2) more predictable usage at least for strings. ---------------------------------------- Bug #18189: `rb_cString` can be NULL during `Init_Object` https://bugs.ruby-lang.org/issues/18189#change-93815 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- It's possible for `rb_cString` to be NULL during `Init_Object` and thus `Init_class_hierarchy` which means that `rb_fstring_lit`, which invokes `setup_fake_str`, invokes `RBASIC_SET_CLASS_RAW(..., NULL)` (or possibly just something totally random if it's not zero initialized!). Later on in `register_fstring` we have an assertion which also fails to detect the abnormality: ``` assert(RBASIC_CLASS(args.fstr) == rb_cString); ``` Because both are NULL. Oops. It seems that later on, `rb_cString` is set on that specific fstring. But in my own usage of `rb_define_module_under` during `InitVM_Object`, this creates invalid class names which fail when passed into Ruby land. -- https://bugs.ruby-lang.org/ Unsubscribe: