From xemacs-m  Fri Mar 14 21:39:43 1997
Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id VAA14795
	for <xemacs-beta@xemacs.org>; Fri, 14 Mar 1997 21:39:42 -0600 (CST)
Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1])
	by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id WAA20984;
	Fri, 14 Mar 1997 22:39:33 -0500
Message-Id: <199703150339.WAA20984@black-ice.cc.vt.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
To: wmperry@aventail.com
Cc: xemacs-beta@xemacs.org
Subject: Re: Cruft I found in glyphs-x.c... 
In-Reply-To: Your message of "Fri, 14 Mar 1997 15:04:18 PST."
             <199703142304.PAA09195@newman> 
From: Valdis.Kletnieks@vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <199703142155.QAA25056@black-ice.cc.vt.edu>
            <199703142304.PAA09195@newman>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-552616190P";
	micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Fri, 14 Mar 1997 22:39:28 -0500

--==_Exmh_-552616190P
Content-Type: text/plain; charset=us-ascii

On Fri, 14 Mar 1997 15:04:18 PST, "William M. Perry" said:
> Valdis.Kletnieks@vt.edu writes:
> >I found this in glyphs-x.c for 20.1-b6.  Anybody want to comment on what
> >the status is now?
> 
>   Still broken.  Wanna fix it?

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

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

Typical example:

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

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

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

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

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


/Valdis



--==_Exmh_-552616190P
Content-Type: application/pgp-signature

-----BEGIN PGP MESSAGE-----
Version: 2.6.2

iQCVAwUBMyoZ7tQBOOoptg9JAQEO6QP8DUbLG6Fu7I8oWgzASg7g1wyQHf3fTiAh
WkScV5CbilUVqWsAtTdDCGuPrGfL6iPXO1zw88n5FjPvbO/Nk1au8PHt4JvbMDnP
sqLTO8VmczPdwM9U6C4BoprPl4kVMDtcIZ/pg1jz0gauM0mi8ydw2pY1H12tCfSE
0Aj5YEmA/Bk=
=EROW
-----END PGP MESSAGE-----

--==_Exmh_-552616190P--

