«

"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) kst- <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"

On 29 Nov, 21:44, Peter Nilsson <ai...@acay.com.au> wrote:
> ravi <nos...@nospam.invalid> 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

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

"Nick Keighley" <> wrote in message
news:93274b8f-2c55-4946-829b-...
> On 29 Nov, 21:44, Peter Nilsson <ai...@acay.com.au> wrote:
>> ravi <nos...@nospam.invalid> 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 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

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

"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 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.

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