[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bash-bug
Subject:    Re: Re: [PATCH 1/9] builtins: extract file content executor function
From:       Koichi Murase <myoga.murase () gmail ! com>
Date:       2024-05-08 7:59:52
Message-ID: CAFLRLk9a8-ZhpFKsnAiOkWHYXyTUG9eOwsGuCok4KLRhCDt6Gw () mail ! gmail ! com
[Download RAW message or body]

2024=E5=B9=B45=E6=9C=888=E6=97=A5(=E6=B0=B4) 6:13 Matheus Afonso Martins Mo=
reira <matheus@matheusmoreira.com>:
> > By exposing this function in `common.h',
> > this effectively becomes a part of the public
> > interface for loadable builtins.
>
> [...]
>
> Are all external functions defined in all files inside the
> builtins directory exposed as part of a public API/ABI?

No.

> If that's the case, then it should also be made static
> as you suggested.

Even if it's not the case, I think one should mark it as `static' as
far as the function is not used by other translation units. Even if
it's not the interface exposed to the users, it's still an interface
for other translation units, and it's a premature exposition of
abstraction at present. No other translation units are using the
function.

> Can you break down for me which parts of the code base
> are public and which are private? This will allow me to
> avoid making such mistakes in the future.

You can check /examples/loadables/loadables.h in the tree. The headers
included from there (and further headers included thereby) are
explicitly the interface that the users can use to implement a
loadable builtin. For a wider public interface, you can look inside
the directory `$prefix/include/bash' (and subdirectories therein)
after running `make install'.

> I'd also like to suggest creating a private commons.c
> file where potentially reusable functionality can be
> moved to without exporting them.

I think such a feature should go into a related file in the main directory.

[prev in list] [next in list] [prev in thread] [next in thread]