Doubts about pointers

Discussion in 'C Programming' started by amit khan, May 21, 2010.

  1. amit khan

    amit khan Guest

    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.
    amit khan, May 21, 2010
    #1
    1. Advertising

  2. amit khan

    Ben Pfaff Guest

    amit khan <> writes:

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


    It's about 21 years old. Have you considered using a more modern
    C implementation?
    --
    Ben Pfaff
    http://benpfaff.org
    Ben Pfaff, May 21, 2010
    #2
    1. Advertising

  3. amit khan

    Ian Collins Guest

    On 05/22/10 09:21 AM, amit khan wrote:
    > 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?


    C (as in standard C) doesn't have near and far pointers. You should
    find your answers in your compiler docs, or a group dedicated to its use.

    --
    Ian Collins
    Ian Collins, May 21, 2010
    #3
  4. amit khan

    Seebs Guest

    On 2010-05-21, amit khan <> wrote:
    > Hello friends,
    >
    > I have a couple of doubts about pointers in C.


    No, you have a couple of doubts about pointers in your implementation.

    > 1) I have a function with prototype is :
    >
    > my_funtion(char far * char);


    You need a DOS or Windows newsgroup.

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


    It is. Your question is unique to a non-standard feature of some DOS
    and Windows implementations which had different kinds of pointers.

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    Seebs, May 21, 2010
    #4
  5. In article <>,
    Ben Pfaff <> wrote:
    >amit khan <> writes:
    >
    >> I am using Borland Turbo-C 2.01 if it's relevant.

    >
    >It's about 21 years old. Have you considered using a more modern
    >C implementation?


    Is there anything per se wrong with using something that is old?

    Obviously, these people have good solid reasons for using TurboC.

    --
    > No, I haven't, that's why I'm asking questions. If you won't help me,
    > why don't you just go find your lost manhood elsewhere.


    CLC in a nutshell.
    Kenny McCormack, May 22, 2010
    #5
  6. On 21 May, 22:30, Seebs <> wrote:
    > On 2010-05-21, amit khan <> wrote:


    > > I have a couple of doubts about pointers in C.

    >
    > No, you have a couple of doubts about pointers in your implementation.
    >
    > > 1) I have a function with prototype is :

    >
    > >  my_funtion(char far * char);

    >
    > You need a DOS or Windows newsgroup.
    >
    > > I am using Borland Turbo-C 2.01 if it's relevant.

    >
    > It is.  Your question is unique to a non-standard feature of some DOS
    > and Windows implementations which had different kinds of pointers.


    even windows doesn't use far pointers (did it ever?)
    Nick Keighley, May 22, 2010
    #6
  7. amit khan

    Tom St Denis Guest

    On May 22, 7:44 am, (Kenny McCormack)
    wrote:
    > In article <>,
    > Ben Pfaff  <> wrote:
    >
    > >amit khan <> writes:

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

    >
    > >It's about 21 years old.  Have you considered using a more modern
    > >C implementation?

    >
    > Is there anything per se wrong with using something that is old?


    Well for one, there is no official support for it. So if you plan on
    doing anything professionally [including education] with it you're at
    a loss.

    Also, DJGPP is freely available for DOS platforms. It also uses GCC
    and is modern, supported, and a hell of a better compiler.

    > Obviously, these people have good solid reasons for using TurboC.


    I seriously 100% doubt that.

    Tom
    Tom St Denis, May 22, 2010
    #7
  8. "Nick Keighley" <> wrote in message
    news:...
    On 21 May, 22:30, Seebs <> wrote:
    > On 2010-05-21, amit khan <> wrote:


    > > I have a couple of doubts about pointers in C.

    >
    > No, you have a couple of doubts about pointers in your implementation.
    >
    > > 1) I have a function with prototype is :

    >
    > > my_funtion(char far * char);

    >
    > You need a DOS or Windows newsgroup.
    >
    > > I am using Borland Turbo-C 2.01 if it's relevant.

    >
    > It is. Your question is unique to a non-standard feature of some DOS
    > and Windows implementations which had different kinds of pointers.


    <--
    even windows doesn't use far pointers (did it ever?)
    -->

    Win 3.x and earlier...


    16-bit apps in Win95-WinXP (NT-XP via NTVDM), but XP64, Vista, and Win7
    dropped support for them...

    Win32s (Win 3.x) and Win95 native and newer apps generally used 32-bit
    memory, and so didn't make use of far pointers...

    far pointers have some (limited) use WRT 32-bit code (on x86, and x86-64),
    but this is mostly limited to OS kernel code and occassional edge cases
    (mostly accessing thread-local-storage and similar), and hence most 32/64
    bit compilers don't bother supporting them AFAIK (usually it is confined to
    the occasional piece of ASM or inline ASM or similar).


    on x86-64, segments are mostly broken, and left mostly as a vestigial
    feature (although FS/GS remain as a special-case hack mostly to help
    facilitate TLS/etc...).
    BGB / cr88192, May 22, 2010
    #8
  9. In article <>,
    Nick Keighley <> wrote:
    ....
    >> It is.  Your question is unique to a non-standard feature of some DOS
    >> and Windows implementations which had different kinds of pointers.

    >
    >even windows doesn't use far pointers (did it ever?)


    Well, that is certainly a question of semantics (what this newsgroup
    excels at). Certainly in Win16 days, it did. In Win32, it could be
    said that all pointers are "far" - in that they are 32 bits, which in
    the terminology of DOS/Windows is "far".

    If you spend some time looking through the include files of a Windows C
    installation, you will see that "far" is still a concept employed
    therein. As far as I can tell (although I certainly didn't look in
    great depth), in the current incarnation of things, "far" (and "FAR")
    are #define'd to empty, so that the concept essentially drops out at
    compile time. But it is still the case that "far" (or "FAR") is part of
    the definition of WINAPI (and some other things).

    P.S. In a way, your question would have been more poignant if you had
    asked if they used "near" pointers. That question could, possibly, be
    answered in the negative.

    --
    (This discussion group is about C, ...)

    Wrong. It is only OCCASIONALLY a discussion group
    about C; mostly, like most "discussion" groups, it is
    off-topic Rorsharch [sic] revelations of the childhood
    traumas of the participants...
    Kenny McCormack, May 22, 2010
    #9
  10. amit khan

    Stargazer Guest

    > > >> I am using Borland Turbo-C 2.01 if it's relevant.
    >
    > > >It's about 21 years old.  Have you considered using a more modern
    > > >C implementation?

    >
    > > Is there anything per se wrong with using something that is old?

    >
    > Well for one, there is no official support for it.  So if you plan on
    > doing anything professionally [including education] with it you're at
    > a loss.


    For two, Turbo-C 2.01 was released even before ANSI C89 Standard.

    > Also, DJGPP is freely available for DOS platforms.  It also uses GCC
    > and is modern, supported, and a hell of a better compiler.


    Unfortunately, it's not the same thing. DJGPP works only in 32-bit
    flat mode and it requires a DOS extender. DOS extender is included in
    the distro, but it won't work on pure real-mode DOS and won't work at
    all on anything before 386.

    Daniel
    Stargazer, May 24, 2010
    #10
  11. amit khan

    Stargazer Guest

    > >> It is.  Your question is unique to a non-standard feature of some DOS
    > >> and Windows implementations which had different kinds of pointers.

    >
    > >even windows doesn't use far pointers (did it ever?)

    >
    > Well, that is certainly a question of semantics (what this newsgroup
    > excels at).  Certainly in Win16 days, it did.  In Win32, it could be
    > said that all pointers are "far" - in that they are 32 bits, which in
    > the terminology of DOS/Windows is "far".


    No, in Win32 all the pointers are "near". The difference between
    "near" and "far" pointers on x86 is not number of bits, but whether
    they use explicitly segment:eek:ffset in two registers (segment and base/
    index) or only base/index+offset, assuming default segment (DS for
    data, SS for stack). Win32 uses only 32-bit offsets.

    At least Watcom C for DOS (may be there are others, don't know)
    allowed use of "far32" pointers (the pointers appeared effectively 48
    bits in size).

    > If you spend some time looking through the include files of a Windows C
    > installation, you will see that "far" is still a concept employed
    > therein.  As far as I can tell (although I certainly didn't look in
    > great depth), in the current incarnation of things, "far" (and "FAR")
    > are #define'd to empty, so that the concept essentially drops out at
    > compile time.  But it is still the case that "far" (or "FAR") is part of
    > the definition of WINAPI (and some other things).


    In Win32 "FAR" presents only for source compatibility with Win 3.x 16-
    bit code (Win3.x API was defined with far pointers indeed)

    > P.S.  In a way, your question would have been more poignant if you had
    > asked if they used "near" pointers.  That question could, possibly, be
    > answered in the negative.


    Positive since introduction of Win32.

    BTW, understanding far and near pointers gives good understanding of
    some pointers constraints, in particular:

    1) why code and data pointers may be of different size
    2) why conversion of pointers to integers and back yields undefined
    behavior when such converted pointers are used.

    Daniel
    Stargazer, May 24, 2010
    #11
  12. On May 22, 12:21 am, amit khan <> wrote:
    >
    > 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,
    >

    The far and near pointer system has been tacked onto C to get round
    the problem of segments. So some things like casts might not work
    sensibly. In this case, the compiler is probably giving the pointer
    the segment corresponding to the segment used as the base of near
    pointers, and treating NULL as the first address within that segment,
    forgetting that this creates a non-null far pointer. It's poor design
    choice, but the only way round it would be to have a special check for
    null in every cast, which would exact a runtime penalty.
    Malcolm McLean, May 24, 2010
    #12
  13. amit khan

    Tom St Denis Guest

    On May 24, 3:54 am, Stargazer <> wrote:
    > > > >> I am using Borland Turbo-C 2.01 if it's relevant.

    >
    > > > >It's about 21 years old.  Have you considered using a more modern
    > > > >C implementation?

    >
    > > > Is there anything per se wrong with using something that is old?

    >
    > > Well for one, there is no official support for it.  So if you plan on
    > > doing anything professionally [including education] with it you're at
    > > a loss.

    >
    > For two, Turbo-C 2.01 was released even before ANSI C89 Standard.
    >
    > > Also, DJGPP is freely available for DOS platforms.  It also uses GCC
    > > and is modern, supported, and a hell of a better compiler.

    >
    > Unfortunately, it's not the same thing. DJGPP works only in 32-bit
    > flat mode and it requires a DOS extender. DOS extender is included in
    > the distro, but it won't work on pure real-mode DOS and won't work at
    > all on anything before 386.


    Who says their target is limited to pre-386?

    And frankly that's a dumbshit restriction to put on oneself. I'd
    rather have an ARM or PPC, even stripped down than an 8086 anyday.
    They win out in all directions, area, MIPS/area, MIPS/power, etc,
    etc...

    Anyone stupid enough to think that an 8086 is a good design choice in
    2010 deserves every last bit of pain they get.

    Tom
    Tom St Denis, May 24, 2010
    #13
  14. amit khan

    Nobody Guest

    On Mon, 24 May 2010 08:08:46 -0700, Malcolm McLean wrote:

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

    > The far and near pointer system has been tacked onto C to get round
    > the problem of segments.


    Near/far pointers were tacked on for efficiency. They're completely
    unnecessary if you use the "huge" model (all pointers have both segment
    and offset, and are always normalised), but this has penalties in terms
    of both memory consumption and speed.
    Nobody, May 25, 2010
    #14
  15. amit khan

    Stargazer Guest

    On May 22, 12:21 am, amit khan <> wrote:

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


    Actually, NULL pointer doesn't have to be represented by all 0 bits. A
    "far" NULL pointer may be represented by segment having a special
    value and offset 0 or even by segment having *any* value and offset
    zero. It just has to compare equal to NULL or (void*)0.

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


    Compiler may have bugs or it may use a not-all-0s representation of
    far NULL pointer ("far" is a non-portable extension). You may print
    out something like:

    char near *x = NULL;
    printf("Test 1: %d; test 2: %d\n", (char far*)x == NULL, (char far*)x
    == (void*)0);

    If you get two 1's then the compiler is doing right.

    Daniel
    Stargazer, May 25, 2010
    #15
  16. amit khan

    Stargazer Guest

    On May 24, 11:14 pm, Tom St Denis <> wrote:

    > Who says their target is limited to pre-386?


    OP did. Turbo C 2.01 produces only 16-bit DOS code (may be with a
    third-party linker it may produce 16-bit Windows executables), while
    DJGPP produces only 32-bit code for DPMI extenders. Even though 16-bit
    code may run on 386 and laters in legacy modes (real and V86), there
    are enough differences to consider execution modes different run-time
    environments.

    > And frankly that's a dumbshit restriction to put on oneself.  I'd
    > rather have an ARM or PPC, even stripped down than an 8086 anyday.
    > They win out in all directions, area, MIPS/area, MIPS/power, etc,
    > etc...
    >
    > Anyone stupid enough to think that an 8086 is a good design choice in
    > 2010 deserves every last bit of pain they get.


    I don't advocate or discourage design choices. 8086/186 is at least a
    cheap design choice, and in some projects people may choose to assume
    that "pain" :) You don't need (I think) to pay fees for implementing
    8086 like you would with ARM or MIPS, and its documentation is much
    clearer and simpler than three-level manuals of PPC.

    Personally I saw only one embedded project that used an x86 (AMD
    Geode) in 10 years, and that failed. About everything else that I even
    heard of indeed used ARM, PowerPC or MIPS.

    Daniel
    Stargazer, May 25, 2010
    #16
  17. Stargazer <> writes:

    > On May 22, 12:21 am, amit khan <> wrote:
    >
    >> 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)!

    >
    > Actually, NULL pointer doesn't have to be represented by all 0 bits. A
    > "far" NULL pointer may be represented by segment having a special
    > value and offset 0 or even by segment having *any* value and offset
    > zero. It just has to compare equal to NULL or (void*)0.


    It should probably also compare equal to 0 (with no decoration). I say
    "probably" because far and near pointers are not standard, so the
    provisions of pointer comparisons in the standard need not apply to
    them. However, a consistent implementation would make x == NULL, x ==
    (void *)0 and x == 0 all behave the same way.

    <snip>
    --
    Ben.
    Ben Bacarisse, May 25, 2010
    #17
  18. amit khan

    Tom St Denis Guest

    On May 25, 5:03 am, Stargazer <> wrote:
    > On May 24, 11:14 pm, Tom St Denis <> wrote:
    >
    > > Who says their target is limited to pre-386?

    >
    > OP did. Turbo C 2.01 produces only 16-bit DOS code (may be with a
    > third-party linker it may produce 16-bit Windows executables), while
    > DJGPP produces only 32-bit code for DPMI extenders. Even though 16-bit
    > code may run on 386 and laters in legacy modes (real and V86), there
    > are enough differences to consider execution modes different run-time
    > environments.


    It's entirely possible they're running on a post-286 computer and just
    happen to have a copy of TC 2. In which case ... I stand by what I
    said.

    Thing is TC2 has been EOL'ed long ago. So from a business point of
    view it's a non-starter. There is no support for it. There are no
    upgrades, it's not even C90 compliant. Might as well be using BYTE
    magazine Small-C for all its worth.

    > I don't advocate or discourage design choices. 8086/186 is at least a
    > cheap design choice, and in some projects people may choose to assume
    > that "pain" :) You don't need (I think) to pay fees for implementing
    > 8086 like you would with ARM or MIPS, and its documentation is much
    > clearer and simpler than three-level manuals of PPC.


    Except that you're still shooting yourself in the foot in terms of
    efficiency or best area usage. A very low end ARM for instance is
    ridiculously small and still more powerful than an 8086 [from any
    manufacturer]

    > Personally I saw only one embedded project that used an x86 (AMD
    > Geode) in 10 years, and that failed. About everything else that I even
    > heard of indeed used ARM, PowerPC or MIPS.


    Because x86 is useless for embedded space. It's far far far too
    inefficient of an ISA. Thing is too if you started to throw the tech
    behind most x86 processors [out of order execution, multiple
    pipelines, etc] at PPC or ARM they start becoming very attractive in
    the high end space.

    Tom
    Tom St Denis, May 25, 2010
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. MS

    Help, .NET doubts.....

    MS, Jun 4, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    536
    Yuancai \(Charlie\) Ye
    Jun 4, 2004
  2. Replies:
    0
    Views:
    522
  3. Nisheeth

    xilinx ise doubts

    Nisheeth, Mar 30, 2005, in forum: VHDL
    Replies:
    0
    Views:
    561
    Nisheeth
    Mar 30, 2005
  4. Simon

    Doubts about pointers

    Simon, Mar 26, 2008, in forum: C Programming
    Replies:
    71
    Views:
    1,438
    Richard Heathfield
    Mar 31, 2008
  5. cerr

    pointers, pointers, pointers...

    cerr, Apr 7, 2011, in forum: C Programming
    Replies:
    12
    Views:
    657
Loading...

Share This Page