I have searched the internet for malloc and dynamic malloc; however, I still
don't know or readily see what is general way to allocate memory to char *
variable that I want to assign the substring that I found inside of a
string.
Any ideas?
Aug 30 '06
94  4767 
Philip Potter said:
"Richard Heathfield" <in*****@invali d.invalidwrote in message
news:8a******** ************@bt .com...
>>
So much for automatic garbage collection.
Richard, while you have earned a lot of my respect and admiration through
your posting, I do feel that you are on a little bit of a crusade here.
Perhaps, but you may be mistaken as to the issues at stake.
You seem to be arguing that because garbage collection can't protect
against all memory leaks without care from the user, it is worthless.
No, I'm sure it has a place in other languages. I just don't think it sits
very well with C, for at least two reasons:
1) As we have already seen upthread, automatic garbage collection (AGC)
encounters serious difficulties when faced with C's heavy use of pointers
for keeping track not only of memory blocks but of particular positions
within them.
2) C is commonly used where not only performance but even timing (in
real-time stuff) is an important criterion for acceptance of the program,
and AGC implementations are notorious for introducing arbitrary delays at
various times through a program's run.
As I have already agreed, AGC is undoubtedly of value to some people in some
situations. I just don't think AGC is a good fit for C programmers, in the
general case. That's not to say that it might not be useful on occasion,
but I don't believe such occasions are sufficiently common to make the
subject a worthwhile diversion away from the topic of this newsgroup, which
is C programming, *not* "C programming + Jacob Navia's AGC extensions".
Were this discussion taking place in Jacob Navia's own newsgroup,
comp.compilers. lcc, then I would not have raised any objections at all.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
"Richard Heathfield" <in*****@invali d.invalidwrote in message
news:gb******** ************@bt .com...
Perhaps, but you may be mistaken as to the issues at stake.
Perhaps. I haven't said very much yet, so it's a bit early to be drawing
conclusions.
No, I'm sure it has a place in other languages. I just don't think it sits
very well with C, for at least two reasons:
1) As we have already seen upthread, automatic garbage collection (AGC)
encounters serious difficulties when faced with C's heavy use of pointers
for keeping track not only of memory blocks but of particular positions
within them.
2) C is commonly used where not only performance but even timing (in
real-time stuff) is an important criterion for acceptance of the program,
and AGC implementations are notorious for introducing arbitrary delays at
various times through a program's run.
You're right that AGC is not always suited to C. However, you said above:
I just don't think it sits
very well with C, for at least two reasons:
suggesting you think it is /never/ suited to C. You have yet to convince me
of this. In non-performance-critical, non-realtime situations, I see nothing
wrong with plugging in a garbage collector. And even in realtime situations,
there are ways to ensure the garbage collector will not activate in critical
sections of code.
As I have already agreed, AGC is undoubtedly of value to some people in
some
situations. I just don't think AGC is a good fit for C programmers, in the
general case. That's not to say that it might not be useful on occasion,
but I don't believe such occasions are sufficiently common to make the
subject a worthwhile diversion away from the topic of this newsgroup,
which
is C programming, *not* "C programming + Jacob Navia's AGC extensions".
Were this discussion taking place in Jacob Navia's own newsgroup,
comp.compilers. lcc, then I would not have raised any objections at all.
If all you were complaining about was topicality, then you should have said
so. But it looks to me more like you were complaining about garbage
collection itself, and you yourself were part of the "diversion" you are now
complaining about.
Anyhow, I agree with you that this is offtopic, so perhaps we should leave
this here.
Philip
Philip Potter said:
"Richard Heathfield" <in*****@invali d.invalidwrote in message
news:gb******** ************@bt .com...
>Perhaps, but you may be mistaken as to the issues at stake.
Perhaps. I haven't said very much yet, so it's a bit early to be drawing
conclusions.
But surely "you may be mistaken" is not a conclusion?
<snip>
You're right that AGC is not always suited to C. However, you said above:
>I just don't think it sits
very well with C, for at least two reasons:
suggesting you think it is /never/ suited to C.
I don't think I suggested that at all. I think I suggested that it doesn't
sit very well with C, which is not quite the same thing!
But I'm very much in favour of people being allowed to do what they want to
do as long as it doesn't hurt other people or frighten the horses. So if
people want to use AGC in some extended version of C, great, more power to
them - but I do very much hope that ISO continue to mandate the provision
of support for manual garbage collection via free(), so that those of us
who prefer to maintain manual control over our own programs' garbage
collection can continue to have that control.
<snip>
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
On Fri, 1 Sep 2006, Richard Heathfield wrote:
jacob navia said:
>CBFalconer wrote:
>>Revise the example:
T *p;
if (p = malloc(n * sizeof *p) {
T *q;
q = p+1; p = NULL;
dosomethingwith (q);
q--;
....
}
The revised example will not fool the GC since the block can be reached
from q, since it points between the beginning and the end of the block.
<shrugFinding ways to fool it is a moderately trivial exercise:
p = malloc(n * sizeof *p);
pos = ftell(fp);
fwrite(&p, sizeof p, 1, fp);
p = NULL;
fseek(fp, pos, SEEK_SET);
fread(&p, sizeof p, 1, fp);
Your rebuttal is worse than the disease, because:
(1) If fwrite or fread fails, any further use of p will
invoke undefined behaviour.
(2) Even with error checking inserted, you would still be
leaking memory when fread fails.
(3) In general, writing pointers to files is always
nonportable. So, I am not sure why you are posting this in a
group that values portability.
Tak-Shing
Tak-Shing Chan <t.****@gold.ac .ukwrites:
(3) In general, writing pointers to files is always
nonportable. So, I am not sure why you are posting this in a
group that values portability.
Writing a pointer to a file is *not* always non-portable. It is
portable to write a pointer to a file, read it back within the
same run of the program, and then use the pointer (as long as the
lifetime of the associated memory has not been reached). This is
what Richard did.
Now, whether it's advisable to do so is another question. I
haven't encountered many (any?) situations where it is.
--
"Give me a couple of years and a large research grant,
and I'll give you a receipt." --Richard Heathfield
In article <87************ @benpfaff.org>,
Ben Pfaff <bl*@cs.stanfor d.eduwrote:
>Writing a pointer to a file is *not* always non-portable. It is
portable to write a pointer to a file, read it back within the
same run of the program, and then use the pointer (as long as the
lifetime of the associated memory has not been reached).
Reference, please?
My recollection is that the relevant section says only that
when something is written out to a binary file, that the same
binary value will be read back in. When, though, it comes to a pointer,
that doesn't promise that the reconstituted pointer points to anything.
There is a section of the standard that talks about writing out
pointers and reading them back in, but that has to do with using
the %p printf() format, which Richard did not do.
--
"law -- it's a commodity"
-- Andrew Ryan (The Globe and Mail, 2005/11/26)
On Fri, 1 Sep 2006, Ben Pfaff wrote:
Tak-Shing Chan <t.****@gold.ac .ukwrites:
> (3) In general, writing pointers to files is always
nonportable. So, I am not sure why you are posting this in a
group that values portability.
Writing a pointer to a file is *not* always non-portable. It is
portable to write a pointer to a file, read it back within the
same run of the program, and then use the pointer (as long as the
lifetime of the associated memory has not been reached).
An intervening realloc could mess it up.
This is
what Richard did.
Now, whether it's advisable to do so is another question. I
haven't encountered many (any?) situations where it is.
Tak-Shing
Tak-Shing Chan <t.****@gold.ac .ukwrites:
On Fri, 1 Sep 2006, Ben Pfaff wrote:
>Tak-Shing Chan <t.****@gold.ac .ukwrites:
>> (3) In general, writing pointers to files is always
nonportable . So, I am not sure why you are posting this in a
group that values portability.
Writing a pointer to a file is *not* always non-portable. It is
portable to write a pointer to a file, read it back within the
same run of the program, and then use the pointer (as long as the
lifetime of the associated memory has not been reached).
An intervening realloc could mess it up.
realloc terminates the memory's lifetime.
--
int main(void){char p[]="ABCDEFGHIJKLM NOPQRSTUVWXYZab cdefghijklmnopq rstuvwxyz.\
\n",*q="kl BIcNBFr.NKEzjwC IxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+= strchr(p,*q++)-p;if(i>=(int)si zeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;} ro******@ibd.nr c-cnrc.gc.ca (Walter Roberson) writes:
In article <87************ @benpfaff.org>,
Ben Pfaff <bl*@cs.stanfor d.eduwrote:
>>Writing a pointer to a file is *not* always non-portable. It is
portable to write a pointer to a file, read it back within the
same run of the program, and then use the pointer (as long as the
lifetime of the associated memory has not been reached).
Reference, please?
My recollection is that the relevant section says only that
when something is written out to a binary file, that the same
binary value will be read back in. When, though, it comes to a pointer,
that doesn't promise that the reconstituted pointer points to anything.
Do you believe that you can portably copy pointers with memcpy?
Then why wouldn't you believe that you can portably read and
write pointers in a file, under the stated conditions? You need
not even use a binary file: you could encode the bits in the
pointers as plain text in hexadecimal or another notation, then
decode them when you read them back in.
--
"It wouldn't be a new C standard if it didn't give a
new meaning to the word `static'."
--Peter Seebach on C99
Tak-Shing Chan said:
On Fri, 1 Sep 2006, Richard Heathfield wrote:
<snip>
>>
<shrugFindin g ways to fool it is a moderately trivial exercise:
p = malloc(n * sizeof *p);
pos = ftell(fp);
fwrite(&p, sizeof p, 1, fp);
p = NULL;
fseek(fp, pos, SEEK_SET);
fread(&p, sizeof p, 1, fp);
Your rebuttal is worse than the disease, because:
No, it isn't. I agree that it's not a terribly bright idea, but it is legal
C. Yes, I omitted error-checking for brevity. This is not a student
discussion. It's a discussion amongst people who all know the importance of
error-checking, and we're all big enough and ugly enough to know where the
error-checking would go. This is just short-hand, that's all. If you want
full error-checking (as indeed I would, in a real program), you are
perfectly capable of adding it yourself.
(1) If fwrite or fread fails, any further use of p will
invoke undefined behaviour.
Sure, but error-checking would cope with that in a real program.
(2) Even with error checking inserted, you would still be
leaking memory when fread fails.
Yes, that's perfectly true. But when it succeeds, you would not be leaking
memory.
(3) In general, writing pointers to files is always
nonportable.
Why? If you mean that freestanding implementations don't need to have
filesystems, you're trivially but IMHO irrelevantly correct.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously) This thread has been closed and replies have been disabled. Please start a new discussion. |
