Yet-another-realloc problem
| Author |
Message |
|
Ghazan Haid
#1 / 9
|
 Yet-another-realloc problem I read many old and new threads on this and found answers distantly
related but not quite.
The first time I realloc() on a malloc-ed pointer, it works perfectly
to sizes in megabytes. The second time it gives a core dump. I re-make
a very basic loop that mallocs and serially reallocs and nothing else,
and it works just fine. Now the really strange part is that in my own
program, if I comment out the workings and it just allocs and
reallocs, it works fine. When I put in the workings, which are
basically entering data into the buffer, the REALLOC fails with
returning NULL, yet not setting errno.
So it must be the place where I enter data into the buffer where I
cause problems... but all variable assignments and usage are identical
to the ones I found in ANSI C tutorials and glibc docs.
Here are the vars(outside main, these are global):
FILE *filename;
char s[100],three[5],caligari[11];
long major,minor,size,id,parent,endofchunk;
float *vertexarray,*facearray,*normalarray,*modearray,*colorarray,*temp;
long vertexcount,facecount,normalcount,modecount,colorcount,counttotal;
int debugone,debugtwo;
float floatx,floaty,floatz;
int count;
-----------------------
Here is part of main. This has to exist because I cant depend on
realloc taking NULL pointer and working like malloc:
vertexarray=(float *)malloc((float) 100);
facearray=(float *)malloc((float)100);
normalarray=(float *)malloc((float)100);
modearray=(float *)malloc((float)100);
colorarray=(float *)malloc((float)100);
if (!vertexarray || !facearray || !normalarray || !modearray ||
!colorarray )
printf("Basic mallocs failed\n");
----------------------------
This routine gets called serially for each realloc required:
debugone = ((counttotal+vertexcount)*3 * sizeof(float));
/* the infamous realloc */
temp = realloc(vertexarray,debugone);
printf("Changed buffer size to %d \n",debugone);
/* the workings where the possible problem exists */
if (temp == 0)
{
printf("Couldnt reallocate mem %d\n",errno);
free(temp);
exit(1);
}
vertexarray = temp;
printf("trying to write to newly all mem\n");
for (count=0;count<debugone;count++)
{
vertexarray[count] = 2.2f;
printf("%d ",count);
}
printf("success\n");
---------------------------------------------
The whole file:
http://www.*-*-*.com/
Datafile that test depents on:
http://www.*-*-*.com/
A skeleton that works without glitches:
http://www.*-*-*.com/
CFLAGS = -Wall -ansi -pedantic -g
----------------------------------------------
|
| Sat, 12 Mar 2005 13:10:22 GMT |
|
 |
