From:	skb AT xmission DOT com (Scott Brown)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: LFNs, timeslices and the preprocessor
Date:	Mon, 23 Oct 2000 06:55:26 GMT
Organization:	(none)
Lines:	31
Message-ID:	<39f3b441.847873445@198.60.22.3>
References:	<39f23421 DOT 749522025 AT 198 DOT 60 DOT 22 DOT 3> <8366mkafrz DOT fsf AT mercury DOT st DOT hmc DOT edu>
NNTP-Posting-Host:	slc259.modem.xmission.com
X-Trace:	news.xmission.com 972284556 16130 166.70.2.5 (23 Oct 2000 07:02:36 GMT)
X-Complaints-To:	abuse AT xmission DOT com
NNTP-Posting-Date:	23 Oct 2000 07:02:36 GMT
X-No-Archive:	Yes
X-Newsreader:	Forte Free Agent 1.21/32.243
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

On 22 Oct 2000 11:32:00 -0700, Nate Eldredge <neldredge AT hmc DOT edu>
wrote:

>skb AT xmission DOT com (Scott Brown) writes:
>> Is there a reliable way to detect whether long filenames are supported?
>
>`_use_lfn'

That's just what I need.  Thanks.

The _use_lfn documentation has a note to the effect that all
filesystems under Win9x support LFNs, and suggests the use of the
_USE_LFN macro instead of calling _use_lfn directly.  There is no
mention of non-native filesystems like network drives and CDROMs.
Does _use_lfn return accurate info in all circumstances?

>> BC to GCC).  What else would be a good way to test the size of a type
>> at compile time (e.g. to make sure that long is exactly 32 bits)?  I
>> could check it with sizeof at runtime, but that would be nasty.
>
>GNU programs do it with a configure script, which compiles a small
>program which outputs the size, and then adds the value to a header.
>
><limits.h> has things like INT_MAX, which you can probably use.

A config script sounds like the only reliable way to handle it.
Offhand I can think of at least one obvious way that comparing INT_MAX
to a literal can fail to do what it's meant to do.

Thanks very much for the information.

- Raw text -