Date: Thu, 28 Dec 1995 12:53:35 +0100
From: Mailer-Daemon@oeillet.saclay.cea.fr (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <199512281153.MDO17889@oeillet.saclay.cea.fr>
To: <owner-kerberos@MIT.EDU>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="MDO17889.820151615/oeillet.saclay.cea.fr"

This is a MIME-encapsulated message

--MDO17889.820151615/oeillet.saclay.cea.fr

The original message was received at Sat, 23 Dec 1995 17:30:18 +0100
from trefle.saclay.cea.fr [132.166.192.212]

   ----- The following addresses had delivery problems -----
<zucco@gardenia.saclay.cea.fr>  (unrecoverable error)

   ----- Transcript of session follows -----
<zucco@gardenia.saclay.cea.fr>... Deferred: Connection timed out with gardenia.saclay.cea.fr.
Message could not be delivered for 3 days
Message will be deleted from queue

   ----- Original message follows -----

--MDO17889.820151615/oeillet.saclay.cea.fr
Content-Type: message/rfc822

Return-Path: <owner-kerberos@MIT.EDU>
Received: from trefle.saclay.cea.fr by oeillet.saclay.cea.fr
	(8.6.10/ CEANET-ROUTER-3.0) with ESMTP id RAA18209
	for <zucco@gardenia.saclay.cea.fr>; Sat, 23 Dec 1995 17:30:18 +0100
Received: from MIT.EDU by trefle.saclay.cea.fr
	(8.6.10/ CEANET-ROUTER-3.0) with SMTP id RAA19237
	for <zucco@gardenia.saclay.cea.fr>; Sat, 23 Dec 1995 17:29:03 +0100
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
	id AA18931; Sat, 23 Dec 95 11:08:38 EST
Received:  by pad-thai.cam.ov.com (8.6.12/)
	id <LAA13059@pad-thai.cam.ov.com>; Sat, 23 Dec 1995 11:11:39 -0500
Received: from GATEWAY by pad-thai.cam.ov.com with netnews
	for kerberos-wrapper@cam.ov.com (kerberos@mit.edu)
To: kerberos@MIT.EDU
Date: 23 Dec 1995 11:05:06 -0500
From: tls@rek.tjls.com (Thor Lancelot Simon)
Message-Id: <4bh9bi$a2@fearsome.tjls.com>
Organization: Never!
Sender: usenet@cam.ov.com
Subject: C_Block is a struct or a pointer?

I've been hacking on an eBones-derived krb4 lately and am on the verge of
tearing my hair out after suddenly realizing why all the prototypes in the
header files didn't match the actual functions.

All the header files had most of the functions taking pointers to struct
des_cblock when they wanted to throw cblock structures around.

Inside the libraries, of course, C_Block is used instead of des_cblock.

The des.h that came as part of the Young libdes that generally is used with
eBones #defines C_Block to des_cblock.

So to get the libraries to compile cleanly, I of course went and fixed all the
"incorrect" prototypes in the header files -- I was fixing a bunch of data
type mistakes anyway, so while I was a bit surprised at the pervasiveness of
the des_cblock vs des_cblock * chaos, I wasn't _too_ surprised.

I then went to make sure the utilities compiled and realized that they didn't
use C_Block, they used des_cblock, and they seemed to assume that the library
functions took des_cblock * where internally they used C_Block.

Of course, all of this nonsense _worked_ if one just ignored the compiler
warnings either when building the libraries or when building the programs --
presumably because GCC passes pointers instead of structures and dynamically
allocates the storage?

I am now about to go reverse the changes I made to the header files and go
fix the libdes I'm using.  Before I do that, I'd like to get confirmation from
someone more familiar with the krb4 internals that C_Block is in fact supposed
to be a pointer to a structure, not the structure itself -- and if I'm wrong,
perhaps a hint as to why all the header files are mistaken!

Is this mistake endemic to all eBones implementations?  Or am I just using an
old or strangely hacked Young libdes?
-- 
Thor Lancelot Simon                                             tls@rek.tjls.com

   Where is the day that melted into one rich noise?          --Thomas Wolfe

--MDO17889.820151615/oeillet.saclay.cea.fr--