const struct sockaddr FAR* name,
+14
A:
It's an old extension from the era of segmented memory architectures. It basically means "this is a pointer that needs to be able to point at any address, not just things in the same segment as the code using it".
See more or on the wikipedia page.
unwind
2010-10-26 13:58:53
So it's useless today?
ollydbg
2010-10-26 14:07:22
pretty much, unless you NEED to write 16 bit code for some funny reason (which is really really really really rare). Useless for normal people.
TomTom
2010-10-26 14:07:54
On some other platforms near and far pointer may appear (not exactly with the same meaning), so if you'll do crosscompiling you may have deal with it.
Vovanium
2010-10-26 14:43:50
@ollydbg - for current-day x86 PC platforms and applications, yes. For other platforms, like single-chip embedded ones, no.
sheepsimulator
2010-10-26 14:51:00
Yes, it's completely useless today and never was part of the language.
R..
2010-10-26 15:29:28
@R..: It's not part of C, but it's a compiler directive that is occasionally *required* for the vast majority of computers in the world today (hint hint, they're not x86 or ARMs).
Nick T
2010-10-26 20:17:05
@Nick: I'm not sure which you mean, but any good compiler for backwards segmented architectures will have a "huge" memory model you can choose to make all pointers large enough to hold any address. That's what I always used back when writing code for DOS/Win16.
R..
2010-10-26 20:39:01
@Nick: In this example `FAR` is in fact most probably a *macro* not a directive, and in Win32 is is an empty macro at that.
Clifford
2010-10-27 09:49:02
C compilers for the 8051 tend to use `near` and `far` (and a host of other platform-specific storage classes like `data`/`xdata`/`pdata`/`code`, `bit`, `sbit`, etc.).
bk1e
2010-10-27 16:46:17
+5
A:
I cannot explain better than this link does. With pictures, code samples etc. :) HTH
Armen Tsirunyan
2010-10-26 14:02:29
+3
A:
far doesn't mean anything in C. Check out the C99 standard [PDF] and see if you can find mention of far pointers. Far pointers were an extension added to compilers targeting the 8086/80286 architectures to provide support for the segmented memory model.
JeremyP
2010-10-26 14:16:28
A:
If does nothing unless you happen to be using a 16 bit x86 compiler.
If you look in the Win32 header WinDef.h (in Visual Studio, simply right-click the word FAR in the source and select "Go to Definition", you will see that it is a macro defined as far, which in turn is also a macro defined as nothing at all!
It is only there to allow the compilation of legacy Win16 source as Win32. In 16 bit x86 compilers, far was a compiler extension keyword to support seg::offset pointers which resolve to a 20bit address (16 bit x86 only had a 1Mb address space!). They are distinct from 16 bit near pointers which comprised only the ::offset from the current segment.
Clifford
2010-10-26 14:24:32
Several other platforms also have near and far pointers. AVR for example.
Vovanium
2010-10-26 14:41:47
@Vovanium: Can you provide a citation? The GNU AVR compiler certainly does not support `far` or `near` keywords. The GNU compiler for Toshiba's MeP has `near` and `far` however, but not for the same architectural reason as x86 Real Mode. So yes, some architectures still require extensions to address different memory spaces; not just `near` and `far`. Harvard architectures and DSPs typically require extensions.
Clifford
2010-10-26 17:05:58
IAR have tiny, near, far and huge storage specifiers (look http://supp.iar.com/FilesPublic/SUPPORT/000373/memoryusage.pdf ) And yes, pointer size specifiers may not be the same as x86 ones.
Vovanium
2010-10-26 18:51:17
@Vovanium: Thanks for taking the time. I've never needed to use an AVR with enough memory to need a far pointer! That's what ARM is for! ;)
Clifford
2010-10-26 20:51:02
Clifford: Look, ATXMEGAs are fat and fast for large applications. So if someone is loving AVR it's the choice. But I prefer 32 bit MCUs too. :)
Vovanium
2010-10-26 20:59:00