LIBC_SCCS

[John Baldwin]

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 */

I'd rather that we make LIBC_SCCS actually work by removing the #if 0 (and
perhaps the lint baggage) but then remove it from the default CFLAGS to
preserve the existing behavior by default. Does anyone else care if I do
this?

[Warner Losh]

Post by John Baldwin
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
#if defined(LIBC_SCCS) && !defined(lint)
#if 0
#endif
#endif /* LIBC_SCCS and not lint */
I'd rather that we make LIBC_SCCS actually work by removing the #if 0 (and
perhaps the lint baggage) but then remove it from the default CFLAGS to
preserve the existing behavior by default. Does anyone else care if I do
this?

I'm cool with it. Why not do __SCCS_ID( "@(#)kvm_hp300.c 8.1 (Berkeley)
6/4/93");?

I don't know if we need a separate #ifdef for each SCCS_ID subtree in our
build. Either it's there, or it's not. Default: not. It would also let us
put them in separate sections ala our freebsd id macros.

I'm slightly against removing it altogether, though I can see a good case
for it. I have a visceral reaction that puts me in the 'against complete
removal' camp, but only just.

Warner

[John Baldwin]

Post by Warner Losh

Post by John Baldwin
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
#if defined(LIBC_SCCS) && !defined(lint)
#if 0
#endif
#endif /* LIBC_SCCS and not lint */
I'd rather that we make LIBC_SCCS actually work by removing the #if 0 (and
perhaps the lint baggage) but then remove it from the default CFLAGS to
preserve the existing behavior by default. Does anyone else care if I do
this?

6/4/93");?

I probably would use that, though perhaps still wrapped in the #ifdef so we
don't enable them by default as __SCCS_ID is enabled by default. Alternatively
we could drop LIBC_SCCS entirely and define NO__SCCSID by default for the
affected libraries?

Post by Warner Losh
I don't know if we need a separate #ifdef for each SCCS_ID subtree in our
build. Either it's there, or it's not. Default: not. It would also let us
put them in separate sections ala our freebsd id macros.
I'm slightly against removing it altogether, though I can see a good case
for it. I have a visceral reaction that puts me in the 'against complete
removal' camp, but only just.

I probably lean towards not outright removing them, but I don't feel too
strongly.

[Mike Karels]

Post by John Baldwin
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
#if defined(LIBC_SCCS) && !defined(lint)
#if 0
#endif
#endif /* LIBC_SCCS and not lint */
I'd rather that we make LIBC_SCCS actually work by removing the #if 0 (and
perhaps the lint baggage) but then remove it from the default CFLAGS to
preserve the existing behavior by default. Does anyone else care if I do
this?

I don't object to this, but I wonder whether anyone will ever want these
ancient IDs in libc. They were useful when libc was not a shared library,
but (a) libc is shared, and (b) the sccsid is not changing much, at least
not for the last 25 years. But "#ifdef LIBC_SCCS" is as good a way as
any to turn this into a comment.

You picked an interesting example; I wonder when someone last ran a
BSD system on an HP 300. IIRC, it was a 68030-based system.

Mike

[Warner Losh]

Post by Mike Karels
You picked an interesting example; I wonder when someone last ran a
BSD system on an HP 300. IIRC, it was a 68030-based system.

A buddy of mine moved out of his college apartment maybe 10 years ago. He
had several HP 68k machines that went to recycling, but a few that he
retained since they still worked and were running OpenBSD.

Warner

[Bruce Evans]

Post by John Baldwin
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
#if defined(LIBC_SCCS) && !defined(lint)
#if 0
#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.

style(9) says to use '#if 0', but not as above. It says to put the #if 0
around everything, but only if there is not already a suitable ifdef like
the LIBC_SCCS one.

The above style is apparently from NetBSD. It is now used a lot on libedit,
with further ugliness and bugs:
- first there is an #if-#else clause with a NetBSD __RCSID() in the #else
clause, so that the #if 0 selects between the sccsid and the NetBSD id
- __RCSID() may be killed by defining NO__RCSID. It is a bug that the
application identifier NO__RCSID affects and system header. sys/cdefs.h
is an especially important system header and is one of the few that tries
to avoid namespace pollution bugs like this. The default is to keep the
NetBSD id.
- after this idfef tangle, there is an unconditional __FBSDID() to give the
FreeBSD id
- __FBSDID() may also be killed by defining either lint or STRIP_FBSDID.
sys/cdefs.h is actually careless about namespace pollution bugs like this.

Post by John Baldwin
I'd rather that we make LIBC_SCCS actually work by removing the #if 0 (and
perhaps the lint baggage) but then remove it from the default CFLAGS to
preserve the existing behavior by default. Does anyone else care if I do
this?

I don't mind removing FreeBSD mistakes like the '#if 0'. Editing to add
const poisoning is hopefully not often needed.

Bruce

[Brooks Davis]

Post by Bruce Evans

Post by John Baldwin
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
#if defined(LIBC_SCCS) && !defined(lint)
#if 0
#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

[John Baldwin]

Post by Brooks Davis

Post by Bruce Evans

Post by John Baldwin
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
#if defined(LIBC_SCCS) && !defined(lint)
#if 0
#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.

I have a review for libkvm (which has many smaller examples than libc) at
https://reviews.freebsd.org/D15459 for any folks who are interested. It
uses __SCCSID() but then disables them by default via -DNO__SCCSID.