Misc #14381: [PATCH] ruby/ruby.h: remove unnecessary exports from C-API

• Status: Closed
• Assignee: shyouhei (Shyouhei Urabe)

[normalperson (Eric Wong)]

Note this depends on r61995, will wait a few days for review
(ENOSPC on my end to run gem-codesearch)

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" <[e-mail]> wrote:
> On Thu, Jan 18, 2018 at 7:33 PM, Eric Wong <[e-mail]> wrote:
> > [e-mail] wrote:
> >>   https://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=revision&revision=61908
> >>
> >>     export rb_mFConst
> >
> > 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
* process.c (rb_mProcGID, rb_mProcUid, rb_mProcID_Syscall): ditto
* file.c (rb_mFConst): ditto
* error.c (rb_mWarning, rb_cWarningBuffer): ditto
* enumerator.c (rb_cLazy): ditto

[shyouhei (Shyouhei Urabe)]

Ack. Like I said I have no strong opinion on this.

• Status changed from Open to Closed

Applied in changeset trunk|r62029.

---

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" [e-mail] wrote:

On Thu, Jan 18, 2018 at 7:33 PM, Eric Wong [e-mail] wrote:

[e-mail] wrote:

https://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=revision&revision=61908

export rb_mFConst

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
• process.c (rb_mProcGID, rb_mProcUid, rb_mProcID_Syscall): ditto
• file.c (rb_mFConst): ditto
• error.c (rb_mWarning, rb_cWarningBuffer): ditto
• enumerator.c (rb_cLazy): ditto
  [Misc #14381]