fill_n and generate_n are documented as std::fill_n / std::generate_n in parallel. The std versions do nothing when the count is zero or negative, but make_fill_n_task and make_generate_n_task convert the count with size_t N = count;, so a count of -1 becomes SIZE_MAX. With one worker the task falls back to std::fill_n / std::generate_n and nothing happens. With more workers the range is split as if it held SIZE_MAX elements and the tasks write past the end of the container.

Reproduction on master (bbd7251):

std::vector<int> vec(8, 0);
tf::Executor executor(2);
tf::Taskflow taskflow;
taskflow.fill_n(vec.begin(), -1, 42);
executor.run(taskflow).wait();  // crashes

I ran this with 1 to 4 workers for both fill_n and generate_n. With 1 worker it returns with vec unchanged. With 2, 3 or 4 workers it crashed in all 60 runs (10 per case). With this change all eight cases return with vec unchanged.

Changes

• taskflow/algorithm/fill.hpp, taskflow/algorithm/generate.hpp: clamp the count to 0 before converting it to size_t.
• unittests/test_fill.cpp, unittests/test_generate.cpp: add ParallelFillN.NonPositiveCount and ParallelGenerateN.NonPositiveCount, covering counts 0, -1 and -1000 with 1 to 4 workers and the guided, dynamic, static and random partitioners, and comparing against the std result. Both crash on master and pass with this change.

Full ctest (GCC 13.3, Release): 3047/3047 pass, against 3045/3045 on master.