Date:	Sun, 7 Nov 1999 15:58:55 -0600 (CST)
From:	Dave Dribin <drib AT enteract DOT com>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc:	djgpp AT delorie DOT com
Subject:	Re: Allegro 3.12: page fault in generate_optimized_palette()
In-Reply-To:	<Pine.SUN.3.91.991107172835.12805h-100000@is>
Message-ID:	<Pine.NEB.3.96.991107154650.22278A-100000@shell-2.enteract.com>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Sun, 7 Nov 1999, Eli Zaretskii wrote:
> On 6 Nov 1999, Dave Dribin wrote:
> 
> > As you can see (max - j) ends up being negative and causing havoc on
> > the memcpy().  Is this a known problem?  Am I using the function
> > wrong?
> 
> Yes and yes.  memcpy has the following prototype (see <string.h> and
> the documentation of memcpy):
> 
>   void * memcpy(void *_dest, const void *_src, size_t _n);
> 
> The last argument is type size_t, which is an unisigned integral
> type.  So your negative value is interpreted as a very large positive
> value, and causes your program to crash because you are writing
> outside the limits of the array common[].
> 
> In other words, your code has a bug.
> 
> In addition, please note that memcpy is not supposed to be used for
> copying overlapping regions, and your code does precisely that.  Use
> memmove if the source and destination overlap.

Ahh... one minor point.  The code I posted was from within the Allegro
get_optimize_palette() library call, not my code. :) I understand
completely why the memcpy() was failing (negative number as length
parameter and all).  I was more looking for why the library call was
page faulting and if I was using the library call incorrectly.  I
think this question belongs more on the Allegro mailing list, but
thanx for your help anyway!

BTW, I've upgraded to Allegro 3.9.26 (WIP) from Allegro 3.12 and this
get_optimize_palette() call works mildly better.  It doesn't page
fault, but it doesn't exactly work 100%, either.

-Dave

- Raw text -