LIBC_SCCS

[Brooks Davis]

On Sat, Apr 28, 2018 at 11:39:02AM +1000, Bruce Evans wrote:
> On Fri, 27 Apr 2018, John Baldwin wrote:
> 
> > I suspect no one cares, but for whatever reason our current handling of the
> > LIBC_SCCS macro in some of our libraries annoys me.  In theory it seems like
> > LIBC_SCCS's purpose is to control whether or not old SCCS IDs from Berkeley
> > are included in libc's sources when libc is built.  (Similar to how macros
> > control the behavior of __FBSDID().)  However, we use an odd construct in
> > the tree.  First, we define LIBC_SCCS by default in the CFLAGS of various
> > libraries (libkvm, libutil, libthr, libc, etc.) which in theory would enable
> > the IDs, but then we explicitly wrap them in #if 0, e.g.:
> >
> > #if defined(LIBC_SCCS) && !defined(lint)
> > #if 0
> > static char sccsid[] = "@(#)kvm_hp300.c 8.1 (Berkeley) 6/4/93";
> > #endif
> > #endif /* LIBC_SCCS and not lint */
> 
> Most aren't actually wrapped with '#if 0'.  E.g., in libc/*/*.c there are
> 839 files but only 47 of these have any '#if 0' at all.  SO this can be
> fixed without much churn.
> 
> I thought there is a problem with the above not actually compiling if
> LIBC_SCCS is defined, but WARNS is only 2 for libc and it takes WARNS >= 4
> to give -Wwrite-strings.

At higher WARNS levels the ones without #if 0 also warn about unused
static variable.  If we're going to keep them, using an __FBSDID()-like
macro seems like the best option so that's easy to make correct and
doesn't require churn if compilers change.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20180501/4511d5f8/attachment.sig>