Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Aug 1996 19:26:24 -0500
From:      Steve Price <sprice@hiwaay.net>
To:        hackers@FreeBSD.org
Subject:   To sccsid or not?
Message-ID:  <322240B0.41C67EA6@hiwaay.net>

next in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?322240B0.41C67EA6>