Message-ID: <3638721B.B112F405@montana.com>
Date: Thu, 29 Oct 1998 06:48:11 -0700
From: bowman <bowman AT montana DOT com>
X-Mailer: Mozilla 4.5b2 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: djgpp AT delorie DOT com
Subject: Re: C++ with DJGPP
References: <363532BA DOT 6FA0626F AT erols DOT com> <gunaalubzrpbz DOT f1gwzw0 DOT pminews AT news DOT avnl1 DOT nj DOT home DOT com> <7144gm$i1n$1 AT star DOT cs DOT vu DOT nl> <gunaalubzrpbz DOT f1hyic2 DOT pminews AT news DOT avnl1 DOT nj DOT home DOT com> <36365A5B DOT D92F78D7 AT cartsys DOT com> <gunaalubzrpbz DOT f1if2m0 DOT pminews AT news DOT avnl1 DOT nj DOT home DOT com> <3637F2A9 DOT 97A150DA AT cartsys DOT com> <gunaalubzrpbz DOT f1kwom2 DOT pminews AT news DOT avnl1 DOT nj DOT home DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp AT delorie DOT com



Mike Ruskai wrote:
> 
> What possessed you to make such a claim.  This very thread was begun because
> of the fact that '#include  <streambuf.h>' does not in fact work equally well
> with or without long filenames.

I would like to throw in an instance I recently encountered. The code in
question
had a common makefile that was included into all the other makefiles, as
well as 
the .in file to produce it with autoconf.

The filenames were Make.common and Make.common.in. On a 8.3 DOS system,
these were truncated
to the very unfortunate 'MAKE.COM' by pkunzip.