extern

david nugent david at csource.oz.au
Sun Jul 15 21:32:09 AEST 1990


In <2569 at dataio.Data-IO.COM> bright at 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 at csource.oz.au    3:632/348 at fidonet    28:4100/1 at signet           



More information about the Comp.lang.c mailing list