Path: utzoo!attcan!uunet!munnari.oz.au!csource!david
From: david@csource.oz.au (david nugent)
Newsgroups: comp.lang.c
Subject: Re: extern
Message-ID: <569@csource.oz.au>
Date: 15 Jul 90 11:32:09 GMT
References: <1990Jul9.190744.1437@Solbourne.COM> <1990Jul10.004710.20500@Octopus.COM> <5353@stpstn.UUCP> <2569@dataio.Data-IO.COM>
Organization: Unique Computing Pty Ltd, Melb, Aust.
Lines: 39

In <2569@dataio.Data-IO.COM> bright@Data-IO.COM (Walter Bright) writes:

><<#define EXTERN extern
><<#define far FAR
><<#define pascal PASCAL
><<
><<What's wrong with extern far pascal foo() vs EXTERN FAR PASCAL foo()?
><Microsoft has decided that for version 6.0, "__far" is better than "far"
><So if you followed the Microsoft "standard", all you have to do is use
><the new set of macros and your code works.
><Then if you would like to port your code to some other machine, you
><can #define FAR to nothing.

>The FAR macro is still entirely unnecessary. To port to a machine that does
>not have far:

>#define far

>To port to the new _far keyword:

>#define far _far

>There is no point to the FAR macro (and the other similar ones).


While technically that's quite correct, I use uppercased macros for
type declarators and moderators purely as a reminder that it isn't
supported in all environments in which the code may be compiled.  I
even use EXTERN, VOLATILE, STATIC and a few others, with one include
file "environ.h" which takes care of the specific environment.

I find that it helps in reminding me not to rely on environment
and/or compiler specific features unless I specifically #ifdef the
code.  It probably helps make the code more readable too.

-- 
_______________________________________________________________________________
 Unique Computing Pty Ltd  Melbourne  Australia  -  Communications Specialists 
        david@csource.oz.au    3:632/348@fidonet    28:4100/1@signet