LIBC_SCCS

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

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?

--
John Baldwin
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: LIBC_SCCS

Mike Karels-2
> 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?

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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: LIBC_SCCS

Warner Losh
In reply to this post by John Baldwin
On Fri, Apr 27, 2018 at 4:19 PM, John Baldwin <[hidden email]> 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 */
>
> 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: LIBC_SCCS

Warner Losh
In reply to this post by Mike Karels-2
On Fri, Apr 27, 2018 at 5:23 PM, Mike Karels <[hidden email]> wrote:

> 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: LIBC_SCCS

Bruce Evans-4
In reply to this post by John Baldwin
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.

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.

> 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: LIBC_SCCS

John Baldwin
In reply to this post by Warner Losh
On Friday, April 27, 2018 05:36:56 PM Warner Losh wrote:

> On Fri, Apr 27, 2018 at 4:19 PM, John Baldwin <[hidden email]> 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 */
> >
> > 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 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?

> 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.

--
John Baldwin
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: LIBC_SCCS

Brooks Davis-2
In reply to this post by Bruce Evans-4
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

signature.asc (465 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: LIBC_SCCS

John Baldwin
On Tuesday, May 01, 2018 09:53:03 PM Brooks Davis wrote:

> 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.

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.

--
John Baldwin
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"