From xemacs-m  Fri Mar 14 22:35:33 1997
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5])
	by xemacs.org (8.8.5/8.8.5) with SMTP id WAA15170
	for <xemacs-beta@xemacs.org>; Fri, 14 Mar 1997 22:35:32 -0600 (CST)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA17564; Fri, 14 Mar 1997 20:34:59 -0800
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id UAA21583; Fri, 14 Mar 1997 20:34:56 -0800
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id UAA05703; Fri, 14 Mar 1997 20:34:47 -0800
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id UAA04937; Fri, 14 Mar 1997 20:34:53 -0800
Date: Fri, 14 Mar 1997 20:34:53 -0800
Message-Id: <199703150434.UAA04937@xemacs.eng.sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: Valdis.Kletnieks@vt.edu
Cc: wmperry@aventail.com, xemacs-beta@xemacs.org
Subject: Re: Cruft I found in glyphs-x.c... 
In-Reply-To: <199703150339.WAA20984@black-ice.cc.vt.edu>
References: <199703142155.QAA25056@black-ice.cc.vt.edu>
	<199703142304.PAA09195@newman>
	<199703150339.WAA20984@black-ice.cc.vt.edu>
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>

>>>>> "Valdis" == Valdis Kletnieks <Valdis.Kletnieks@vt.edu> writes:

Valdis> Umm.. I'll look around and see what other #### stuff looks more interesting ;)

Valdis> In an actually related issue, could the person (attribution lost) who was
Valdis> doing the patch to get a clean compile with C++ toss me a copy?  While in
Valdis> search of the cause of the LV_LV locale problem, I happened to discover that
Valdis> the AIX 'xlc' compiler thought there were a bunch of missing prototypes
Valdis> (bad, but mostly against stand-alone stuff like etags and the like),
Valdis> and *conflicting* prototypes between modules.  I'm currently sorting this
Valdis> out, and trying to figure out which are problems and which aren't.

etags.c is owned and maintained by Fransesco Potorti.  He deliberately
keeps this file written in K&R style.  I have not C++-ized the lib-src directory.

Valdis> Typical example:

Valdis> in ralloc.c, we had a declaration
Valdis> void r_alloc_free (POINTER *ptr);

Valdis> but in buffer.h, it was declared as
Valdis> void r_alloc_free (void **);

Valdis> so that's the prototype that insdel.c ended up using.

I've placed a copy of CC.diff in
ftp://ftp.xemacs.org/pub/beta/incoming/CC.diff

Please don't do any code cleanup without CC.diff applied.  r_alloc and
friends have fixes in CC.diff.  Many other little things have been
tightened up.  CC.diff won't be in the main distribution until after
20.1 is released.  It's best to wait until then.

Valdis> I'm sure that most of these are innocuous, but I keep wondering if some
Valdis> of the flakier bugs we see are caused by compilers doing Bad Things when
Valdis> lied to. ;)  The IBM xlc documentation comes right out and *says* that
Valdis> at -O3, it uses the prototypes to help decide if it has to worry about
Valdis> aliasing screws.  Very odd.. ;)

Valdis> As an aside, does anybody else think it's worth the effort for me to go
Valdis> through and clean this all up to the point of no compiler warnings?  The
Valdis> odd part is that of all the stuff the IBM compilers found, only a few
Valdis> missing prototypes in unexaix.c are IBM-specific - so this stuff might
Valdis> be biting other people too...

Obviously I think it's worth the effort, but complete elimination of
warnings is often simply impossible, or not worth it.  For example, if
elimination of warnings means excessive additions of compiler-specific
ifdef's to the code, then NO.  The final goal should be high quality
readable and maintainable code, not elimination of warnings.  For the
primary maintainers, a clean compile is more important (to catch newly
introduced errors).

Martin

