Skip Menu |

Download (untitled) / with headers
text/plain 2.6KiB
From tlyu@MIT.EDU Tue Nov 12 15:51:59 1996
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU []) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id PAA28063 for <bugs@RT-11.MIT.EDU>; Tue, 12 Nov 1996 15:51:59 -0500
Received: from TESLA-COIL.MIT.EDU by MIT.EDU with SMTP
id AA19467; Tue, 12 Nov 96 15:51:58 EST
Received: by tesla-coil.MIT.EDU (5.x/4.7) id AA16786; Tue, 12 Nov 1996 15:51:57 -0500
Message-Id: <9611122051.AA16786@tesla-coil.MIT.EDU>
Date: Tue, 12 Nov 1996 15:51:57 -0500
From: tlyu@MIT.EDU
Reply-To: tlyu@MIT.EDU
To: krb5-bugs@MIT.EDU
Subject: NEAR, FAR not properly defined when header files
X-Send-Pr-Version: 3.99

Show quoted text
>Number: 177
>Category: krb5-libs
>Synopsis: NEAR, FAR not properly defined when header files
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: basch
>State: closed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Tue Nov 12 15:52:01 EST 1996
>Last-Modified: Sun Feb 16 18:17:43 EST 1997
>Originator: "Jonathan I. Kamens" <>
Show quoted text
>Release: 1.0-development

System: SunOS tesla-coil 5.4 Generic_101945-37 sun4m sparc

Show quoted text
[2251] daemon@ATHENA.MIT.EDU (Jonathan I. Kamens) Kerberos-V5-bugs 09/22/96 12:58 (25 lines)
Subject: krb5-beta7: NEAR, FAR not properly defined when header files
Date: Sun, 22 Sep 1996 12:53:57 -0400
From: "Jonathan I. Kamens" <>
To: krb5-bugs@MIT.EDU, kerberos@MIT.EDU

If I preprocess this file:

#include <kerberosIV/krb.h>
#include <com_err.h>
#include <krb5.h>


The last line of the preprocessor output contains "NEAR". If,
however, I swap <com_err.h> and <krb.h>, the last line of the
preprocessor output is (correctly) blank.

All of the preprocessor stuff in the various header files is so hairy
and disgusting that I had to spend quite a while just figuring out
this problem. I assume there's someone at MIT who came up with the
idea of putting the same stuff in N different header files and who
understands how it's all supposed to work; that person will probably
be able to fix this problem far more quickly than I can, so I leave it
to him to come up with a patch.


Show quoted text

Show quoted text
[Wed Jan 29 20:59:20 EST 1997 Richard Basch]
This has been fixed for awhile in the V1_0_WIN32_BRANCH.
When that branch is merged in with the mainline (after the win16
portion of it is fully tested), there should be no further problem.
Show quoted text

*** Sun Feb 16 18:16:46 EST 1997 *** probe
This is fixed in 1.0, the NT snapshot, and the current mainline.