Re: [MiNT] Dopendir() return values

[Paul Wratt <paul.wratt@gmail.com>]

the ENOENT (-33) is the *nix way to answer - making it a non-issue for
porting code or "posix compliance" (adding to it at least)

but EPTHNF (-34) is the "atari way" of doing it (which for historical
reason is standard) in Magic

how do current libraries handle this situation, ones that work with
both Magic & 1.15

there must be a way to handle the situation where the binary can be
running on either Magic or MiNT

if the return check it handled "the standard GEMDOS" way - then the
true return value can be "hidden" or available elsewhere if the system
is MiNT - vice-versa for "the standard *nix" way when running on Magic

but that implys there is some standard method of checking return
values from Dopendir calls  - and this (more than) unlikely on atari
systems at least..

if there are "standard functions" to do this, and they are in current
use then IF(ENOENT||EPTHNF)RETURN DNF=TRUE; is a solution, or some
variant that caters for situations where Magic/MiNT may return the
"other value" (is that possible - if so when?)

with all that said - how are things handled atm - are there apps which
actually have issues with this?

On Fri, Jan 6, 2012 at 11:16 PM, Gerhard Stoll <gerhard_stoll@gmx.de> wrote:
>> is there anything else in toshyp that man pages are missing? (or vice-
>> versa)
>
> I don't know. I look only for Dopendir.
>
> But there is an other problem:
>
> I make a short programm.
> -------------------------------cut-------------------------------
> void main ( void )
> {
>  long ret;
>  ret = Dopendir ( "c:\\tes", 0 );
>  printf ("Ret 1: %li\r\n", ret );
>
>  ret = Dopendir ( "c:\\tes", 1 );
>  printf ("Ret 2: %li\r\n", ret );
> }
> -------------------------------cut-------------------------------
> The directory "tes" is not present. MagiC 6.20 returns EPTHNF (-34)
> and FreeMiNT 1.15.12 ENOENT (-33).
>
> While the old manpage wrote also EPTHNF (-34) I think there was a
> change some day in FreeMiNT[1]. Like Andreas Schwab says, I think
> also that all GEMDOS function should returns GEMDOS error codes and
> not a Unix/FreeMiNT one.
>
> Gerhard
>
> [1] At the moment I find not if that realy happens.
>
>
>