[ET Trac] [Einstein Toolkit] #1743: Reduce number of output files per directory

Einstein Toolkit trac-noreply at einsteintoolkit.org
Fri Feb 13 09:47:25 CST 2015


#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.

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1743#comment:13>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit


More information about the Trac mailing list