Message-ID: <00a201c152ff$9fe975a0$180b24d5@zephyr>
From: "Eric Botcazou" <ebotcazou AT libertysurf DOT fr>
To: "DJGPP workers" <djgpp-workers AT delorie DOT com>
References: <10110111357 DOT AA18726 AT clio DOT rice DOT edu> <006601c15277$3736ab00$d27824d5 AT zephyr> <1659-Thu11Oct2001211157+0200-eliz AT is DOT elta DOT co DOT il> <00d901c152a0$398d6fa0$845824d5 AT zephyr> <7458-Fri12Oct2001003417+0200-eliz AT is DOT elta DOT co DOT il> <018a01c152ad$8f5ad8c0$845824d5 AT zephyr> <4331-Fri12Oct2001084812+0200-eliz AT is DOT elta DOT co DOT il>
Subject: Re: _findfirst() patch
Date: Fri, 12 Oct 2001 11:20:06 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Reply-To: djgpp-workers AT delorie DOT com

> Right, except that findfirst was there first, and _dos_findfirst
> didn't seem like an important addition, so I guess no one looked very
> hard inside it.

May I say that's for me the limit of the 'one external function per file'
rule ? Instead of having one core code in one location privately shared by
multiple interfaces, you end up with multiple core codes with their own
interface or single core codes publicly shared by multiple interfaces (see
below).

> There is no one function per file rule, only one _external_ function
> per file rule.  You will see that some source files in the library do
> have static helper functions, and those are not (and should not be)
> documented.

Ok, but the 'one external function per file rule' leads precisely to make
external functions of helper functions: the three low-level wrapper
functions I proposed are IMHO helper functions that shouldn't be exposed to
the public. Now they are exposed to the public: should I document them
anyway, given that the user will be already faced with no less than three
sets of find*() functions ? Won't a fourth set of find*() functions confuse
him ?

> An external function is something that functions in other modules can
> call.

So either a function is private to a module (static) or publicy exposed and
documented (external) ? Isn't there any room for functions private to the
library (non static, non publicy exposed and non documented in a .txh file
but only in their source file) ?

--
Eric Botcazou
ebotcazou AT multimania DOT com