Re: [patches] Git repository

["Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>]

On Fri, 8 May 2009, Joseph S. Myers wrote:

> On Fri, 8 May 2009, Heikki Orsila wrote:
> 
> > I was very pleased to hear that eglibc project exists. I have two 
> > issues / suggestions:
> > 
> > 1. Would you accept strlcpy()/strlcat() functions into eglibc?
> > 
> > 	http://www.rocketaware.com/man/man3/strlcpy.3.htm
> 
> Adding new functions to the exported interface (for platforms supported by 
> FSF glibc) is a bad idea; we cannot assign GLIBC_* symbol versions, there 
> is no good reason for these functions to be static-only and if they were 
> added with an EGLIBC_* symbol version, even in a disabled-by-default 
> option group, it would inevitably lead to unwanted incompatibilities of 
> binaries between GNU/Linux distributions.

To clarify this: in general the compatibility principle is for the default 
configuration, and just as disabling enabled-by-default option groups will 
remove symbols, it is possible that disabled-by-default options groups 
might be added in future that will add symbols if enabled, and any such 
symbols will have appropriate EGLIBC_* symbol versions; configurations for 
(sub)targets not supported by FSF glibc may also sometimes have 
target-specific symbols (the e500 port has a few).  But such symbols are 
likely to be for comparatively specialized new functionality that would be 
documented as EGLIBC-specific and specific to those option groups; adding 
features from other operating systems that way would be problematic 
because of the likelihood of incompatibilities resulting.

If I maintained FSF glibc, I'd have added these functions long ago 
(unconditionally); I think they are used widely enough to justify their 
inclusion, despite the problems with them that mean there are generally 
more efficient ways of writing code while avoiding arbitrary limits.  But 
I don't maintain FSF glibc, and while there are many improvements that can 
be made without compatibility concerns, not all possible improvements can 
be.

-- 
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx