Asp Forum - memory allocation problem

Quentin Pope

7/7/2011 9:15:00 PM

--
"If a tree falls over in the forest, ##
and there's nobody there to hear it, ###----------------;
do the other trees all laugh at it?" ### 8 - ( ;
~~~~~~~~~~~~~~~~~~~~~~~~~ ###----------------;void

Hello all,
I'm learning about programing graphics in c on the PC at the
moment,
this function is supposed to allocate memory to put a background picture
into, but it never allocates the memory. Could anyone suggest anything
which might fix the problem. I don't know a great deal about allocating
memory etc, but I'm using the medium memory model. Is the fact that I'm
trying to allocate more than 64k the problem - if it is, how can I fix
it? (or if anyone does know graphics, perhaps an alternative way of
doing this entirely would be better?)

PCX_Init(pcx_picture_ptr image)
{
/* This function allocates the buffer region needed to load a
PCX file.
the SCREEN_WIDTH is 320 and SCREEN_HEIGHT is 200
(I've defined
that.*/

if (!(image->buffer = (char far *)malloc(SCREEN-WIDTH *
SCREENJEIGHT +
1)
{
printf("\ncouldn't allocate screen buffer");
exit(7);
}

}

regards,

Quentin

3 Answers

Bartc

7/7/2011 10:02:00 PM

"Quentin Pope" <qp19433@hotmail.NOSPAM.com> wrote in message
news:iv57jn$35t$1@speranza.aioe.org...

> into, but it never allocates the memory. Could anyone suggest anything
> which might fix the problem. I don't know a great deal about allocating
> memory etc, but I'm using the medium memory model. Is the fact that I'm
> trying to allocate more than 64k the problem - if it is, how can I fix
> it? (or if anyone does know graphics, perhaps an alternative way of
> doing this entirely would be better?)
>
> PCX_Init(pcx_picture_ptr image)
> {
> /* This function allocates the buffer region needed to load a
> PCX file.
> the SCREEN_WIDTH is 320 and SCREEN_HEIGHT is 200
> (I've defined
> that.*/
>
> if (!(image->buffer = (char far *)malloc(SCREEN-WIDTH *
> SCREENJEIGHT +
> 1)
> {
> printf("\ncouldn't allocate screen buffer");
> exit(7);
> }
>
> }

You might post the original code. There are a couple of typos here which
would have caused compilation problems.

BTW how much memory is available in your machine? Is there a restriction on
single memory blocks over 64K (although 320x200 is 64000)?

You might try a test program, which does not attempt graphics, but which
simply allocates (and frees) an increasing amount of memory until it fails.
That might give a clue.

--
Bartc

Kenneth Brody

7/8/2011 3:06:00 PM

On 7/7/2011 5:14 PM, Quentin Pope wrote:
> --
> "If a tree falls over in the forest, ##
> and there's nobody there to hear it, ###----------------;
> do the other trees all laugh at it?" ### 8 - ( ;
> ~~~~~~~~~~~~~~~~~~~~~~~~~ ###----------------;void
>
> Hello all,
> I'm learning about programing graphics in c on the PC at the
> moment,
> this function is supposed to allocate memory to put a background picture
> into, but it never allocates the memory. Could anyone suggest anything
> which might fix the problem. I don't know a great deal about allocating
> memory etc, but I'm using the medium memory model. Is the fact that I'm
> trying to allocate more than 64k the problem - if it is, how can I fix
> it? (or if anyone does know graphics, perhaps an alternative way of
> doing this entirely would be better?)
[...]
> if (!(image->buffer = (char far *)malloc(SCREEN-WIDTH *
> SCREENJEIGHT +
> 1)
[...]

I have to assume that by "never allocates the memory", you mean that
malloc() returns NULL.

Since you mention "medium memory model", and "char far *", I am also going
to assume that this is a real-mode x86 system.

First, what are the values of the #defines you are passing to malloc(), and
what is the actual malloc() statement, without the apparent typos in your post?

From what I recall, data pointers (even "far" pointers) are limited to 64K.
To use something larger you need "huge" pointers, and you need to call
something other than malloc(). (Unless you use "huge memory model", which
has huge pointers by default.) Check for "huge_malloc()" or something
similar, and change your struct to use a "huge char *" for buffer.

Finally, don't cast the return value from malloc() or whatever function you
will eventually use, as it can hide problems caused by not #include'ing the
proper header file.

Beyond that, you will need to ask more questions in a group where all this
system-specific functionality is topical.

--
Kenneth Brody

Quentin Pope

7/8/2011 10:44:00 PM

On Fri, 08 Jul 2011 11:06:05 -0400, Kenneth Brody wrote:
> On 7/7/2011 5:14 PM, Quentin Pope wrote:
>> --
>> "If a tree falls over in the forest, ## and there's nobody
>> there to hear it, ###----------------; do the other trees all
>> laugh at it?" ### 8 - ( ; ~~~~~~~~~~~~~~~~~~~~~~~~~
>> ###----------------;void
>>
>> Hello all,
>> I'm learning about programing graphics in c on the PC at the
>> moment,
>> this function is supposed to allocate memory to put a background
>> picture into, but it never allocates the memory. Could anyone suggest
>> anything which might fix the problem. I don't know a great deal about
>> allocating memory etc, but I'm using the medium memory model. Is the
>> fact that I'm trying to allocate more than 64k the problem - if it is,
>> how can I fix it? (or if anyone does know graphics, perhaps an
>> alternative way of doing this entirely would be better?)
> [...]
>> if (!(image->buffer = (char far *)malloc(SCREEN-WIDTH *
>> SCREENJEIGHT +
>> 1)
> [...]
>
> I have to assume that by "never allocates the memory", you mean that
> malloc() returns NULL.
>
> Since you mention "medium memory model", and "char far *", I am also
> going to assume that this is a real-mode x86 system.
>
> First, what are the values of the #defines you are passing to malloc(),
> and what is the actual malloc() statement, without the apparent typos in
> your post?
>
> From what I recall, data pointers (even "far" pointers) are limited to
> 64K.
> To use something larger you need "huge" pointers, and you need to call
> something other than malloc(). (Unless you use "huge memory model",
> which has huge pointers by default.) Check for "huge_malloc()" or
> something similar, and change your struct to use a "huge char *" for
> buffer.
>
> Finally, don't cast the return value from malloc() or whatever function
> you will eventually use, as it can hide problems caused by not
> #include'ing the proper header file.
>
> Beyond that, you will need to ask more questions in a group where all
> this system-specific functionality is topical.

Ken:

I put the (char far *) in before malloc because I got this part of my
code from a book I'm reading with graphics in it (teach yourself Game
Programming in 21 days, by Andre LaMathe), and also because that's what
image->buffer was defined as. Also the book is written using ms c, and
I'm using borland, so I'm trying to work out what I'm doing wrong and
what the differences between ms and borland c are... in the book they
use _fmalloc, I interpreted this as malloc, but now I look at it, is it
meant to be farmalloc?

Anyway, I tried changing the type of buffer from char far * to unsigned
int *. Now I no longer get the unable to initialise graphics message,
the computer goes into (a) graphics mode and completely hangs (I made
the mistake of finding this out while I was online writing this message
for the first time - I knew I shouldn't have broken my rule about
programming whilst online...)

Since that bit of code doesn't send the computer into graphics mode,
should I guess that it now works, and it's another bit of code that
doesn't?

ah well, I'll get there.

Regards,

Quentin.

PS: thanks to the people who responded so far, and to those who will
help in the future.

PSS: and now, my sig, in it's entirety and where it's supposed to be:

--
"If a tree falls over in the forest, ##
and there's nobody there to hear it, ###----------------;
do the other trees all laugh at it?" ### 8 - ( ;
~~~~~~~~~~~~~~~~~~~~~~~~~ ###----------------;

comp.lang.c

memory allocation problem

Quentin Pope

Bartc

Kenneth Brody

Quentin Pope

x Login to ForumsZone