Re: Identical function names in bash source code

[Chet Ramey]

On 1/5/19 9:19 AM, Peng Yu wrote:
> Hi,
> 
> It is not uncommon to see the same name is used to defined functions
> in different .c files in bash source code.

"Not uncommon" is stretching it, since it happens in only one place:
lib/readline/shell.c.

> For example, sh_single_quote is defined in both lib/readline/shell.c
> and lib/sh/shquote.c with the exact same signature. The two pieces of
> code are slightly different. Do they do the exact same things or do
> something different?

In this case, they do the same thing. In others, e.g.,
sh_set_lines_and_columns, the version in readline/shell.c changes the
process's environment without using any of the shell features.


> In either case, is having the same name for different functions a good
> practice? 

Yes, if you understand the reasoning.

Readline is now distributed separately, and used in hundreds of other
applications in addition to bash, but it was not always this way.

Readline was originally part of bash, and not a library at all. It was
a single source file in the bash source directory, and, as such, there
wasn't any problem with it using internal bash APIs and manipulating
internal shell data structures directly.

When I made it a separately distributed library in 1994, accompanying
the bash-2.0 release, I removed or reworked a lot of that code, but
there was still some that was #idef SHELL. Not only was this messy, it
prevented bash from linking against an already-installed system version.

Over the next couple of years, I refactored the #ifdef SHELL code into a
set of functions, and by bash-2.05 (I didn't really look any further
back), the functions had the form they do today. Bash has its versions,
which use private bash features, and the ones in readline/shell.c are
suitable for other applications to use.

When bash links with its included copy of readline, or against an
already-installed system readline, it satisfies the symbols in readline/
shell.c internally, so the readline versions don't get linked in. When
a different application links with readline, readline resolves those
symbols.

This is standard historical Unix linker behavior, nothing exotic.

> This will make the linked binary dependent on the order of
> the corresponding .a files specified. Or if linked via .o files, then
> one function will shadow the others. See 1) and 2) below for minimal
> working examples. Neither cases seem to be good and could be avoided
> easily by giving the functions unique names.

That would defeat the purpose. If you want to use readline in your own
application, there's nothing you need to do. Bash understands what it's
doing.

> So, should such functions with the same name be named differently? 

No.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/