ruby/ruby.h: remove unnecessary exports from C-API
Needlessly exporting can reduce performance locally and increase binary size.
Increasing the footprint of our C-API larger is also detrimental to our development as it encourages tighter coupling with our internals; making it harder for us to preserve compatibility.
If some parts of the core codebase needs access to globals, internal.h should be used instead of anything in include/ruby/*.
Why are we exporting all these and making the public C-API bigger? If anything, we should make these static. Thanks.
No concrete reason, except they have already been externed in 2.5. These variables had lacked declarations so far, which resulted in their visibility to be that of extern. The commit is just confirming the status quo.
I'm not against to turn them into static.
This reverts changes from r61910, r61909, r61908, r61907, and r61906.
transcode.c (rb_eUndefinedConversionError): make static (rb_eInvalidByteSequenceError): ditto (rb_eConverterNotFoundError): ditto
ruby/ruby.h: remove unnecessary exports from C-API
Needlessly exporting can reduce performance locally and increase
binary size.
Increasing the footprint of our C-API larger is also detrimental
to our development as it encourages tighter coupling with our
internals; making it harder for us to preserve compatibility.
If some parts of the core codebase needs access to globals,
internal.h should be used instead of anything in include/ruby/*.
"Urabe, Shyouhei" shyouhei@ruby-lang.org wrote:
This reverts changes from r61910, r61909, r61908, r61907, and r61906.
(rb_eInvalidByteSequenceError): ditto
(rb_eConverterNotFoundError): ditto
[Misc #14381]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62029 b2dd03c8-39d4-4d8f-98ff-823fe69b080e