about far & near keywords in c

[mkausalya]

hai experts can know about the use of far & near keywords in c lang

[santosh]

mk*******@gmail.com wrote:

hai experts can know about the use of far & near keywords in c lang

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:offset address.
For more details, post to a Turbo C or DOS newsgroup.
</OT>

[Roberto Waltman]

"santosh" wrote:

>mk*******@gmail.com wrote:

>...know about the use of far & near keywords in c lang

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:offset address.
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 Pradeep Chandran]

On Thu, 22 Feb 2007 09:16:38 -0500, Roberto Waltman
<us****@rwaltman.netwrote:

>"santosh" wrote:

>>mk*******@gmail.com wrote:

>>...know about the use of far & near keywords in c lang

There are no keywords called far and near in C as standardised by ISO.
They're implementation specific extensions.

<snip explanation of far/near by santosh>

>
[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.

<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
--
All opinions are mine and do not represent the views or
policies of my employer.
R Pradeep Chandran rpc AT pobox DOT com

[Malcolm McLean]

"R Pradeep Chandran" <se*@sig.belowwrote in message >
<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>

The huge and tiny memory models were a bit different.
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.

[CBFalconer]

Roberto Waltman wrote:

>

.... snip ...

>
[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.

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).

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[jaysome]

On Thu, 22 Feb 2007 20:48:17 -0500, CBFalconer <cb********@yahoo.com>
wrote:

>Roberto Waltman wrote:

>>

... snip ...

>>
[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.

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).

I think it was Lattice.

http://en.wikipedia.org/wiki/Lattice_C

Regards
--
jay
http://www.microsoft.com/windows/pro...a/default.mspx

[Roberto Waltman]

jaysome wrote:

>CBFalconer wrote:

>>Roberto Waltman wrote:

>>[OT] The FAR/NEAR keywords were actually introduced by Microsoft,

Not so. As usual, Microsoft does not innovate.

Those keywords

>>appeared with the assembly language for the 8088/8086, back around
1976.

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.)

>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).

I think it was Lattice.

http://en.wikipedia.org/wiki/Lattice_C

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 ]

[Jack Klein]

On Thu, 22 Feb 2007 20:48:17 -0500, CBFalconer <cb********@yahoo.com>
wrote in comp.lang.c:

Roberto Waltman wrote:

... snip ...

[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.

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).

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.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[CBFalconer]

Jack Klein wrote:

>

.... snip ...

>
<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.

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?

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[Flash Gordon]

CBFalconer wrote, On 24/02/07 09:46:

Jack Klein wrote:
... snip ...

><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.

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?

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.
--
Flash Gordon