Standards for a FAR Pointer

[sarojkmohapatra]

===========
chat far * p;
delete (p);
===========

Can somebody let me know the behaviour of the above code (As per C
standards;irrespective of compiler implementations)

[Walter Roberson]

In article <11**********************@i3g2000cwc.googlegroups. com>,
<sa*************@gmail.comwrote:

>===========
chat far * p;
delete (p);
===========

>Can somebody let me know the behaviour of the above code (As per C
standards;irrespective of compiler implementations)

There is no far pointers in the C standard.

There is also no delete() function in the C standard.
If you were to call free() on an uninitialized pointer, the result
would be undefined.

--
Prototypes are supertypes of their clones. -- maplesoft

[Richard Heathfield]

Walter Roberson said:

In article <11**********************@i3g2000cwc.googlegroups. com>,
<sa*************@gmail.comwrote:

>>===========
chat far * p;
delete (p);
===========

>>Can somebody let me know the behaviour of the above code (As per C
standards;irrespective of compiler implementations)

There is no far pointers in the C standard.

There is also no delete() function in the C standard.

Furthermore, the language defines no chat type.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Malcolm]

<sa*************@gmail.comwrote in message

===========
chat far * p;
delete (p);
===========

Can somebody let me know the behaviour of the above code (As per C
standards;irrespective of compiler implementations)

In the bad old days Intel processors had what is known as segmented memory.
Whilst no doubt a great convenience to the electronics engineer, it was a
major nuisance tot he programmer. A segment was up to 64K, and to use blocks
of memory larger than that you had to do all sorts of fancy calculations.
This meant that the fancy calculations slowed down code, so to speed things
up a little PC compilers invented the "far" keyword. A far pointer was fancy
and slow, but could point to bigger regions of memory than normal pointers.

In modern times the far pointer is largely of historical interest only. If
you need to compile code with far pointer, sinple define "far" as a blank or
a comment.

delete is C++ and an extension of free. it is also a perfectly valid name
for a C function, but don't use it, unless you are one of those people who
think it makes a telling point to make your code a nuisance for C++
programmers to call and maintain.
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.

[CBFalconer]

Richard Heathfield wrote:

Walter Roberson said:

> <sa*************@gmail.comwrote:

>>===========
chat far * p;
delete (p);
===========

>>Can somebody let me know the behaviour of the above code (As
per C standards;irrespective of compiler implementations)

There is no far pointers in the C standard.

There is also no delete() function in the C standard.

Furthermore, the language defines no chat type.

In addition the superequality operator =========== is a very rare
extension. Definitely not mentioned in the standard.

--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

[Gordon Burditt]

>===========

>chat far * p;
delete (p);
===========

Can somebody let me know the behaviour of the above code (As per C
standards;irrespective of compiler implementations)

It shouldn't compile.

>In the bad old days Intel processors had what is known as segmented memory.
Whilst no doubt a great convenience to the electronics engineer, it was a
major nuisance tot he programmer. A segment was up to 64K, and to use blocks
of memory larger than that you had to do all sorts of fancy calculations.

Expect the issue to come back, when it gets uncomfortable to squeeze
programs into segments of only 4GB.

>This meant that the fancy calculations slowed down code, so to speed things
up a little PC compilers invented the "far" keyword. A far pointer was fancy
and slow, but could point to bigger regions of memory than normal pointers.

>In modern times the far pointer is largely of historical interest only. If
you need to compile code with far pointer, sinple define "far" as a blank or
a comment.

In modern times the so-called far pointer exists (as a 48-bit pointer
on Intel Pentium, for example) but is infrequently used as 4GB as
a limit isn't too constraining yet. There is no (good) reason to
make it a separate pointer type in C. You just use a compiler
implementation, often selected by a compiler command-line option,
that makes *ALL* pointers "far". Of course all the pieces of the
program have to be compiled the same way, but there are plenty of
options that have the same problem.