xserver: Branch 'master'

[Paulo Cesar Pereira de Andrade]

Adam Jackson wrote:
>  hw/xfree86/xf4bpp/ppcSpMcro.h |    6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> New commits:
> commit 57d48d94b8947c571925e6fd4c9bf041fbd1b2ac
> Author: Adam Jackson <ajax at redhat.com>
> Date:   Fri Mar 14 14:37:42 2008 -0400
>
>     Fix a stray use of ALLOCATE_LOCAL.
>
> diff --git a/hw/xfree86/xf4bpp/ppcSpMcro.h b/hw/xfree86/xf4bpp/ppcSpMcro.h
> index 2b7f951..655a883 100644
> --- a/hw/xfree86/xf4bpp/ppcSpMcro.h
> +++ b/hw/xfree86/xf4bpp/ppcSpMcro.h
> @@ -28,11 +28,11 @@
>  #define SETSPANPTRS(IN,N,IPW,PW,IPPT,PPT,FPW,FPPT,FSORT)		\
>  	{								\
>  	N = IN * miFindMaxBand(pGC->pCompositeClip);			\
> -	if(!(PW = (int *)ALLOCATE_LOCAL(N * sizeof(int))))		\
> +	if(!(PW = (int *)xalloc(N * sizeof(int))))		\
>  		return;							\
> -	if(!(PPT = (DDXPointRec *)ALLOCATE_LOCAL(N * sizeof(DDXPointRec)))) \
> +	if(!(PPT = (DDXPointRec *)xalloc(N * sizeof(DDXPointRec)))) \
>  		{							\
> -		DEALLOCATE_LOCAL(PW);					\
> +		free(PW);					\
>  		return;							\
>      		}							\
>  	FPW = PW;							\
> _______________________________________________
> xorg-commit mailing list
> xorg-commit at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg-commit

  I posted a fix for it long long ago at xorg at lists.freedesktop.org,
then I also added it to https://bugs.freedesktop.org/show_bug.cgi?id=14730
so that maybe someone with commit rights would look at.

  This is like the fourth time this week someone will "independently"
find and fix a bug I posted the solution to the mailing list, and
opened a bugzilla for it.

  And I think it was really a bad idea to just "nuke" ALLOCATE_LOCAL
and DEALLOCATE_LOCAL, instead, at least do a grep in the sources to
not leave so many other occurrences that now are compiled as calls
to functions (hell, -Wmissing-prototypes should be in XORG_CFLAGS,
or maybe -Werror=missing-prototypes).

  But the real solution would be to write proper code possibly
analyzing the usages, so that where the buffer size is not known have
a malloc/free fallback, allocating data in the stack isn't something
bad and if done in some inner loop, it can be a major performance
killer. One could just "preallocate" something like 1024 bytes in
the stack, and do it in a 100% portable way, i.e. if requiring more
than those 1024 byte, allocate memory...

Paulo