size of a pointer on 4-bit system

Discussion in 'C Programming' started by Mark, Jan 30, 2013.

  1. Mark

    Mark Guest

    Hello

    I ran in a such interview question on the net: what is the size of pointer
    on 4-bit system. Regardless of the fact that such system probably don't
    exist, what would be the reasonable answer to such question? (I think saying
    that in theory the size is 4, however the standard doesn't allow bytes to be
    less than 8 bits).

    Mark
    Mark, Jan 30, 2013
    #1
    1. Advertising

  2. Mark

    W Karas Guest

    On Tuesday, January 29, 2013 9:30:01 PM UTC-5, Mark wrote:
    > Hello
    >
    >
    >
    > I ran in a such interview question on the net: what is the size of pointer
    >
    > on 4-bit system. Regardless of the fact that such system probably don't
    >
    > exist, what would be the reasonable answer to such question? (I think saying
    >
    > that in theory the size is 4, however the standard doesn't allow bytes tobe
    >
    > less than 8 bits).
    >
    >
    >
    > Mark


    Seems like a trick question. 4-bit processors were perhaps the most commonembedded processors back in the early 80s, when affordable personal computers where based on 8-bit processors. It wouldn't surprise me if immediate was the only addressing mode, making a "pointer" impossible without self-modifying code. I'd think bragging rights would be the only reason anyone would write a C compiler for a 4-bit processor.

    If you build a system with main memory on a PCIe bus, could that be called a 1-bit system?
    W Karas, Jan 30, 2013
    #2
    1. Advertising

  3. Mark

    Geoff Guest

    On Tue, 29 Jan 2013 21:30:01 -0500, "Mark" <>
    wrote:

    >Hello
    >
    >I ran in a such interview question on the net: what is the size of pointer
    >on 4-bit system. Regardless of the fact that such system probably don't
    >exist, what would be the reasonable answer to such question? (I think saying
    >that in theory the size is 4, however the standard doesn't allow bytes to be
    >less than 8 bits).
    >
    >Mark
    >


    The correct answer is "it cannot be determined". The size of the "system" is not
    a relevant question within the context of C.

    The Intel 4004 had a 4-bit ALU but 8-bit and 16-bit instructions and 12-bit
    addressing. It had indirect mode addressing into 4k ROM but could access only
    640 bytes of RAM. The FIN n instruction fetched indirect via index register pair
    0 and loaded the contents into register n where 1 <= n <=15.

    Any theoretical 4-bit processor could have any number of address bits and still
    be called a 4-bit system.
    Geoff, Jan 30, 2013
    #3
  4. Mark

    Lew Pitcher Guest

    On Tuesday 29 January 2013 21:48, in comp.lang.c, wrote:

    > On Tuesday, January 29, 2013 9:30:01 PM UTC-5, Mark wrote:
    >> Hello
    >>
    >>
    >>
    >> I ran in a such interview question on the net: what is the size of
    >> pointer
    >>
    >> on 4-bit system. Regardless of the fact that such system probably don't
    >>
    >> exist, what would be the reasonable answer to such question? (I think
    >> saying
    >>
    >> that in theory the size is 4, however the standard doesn't allow bytes to
    >> be
    >>
    >> less than 8 bits).
    >>
    >>
    >>
    >> Mark

    >
    > Seems like a trick question. 4-bit processors were perhaps the most
    > common embedded processors back in the early 80s, when affordable personal
    > computers where based on 8-bit processors.


    Intel's predecessor to the 8008 (and later, the 8080) was the 4004.
    Wikipedia describes it as having:
    Separate program and data storage.
    12-bit addresses
    8-bit instructions
    4-bit data words

    It would seem to me, /if/ a C compiler were targetted to such a processor,
    it would use pointers of 11 bits in width.


    --
    Lew Pitcher
    "In Skills, We Trust"
    Lew Pitcher, Jan 30, 2013
    #4
  5. Lew Pitcher <> wrote:

    (snip)
    >> On Tuesday, January 29, 2013 9:30:01 PM UTC-5, Mark wrote:


    (snip)
    >>> I ran in a such interview question on the net: what is the
    >>> size of pointer on 4-bit system.


    (snip)

    > Intel's predecessor to the 8008 (and later, the 8080) was the 4004.


    You forgot about the 4040.

    > Wikipedia describes it as having:
    > Separate program and data storage.
    > 12-bit addresses
    > 8-bit instructions
    > 4-bit data words


    > It would seem to me, /if/ a C compiler were targetted to such a processor,
    > it would use pointers of 11 bits in width.


    I would think one would want to have a nybble type, even if char was
    an 8 bit type. The 4004 was supposed to be used for building
    calculators, presumably in BCD.

    Are there C implementations for any Harvard (separate program and
    data space) machines? Maybe the 8048 series?

    -- glen
    glen herrmannsfeldt, Jan 30, 2013
    #5
  6. Mark

    Shao Miller Guest

    On 1/29/2013 21:30, Mark wrote:
    >
    > I ran in a such interview question on the net: what is the size of pointer
    > on 4-bit system. Regardless of the fact that such system probably don't
    > exist, what would be the reasonable answer to such question? (I think saying
    > that in theory the size is 4, however the standard doesn't allow bytes to be
    > less than 8 bits).
    >


    Did the interview question have anything to do with the computer
    programming language called C?

    --
    - Shao Miller
    --
    "Thank you for the kind words; those are the kind of words I like to hear.

    Cheerily," -- Richard Harter
    Shao Miller, Jan 30, 2013
    #6
  7. Mark

    Robert Miles Guest

    On Tuesday, January 29, 2013 8:30:01 PM UTC-6, Mark wrote:
    > Hello
    >
    > I ran in a such interview question on the net: what is the size of pointer
    > on 4-bit system. Regardless of the fact that such system probably don't
    > exist, what would be the reasonable answer to such question? (I think saying
    > that in theory the size is 4, however the standard doesn't allow bytes to be
    > less than 8 bits).
    >
    > Mark


    If only one 4-bit word is used to hold the pointer, 4 bits. However, such a system can only address 16 4-bit words, which must include both the program that is running and the data it is running on - not a very interesting system.

    However, if the hardware allows loading addresses as multiple 4-bit words, 4 bits times the number of words in that type of address.

    I used to have a PC board that included a 4004, but never did much with it.

    Server systems now use a similar idea of using more than one word to hold an address - some 32-bit servers use 2 32-bit words to hold an address, and can therefore reach more than tha 4 GB of memory they could use if they only used one 32-bit word.
    Robert Miles, Jan 30, 2013
    #7
  8. Mark

    Noob Guest

    Robert Miles wrote:

    > Server systems now use a similar idea of using more than one word to
    > hold an address - some 32-bit servers use 2 32-bit words to hold an
    > address, and can therefore reach more than tha 4 GB of memory they
    > could use if they only used one 32-bit word.


    Which (computer) architecture do you have in mind?
    Noob, Jan 30, 2013
    #8
  9. Robert Miles <> wrote:

    (snip)
    > I used to have a PC board that included a 4004, but never did much with it.


    > Server systems now use a similar idea of using more than one
    > word to hold an address - some 32-bit servers use 2 32-bit words
    > to hold an address, and can therefore reach more than tha 4 GB of
    > memory they could use if they only used one 32-bit word.


    How about ones that use a 16 bit segment selector and 32 bit
    segment offset? Plenty of those around, but not many OS that
    let programs use multiple segments.

    Last I knew, the Watcom C compiler would generate large model 32 bit
    code, and maybe OS/2 could run it.

    -- glen
    glen herrmannsfeldt, Jan 30, 2013
    #9
  10. Mark

    Nobody Guest

    On Tue, 29 Jan 2013 21:30:01 -0500, Mark wrote:

    > I ran in a such interview question on the net: what is the size of pointer
    > on 4-bit system. Regardless of the fact that such system probably don't
    > exist, what would be the reasonable answer to such question?


    The correct answer is "whatever the compiler's authors chose to make it".

    The hardware only matters insofar as the compiler's authors want it to
    matter. Compilers for the 8086 (and later CPUs running in 8086 mode)
    typically offered both 16-bit and 32-bit pointers. C explicitly allows
    different types of pointer to have different sizes (char* and void* may be
    larger than an int*, and the size of function pointers isn't related to
    the size of data pointers).
    Nobody, Jan 30, 2013
    #10
  11. Robert Miles <> writes:
    > On Tuesday, January 29, 2013 8:30:01 PM UTC-6, Mark wrote:
    >> I ran in a such interview question on the net: what is the size of pointer
    >> on 4-bit system. Regardless of the fact that such system probably don't
    >> exist, what would be the reasonable answer to such question? (I think saying
    >> that in theory the size is 4, however the standard doesn't allow bytes to be
    >> less than 8 bits).

    >
    > If only one 4-bit word is used to hold the pointer, 4 bits. However,
    > such a system can only address 16 4-bit words, which must include both
    > the program that is running and the data it is running on - not a very
    > interesting system.


    A pointer needn't be able to address both data and code.
    Data pointers (including void*) need to be able to address any
    byte in the address space; function pointers need to be able to
    refer to any function in the program, typically but not necessarily
    by holding the function's address (a function pointer could be an
    index into a table). A data pointers must be able to point to any
    byte within any object; a function pointer only needs to refer to
    a function as a whole.

    There needn't be any meaningful conversion between data pointers
    and function pointers.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jan 30, 2013
    #11
  12. Nobody <> writes:
    > On Tue, 29 Jan 2013 21:30:01 -0500, Mark wrote:
    >> I ran in a such interview question on the net: what is the size of pointer
    >> on 4-bit system. Regardless of the fact that such system probably don't
    >> exist, what would be the reasonable answer to such question?

    >
    > The correct answer is "whatever the compiler's authors chose to make it".
    >
    > The hardware only matters insofar as the compiler's authors want it to
    > matter. Compilers for the 8086 (and later CPUs running in 8086 mode)
    > typically offered both 16-bit and 32-bit pointers. C explicitly allows
    > different types of pointer to have different sizes (char* and void* may be
    > larger than an int*, and the size of function pointers isn't related to
    > the size of data pointers).


    The compiler's authors' choices will be strongly influenced by the
    capabilities provided by the hardware.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jan 30, 2013
    #12
  13. "Mark" <> writes:
    > I ran in a such interview question on the net: what is the size of pointer
    > on 4-bit system. Regardless of the fact that such system probably don't
    > exist, what would be the reasonable answer to such question? (I think saying
    > that in theory the size is 4, however the standard doesn't allow bytes to be
    > less than 8 bits).


    In a conforming C implementation, as you say, a byte must be at
    least 8 bits. That implies that a pointer must be at least 8 bits,
    but not that all those bits are significant.

    A hosted environment must support objects of at least 65535
    bytes, which would imply at least 16-bit pointers even if only
    one object existed -- but that doesn't apply to freestanding
    (embedded) environments, as a 4-bit system is almost certain to
    be. The requirement to support string literals of at least 4095
    characters, assuming the resulting string can be supported at run
    time, implies at least 12-bit pointers -- and more than that if
    you want more than that single object in your running program.

    I can imagine a conforming implementation with 16-bit data pointers,
    of which 13 bits are significant, permitting 8192 distinct addresses.

    On the other hand, I doubt that it would be worth the effort
    to provide a conforming C implementation for a 4-bit system.
    For example, it wouldn't be able to handle arrays of 4-bit objects
    without compiler extensions.

    It might make sense to provide an implementation of a C-like language
    that *doesn't* conform to the C standard, but that's closer to
    the semantic level of the underlying hardware. Portability isn't
    likely to be much of a concern; any software written for a 4-bit
    system is likely intended to run only on that system.

    In any case, the size of a pointer is going to be whatever it
    needs to be. Saying it's a "4-bit system" doesn't provide enough
    information to answer the question. (I think such systems typically
    have much more ROM than RAM; there might be different kinds of
    addresses to refer to them.)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jan 30, 2013
    #13
  14. Mark

    Mark Guest

    "Keith Thompson" <> wrote in message
    news:...
    > A hosted environment must support objects of at least 65535
    > bytes, which would imply at least 16-bit pointers even if only
    > one object existed -- but that doesn't apply to freestanding
    > (embedded) environments, as a 4-bit system is almost certain to
    > be.


    Thank you very much for elaborated answer.
    What objects you mean when saying about its size defined by the standard --
    are you referring to size_t describing sizes of objects in memory or
    something different?

    Could you refer to the paragraph in the standard, I'm somewhat confused.
    Thanks.

    [skip]

    --
    Mark
    Mark, Jan 30, 2013
    #14
  15. Mark

    James Kuyper Guest

    On 01/30/2013 02:26 PM, Mark wrote:
    > "Keith Thompson" <> wrote in message
    > news:...
    >> A hosted environment must support objects of at least 65535
    >> bytes, which would imply at least 16-bit pointers even if only
    >> one object existed -- but that doesn't apply to freestanding
    >> (embedded) environments, as a 4-bit system is almost certain to
    >> be.

    >
    > Thank you very much for elaborated answer.
    > What objects you mean when saying about its size defined by the standard --
    > are you referring to size_t describing sizes of objects in memory or
    > something different?
    >
    > Could you refer to the paragraph in the standard, I'm somewhat confused.


    size_t should be big enough to correctly describe the size of any object
    that the implementation lets you define, and there is a requirement that
    SIZE_MAX >= 65535 (7.20.3p2). However, an implementation could satisfy
    both of those conditions without allowing creation of any object larger
    than, say, 8 bytes.

    The requirement he's referring to is 5.2.4.2.1p1, which requires that a
    conforming "... implementation shall be able to translate and execute at
    least one program that contains at least one instance ..." of "65535
    bytes in an object", among many other things.

    This does NOT imply that a conforming implementation of C will be able
    to translate and execute every strictly conforming program that doesn't
    exceed any of the limits listed in that section. A program that exceeds
    none of those limits can still be arbitrarily long and complicated, and
    therefore impossible to compile by any compiler with finite resources.

    5.2.4.2.1p1 does not even imply that there's even a single additional
    program that the implementation can translate and execute. The only
    guarantee it provides is for the "one program". As written, it's a
    completely useless requirement.

    However, no implementation that imposes a fixed limit on something which
    is lower than the corresponding limit listed in 5.2.4.2.1p1 could meet
    this requirement. As a result, people tend to simplify this issue by
    pretending that 5.2.4.2.1p1 means (a LOT) more than it actually says,
    and thus mandates support for, among other things, objects up to 65535
    bytes.

    An implementation's limits don't have to be fixed - in fact, I think
    many modern implementations only have a upper limit on the total amount
    of memory needed to process the program; all other limits are indirect
    side-effects of running out of memory.
    James Kuyper, Jan 30, 2013
    #15
  16. "Mark" <> writes:
    > "Keith Thompson" <> wrote in message
    > news:...
    >> A hosted environment must support objects of at least 65535
    >> bytes, which would imply at least 16-bit pointers even if only
    >> one object existed -- but that doesn't apply to freestanding
    >> (embedded) environments, as a 4-bit system is almost certain to
    >> be.

    >
    > Thank you very much for elaborated answer.
    > What objects you mean when saying about its size defined by the standard --
    > are you referring to size_t describing sizes of objects in memory or
    > something different?
    >
    > Could you refer to the paragraph in the standard, I'm somewhat confused.
    > Thanks.


    See N1570 5.2.4.1, "Translation Limits".

    A hosted implementation must successfully translate and execute at least
    one program that has, among other things, an object whose size is 65535
    bytes. It can be any object (defined as a "region of data storage in
    the execution environment, the contents of which can represent values"),
    such as a declared variable or an object allocated by a call to
    malloc().

    This requirement is not imposed on freestanding (typically embedded)
    implementations.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jan 30, 2013
    #16
  17. Keith Thompson <> wrote:
    > "Mark" <> writes:
    >> I ran in a such interview question on the net: what is the size of pointer
    >> on 4-bit system.


    (snip)

    > In a conforming C implementation, as you say, a byte must be at
    > least 8 bits. That implies that a pointer must be at least 8 bits,
    > but not that all those bits are significant.


    > A hosted environment must support objects of at least 65535
    > bytes, which would imply at least 16-bit pointers even if only
    > one object existed -- but that doesn't apply to freestanding
    > (embedded) environments, as a 4-bit system is almost certain to
    > be. The requirement to support string literals of at least 4095
    > characters, assuming the resulting string can be supported at run
    > time, implies at least 12-bit pointers -- and more than that if
    > you want more than that single object in your running program.


    Seems to me that the phrase "N bit system" is mostly useful when
    discussing machines where the data register width, address width,
    memory bus width, and ALU width are all the same, or maybe three
    of them are the same. Otherwise, it is more useful if you
    qualify the statement with which width(s) you mean.

    As mentioned, the 4004, generally considered a 4 bit processor,
    has 12 bit addresses, but I believe 4 bit ALU, 4 bit registers,
    and 4 bit memory bus.

    The 8080, (and 6800, 6502, and others of the time), generally
    considered 8 bit processors, have a 16 bit address space,
    but 8 bit registers (sometimes used in pairs), 8 bit ALU
    and 8 bit memory bus.

    IBM S/360 and S/370, generally considered 32 bit architectures,
    have 32 bit registers, 24 bit address space, implementations
    with ALU and memory data bus width from 8 to 64 bits.

    The PDP-11, considered 16 bit, has 16 bit registers, 16 bit
    addresses (though possibly with bank switching to allow for
    a larger physical address space), byte addressable, but
    commonly implemented with a 16 bit memory bus, and, I
    believe, usually a 16 bit ALU.

    The expansion of microprocessors fromn 8 to 16 bits tended
    to also require a larger address space. The TI 9900 was one
    of the earlier ones, but not so cheap or easy to use, so
    as to catch on easily.

    The 8086, more or less an extension to the 8080, with a 16 but
    ALU, 16 bit memory bus, and 16 bit registers, but a 20 bit
    address space, popularized the transition to 16 bit systems
    affordable to more users. (The PDP-11, down to the LSI 11/03,
    had been available, but not priced to compete with existing 8
    bit systems.)

    The PDP-10, generally considered 36 bits, with 36 bit registers,
    presumably 36 bit ALU, I believe 36 bit data bus, but 18 bit
    (user) address space (addressing 36 bit words). The address
    space was expanded with an extended addressing system in later
    processors.

    > I can imagine a conforming implementation with 16-bit data pointers,
    > of which 13 bits are significant, permitting 8192 distinct addresses.


    > On the other hand, I doubt that it would be worth the effort
    > to provide a conforming C implementation for a 4-bit system.
    > For example, it wouldn't be able to handle arrays of 4-bit objects
    > without compiler extensions.


    Yes. For the usual uses, such as BCD calculators, it would be
    very nice to have a 4 bit data type.

    > It might make sense to provide an implementation of a C-like language
    > that *doesn't* conform to the C standard, but that's closer to
    > the semantic level of the underlying hardware. Portability isn't
    > likely to be much of a concern; any software written for a 4-bit
    > system is likely intended to run only on that system.


    > In any case, the size of a pointer is going to be whatever it
    > needs to be. Saying it's a "4-bit system" doesn't provide enough
    > information to answer the question. (I think such systems typically
    > have much more ROM than RAM; there might be different kinds of
    > addresses to refer to them.)


    As noted above, for smaller systems it is usually the address space
    that is larger than the other three. It seems likely that the
    width (though not necessarily the amount of actual memory available)
    would be a multiple of four. Assuming addressing 4 bit nybbles,
    the program space likely has to be larger than 256 addressable
    units, so 12 or 16 bit addresses. Besides already knowing about
    the 4004, 12 makes somewhat more sense. With the extra hardware
    for 16 bit addressing, the cost of an 8 bit data bus isn't so
    far off, even with a fundamental 4 bit data type.

    But for such systems, including later ones such as the 8048
    and successors, it is more usual to have separate data and
    instruction space, (though maybe with one data bus) and
    so separate width for data and instruction pointers.

    So, one should not as for "the size of a pointer" but for
    the "size of a data pointer" or "size of an instruction
    pointer."

    But as a question to get a discussion started, maybe it
    isn't so bad. Just don't expect a simple answer.

    -- glen
    glen herrmannsfeldt, Jan 30, 2013
    #17
  18. Mark <> wrote:
    > "Keith Thompson" <> wrote in message
    > news:...
    >> A hosted environment must support objects of at least 65535
    >> bytes, which would imply at least 16-bit pointers even if only
    >> one object existed -- but that doesn't apply to freestanding
    >> (embedded) environments, as a 4-bit system is almost certain to
    >> be.


    > Thank you very much for elaborated answer.
    > What objects you mean when saying about its size defined by the standard --
    > are you referring to size_t describing sizes of objects in memory or
    > something different?


    > Could you refer to the paragraph in the standard, I'm somewhat confused.
    > Thanks.


    C requires char to be at least 8 bits, but it can be more. All other
    types have to be multiples (including 1) of the size of char.

    That seems to prohibit a four bit type, which would be especially
    useful on a four bit processor.

    -- glen
    glen herrmannsfeldt, Jan 30, 2013
    #18
  19. glen herrmannsfeldt wrote:
    >Lew Pitcher wrote:
    >> Intel's predecessor to the 8008 (and later, the 8080) was the 4004.

    >
    >You forgot about the 4040.
    >


    And everybody should forget the Motorola 14500 ...
    http://www.linurs.org/mc14500.html
    http://tinymicros.com/wiki/MC14500B

    >Are there C implementations for any Harvard (separate program and
    >data space) machines? Maybe the 8048 series?


    Many, starting with the PDP-11's, today's Atmel AVR's, etc.
    --
    Roberto Waltman

    [ Please reply to the group,
    return address is invalid ]
    Roberto Waltman, Jan 30, 2013
    #19
  20. James Kuyper <> writes:
    [...]
    > 5.2.4.2.1p1 does not even imply that there's even a single additional
    > program that the implementation can translate and execute. The only
    > guarantee it provides is for the "one program". As written, it's a
    > completely useless requirement.


    I think you mean 5.2.4.1p1; at least that's the number in N1570.

    That's true in principle, but in practice (and I think I've made this
    point here before) it's probably easier to satisfy 5.2.4.2.1p1 by
    implementing a compiler that's actually *useful* (with large fixed
    limits, or no fixed limits at all), than by implementing something that
    supports just "one program" and nothing else.

    It would be amusing to write a "compiler" that recognizes a single
    program that hits all the listed limits and generates correct code for
    it, and reports "Capacity exceeded" for any other program. But nobody
    would buy or use it.

    > However, no implementation that imposes a fixed limit on something which
    > is lower than the corresponding limit listed in 5.2.4.2.1p1 could meet
    > this requirement. As a result, people tend to simplify this issue by
    > pretending that 5.2.4.2.1p1 means (a LOT) more than it actually says,
    > and thus mandates support for, among other things, objects up to 65535
    > bytes.
    >
    > An implementation's limits don't have to be fixed - in fact, I think
    > many modern implementations only have a upper limit on the total amount
    > of memory needed to process the program; all other limits are indirect
    > side-effects of running out of memory.


    And the standard recommends that approach in a (non-binding, of course)
    footnote:

    Implementations should avoid imposing fixed translation limits
    whenever possible.

    The compiler doesn't require implementations to have *sensible* capacity
    limits. I'm not at all sure how such a requirement could be worded.
    Perhaps a suite of strictly conforming test programs could be written,
    with all conforming compilers required to successfully translate and
    execute them. But I'm not sure it would be worth the effort (though a
    more general-purpose conformance test suite would be).

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jan 31, 2013
    #20
    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. Saurabh Aggrawal

    32 bit pointer to 64 bit pointer

    Saurabh Aggrawal, Dec 9, 2004, in forum: C++
    Replies:
    1
    Views:
    590
    msalters
    Dec 9, 2004
  2. Replies:
    3
    Views:
    1,716
    Timothy Bendfelt
    Jan 19, 2007
  3. Christian Wittrock

    16 bit pointer typecast on 16 bit system

    Christian Wittrock, Jul 3, 2006, in forum: C Programming
    Replies:
    17
    Views:
    796
  4. Replies:
    9
    Views:
    939
    Juha Nieminen
    Aug 22, 2007
  5. David Filmer
    Replies:
    14
    Views:
    174
    Peter J. Holzer
    Aug 8, 2010
Loading...

Share This Page