svn commit: r240675 - in projects/mtree: include lib/libc/gen

[Brooks Davis]

On Wed, Sep 19, 2012 at 09:42:54PM +0200, Jilles Tjoelker wrote:
> On Tue, Sep 18, 2012 at 08:28:01PM +0000, Brooks Davis wrote:
> > Author: brooks
> > Date: Tue Sep 18 20:28:01 2012
> > New Revision: 240675
> > URL: http://svn.freebsd.org/changeset/base/240675
> 
> > Log:
> >   Implement VIS_GLOB support including compatibilty symbols required by
> >   overlapping flags between FreeBSD and NetBSD.
> 
> >   Add a compatibility symbol for unvis() due to NetBSD's allocation of
> >   a flag value for UNVIS_END rather than just using 1.
> 
> >   Add symbol version entries for new vis and unvis functions.
> 
> > [snip]
> > Modified: projects/mtree/include/vis.h
> > ==============================================================================
> > --- projects/mtree/include/vis.h	Tue Sep 18 20:20:29 2012	(r240674)
> > +++ projects/mtree/include/vis.h	Tue Sep 18 20:28:01 2012	(r240675)
> > @@ -62,6 +62,7 @@
> >  #define	VIS_HTTP1866	0x200	/* http-style &#num; or &string; */
> >  #define	VIS_NOESCAPE	0x400	/* don't decode `\' */
> >  #define	_VIS_END	0x800	/* for unvis */
> > +#define	VIS_GLOB	0x1000	/* encode glob(3) magics */
> >  
> >  /*
> >   * unvis return codes
> > 
> > [snip]
> 
> Is it really necessary to be binary compatible with NetBSD in the VIS_*
> constants or is it possible to keep our values for the VIS_* constants
> we already have?
> 
> While symbol versioning works, it leaves additional code around forever,
> which would not be necessary if compatibility had been kept.

For the vis(3) functions we could instead alter all the flags to retain
compatibility to avoid the (very trivial) wrapper.  Unfortunately, I think
we should adopt their UNVIS_END change since it is obviously more correct
and that does require a version change.  There is probably an argument
for splitting the difference.  I argued with my self a fair bit before
decided to go the versioned route since that would reduce diffs to the
upstream, but it could go ether way.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-projects/attachments/20120919/3278140b/attachment.pgp