From owner-freebsd-hackers  Mon Aug 26 17:27:54 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id RAA26906
          for hackers-outgoing; Mon, 26 Aug 1996 17:27:54 -0700 (PDT)
Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [204.214.4.2])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA26900
          for <hackers@FreeBSD.org>; Mon, 26 Aug 1996 17:27:51 -0700 (PDT)
Received: from max3-189.HiWAAY.net by fly.HiWAAY.net; (5.65/1.1.8.2/21Sep95-1003PM)
	id AA20931; Mon, 26 Aug 1996 19:27:44 -0500
Message-Id: <322240B0.41C67EA6@hiwaay.net>
Date: Mon, 26 Aug 1996 19:26:24 -0500
From: Steve Price <sprice@hiwaay.net>
Reply-To: sprice@hiwaay.net
X-Mailer: Mozilla 2.02 (X11; I; FreeBSD 2.2-CURRENT i386)
Mime-Version: 1.0
To: hackers@FreeBSD.org
Subject: To sccsid or not?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

Hi,

I've been tooling around with the source in /bin/* to get it compile
without any warnings using the -Wall command line option (also to get
all the /bin/* code up to Lite2 status).  I have already given a set
of patches for /bin/sh to Joerg (which he gratiously agreed to get in
as soon as he has time to breathe :).

I have a tiny stumbling block in my path that I thought I would run
by everybody.  It involves sccsid's.

My impression of why the sccsid's are in the code is two-fold:

	1) Lite2 has them (well mostly to maintain small diffs
	   from the Lite2 base :)

	2) to be able to run what(1) over the source and executable

As for number 1, I would like to leave them there as well, but I *hate*
seeing warnings from any compiled code.  These warnings generally
(but not always, at least not in this case) suggest that there are
critters lurking in the code.  Please, nobody take offense, read on. :)

As for number 2, what(1) states:

	What reads each file name and searches for sequences of the
	form ``@(#)''...

Aha!  Maybe there's an out.  That is, there's seemingly a way around
the warnings surrounding sccsid's.  So here's my take and the reason
for this e-mail (to get everybody's opinion).  I can think of at
least the three following paths:

	1) Remove the sccsid defines and put them near the bottom
	   of the copyright notice, as they are in most header files.

	2) Change the name from  'sccsid' to 'filename_id'.  For
	   example, in cp.c the sccsid define would now look like:

		static const char cp_c_id[] = ``@(#)cp.c ...'';

	   Note the addition of 'const', so the compiler won't
	   complain any more.

	3) Leave things alone and learn to live with the warnings. :(

The problem with the first approach is that what(1) can now only be run
on the source files and not on the executable.

The second approach maintains the intent of the original code (only
the name is changed to protect the innocent or is that guilty 8).

You probably can guess my opinion on the third approach.

IMHO, the first approach seems to be the cleaner one.  Any thoughts?


Steve