The problem should be fixed in the trunk. VampirTrace also comes now with an own implementation of 'snprintf'. More precisely, the corresponding sources are based on 'opal/util/printf.<c|h>' and located in 'ompi/contrib/vt/vt/util/util.c'. Concerning this matter, I want to know, whether there is a copyright/license problem. Should our 'util.c' also contain your copyright headlines from 'printf.c', for instance?
BTW: We are rather sure, that we found a memory leak in the function 'opal_vsnprintf()'. It seems, that there is a 'free' missing at the and of this function. Can you confirm? Matthias On Mo, 2008-10-27 at 10:46 -0400, George Bosilca wrote: > Brad, > > We have our version of snprintf, just in case the installed standard > library doesn't support it. This function called opal_snprintf will be > aliased to snprintf (./opal/include/opal_config_bottom.h:410). As you > are supposed to always include opal_config.h as first header in your > files, using snprintf will always be safe. > > george. > > On Oct 27, 2008, at 8:08 AM, Brad Penoff wrote: > > > Greetings, > > > > In the current ompi-trunk (r19808), my build was breaking. I have > > created a small patch to fix this, but I wanted to ask the team about > > something first. One of the problems was with snprintf. I read a > > little bit more about this and I found this quote about snprintf: > > > > "snprintf does not form part of the widely implemented ANSI C > > standard, as sprintf does. However, it came into the language for the > > later C99 standard and often existed in C libraries before that." > > > > So I'm wondering, should the use of snprintf as in > > ompi/contrib/vt/vt/tools/opari/tool/opari.cc depend on the value of > > _GLIBCXX_USE_C99 ? > > > > For my system, one "fix" seemed to be to just delete this "using > > std::snprintf;" line. Everything then compiled and worked, but I don't > > know how general/desired this "solution" is. Any comments on snprintf > > and this solution? > > > > Thanks, > > brad > > > > $ svn diff > > Index: ompi/contrib/vt/vt/tools/opari/tool/opari.cc > > =================================================================== > > --- ompi/contrib/vt/vt/tools/opari/tool/opari.cc (revision 19808) > > +++ ompi/contrib/vt/vt/tools/opari/tool/opari.cc (working copy) > > @@ -15,7 +15,6 @@ > > using std::cout; > > using std::cerr; > > #include <cstdio> > > - using std::snprintf; > > using std::remove; > > #include <cstring> > > using std::strcmp; > > Index: orte/tools/orte-iof/orte-iof.c > > =================================================================== > > --- orte/tools/orte-iof/orte-iof.c (revision 19808) > > +++ orte/tools/orte-iof/orte-iof.c (working copy) > > @@ -37,6 +37,9 @@ > > #ifdef HAVE_STDLIB_H > > #include <stdlib.h> > > #endif /* HAVE_STDLIB_H */ > > +#ifdef HAVE_SIGNAL_H > > +#include <signal.h> > > +#endif /* HAVE_SIGNAL_H */ > > #ifdef HAVE_SYS_STAT_H > > #include <sys/stat.h> > > #endif /* HAVE_SYS_STAT_H */ > > _______________________________________________ > > devel mailing list > > de...@open-mpi.org > > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Matthias Jurenz, Center for Information Services and High Performance Computing (ZIH), TU Dresden, Willersbau A106, Zellescher Weg 12, 01062 Dresden phone +49-351-463-31945, fax +49-351-463-37773
smime.p7s
Description: S/MIME cryptographic signature
