From: Martin Str|mberg <ams AT ludd DOT luth DOT se>
Message-Id: <200006091807.UAA13129@father.ludd.luth.se>
Subject: Re: LONG: fat32 diff in cvs
In-Reply-To: <200005302118.AAA13852@mailgw1.netvision.net.il> from Eli Zaretskii at "May 31, 2000 00:17:29 am"
To: djgpp-workers AT delorie DOT com
Date: Fri, 9 Jun 2000 20:07:05 +0200 (MET DST)
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

According to Eli Zaretskii:
> > No, I don't think so. The functions _is_fat32() and _get_fat_size() is
> > very similar in function. But the _get_fs_type() function isn't
> > necessarily so - it just takes whatever happens to be in a certain
> > part of the disk; we are lucky it usually works out as FAT<something>
> > for FAT partitions, but the specification clearly states that this
> > string has nothing to do with the actual file system type (it advices
> > against relying on this information). This would of course mean that
> > _is_fat32() and _get_fat_size() break if this convention isn't adhered
> > to, but what can we do...

Hmmm, thinking it over, I think you can depend on that a FAT
filesystem will generate something starting with "FAT"; it's the
number after "FAT" that you can't depend on.

> Well, the above is the explanation that I think will help users to
> understand what function to use in which case.  That's what I thought
> was missing from the current docs.

Hmm. I'm not sure how or where I should put that in.

As a matter of fact, thinking about it, I think it would be better to
improve each function's description so the user would know if a
certain function is what he wants. Wouldn't it? That would mean that
there some ambiguity in the docs today.

Meanwhile you can look at the diff of wc204.txi. I'm open to
suggestions to make it better.


Right,

							MartinS

Index: djgpp/src/docs/kb/wc204.txi
===================================================================
RCS file: /cvs/djgpp/djgpp/src/docs/kb/wc204.txi,v
retrieving revision 1.1
diff -p -3 -r1.1 wc204.txi
*** wc204.txi   2000/05/30 18:07:38     1.1
--- wc204.txi   2000/06/09 17:54:20
***************
*** 1,7 ****
  @node Changes in 2.04, , Changes in 2.03, What Changed
  @section Changes in 2.04

! Here is a list of changes from DJGPP V2.03 to V2.04.

  @findex uname AT r{, CPU type detection}
! Ability to report the exact CPU type in @code{uname}.
--- 1,35 ----
  @node Changes in 2.04, , Changes in 2.03, What Changed
  @section Changes in 2.04

! Here is a list of changes from DJGPP V2.03 to V2.04.

  @findex uname AT r{, CPU type detection}
! Ability to report the exact CPU type in @code{uname}.
!
! @findex _creat AT r{, FAT32}
! @findex _creatnew AT r{, FAT32}
! @findex _open AT r{, FAT32}
! Set extended size flag in interrupt calls to be able to create files
! with size up to 2^32-1.
!
! @findex llseek AT r{, FAT32}
! Function added with type @code{offset_t} to support file seeks up to
! 2^32-2.
!
! @findex statfs AT r{, FAT32}
! Made to report correct values > 2^31 on FAT32 partitions.
!
! @findex _invent_inode AT r{, FAT32}
! Changed start of invented inodes from @code{USHRT_MAX+1} to
! @code{2^28+1}.
!
! @findex _is_cdrom_drive
! @findex _is_ram_drive
! @findex _media_type
! Functions taken out of @file{mntent.c} and made externally callable.  
!
! @findex _get_fat_size
! @findex _get_fs_type
! @findex _is_fat32
! New functions added.
!