#1743: Reduce number of output files per directory -----------------------+---------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: review Priority: unset | Milestone: Component: Other | Version: development version Resolution: | Keywords: -----------------------+----------------------------------------------------
Comment (by eschnett):
Replying to [comment:12 knarf]:
This is a special case, since {{{ilog(0)}}} is not defined.
We could define it. The "Number of processes that can access the same
directory" being 1 doesn't seem to be unreasonable to me.
It's "log of the number of processes minus one", and "log of zero" is undefined. Running on one process is truly a special case.
The fact that you cannot have just one file per directory is different. The subdirectories form a tree; if each tree branch has just 1 child, then the tree would be infinite. That's a limit on the use parameter {{{processes_per_directory}}}.
- The patch uses strcpy/strcat; it should use strncpy/strncat
instead. The assert about the length before
isn't enough; asserts can be no-ops, and they wouldn't silence
warnings as well.
That's a common misconception. The semantics of {{{strncpy}}} and
{{{strncat}}} are not what people think. The length argument of {{{strncat}}} isn't the available buffer size, and {{{strncpy}}} does not always append a {{{NUL}}} character.
I do understand that a wrong usage of both strncat and strncpy can lead
to problems much like the usage of strcat and strcpy. I don't understand why that should prevent us from using them correctly. Right now, with asserts possibly doing nothing, both strcat and strcpy could write into memory they shouldn't touch.
I refuse to do that. I'll convert the file to C++ instead.
Style: I really didn't intend to complain about the style, and even if
so, certainly not to you. I am sorry if it sounded like that. On that topic: I didn't find this particular topic in the Coding Style guide of Cactus (maintguide), and spaces between function names and the opening parenthesis are not consistently used (or not) even within the flesh. We could add this to the style guide and probably should, even if that alone wouldn't improve the source magically. And yes, I agree: that style guide needs updating. But that would be another ticket.
Sure. I'm actually with you on this -- I don't like the style, and I'm serious about changing the style with an automated tool.