delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2000/05/30/13:49:29

From: Martin Str|mberg <ams AT ludd DOT luth DOT se>
Message-Id: <200005301749.TAA27937@father.ludd.luth.se>
Subject: Re: LONG: fat32 diff in cvs
In-Reply-To: <Pine.SUN.3.91.1000530132402.1964B-100000@is> from Eli Zaretskii at "May 30, 2000 01:43:02 pm"
To: djgpp-workers AT delorie DOT com
Date: Tue, 30 May 2000 19:49:08 +0200 (MET DST)
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
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

According to Eli Zaretskii:
> On Tue, 30 May 2000, Martin Stromberg wrote:
> > > > + int _get_fs_type( const int drive
> > > > +                 , char *const result_str
> > > > + 	         );

The line above this line has been mangeled by
mail-reader/posters. It's supposed to be:
> > > > +                 );

> > > > + @end example
> > > 
> > > Why this strange format?
> > 
> > It's very good patch-wise.

I forgot to say it also is good edit-wise.

> But it looks ugly (IMHO), both in the Info file and in the printed 
> version, since an @example block isn't filled.

I think it looks beautiful, lines up perfectly! In the source at least
but the translation to texinfo messes it up a little:

     int _get_fs_type( const int drive
                     , char *const result_str
                 );

How do I make the ");" part align on "(
                                      ,"? Or can't I?

> > > Btw, it looks like there's a whole slew of functions that can be used
> > > to find out the filesystem properties, in particular whether it is or
> > > isn't FAT32.  How about adding cross-references between them, and some
> > > short discussion of their relative merits?  Some user might become
> > > really confused when faced with a decision which function(s) to use.
> > 
> > Ok. Where should this short discussion be put?
> 
> I suggest to put it with one of the functions, and make a cross-reference 
> from others to that function.

I would rather put it in a separate part, if it's ok... Can I? How?

> > Regarding detecting FAT32, I don't follow you. For FAT32 you should
> > use _is_fat32().
> 
> _get_fat_size and _get_fs_type seem to have similar functionality, no?
> They surely return enough info to be able to distinguish FAT32 disks from 
> the others, at least as far as I follow the docs.

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...

But I agree an explanation when to use which would be good.

> > Ooops! I've only used one space everywhere while writing the texinfo
> > files.
> 
> Yes, I know; it's typical for European culture.  I usually don't comment 
> on that, and instead correct it silently.  However, since you are now an 
> official libc maintainer...
> 
> > Where are such _crucial_ things documented?
> 
> In the Texinfo manual, of course.

Of course. But the texinfo format is easy to learn by example (as I
have) so having this really strange typographical rule, seems quite
(hmmm... what's the word?) quaint(?). It surely doesn't help it's
white-space too...

> You really should invest an evening or two reading it, and then look up 
> each feature (using the `i' command) when you use it.  The Texinfo manual 
> is one of the best manuals I saw: complete, clearly written, and 
> extensively indexed.  So you also get good examples of how to write 
> documentation, simply by looking at the manual, in addition to learning.

I'll try and do that.


Right,

							MartinS

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019