Re: [cc65] Common macros for dirent.d_type

From: Ullrich von Bassewitz <uz1musoftware.de>
Date: 2012-06-25 20:42:40
On Mon, Jun 25, 2012 at 06:23:10PM +0200, Oliver Schmidt wrote:
> >> Maybe I get you wrong but the macros in question are taking the d_type
> >> field as parameter. So if there's no d_type at all you'd get a
> >> compiler error.
> >
> > #define _DE_ISREG(t)    0
> >
> > how does that result in a compiler error? code that is written the "typical"
> > way using these macros might even work correctly without change =P
>
> A misunderstanding. Now I see your point. I'll add those...

Sorry, but I don't get it. I'm opposed to using #ifdef as well, but what help
would it be defining the macros for platforms that don't have d_type?

If one has _DE_ISREG() for platforms that have d_type, one would code

    unsigned char regular_file;
    ...
    #ifdef _DE_ISREG
        regular_file = _DE_ISREG(e.d_type);
    #else
        regular_file = 1;
    #endif

catching all possible cases. The code above is compatible with all current and
future platforms. If _DE_ISREG is defined as in Groepaz example, there is
nothing one can use to detect a platform that doesn't have d_type. Using
something like

    #if defined(__ATARI__)
        regular_file = 1;
    #else
        regular_file = _DE_ISREG(e.d_type);
    #endif

would be the result. Where's the advantage? Code would have to be fixed for
each and every upcoming platform and maybe even for new compiler releases.

What I could think of would be to make the d_type field a requirement *AND*
use dummy #defines for _DE_ISxxx. This is similar as the Lynx does. It would
waste a single byte for platforms that don't have it now, but would remove the
need for #if checks alltogether.

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz@musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Mon Jun 25 20:42:56 2012

This archive was generated by hypermail 2.1.8 : 2012-06-25 20:42:59 CEST