Doubts about pointers

[Simon]

Hello friends,

I have a couple of doubts about pointers in C.


1) I have a function with prototype is :

my_funtion(char far * char);

I need to pass it an array of char which I have defined as follows:

char my_array[10]

The question is: is it allright to typecast to a far pointer? e.g.
int i=my_function( (char far *) ( (char *) my_array );

I think I am still only passing a near pointer, so how do I force
the segment to be passed also?


2) As expected, (char far *) NULL is NULL, but if I set
char near *x = NULL,
then (char far *)x is non-NULL (the segment is non-zero)!

This seems crazy, it means that if you have a prototyped function
with a far pointer argument (maybe NULL) and you have some
near-mode address from somewhere else (maybe NULL),
you have to handle the NULL case specially. What's going on?


I am using Borland Turbo-C 2.01 if it's relevant.

Thanks.

 

[Walter Roberson]

I have a couple of doubts about pointers in C.

1) I have a function with prototype is :

my_funtion(char far * char);

Then it is not C. 'far' is not a qualifier in standard C.

Also note that in C99, specifying the return type of the function
is mandatory; in C95 and earlier, 'int' was assumed by default.

I am using Borland Turbo-C 2.01 if it's relevant.

That thing is harder to kill off than kudzu!

 

[Ian Collins]

Hello friends,

I have a couple of doubts about pointers in C.


1) I have a function with prototype is :

my_funtion(char far * char);

far and near pointers aren't part of C, they are specific to certain
implementations. You would be better off asking on a group dedicated to
your compiler.

 

[jacob navia]

Hello friends,

I have a couple of doubts about pointers in C.


1) I have a function with prototype is :

my_funtion(char far * char);

I need to pass it an array of char which I have defined as follows:

char my_array[10]

The question is: is it allright to typecast to a far pointer? e.g.
int i=my_function( (char far *) ( (char *) my_array );

I think I am still only passing a near pointer, so how do I force
the segment to be passed also?

If I remember correctly, the segment will be added when
you cast a near pointer to a far one, i.e. the current data
segment will be passed. You should look at the assembly
generated to be sure.

2) As expected, (char far *) NULL is NULL, but if I set
char near *x = NULL,
then (char far *)x is non-NULL (the segment is non-zero)!

Probably because the data segment is added to the NULL pointer
see above...

This seems crazy, it means that if you have a prototyped function
with a far pointer argument (maybe NULL) and you have some
near-mode address from somewhere else (maybe NULL),
you have to handle the NULL case specially. What's going on?


I am using Borland Turbo-C 2.01 if it's relevant.

Forget that stuff. You are programming for a system that is
around 20 years old. All this stuff is obsolete.

P.S. There was in this group someone that loved TURBOC. I am
surprised he doesn't answer your question.

 

[Simon]

Thanks for the answer. I guessed that is what would happen but I
couldn't find any documentation, can you provide a link to the relevant
Borland documentation?

Actually I'm mostly learning C from the book by H. Schildt, which is
excellent but it doesn't mention near and far pointers at all. I find
them quite confusing, so I think any book should explain them clearly.

As for being obsolete, the good thing is that Borland have released
Turbo-C for free now, so there's no need to worry about Micro$oft
license fees. Also C doesn't change much!

Hello friends,

I have a couple of doubts about pointers in C.


1) I have a function with prototype is :

my_funtion(char far * char);

I need to pass it an array of char which I have defined as follows:

char my_array[10]

The question is: is it allright to typecast to a far pointer? e.g.
int i=my_function( (char far *) ( (char *) my_array );

I think I am still only passing a near pointer, so how do I force
the segment to be passed also?

If I remember correctly, the segment will be added when
you cast a near pointer to a far one, i.e. the current data
segment will be passed. You should look at the assembly
generated to be sure.

2) As expected, (char far *) NULL is NULL, but if I set
char near *x = NULL,
then (char far *)x is non-NULL (the segment is non-zero)!

Probably because the data segment is added to the NULL pointer
see above...

