Date: Thu, 10 Jun 1999 12:07:23 +0200 From: Hans-Bernhard Broeker Message-Id: <199906101007.MAA28396@acp3bf.physik.rwth-aachen.de> To: djgpp AT delorie DOT com Subject: Re: malloc() problem Newsgroups: comp.os.msdos.djgpp Organization: RWTH Aachen, III. physikalisches Institut B X-Newsreader: TIN [version 1.2 PL2] Reply-To: djgpp AT delorie DOT com In article you wrote: [...] > I don't recall what it was called, but it was described as "test sources" > and unpacked into a directory called DJGPP/TESTS. That'd be the 'djtst202.zip' (or other version number of it), then. And no, there's no need to mail it to us: we know it. [...] > So I gathered. Another weird thing, though: at your request I tried > downsizing the source of the program that produces the error, by allocating > an char array of the same size in stead of the struct I was using (but > leaving everything else, including the typedef, libraries, etc. in place). > The error was gone. Here's the change: This suggests another, possibly somewhat weird idea: did you actually *check* that the size of your structure is 34K, and not something else? You should never assume you can calculate the size of a structure layed out by gcc, yourself. Ask gcc what size it made it. [...] > // if (rc) rc = ((buffer = malloc(sizeof(bufferType))) != NULL); // old > if (rc) rc = ((buffer = malloc(34 * 1024)) != NULL); // new > This produces no errors. If I uncomment where I say "// old" and comment > away where I say "// new", the error is produced. This strongly suggests that the arguments you pass to malloc, here, are not really the same, actually. > typedef struct { > } baseStruct; > typedef struct { > baseStruct crap1; > } firstLevel; > typedef struct { > firstLevel dcrap2[500]; > } secondLevel; > typedef struct { > secondLevel prr[11]; > } bufferType; That's 5500*sizeof(baseStruct), at minimum. Unless there's not more than about 6 bytes in there, that's more than 34K, *before* gcc puts in any padding. > As far as I know, this is legal. I.e., I have used it before without any > problem, but with another compiler. My current working hypothesis is that > there is a problem with this anyway. I am currently thinking of simply > ripping the struct apart and allocating it in diffirent variables. Though > the endresult - at least in the database I/O - will much much less elegant, > I think it may be the only option, as I am starting to suspect this is not > all that legal after all.. It's perfectly legal. -- Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.