infinite loop when filename does not contain '%T' but IterationEncoding is fileBased

[PrometheusPi]

Describe the bug
When setting a series' file name without the %T and switching the IterationEncoding to fileBased the code runs into an infinite loop.

To Reproduce
C++

#include <openPMD/openPMD.hpp>

void error_openPMD()
{
    ::openPMD::Series series = ::openPMD::Series("error.h5", ::openPMD::Access::CREATE);
    series.iterations[10];
    series.setIterationEncoding(::openPMD::IterationEncoding::fileBased);
    series.flush(); 
};

int main()
{
    error_openPMD();
};

Expected behavior
Such a wrong configuration should be caught and an error should be thrown.

Software Environment

• version of openPMD-api: 0.13.2
• installed openPMD-api via: conda-forge,
• operating system: MacOS 10.15.7
• version of HDF5: 1.10.6

Additional context
This infinite loop can only be triggered if the user initially set a wrong file name.

[franzpoeschel]

I cannot reproduce this behavior neither on the dev nor with 0.13.2. Both versions create a file 000000000000000000000000000000000000000000000010.h5 which is a bug in itself.
Will retry this with the conda-forge version of openPMD-api.

[franzpoeschel]

With openPMD 0.13.2 from Conda, this writes a file 10.h5. I think the best way to go forward will be not to try reproducing this, but instead to cleanly catch this setup and throw an error.

[PrometheusPi]

Strange, I could not create a file but ran into an infinite loop. Might there be differences in (I assume) gcc on your OS and clang (on mine) that cause that issue?
My file system would support the strange file name with many zeros.

But I agree with you @franzpoeschel - catching it (and not reproducing it) might be the best solution. Perhaps that will also solve the infinite loop.

[franzpoeschel]

I've found the reason: The filename padding has no default value. If you specify file-based iteration encoding without specifying an expansion pattern, it remains uninitialized and you get an arbitrary number of zeros on your file path. So you don't really have an infinite loop, just a very long one resulting in a very long filename.
I'll open a PR to fix that and also to recognize this wrong use of the API.