This seems crazy, it means that if you have a prototyped function
with a far pointer argument (maybe NULL) and you have some
near-mode address from somewhere else (maybe NULL),
you have to handle the NULL case specially. What's going on?


I am using Borland Turbo-C 2.01 if it's relevant.

Forget that stuff. You are programming for a system that is
around 20 years old. All this stuff is obsolete.

P.S. There was in this group someone that loved TURBOC. I am
surprised he doesn't answer your question.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

 

[Ian Collins]

[please don't top post]

Thanks for the answer. I guessed that is what would happen but I
couldn't find any documentation, can you provide a link to the relevant
Borland documentation?

I'm sure someone on a Borland list could.

Actually I'm mostly learning C from the book by H. Schildt, which is
excellent but it doesn't mention near and far pointers at all. I find
them quite confusing, so I think any book should explain them clearly.

That's generally regarded as the worst C book on the planet.

The is no need for any C book to explain near and far pointers as they
are not C, but an obsolete platform extension.

 

[Keith Thompson]

Actually I'm mostly learning C from the book by H. Schildt, which is
excellent but it doesn't mention near and far pointers at all. I find
them quite confusing, so I think any book should explain them clearly.

[...]

Schildt writes bad books.

Get yourself a copy of K&R2 (Kernighan & Ritchie, "The C Programming
Language", 2nd edition).

near and far pointers are not part of C, so I wouldn't expect a book
on C to mention them. A book about your system might, but they're
largely obsolete, so you might consider just ignoring them.

As for being obsolete, the good thing is that Borland have released
Turbo-C for free now, so there's no need to worry about Micro$oft
license fees. Also C doesn't change much!

There are more modern C implementations available at no charge.

You might also take a look at the comp.lang.c FAQ,
<http://www.c-faq.com>, particularly the "Tools and Resources"
section.

 

[CBFalconer]

.... snip ...


That thing is harder to kill off than kudzu!

And useful for verifying that you haven't made invalid assumptions
about the size of an int.

 

[jacob navia]

You might also take a look at the comp.lang.c FAQ,
<http://www.c-faq.com>, particularly the "Tools and Resources"
section.

The link in the FAQ to
<quote>
A shareware MS-DOS C compiler is available from
ftp.hitech.com.au/hitech/pacific.

Registration is optional for non-commercial use.
< end quote>

The link is dead. It would be better to get rid of the old MSDOS
links

 

[Richard]

[please don't top post]

Thanks for the answer. I guessed that is what would happen but I
couldn't find any documentation, can you provide a link to the relevant
Borland documentation?

I'm sure someone on a Borland list could.

Actually I'm mostly learning C from the book by H. Schildt, which is
excellent but it doesn't mention near and far pointers at all. I find
them quite confusing, so I think any book should explain them clearly.

That's generally regarded as the worst C book on the planet.

The is no need for any C book to explain near and far pointers as they
are not C, but an obsolete platform extension.

The other day we had someone harping on about
pascal on 8080 and 486s.

near and Far pointers were used in lots of legacy code which is still in
use. And they are part of the C used on those platforms.

Now, if that wasn't C in use then I must be dreaming. Because there were
many books on C which explained this pointers.

So your claim that there is no need for "any C book" to explain them is
clearly rubbish.

 

[santosh]

[please don't top post]

Thanks for the answer. I guessed that is what would happen but I
couldn't find any documentation, can you provide a link to the
relevant Borland documentation?

I'm sure someone on a Borland list could.

Actually I'm mostly learning C from the book by H. Schildt, which is
excellent but it doesn't mention near and far pointers at all. I
find them quite confusing, so I think any book should explain them
clearly.

That's generally regarded as the worst C book on the planet.

The is no need for any C book to explain near and far pointers as
they are not C, but an obsolete platform extension.

The other day we had someone harping on about
pascal on 8080 and 486s.

near and Far pointers were used in lots of legacy code which is still
in use. And they are part of the C used on those platforms.

Now, if that wasn't C in use then I must be dreaming. Because there
were many books on C which explained this pointers.

So your claim that there is no need for "any C book" to explain them
is clearly rubbish.

Nevertheless it isn't wise for a beginner to start out on learning C by
involving himself with nearly extinct systems and their peculiarities
that he is unlikely to meet 95% of the time. It's better to learn
standard C and if in the remote chance that he does get to work on old
DOS systems, he can always pick up segments and near and far pointers
then.

 

[Ian Collins]

near and Far pointers were used in lots of legacy code which is still in
use. And they are part of the C used on those platforms.

Now, if that wasn't C in use then I must be dreaming. Because there were
many books on C which explained this pointers.

So your claim that there is no need for "any C book" to explain them is
clearly rubbish.

I learned C from K&R. I learned about near and far pointers form Intel
and compiler documentation.

The C book explained C, the documentation explained segments. Segments
were just as relevant to my assembly as my C programming.

There was and still is no need for any C book to explain near and far
pointers. There is a need for DOS and 386 books to explain near and far
pointers.

 

[Richard Heathfield]

jacob navia said:

The link in the FAQ to
<quote>
A shareware MS-DOS C compiler is available from
ftp.hitech.com.au/hitech/pacific.

Registration is optional for non-commercial use.
< end quote>

The link is dead.

You're right. The hitech compiler is now available from
http://www.htsoft.com/products/compilers/PACIFICc.php - and I have dropped
Steve an email suggesting that he use this link instead.

It would be better to get rid of the old MSDOS links

Why?

 

[CBFalconer]

And the only sane use for a Schildt C book is to warm you on a cold
day. This is done by inserting it in a suitably closed and vented
combustion chamber and applying a match. To learn C, get K&R2.

.... snip ...

Nevertheless it isn't wise for a beginner to start out on learning
C by involving himself with nearly extinct systems and their
peculiarities that he is unlikely to meet 95% of the time. It's
better to learn standard C and if in the remote chance that he
does get to work on old DOS systems, he can always pick up
segments and near and far pointers then.

To use TC2.01 sanely today, simply mount it and set the model to
compact. This allows 64k of code, 64k of stack, and up to 1 meg of
heap data for malloc. You can then forget about near and far etc.
After all, its only real purpose is to check portability to 16 bit
systems. You don't need to mount the other libraries etc.

 

[santosh]

santosh wrote:


To use TC2.01 sanely today, simply mount it and set the model to
compact. This allows 64k of code, 64k of stack, and up to 1 meg of
heap data for malloc. You can then forget about near and far etc.
After all, its only real purpose is to check portability to 16 bit
systems. You don't need to mount the other libraries etc.

Thanks, but I have access to better systems, and so do most.

 

[Nick Keighley]

Actually I'm mostly learning C from the book by H. Schildt, which is
excellent but it doesn't mention near and far pointers at all. I find
them quite confusing, so I think any book should explain them clearly.

As for being obsolete, the good thing is that Borland have released
Turbo-C for free now, so there's no need to worry about Micro$oft
license fees. Also C doesn't change much!

there are many free compilers for modern systems (no near and far).
If you are confined to Windows then there is a gcc based one (ming-w
(sp?))
lcc (no charge for non-commercial use) and even Microsoft express
versions.

 

[Keith Thompson]

Thanks, but I have access to better systems, and so do most.

Do those better systems allow you to test your code for portability to
16-bit systems?

 

[Ian Collins]

Do those better systems allow you to test your code for portability to
16-bit systems?

Well that depends if he has emulators for them. There are a lot of
different 16 bit systems out there.

 

[CBFalconer]

Thanks, but I have access to better systems, and so do most.

I have no idea where you get 'better' 16 bit systems, but TC does
the job for me, and is totally free. I don't need 'better'.

 

[CBFalconer]

there are many free compilers for modern systems (no near and far).
If you are confined to Windows then there is a gcc based one (ming-w
(sp?)) lcc (no charge for non-commercial use) and even Microsoft
express versions.

Those are NOT 16 bit systems. They cannot be used to check code
executes correctly on a minimal system.