M
mkausalya
hai experts can know about the use of far & near keywords in c lang
S
santosh
There are no keywords called far and near in C as standardised by ISO.
They're implementation specific extensions.
<OT>
IIRC they're extensions in Turbo C for use under DOS's segmented
memory model, particularly with pointers. The so called 'near'
pointers are 16 bit and contain an offset address alone while the
'far' pointer is 32 bit and contains a full segment
ffset address.For more details, post to a Turbo C or DOS newsgroup.
</OT>
R
Roberto Waltman
santosh said:There are no keywords called far and near in C as standardised by ISO.
They're implementation specific extensions.
<OT>
IIRC they're extensions in Turbo C for use under DOS's segmented
memory model, particularly with pointers. The so called 'near'
pointers are 16 bit and contain an offset address alone while the
'far' pointer is 32 bit and contains a full segment
For more details, post to a Turbo C or DOS newsgroup.
</OT>
[OT] The FAR/NEAR keywords were actually introduced by Microsoft, not
Borland, and they quickly spread to every C compiler for the
8086/Intel/DOS world.
Roberto Waltman
[ Please reply to the group,
return address is invalid ]
R
R Pradeep Chandran
<OT>
Well, 'far', 'near' and relatives (mainly 'huge' and 'tiny') are still
used by many cross compilers for microcontrollers. Some compilers use
__near or __far to comply with the ISO standard. Some don't.
</OT>
Have a nice day,
Pradeep
M
Malcolm McLean
The huge and tiny memory models were a bit different.R Pradeep Chandran said:
To avoid having to mess about with far pointers, you could declare all
pointers to be far or near by default. There were even large and small
memory models as well.
The big advantage was you had to rewrite all the standrad library functions
to take far pointers. So you learnt how things were implemented.
C
CBFalconer
Roberto said:
Not so. As usual, Microsoft does not innovate. Those keywords
appeared with the assembly language for the 8088/8086, back around
1976. The amazing thing is that Microsoft actually used a
pre-existing standard. This may be tied in with the fact that they
bought their C compiler from somebody else (I forget who).
J
jaysome
R
Roberto Waltman
jaysome said:
Right, and Intel would have been the culprit here.
My comment was on the introduction of the far and near keywords as a C
language extension.
Based (from memory,) in reading an interview with somebody who was in
a management position for the DOS Microsoft C compilers.
He took pride in bringing far and near to the masses. (Can not recall
the person's name.)
Correct. The first C compilers sold under the Microsoft brand where
Lattice-C. (Not even repackaged.)
Roberto Waltman
[ Please reply to the group,
return address is invalid ]
J
Jack Klein
Sigh...
<off-topic trip down memory lane>
Microsoft's C compiler version prior to Version 3 were Lattice C
repackaged. Microsoft C 3.0 and later were their own in-house
compilers.
Neither Lattice nor Microsoft's pre version 3 compilers supported the
"near" or "far" extension keywords. Nor did they support the "tiny"
or "huge" memory models.
In fact, they did not support mixing pointer types or memory models.
Lattice came with four libraries, for the four possible combinations
of 16/32 bit code/data addressing. It was up to the user to link the
one matched the options passed to the compiler.
C
CBFalconer
Jack said:
Then how did the compiler know what kind of calling protocol to
generate? Did it have an anticipator function to read the
following link commands?
F
Flash Gordon
CBFalconer wrote, On 24/02/07 09:46:
No, it has an option to tell it. If you told the compiler one thing but
the linker something else it all fell apart horribly.
No, it has an option to tell it. If you told the compiler one thing but
the linker something else it all fell apart horribly.