malloc realloc and pointers

Discussion in 'C Programming' started by ravi, Nov 29, 2007.

  1. ravi

    ravi Guest

    Hi all,

    I m relatively new to C. I have few queries related to malloc():

    1. When we perform malloc(), the memory allocated dynamically comes from
    the heap area of the process in concern. Well, we then say that the heap
    has shrinked. my query is: Is it that the heap physically does not
    shrink but the perticular nodes are marked 'ALLOCATED' and for
    subsequent calls to malloc() the memory manager remembers them and does
    not reference them?

    2. With realloc(), if some pointer 'ptr' is pointing initially to a
    perticular position in a buffer (char *buffer) then on performing a
    realloc() on this buffer, what will be 'ptr' pointing to?

    3. whats the maximum memory size that we can allocate dynamically by
    calling malloc() ?

    4. Is it valid in C to typecast a pointer? eg. code snippet... of
    course int is 16 bit and long is 32 bit.
    int *variable, value;
    *((long*)variable)++ = value;
    *((long*)variable)++ = value;
    *((long*)variable)++ = value;
    *((long*)variable)++ = value;

    thanx in advance
     
    ravi, Nov 29, 2007
    #1
    1. Advertising

  2. ravi <> wrote:
    > Hi all,
    >
    > I m relatively new to C.


    Then why ask questions on how it's implemented? You're
    trying to run before you can crawl.

    > I have few queries related to malloc():
    >
    > 1. When we perform malloc(), the memory allocated
    > dynamically comes from the heap area of the process in
    > concern.


    If you say so. The language standard does not specify how
    malloc is implemented, merely how it must operate.

    > Well, we then say that the heap has shrinked. my query
    > is: Is it that the heap physically does not shrink but
    > the perticular nodes are marked 'ALLOCATED' and for
    > subsequent calls to malloc() the memory manager
    > remembers them and does not reference them?


    You should ask in a group where such implementation details
    are topical.

    > 2. With realloc(), if some pointer 'ptr' is pointing
    > initially to a perticular position in a buffer (char
    > *buffer) then on performing a realloc() on this buffer,
    > what will be 'ptr' pointing to?


    The original pointer value becomes indeterminate if the
    allocation is successful.

    > 3. whats the maximum memory size that we can allocate
    > dynamically by calling malloc() ?


    The most you can try for is ((size_t) -1). The most you
    can actually allocate depends on the implementation.

    > 4. Is it valid in C to typecast a pointer?


    Yes, but subject to a few rules. Converting between
    different non-void types isn't as well defined as
    some program code would have you believe.

    > eg. code snippet... of
    > course int is 16 bit and long is 32 bit.


    If that has any relevance, then you're heading down the
    wrong path in your quest to learn C.

    > int *variable, value;
    > *((long*)variable)++ = value;


    This potentially breaks several rules on pointer conversion.
    It also violates a constraint.

    The cast from int * to long * is not required to be well
    defined. Even if it is, it will not produce a modifiable
    lvalue suitable for postfix ++.

    --
    Peter
     
    Peter Nilsson, Nov 29, 2007
    #2
    1. Advertising

  3. ravi wrote:
    >
    > Hi all,
    >
    > I m relatively new to C. I have few queries related to malloc():
    >
    > 1. When we perform malloc(), the memory allocated dynamically comes from
    > the heap area of the process in concern.


    Technically, C doesn't define "heap". However, it is a term in
    general use to mean "the memory from which malloc and friends
    get their memory".

    > Well, we then say that the heap
    > has shrinked.


    Not necessarily. Perhaps the amount of memory available on the
    heap has shrunk, but even that's not necessarily true. It is
    possible that the memory you request wasn't available in the
    existing heap, and so the heap was grown to accomodate your
    request. It is possible that the result is that you now have
    more memory available on the heap than before the call to
    malloc().

    > my query is: Is it that the heap physically does not
    > shrink but the perticular nodes are marked 'ALLOCATED' and for
    > subsequent calls to malloc() the memory manager remembers them and does
    > not reference them?


    The memory management within malloc/calloc/etc. keeps track of
    what memory is used and that is still available. The details on
    How it does this is entirely up to the implemenation.

    > 2. With realloc(), if some pointer 'ptr' is pointing initially to a
    > perticular position in a buffer (char *buffer) then on performing a
    > realloc() on this buffer, what will be 'ptr' pointing to?


    Three possibilities:

    1) realloc() returns the same pointer, in which case ptr is still
    valid, pointing to the newly-sized buffer.

    2) realloc() returns a different pointer, in which case ptr is
    no longer valid, and must not be dereferenced.

    3) realloc() returns NULL, in which case ptr is pointing to the
    unchanged memory region as before.

    Typically, the only use for the old pointer is to remember where
    it pointed to when realloc() returns NULL. Otherwise, simply use
    the new pointer.

    > 3. whats the maximum memory size that we can allocate dynamically by
    > calling malloc() ?


    Whatever is the maximum value of a size_t variable, though you
    are more likely to run into limits of the platform you are running
    on. (For example, size_t may allow values up to 4GB-1, but the
    O/S may only allow 2GB.)

    > 4. Is it valid in C to typecast a pointer? eg. code snippet... of
    > course int is 16 bit and long is 32 bit.
    > int *variable, value;
    > *((long*)variable)++ = value;
    > *((long*)variable)++ = value;
    > *((long*)variable)++ = value;
    > *((long*)variable)++ = value;


    If variable is properly aligned, I believe it's valid.

    --
    +-------------------------+--------------------+-----------------------+
    | Kenneth J. Brody | www.hvcomputer.com | #include |
    | kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
    +-------------------------+--------------------+-----------------------+
    Don't e-mail me at: <mailto:>
     
    Kenneth Brody, Nov 29, 2007
    #3
  4. In article <>,
    Kenneth Brody <> wrote:
    >ravi wrote:


    >> int *variable, value;
    >> *((long*)variable)++ = value;
    >> *((long*)variable)++ = value;
    >> *((long*)variable)++ = value;
    >> *((long*)variable)++ = value;


    >If variable is properly aligned, I believe it's valid.


    variable has not been initialized, so it is a dangling pointer.
    --
    "Beware of bugs in the above code; I have only proved it correct,
    not tried it." -- Donald Knuth
     
    Walter Roberson, Nov 29, 2007
    #4
  5. On Thu, 29 Nov 2007 17:00:05 -0500, Kenneth Brody wrote:
    > ravi wrote:
    >> 2. With realloc(), if some pointer 'ptr' is pointing initially to a
    >> perticular position in a buffer (char *buffer) then on performing a
    >> realloc() on this buffer, what will be 'ptr' pointing to?

    >
    > Three possibilities:
    >
    > 1) realloc() returns the same pointer, in which case ptr is still
    > valid, pointing to the newly-sized buffer.


    According to DR #260, applied to realloc, even if memcmp proves the new
    pointer is identical to the old pointer, you're not allowed to use them
    interchangeably. If you pass a non-null pointer ptr to realloc, and it
    doesn't return a null pointer, ptr is no longer valid.

    (I do not believe the DR's conclusions can be drawn from any
    interpretation of the actual standard, and in fact I believe some points
    from the DR directly contradict explicit guarantees by the standard, but
    that's just me.)
     
    Harald van Dijk, Nov 29, 2007
    #5
  6. ravi

    CBFalconer Guest

    ravi wrote:
    >
    > I m relatively new to C. I have few queries related to malloc():
    >
    > 1. When we perform malloc(), the memory allocated dynamically
    > comes from the heap area of the process in concern. Well, we then
    > say that the heap has shrinked. my query is: Is it that the heap
    > physically does not shrink but the perticular nodes are marked
    > 'ALLOCATED' and for subsequent calls to malloc() the memory
    > manager remembers them and does not reference them?


    There is not necessarily anything called a heap. That is an
    implementors decision. Somehow or other the implementor guarantees
    that subsequent malloc calls do not return pointers to previously
    allocated space (unless freed).

    > 2. With realloc(), if some pointer 'ptr' is pointing initially to a
    > perticular position in a buffer (char *buffer) then on performing a
    > realloc() on this buffer, what will be 'ptr' pointing to?


    That depends. If realloc succeeds, it returns a replacement value
    for ptr, which has the desired space and preserves the original
    data. If realloc fails it return NULL, and ptr and *ptr are both
    unaltered.

    > 3. whats the maximum memory size that we can allocate dynamically by
    > calling malloc() ?


    Depends on the system. All you can find out is that a malloc
    (etc.) request is fulfilled or rejected.

    > 4. Is it valid in C to typecast a pointer? eg. code snippet... of
    > course int is 16 bit and long is 32 bit.
    > int *variable, value;
    > *((long*)variable)++ = value;
    > *((long*)variable)++ = value;
    > *((long*)variable)++ = value;
    > *((long*)variable)++ = value;


    Very likely to cause serious run-time faults. Don't do it.

    --
    Chuck F (cbfalconer at maineline dot net)
    <http://cbfalconer.home.att.net>
    Try the download section.



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Nov 30, 2007
    #6
  7. ravi

    Jack Klein Guest

    On Thu, 29 Nov 2007 21:50:38 +0100 (CET), ravi <>
    wrote in comp.lang.c:

    > Hi all,
    >
    > I m relatively new to C. I have few queries related to malloc():
    >
    > 1. When we perform malloc(), the memory allocated dynamically comes from
    > the heap area of the process in concern. Well, we then say that the heap
    > has shrinked. my query is: Is it that the heap physically does not
    > shrink but the perticular nodes are marked 'ALLOCATED' and for
    > subsequent calls to malloc() the memory manager remembers them and does
    > not reference them?
    >
    > 2. With realloc(), if some pointer 'ptr' is pointing initially to a
    > perticular position in a buffer (char *buffer) then on performing a
    > realloc() on this buffer, what will be 'ptr' pointing to?
    >
    > 3. whats the maximum memory size that we can allocate dynamically by
    > calling malloc() ?
    >
    > 4. Is it valid in C to typecast a pointer? eg. code snippet... of
    > course int is 16 bit and long is 32 bit.
    > int *variable, value;
    > *((long*)variable)++ = value;


    This is not legal C code. The cast generates an rvalue, and the post
    increment operator cannot be applied to lvalues. You cannot assign to
    the result of a cast.

    > *((long*)variable)++ = value;
    > *((long*)variable)++ = value;
    > *((long*)variable)++ = value;
    >
    > thanx in advance


    --
    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.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Nov 30, 2007
    #7
  8. ravi

    K. Jennings Guest

    On Thu, 29 Nov 2007 17:00:05 -0500, Kenneth Brody wrote:

    > ravi wrote:
    >> 2. With realloc(), if some pointer 'ptr' is pointing initially to a
    >> perticular position in a buffer (char *buffer) then on performing a
    >> realloc() on this buffer, what will be 'ptr' pointing to?

    >
    > Three possibilities:
    >
    > 1) realloc() returns the same pointer, in which case ptr is still
    > valid, pointing to the newly-sized buffer.
    >
    > 2) realloc() returns a different pointer, in which case ptr is
    > no longer valid, and must not be dereferenced.
    >
    > 3) realloc() returns NULL, in which case ptr is pointing to the
    > unchanged memory region as before.


    What happens when ptr is not one returned by a previous
    invocation to malloc(), calloc() or realloc()?
     
    K. Jennings, Nov 30, 2007
    #8
  9. ravi

    cr88192 Guest

    "K. Jennings" <> wrote in message
    news:p...
    > On Thu, 29 Nov 2007 17:00:05 -0500, Kenneth Brody wrote:
    >
    >> ravi wrote:
    >>> 2. With realloc(), if some pointer 'ptr' is pointing initially to a
    >>> perticular position in a buffer (char *buffer) then on performing a
    >>> realloc() on this buffer, what will be 'ptr' pointing to?

    >>
    >> Three possibilities:
    >>
    >> 1) realloc() returns the same pointer, in which case ptr is still
    >> valid, pointing to the newly-sized buffer.
    >>
    >> 2) realloc() returns a different pointer, in which case ptr is
    >> no longer valid, and must not be dereferenced.
    >>
    >> 3) realloc() returns NULL, in which case ptr is pointing to the
    >> unchanged memory region as before.

    >
    > What happens when ptr is not one returned by a previous
    > invocation to malloc(), calloc() or realloc()?
    >


    then, if you are the program, ninjas run up, kick you somewhere painful, and
    insert a corncob somewhere painful.
    one then has to try to hobble off to the bathroom for a 'core dump'...
     
    cr88192, Nov 30, 2007
    #9
  10. ravi

    CBFalconer Guest

    "K. Jennings" wrote:
    >

    .... snip ...
    >>
    >> 3) realloc() returns NULL, in which case ptr is pointing to the
    >> unchanged memory region as before.

    >
    > What happens when ptr is not one returned by a previous
    > invocation to malloc(), calloc() or realloc()?


    Then you know that realloc moved the storage. It doesn't affect
    the data held by the pointed to object.

    --
    Chuck F (cbfalconer at maineline dot net)
    <http://cbfalconer.home.att.net>
    Try the download section.



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Nov 30, 2007
    #10
  11. "K. Jennings" <> writes:
    [...]
    >> ravi wrote:
    >>> 2. With realloc(), if some pointer 'ptr' is pointing initially to a
    >>> perticular position in a buffer (char *buffer) then on performing a
    >>> realloc() on this buffer, what will be 'ptr' pointing to?

    [snip]
    > What happens when ptr is not one returned by a previous
    > invocation to malloc(), calloc() or realloc()?


    Undefined behavior.

    (This is partly a test of news-server.san.rr.com.)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Looking for software development work in the San Diego area.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Nov 30, 2007
    #11
  12. On 29 Nov, 21:44, Peter Nilsson <> wrote:
    > ravi <> wrote:


    > > I m relatively new to C.

    >
    > Then why ask questions on how it's implemented? You're
    > trying to run before you can crawl.


    in theory this is the right answer but some people need
    a concrete implementation to hang their thoughts on.

    E1: "but you don't need to know the dtails of how that works!"
    E2: "yes I do!"
    E1: "you wouldn't expect to know the dtails of how the compiler
    worked would you?"
    E2: "well yes I would actually"


    "I understood once I realised it's all shift registers!"
    an explanation of the functioning of a digital switch,
    that I felt lacked detail.



    > > I have few queries related to malloc():

    >
    > > 1. When we perform malloc(), the memory allocated
    > > dynamically comes from the heap area of the process in
    > > concern.

    >
    > If you say so. The language standard does not specify how
    > malloc is implemented, merely how it must operate.


    again, an outline sketch of an implementation can help.


    > > Well, we then say that the heap has shrinked. my query
    > > is: Is it that the heap physically does not shrink but
    > > the perticular nodes are marked 'ALLOCATED' and for
    > > subsequent calls to malloc() the memory manager
    > > remembers them and does not reference them?


    typically, yes (actually pretty well certainly, yes!)

    <snip>

    --
    Nick Keighley
     
    Nick Keighley, Nov 30, 2007
    #12
  13. ravi

    Flash Gordon Guest

    CBFalconer wrote, On 30/11/07 00:42:
    > ravi wrote:


    <snip>

    >> 3. whats the maximum memory size that we can allocate dynamically by
    >> calling malloc() ?

    >
    > Depends on the system. All you can find out is that a malloc
    > (etc.) request is fulfilled or rejected.


    <snip>

    You also know that you cannot allocate more than (size_t)-1 bytes with a
    single call to malloc.
    --
    Flash Gordon
     
    Flash Gordon, Nov 30, 2007
    #13
  14. ravi

    cr88192 Guest

    "Nick Keighley" <> wrote in message
    news:...
    > On 29 Nov, 21:44, Peter Nilsson <> wrote:
    >> ravi <> wrote:

    >
    >> > I m relatively new to C.

    >>
    >> Then why ask questions on how it's implemented? You're
    >> trying to run before you can crawl.

    >
    > in theory this is the right answer but some people need
    > a concrete implementation to hang their thoughts on.
    >


    yes.

    in the college where I am going, this has sometimes been referred to as a
    difference between platonic and aristotelean thought processes...


    > E1: "but you don't need to know the dtails of how that works!"
    > E2: "yes I do!"
    > E1: "you wouldn't expect to know the dtails of how the compiler
    > worked would you?"
    > E2: "well yes I would actually"
    >
    >
    > "I understood once I realised it's all shift registers!"
    > an explanation of the functioning of a digital switch,
    > that I felt lacked detail.
    >
    >


    I originally partly learned C by examining lots of assembler output from the
    compiler (at first I had found assembler easier to understand).

    so, this was my early years:
    I started with basic, later moving to assembler.
    I then more or less moved from assembler to C.

    back in my early days of learning C, there were more than a few things that
    I learned from the wolfenstien source as well...

    look at source, try to figure out how to imitate it...


    then I moved to 32 bit archs, as over the years 16-bit was gradually
    replaced by 32-bit, and dos by windows and linux. for a long time after
    this, I continued on with a faulty understanding of all that was going on in
    assembler land, until more recently when I have gotten much more heavily
    involved with assembler again (compiler writing does this...).

    and, now, for me much of a lifetime later, we are again seeing a transition,
    from 32 to 64 bits...


    and I watch as those of us born in the 80s are becomming 'old', being
    rapidly replaced by those from the 90s...
    a few years back, people born in the 80s were still young, and people born
    in the 90s were little kids...

    time passes and the distant past becomes ever more detached, as my life
    quickly escaped me and I become old and pointless, in a life quickly going
    nowhere...

    and such...


    >
    >> > I have few queries related to malloc():

    >>
    >> > 1. When we perform malloc(), the memory allocated
    >> > dynamically comes from the heap area of the process in
    >> > concern.

    >>
    >> If you say so. The language standard does not specify how
    >> malloc is implemented, merely how it must operate.

    >
    > again, an outline sketch of an implementation can help.
    >


    yes.


    >
    >> > Well, we then say that the heap has shrinked. my query
    >> > is: Is it that the heap physically does not shrink but
    >> > the perticular nodes are marked 'ALLOCATED' and for
    >> > subsequent calls to malloc() the memory manager
    >> > remembers them and does not reference them?

    >
    > typically, yes (actually pretty well certainly, yes!)
    >
    > <snip>
    >
    > --
    > Nick Keighley
     
    cr88192, Dec 1, 2007
    #14
  15. ravi

    CBFalconer Guest

    cr88192 wrote:
    >

    .... snip ...
    >
    > and I watch as those of us born in the 80s are becomming 'old',
    > being rapidly replaced by those from the 90s... a few years back,
    > people born in the 80s were still young, and people born in the
    > 90s were little kids...
    >
    > time passes and the distant past becomes ever more detached, as
    > my life quickly escaped me and I become old and pointless, in a
    > life quickly going nowhere...


    Now try the effect of being born in the early '30s. :)

    --
    Chuck F (cbfalconer at maineline dot net)
    <http://cbfalconer.home.att.net>
    Try the download section.


    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Dec 1, 2007
    #15
  16. ravi

    santosh Guest

    OT - Re: malloc realloc and pointers

    cr88192 wrote:

    <snip>

    > I originally partly learned C by examining lots of assembler output
    > from the compiler (at first I had found assembler easier to
    > understand).
    >
    > so, this was my early years:
    > I started with basic, later moving to assembler.
    > I then more or less moved from assembler to C.


    It was a slightly different sequence for me. My first languages were
    BASIC (BASICA) and Pascal. Then I moved on to C and now more recently,
    I have also been dabbling in assembler (x86_32).

    I also know a fair bit of Java, Perl and shell (sh).

    I prefer C or assembler for hobby programming. To hack out a quick
    prototype I usually use Perl or bash. Of course BASIC and Pascal have
    fallen by the wayside...

    > back in my early days of learning C, there were more than a few things
    > that I learned from the wolfenstien source as well...


    My approach is a bit different. I read up on a concept and then try my
    hand at several "demos" that exercise that. For a long time before
    finding this group I did not really pay any attention to portability -
    my code used to make heavy use of compiler extensions. Now of course, I
    try to keep as much of my code as possible portable.

    > look at source, try to figure out how to imitate it...


    This approach has generally not worked that well for me. I prefer the
    textbook and try-it-and-see approach. But to each his own I guess.

    <snip>

    > and, now, for me much of a lifetime later, we are again seeing a
    > transition, from 32 to 64 bits...


    Yes. For the moment I'm still staying with x86_32. The prospect of
    learning yet another bunch of instructions and rules is wearysome, but
    sooner rather than later I'll have to crack open the x86_64 manuals.
    Sometimes I wish Herbert's 68000 series had made it instead of Intel's
    IA-32. It'd have so much easier on the grey matter...

    <snip>
     
    santosh, Dec 1, 2007
    #16
  17. ravi

    cr88192 Guest

    Re: OT - Re: malloc realloc and pointers

    "santosh" <> wrote in message
    news:fir7hg$fut$...
    > cr88192 wrote:
    >
    > <snip>
    >
    >> I originally partly learned C by examining lots of assembler output
    >> from the compiler (at first I had found assembler easier to
    >> understand).
    >>
    >> so, this was my early years:
    >> I started with basic, later moving to assembler.
    >> I then more or less moved from assembler to C.

    >
    > It was a slightly different sequence for me. My first languages were
    > BASIC (BASICA) and Pascal. Then I moved on to C and now more recently,
    > I have also been dabbling in assembler (x86_32).
    >


    yeah.
    I started out with QBasic...

    but, in time one runs into some limitations with basic, and assembler was in
    part an escape.
    I started learning C as well, but it was an indirect path.

    all this was starting partyway through elem (I think mostly starting around
    3rd and 4th grade), where I started transitioning to messing with C and
    transitioning mostly to assembler sometime around 6th grade.

    by 8th grade, I was writing stuff almost purely in C.

    I didn't really start making "progress" on things until about the middle or
    end of highschool, with the first noteworthy project being a crude OS
    (32-bit protected mode, ...). eventually this project died for looking too
    much like "yet another unix" (but horribly buggy with lacking driver
    support).

    and, time has moved on...

    many years have gone by since then (ok, it is still a "one hand" number, but
    I still feel old and useless...). everything seems so long ago, my life
    quickly escaping from me...


    by now I should have been presumably independent, with a job and female
    interest and so on...
    but, it is lame, I am still stuck going to college and females are not
    interested in someone like me...
    they seemingly all find someone already, yet I am still alone...


    > I also know a fair bit of Java, Perl and shell (sh).
    >


    never really learned Java in much detail (I learned enough to give me a
    strong distaste for OO for a number of years).

    Perl, never really liked or felt much need for.
    'sh', too minor of a thing to really consider much of.


    > I prefer C or assembler for hobby programming. To hack out a quick
    > prototype I usually use Perl or bash. Of course BASIC and Pascal have
    > fallen by the wayside...
    >


    yes. I haven't done much of anything in basic for many years.


    >> back in my early days of learning C, there were more than a few things
    >> that I learned from the wolfenstien source as well...

    >
    > My approach is a bit different. I read up on a concept and then try my
    > hand at several "demos" that exercise that. For a long time before
    > finding this group I did not really pay any attention to portability -
    > my code used to make heavy use of compiler extensions. Now of course, I
    > try to keep as much of my code as possible portable.
    >


    I primarily learned things by studying and immitating things.
    so, it was wolfenstien, doom, quake, and the linux kernel, mostly...

    moving past that, I switched primarily to independent projects...


    >> look at source, try to figure out how to imitate it...

    >
    > This approach has generally not worked that well for me. I prefer the
    > textbook and try-it-and-see approach. But to each his own I guess.
    >


    books are hard to come by.
    parents never really much liked buying books for me (or, at least, ones that
    were actually useful).

    they were good at getting total introductory/newb books, but I don't really
    need books with a bunch of stuff I already know.


    > <snip>
    >
    >> and, now, for me much of a lifetime later, we are again seeing a
    >> transition, from 32 to 64 bits...

    >
    > Yes. For the moment I'm still staying with x86_32. The prospect of
    > learning yet another bunch of instructions and rules is wearysome, but
    > sooner rather than later I'll have to crack open the x86_64 manuals.
    > Sometimes I wish Herbert's 68000 series had made it instead of Intel's
    > IA-32. It'd have so much easier on the grey matter...
    >


    yes, ok.

    well, 16-bits was fading when I was back in elem, watching the change in
    progress, as the distant past transitions into the present.

    I remember when I was back in HS or so and heard about x86-64 (I was like,
    cool, a 64 bit chip that there is actually reason to use...), but it took so
    long in comming out, me getting one, and am still waiting for good OS
    support, ...


    so, the world has changed some since when I was young...
    slowly but surely the world has changed.


    > <snip>
    >
     
    cr88192, Dec 1, 2007
    #17
  18. ravi

    cr88192 Guest

    "CBFalconer" <> wrote in message
    news:...
    > cr88192 wrote:
    >>

    > ... snip ...
    >>
    >> and I watch as those of us born in the 80s are becomming 'old',
    >> being rapidly replaced by those from the 90s... a few years back,
    >> people born in the 80s were still young, and people born in the
    >> 90s were little kids...
    >>
    >> time passes and the distant past becomes ever more detached, as
    >> my life quickly escaped me and I become old and pointless, in a
    >> life quickly going nowhere...

    >
    > Now try the effect of being born in the early '30s. :)
    >


    your case, or hypothetical?...


    I guess the changes for someone who has lived so long would be far greater
    than what I have seen in my 2+ decades of existence (of which I can remember
    maybe about 12-15 years of it, and of which I have been coding most of
    this...).

    well, it will soon be my birthday.
    another year older, and I have little to show for it...
    well, I wrote a C compiler this year, and wrote a few other things, maybe at
    least worth something...

    but, in time, my life will end, and I wonder if I will ever have much of
    anything to show for having existed.
    what of all the people younger than me possible making more impressive
    achievements?...
    one gets overrun and one gets replaced...

    like middle or high schoolers or such who can pull off maybe 200 or 300
    kloc/year or more?...
    maybe they can write impressive stuff, or make interesting discoveries?...

    it has been much of a year, and my compiler has not even broken 100 kloc
    yet.

    taking my average rate calculated earlier this year, and estimating for a
    full year, it comes out to about 100kloc/year, which is probably rather
    lame...


    > --
    > Chuck F (cbfalconer at maineline dot net)
    > <http://cbfalconer.home.att.net>
    > Try the download section.
    >
    >
    > --
    > Posted via a free Usenet account from http://www.teranews.com
    >
     
    cr88192, Dec 1, 2007
    #18
  19. ravi

    santosh Guest

    cr88192 wrote:

    >
    > "CBFalconer" <> wrote in message
    > news:...
    >> cr88192 wrote:
    >>>

    >> ... snip ...
    >>>
    >>> and I watch as those of us born in the 80s are becomming 'old',
    >>> being rapidly replaced by those from the 90s... a few years back,
    >>> people born in the 80s were still young, and people born in the
    >>> 90s were little kids...
    >>>
    >>> time passes and the distant past becomes ever more detached, as
    >>> my life quickly escaped me and I become old and pointless, in a
    >>> life quickly going nowhere...

    >>
    >> Now try the effect of being born in the early '30s. :)
    >>

    >
    > your case, or hypothetical?...


    <snip>

    > but, in time, my life will end, and I wonder if I will ever have much
    > of anything to show for having existed.
    > what of all the people younger than me possible making more impressive
    > achievements?...
    > one gets overrun and one gets replaced...
    >
    > like middle or high schoolers or such who can pull off maybe 200 or
    > 300 kloc/year or more?...
    > maybe they can write impressive stuff, or make interesting
    > discoveries?...
    >
    > it has been much of a year, and my compiler has not even broken 100
    > kloc yet.
    >
    > taking my average rate calculated earlier this year, and estimating
    > for a full year, it comes out to about 100kloc/year, which is probably
    > rather lame...


    Believe it or not you still seem to be _far_ above average with regards
    to programming, for someone of such youth. It _very_ impressive for
    someone of 25 years of age to have written multiple compilers and GCs.
     
    santosh, Dec 1, 2007
    #19
  20. ravi

    CBFalconer Guest

    Re: OT - Re: malloc realloc and pointers

    cr88192 wrote:
    >

    .... snip ...
    >
    > I remember when I was back in HS or so and heard about x86-64 (I
    > was like, cool, a 64 bit chip that there is actually reason to
    > use...), but it took so long in comming out, me getting one, and
    > am still waiting for good OS support, ...


    Well, it looks like you are using Microsoft junk, and they will
    never produce a good OS. I suspect that moving to Linux will
    rapidly satisfy you.
    </BLAST>

    --
    Chuck F (cbfalconer at maineline dot net)
    <http://cbfalconer.home.att.net>
    Try the download section.



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Dec 1, 2007
    #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. Bren
    Replies:
    8
    Views:
    2,032
    Stephen Howe
    Sep 4, 2003
  2. DrBob
    Replies:
    2
    Views:
    584
    Unforgiven
    Nov 26, 2003
  3. Jun Woong

    Re: Override malloc,calloc,realloc and free?

    Jun Woong, Jun 26, 2003, in forum: C Programming
    Replies:
    0
    Views:
    1,084
    Jun Woong
    Jun 26, 2003
  4. Dan Pop
    Replies:
    0
    Views:
    902
    Dan Pop
    Jun 26, 2003
  5. Douglas A. Gwyn

    Re: Override malloc,calloc,realloc and free?

    Douglas A. Gwyn, Jun 26, 2003, in forum: C Programming
    Replies:
    0
    Views:
    751
    Douglas A. Gwyn
    Jun 26, 2003
Loading...

Share This Page