Re: [AD] bugfix in floodfill()

[Sven Sandberg <svens@xxxxxxxxxx>]

Eric Botcazou wrote:
> Can't we use the flood() function with negative coordinates too?

No, because the first thing that floodfill() does is make sure 
coordinates are in range. Only nonnegative values are in range. Well, it 
doesn't really matter, I can take away the `unsigned' and use my first 
patch.

> > Oh, but now that we have int's, this can't happen: the int is an array
> > index, and the language guarantees that no array is so big that an int
> > can't index it.
>
> Are you sure? I find only "the expression shall have an integer type" in ISO 
> C99.

OK, you are possibly right in that the language can accept arrays so 
large that they can't be indexed by an int. But on the other hand we use 
int as array index throughout the library, and I think it's safe to say 
that most other code in the world does, too. Are you seriously 
suggesting to check explicitly that an array does not have more than 
2,147,483,647 elements??? With 12 bytes per element, we would first have 
to allocate 6 times more bytes than can be addressed by a 32-bit word, 
which is absurd (especially since crucial parts of Allegro still assume 
sizeof(pointer)=sizeof(int)=sizeof(long)>=4). With the same logic, we 
would have to check integer overflow every time we change an array 
index. We don't want to do that :-)

> Moreover, there is no array in flood.c at all, only a pointer to 
> scratch mem.

It is used as ((FLOODED_LINE*)_scratch_mem + p->next), so it is used in 
pointer addition, which is equivalent to array indexing.


More seriously though, it could be useful to do

   ASSERT(bmp->w<32768 && bmp->h<32768)

But that test would probably be better to do once and for all when the 
bitmap is created, because there are too many places that need this 
assumption.

Sven