Re: filling area by color atack safety

On 17/03/2024 16:45, David Brown wrote:

On 16/03/2024 16:09, Malcolm McLean wrote:

 

The OP's code is simple and obvious, as is its correctness (assuming reasonable definitions of the pixel access and setting functions) and its time and space requirements.  Yours is not.
 

Except it is not. You didn't give the right answer for the space requirements.

Your algorithm could be used in a proper implementation, with separate functions to handle the different parts (such as the stack).  The algorithm itself is not bad, it's the implementation that is the main problem.
 

It's better to have one function. Subroutines have a way of getting lost.>

I have no idea if your code is "out of date" or not.  It seems to be written for images consisting of unsigned chars, so I a not sure it was ever designed for real-world images.
 

It was written a long time ago. But it is writeen in a conservative subset of ANSI C, and so of course it still works, and should work for along time to come. But the 256 integer queue tweak might be out of date. And cache use is far more important now that it was on big processors. So it might be a bit long in the tooth.
And it's part of the binary image library, and it's designed for marking 8- or 4- connected sections of those images by setting the 1 to a different value. And then further processing. The binary images are often derived from photographs by Otsu thresholding, which is in the same library. But they aren't usually meant for human viewing by end users.

 I don't know if it is fair to call them a /lot/ more advanced, but certainly a bit more advanced.  And certainly better implementations are possible.
 

And are you going to be constructive or not? Suggest one which might be better? Even implement it?
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm