MESSAGE
| DATE | 2004-04-22 |
| FROM | Billy
|
| SUBJECT | Re: [hangout] Debugging cdparanoia in C
|
On Thu, Apr 22, 2004 at 06:15:04AM -0400, Ruben I Safir wrote:
> ie: malloc in copystring.
>
> I don't know what was wrong with the standard strcpy program
I'll assume you meant strdup.
Their copystring function allocates 9 extra bytes to workaround
what they claim is a bug in libc5 (details hazy).
> Would you recommend using a signal handler for the malloc problem or
> just exit. If you run out of ram, it might hang the program (and the
> OS)
Exit. The way they have it implemented, they're going
to get to a signal handler (SIGSEGV) as soon as they try
to copy characters into the null pointer. Portable
code shouldn't rely on such local color as SIGSEGV, and should somehow
exit or recover. Being careful about memory leaks goes a long way
toward making sure it never comes to that, of course :) .
I'm pretty sure there's plenty of error reporting/recovery
infrastructure in cdparanoia, considering that paranoia's PRIMARY
purpose is error recovery for CD audio..
> In any event, for anyone following this thread, the malloc command in C allocates
> a block of memory for future use, so properly writing an allocation should look something
> like:
>
> char *p;
>
> if((p=malloc(1000))==NULL){
> fprintf( STDERR, "%s", "Out of RAM - can not allocate more memory");
> exit(0);
> }
Wrong.
char *p;
if((p=malloc(1000))==NULL){
fprintf(stderr, "malloc failed: %s\n", strerror(errno));
exit(1);
}
...
free(p);
Find 5 differences between Ruben's version and my version.
____________________________
NYLXS: New Yorker Free Software Users Scene
Fair Use -
because it's either fair use or useless....
NYLXS is a trademark of NYLXS, Inc
|
|
