title: Dealing with FAR pointers in code library for multiple embedded platforms
body: <p>I'm trying to maintain a library of code, with samples, for multiple embedded platforms.  I need to support the concept of "far" (non 16-bit) pointers for some function parameters.</p>
  
  <p>I thought I had a good solution with defining the macro <code>FAR</code> to be <code>__far</code> on some platforms and nothing on platforms with 32-bit pointers (embedded Linux, Win32, etc.).  With that macro, I could easily define pointers as <code>somestruct_t FAR *foo</code>.</p>
  
  <p>But then I started working with Freescale processors, and their compiler requires the <code>FAR</code> to go <strong>between</strong> the asterisk and variable name. (<code>somestruct_t * __far foo</code>).</p>
  
  <p>The best solution I've come up with to handle this case is to define a macro <code>FARPTR</code> as either <code>__far *</code>, <code>* __far</code> or just <code>*</code> depending on the platform.  This allows for <code>somestruct_t FARPTR foo</code>.</p>
  
  <p>Are there cleaner solutions out there?  <strong>In particular, I don't like that there isn't a <code>*</code> visible to someone reading that code.</strong>  I'm also worried that I will run into problems when it comes to function declarations.  Get a load of this syntax from the Freescale compiler help:</p>
  
  <pre><code>int __far *f();          // __far function returning a pointer to int
  int * __far f();         // Function returning a __far pointer to int
  int __near * __far f();  // __near function returning a __far pointer to int
  </code></pre>
  
  <p>That last one kills me -- a qualifier <strong>inside</strong> of the return type indicates a near function?!  And I've recently learned that adding the <code>__near</code> isn't enough to actually compile a function to near memory -- I need to wrap it in pragmas.</p>
  
  <p>So, has anyone seen a nicer solution than my <code>FARPTR</code> macro idea?</p>