|
Celine Ambros
#2 / 9
|
Yet-another-realloc problem "Ghazan Haider"
[snip]
Quote: > Here is part of main. This has to exist because I cant depend on > realloc taking NULL pointer and working like malloc: > vertexarray=(float *)malloc((float) 100);
> facearray=(float *)malloc((float)100);
> normalarray=(float *)malloc((float)100);
> modearray=(float *)malloc((float)100);
> colorarray=(float *)malloc((float)100);
block of memory 100 bytes in size. You probably want:
vertexarray = malloc(100 * sizeof *vertexarray);
facearray = malloc(100 * sizeof *facearray);
normalarray = malloc(100 * sizeof *normalarray);
modearray = malloc(100 * sizeof *modearray);
colorarray = malloc(100 * sizeof *colorarray);
[snip didnot bother to go through the rest of your code]
|
| Sat, 12 Mar 2005 13:20:09 GMT |
|
|
|
Kevin Goodsel
#3 / 9
|
Yet-another-realloc problem On Tue, 24 Sep 2002 07:20:09 +0200, "Celine Ambross"
Quote:
>"Ghazan Haider" >[snip]
>> Here is part of main. This has to exist because I cant depend on
>> realloc taking NULL pointer and working like malloc:
>> vertexarray=(float *)malloc((float) 100);
>> facearray=(float *)malloc((float)100);
>> normalarray=(float *)malloc((float)100);
>> modearray=(float *)malloc((float)100);
>> colorarray=(float *)malloc((float)100);
>The above lines probably donot do what you think they do: they try to allocate a
>block of memory 100 bytes in size.
Actually, I don't think we can be too sure of that. If there's no
declaration for malloc in scope, this is a huge chunk of undefined
behavior.
OP: Did you remember to #include <stdlib.h> at the top of *every*
source file that calls malloc, realloc, or calloc?
Look for recent threads about why you should *never* cast the return
value from malloc and friends.
-Kevin
|
| Sat, 12 Mar 2005 13:46:52 GMT |
|
|
|
Barry Schwar
#4 / 9
|
Yet-another-realloc problem
Quote: >Here is part of main. This has to exist because I cant depend on
>realloc taking NULL pointer and working like malloc:
>vertexarray=(float *)malloc((float) 100);
Yes you can. The standard requires realloc to work like malloc when
the "old pointer" is NULL.
<<Remove the del for email>>
|
| Sun, 13 Mar 2005 17:55:30 GMT |
|
|
|
Mark McIntyr
#5 / 9
|
Yet-another-realloc problem On 25 Sep 2002 09:55:30 GMT, in comp.lang.c , Barry Schwarz
Quote:
>>Here is part of main. This has to exist because I cant depend on
>>realloc taking NULL pointer and working like malloc:
>>vertexarray=(float *)malloc((float) 100);
>Yes you can. The standard requires realloc to work like malloc when
>the "old pointer" is NULL.
on the other hand, you can't rely on malloc to work like anything when
its called like *that*, so perhaps the OP meant that realloc didn't
produce the same weird behaviour? :-)
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
|
| Mon, 14 Mar 2005 04:54:47 GMT |
|
|
|
Dan P
#6 / 9
|
Yet-another-realloc problem
Quote: >On 25 Sep 2002 09:55:30 GMT, in comp.lang.c , Barry Schwarz
>>>Here is part of main. This has to exist because I cant depend on
>>>realloc taking NULL pointer and working like malloc:
>>>vertexarray=(float *)malloc((float) 100);
>>Yes you can. The standard requires realloc to work like malloc when
>>the "old pointer" is NULL.
>on the other hand, you can't rely on malloc to work like anything when
>its called like *that*, so perhaps the OP meant that realloc didn't
>produce the same weird behaviour? :-)
malloc is in scope. On any implementation with a non-null QoI factor, the
conversion of 100 to floating point will be done exactly and so will be
the conversion back to size_t. Therefore, the OP's code is equivalent to
vertexarray = (float *)malloc(100);
So, I have no clue about what "weird behaviour" Mark McIntyre is talking.
Of course, this doesn't mean that the code does what the OP thinks it
does (most likley, allocate space for 100 float's), but this is a
completely different issue.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
|
| Tue, 15 Mar 2005 00:54:28 GMT |
|
|
|
Herbert Rosen
#7 / 9
|
Yet-another-realloc problem Quote:
>>On 25 Sep 2002 09:55:30 GMT, in comp.lang.c , Barry Schwarz
>>>>Here is part of main. This has to exist because I cant depend on
>>>>realloc taking NULL pointer and working like malloc:
>>>>vertexarray=(float *)malloc((float) 100);
>>>Yes you can. The standard requires realloc to work like malloc when
>>>the "old pointer" is NULL.
>>on the other hand, you can't rely on malloc to work like anything when
>>its called like *that*, so perhaps the OP meant that realloc didn't
>>produce the same weird behaviour? :-)
>The malloc call above is technically correct, if a prototype for
>malloc is in scope. On any implementation with a non-null QoI factor, the
>conversion of 100 to floating point will be done exactly and so will be
>the conversion back to size_t. Therefore, the OP's code is equivalent to
> vertexarray = (float *)malloc(100);
is errornous and may result in an unuseable pointer if the prototype
of malloc is missed. When the casting were missied the compiler will
give a diagnose, that means it will prevent you for using illegal
pointers. NEVER, really never cast the result of a unprototyped
funtion that returns a pointer to void.
I know of at least one hardware that will let give you an illegal
pointer - but it would't crash, because the illegal address would
point somewhere in the addressroom of the program - but constantly on
an address that contains anything but is unequal to the pointer malloc
had returned. Or in other words, it is possible on that hardware that
casing the result of an unpototyped malloc bombs an nuclear power
station out.
Quote: >So, I have no clue about what "weird behaviour" Mark McIntyre is talking. >Of course, this doesn't mean that the code does what the OP thinks it
>does (most likley, allocate space for 100 float's), but this is a
>completely different issue.
>Dan
Tschau/Bye
Herbert
http://www.pc-rosenau.de
the point to buy eComStation in germany
|
| Wed, 16 Mar 2005 20:47:57 GMT |
|
|
|
Mark McIntyr
#8 / 9
|
Yet-another-realloc problem
Quote:
>>>On 25 Sep 2002 09:55:30 GMT, in comp.lang.c , Barry Schwarz
>>>>>Here is part of main. This has to exist because I cant depend on
>>>>>realloc taking NULL pointer and working like malloc:
>>>>>vertexarray=(float *)malloc((float) 100);
>>>>Yes you can. The standard requires realloc to work like malloc when
>>>>the "old pointer" is NULL.
>>>on the other hand, you can't rely on malloc to work like anything when
>>>its called like *that*, so perhaps the OP meant that realloc didn't
>>>produce the same weird behaviour? :-)
>>The malloc call above is technically correct, if a prototype for
>>malloc is in scope. On any implementation with a non-null QoI factor, the
>>conversion of 100 to floating point will be done exactly and so will be
>>the conversion back to size_t.
Sure. My point was that I bet the OP wanted 100 floats, not 100 chars.
So to him, the fact that it only allocated, say, 25 would be unknown
(to him), and when he wrote to the 26th, "weird" would be a good way
to describe the likely results, from his point of view.
Quote: >Therefore, the OP's code is equivalent to >> vertexarray = (float *)malloc(100);
>is errornous and may result in an unuseable pointer if the prototype
>of malloc is missed. When the casting were missied the compiler will
>give a diagnose, that means it will prevent you for using illegal
>pointers. NEVER, really never cast the result of a unprototyped
>funtion that returns a pointer to void.
Quote: >>So, I have no clue about what "weird behaviour" Mark McIntyre is talking.
{*filter*}imindeness aside of course.
Quote: >>Of course, this doesn't mean that the code does what the OP thinks it
>>does (most likley, allocate space for 100 float's), but this is a
>>completely different issue.
What, you think that doing something completely different to what the
user expected isn't weird from the users perspective? Remind me not to
employ you - I can just imagine the support calls. :-)
--
Mark McIntyre
CLC FAQ < http://www.*-*-*.com/ ~scs/C-faq/top.html>
CLC readme: < http://www.*-*-*.com/ ;
|
| Thu, 17 Mar 2005 05:11:40 GMT |
|
|
|
Dan P
#9 / 9
|
Yet-another-realloc problem
Quote:
>>>On 25 Sep 2002 09:55:30 GMT, in comp.lang.c , Barry Schwarz
>>>>>Here is part of main. This has to exist because I cant depend on
>>>>>realloc taking NULL pointer and working like malloc:
>>>>>vertexarray=(float *)malloc((float) 100);
>>>>Yes you can. The standard requires realloc to work like malloc when
>>>>the "old pointer" is NULL.
>>>on the other hand, you can't rely on malloc to work like anything when
>>>its called like *that*, so perhaps the OP meant that realloc didn't
>>>produce the same weird behaviour? :-)
>>The malloc call above is technically correct, if a prototype for
>>malloc is in scope. On any implementation with a non-null QoI factor, the
>>conversion of 100 to floating point will be done exactly and so will be
>>the conversion back to size_t. Therefore, the OP's code is equivalent to
>> vertexarray = (float *)malloc(100);
>is errornous
Chapter and verse, please.
Quote: >and may result in an unuseable pointer if the prototype
>of malloc is missed.
Which part of "if a prototype for malloc is in scope" in my previous post
was too difficult for you to understand?
Quote: >When the casting were missied the compiler will
>give a diagnose, that means it will prevent you for using illegal
>pointers.
Where did you get the idea from? It will give a diagnostic, but this
doesn't necessarily means that it won't compile the broken code, anyway.
Quote: >NEVER, really never cast the result of a unprototyped
>funtion that returns a pointer to void.
How do you know the function was unprototyped? E.S.P.?
Note that I'm not advocating this silly casting, merely pointing out that
this is a style issue, not a correctness one. The cast is silly, but it
doesn't affect the correctness of a program: if the program is correct
without the cast, it is also correct with the cast and vice versa.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
|
| Fri, 18 Mar 2005 23:14:42 GMT |
|
| |
|
