- Boost - lists.boost.org

[inspect] Changes to Inspection Report
by Beman Dawes 18 Jan '10

18 Jan '10

The latest run of the trunk inspection report is up at http://boost.cowic.de/rc/inspect-trunk.html Several new features have been added: * References to unknown bookmarks are now detected. * Duplicate bookmarks are now detected. * Each problem detected is reported on a separate line, to make it easier to work with files that have multiple problems. For example, see the errors below in the filesystem library. Comments? --Beman filesystem libs/filesystem/doc/faq.htm: *LINK* unknown bookmark: #global libs/filesystem/doc/i18n.html: *LINK* unknown bookmark: #Footnote *LINK* unknown bookmark: #status libs/filesystem/doc/index.htm: *LINK* unknown bookmark: #path libs/filesystem/doc/reference.html: *LINK* duplicate bookmark: exists *LINK* duplicate bookmark: initial_path *LINK* unknown bookmark: #basic_directory_entry-comparisons *LINK* unknown bookmark: #operator-eq libs/filesystem/test/deprecated_test.cpp: *APPLE-MACROS* violation of Boost apple-macro guidelines on line 21 *APPLE-MACROS* violation of Boost apple-macro guidelines on line 27 libs/filesystem/test/path_test.cpp: *APPLE-MACROS* violation of Boost apple-macro guidelines on line 34 *APPLE-MACROS* violation of Boost apple-macro guidelines on line 43

8 11

[1.42] Release Notes
by Daniel James 18 Jan '10

18 Jan '10

Hi, Just a quick reminder about the release notes. This is the ideal time to add them to 'boost_1_42_0.qbk' in: https://svn.boost.org/svn/boost/website/public_html/beta/feed/history/ Or if you send them to the list and I'll add them for you. It's helpful if they're added before the beta, so that beta testers know what needs testing. thanks, Daniel

2 3

[1.42.0] Ready for beta?
by Beman Dawes 18 Jan '10

18 Jan '10

How do we look for going ahead with the beta? Unless there are concerns, I'll start putting the beta together later today. --Beman

1 0

[interval containers (itl)] found review manager. New release on sourceforge
by Joachim Faulhaber 18 Jan '10

18 Jan '10

Dear list! I am pleased to announce that Hartmut Kaiser now supports my library of interval containers as review manager. Although this was not necessarily intended, the planned date for the review already found it's way into the review schedule. But this is unofficial as long as Hartmut has not done his announcement of the review period. In preparation to the review I have done some improvements mainly for documentation of the extended parts of the itl, so I have uploaded a new release to the itl's project page on sourceforge http://sourceforge.net/projects/itl/ There are a few corrections and additions to the quickbook docs of the core library itl which is submitted for review: http://herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/index.html For the extended parts there is a doxygen generated documentation http://www.herold-faulhaber.de/itl/index.html that now also contains a commented example for a law based test http://www.herold-faulhaber.de/itl/de__morgan_8cpp.html for people how are interested how this works. Any feed back, comments and suggestions are welcome. Best regards Joachim --------------------------------------------------------------------- Interval Template Library (ITL) | Boost.IntervalContainers --------------------------------------------------------------------- Availability: Project page at sourceforge: http://sourceforge.net/projects/itl/ Boost Vault: http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Conta… Boost Quickbook documentation (corelibrary itl) http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/index.html Doxygen Documentation (extensions itl_xt, validate) http://www.herold-faulhaber.de/itl/index.html The name ITL is provisional and will probably be changed to Boost.IntervalContainers after the review.

1 0

[property_tree] stream_translator <-> lexical_cast
by Domagoj Saric 18 Jan '10

18 Jan '10

By scanning briefly through the property_tree implementation I noticed that it uses its own stream_translator<> class for string-to-other_type and vice verse conversions. The functionality seems very similar/overlapping to that of lexical_cast (and also uses streams), if this is true this part of property_tree should probably be refactored to use lexical_cast so that it gets implicitly 'fixed' when/if lexical_cast gets fixed (regarding the issues outlined in the previous relevant post). -- "That men do not learn very much from the lessons of history is the most important of all the lessons of history." Aldous Huxley

1 0

Boost.Filesystem: basename function is not compatible with POSIX; potential for path-related security issues
by Steve M. Robbins 18 Jan '10

18 Jan '10

Hi, I got the following report [1] for Boost.Filesystem from a Debian user. Before entering into trac, I thought I'd ask whether this deviation from POSIX is by design or is a bug. Thanks, -Steve P.S. The original report is based on Boost 1.40, but I verified the same behaviour on Boost 1.41. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565504 ----- Forwarded message from Roger Leigh <rleigh(a)debian.org> ----- Package: libboost-filesystem1.40.0 Version: 1.40.0-5 Severity: important The basename function is not compatible with the POSIX function by the same name: Path POSIX Boost test.real test.real test /usr/bin/perl perl perl /usr/lib lib lib /usr/ usr usr usr usr / / / . . .. .. . The test program is attached. Just compile with g++ -o testbasename -lboost_filesystem testbasename.cc http://www.opengroup.org/onlinepubs/000095399/functions/basename.html ??? It is not stripping trailing backslashes. ??? "if ph.leaf() contains a dot ('.'), returns the substring of ph.leaf() starting from beginning and ending at the last dot (the dot is not included). Otherwise, returns ph.leaf()". This is wrong, shown by the paths returned for "." ("") and ".." (".") above. The latter could lead to reading and writing using the wrong path, which could have security issues if used in a secure context. This might be justification for raising the severity of this bug. Looking at the API reference, it looks like extension() and basename() may be intended to be complementary and are for splitting a filename into its main part and extension part, *not* the directory and filename components of a path. This should probably be explicitly spelled out due to the dangerous confusion which may result if used inappropriately. In particular, "." and ".." definitely need special casing--these are not extension separators and basename should return them intact; extension() should return an empty string. I noticed this when converting schroot to use the boost convenience function instead of my own. For reference, this is my version: std::string sbuild::basename (std::string name, char separator = '/') { // Remove trailing separators std::string::size_type cur = name.length(); while (cur > 0 && name[cur - 1] == separator) --cur; name.resize(cur); // Find last separator std::string::size_type pos = name.rfind(separator); std::string ret; if (pos == std::string::npos) ret = name; // No separators else if (pos == 0 && name.length() == 1 && name[0] == separator) ret = separator; // Only separators else ret = name.substr(pos + 1); // Basename only // Remove any duplicate adjacent path separators return remove_duplicates(ret, separator); } A POSIX-compatible dirname() function would nicely complement a POSIX-compatible basename() function as an addition to boost::filesystem. It looks like these are orthogonal to the existing functionality, however. Regards, Roger -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (550, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libboost-filesystem1.40.0 depends on: ii libboost-system1.40.0 1.40.0-5 Operating system (e.g. diagnostics ii libc6 2.10.2-5 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.2-9 GCC support library ii libstdc++6 4.4.2-9 The GNU Standard C++ Library v3 libboost-filesystem1.40.0 recommends no packages. libboost-filesystem1.40.0 suggests no packages. -- no debconf information #include <libgen.h> #include <boost/filesystem/convenience.hpp> #include <cstring> #include <iostream> #include <iomanip> int main () { const char *paths[] = { "test.real", "/usr/bin/perl", "/usr/lib", "/usr/", "usr", "/", ".", "..", 0 }; std::cout << std::setw(16) << std::left << "Path" << std::setw(16) << std::left << "POSIX" << std::setw(16) << std::left << "Boost" << '\n'; for (const char **path = &paths[0]; *path != 0; ++path) { char *bpath = strdup(*path); std::cout << std::setw(16) << std::left << *path << std::setw(16) << std::left << basename(bpath) << std::setw(16) << std::left << boost::filesystem::basename(*path) << '\n'; free(bpath); } return 0; } _______________________________________________ pkg-boost-devel mailing list pkg-boost-devel(a)lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-boost-devel ----- End forwarded message -----

2 1

String literals concatenation issue when using BOOST_CURRENT_FUNCTION
by vicente.botet 16 Jan '10

16 Jan '10

Hi, I want to define a macro as #define BOOST_CHRONO_DIGITAL_TIME_FORMAT(F) "\n" F " tokes %d day(s) %h:%m:%s.%n\n" #define BOOST_CHRONO_DIGITAL_TIME_FUNCTION_FORMAT BOOST_CHRONO_DIGITAL_TIME_FORMAT(BOOST_CURRENT_FUNCTION) I have a compile error with gcc(3.4.4 or 4.4.0) (Boost v1.41) in the following sentence const char* c= "\n" BOOST_CURRENT_FUNCTION " %d day(s) %h:%m:%s.%n\n"; C:\cygwin\boost_1_41_0\libs\chrono\example\digital_time_example.cpp: In function `int f1(long int)': C:\cygwin\boost_1_41_0\libs\chrono\example\digital_time_example.cpp:24: error: expected `;' before "__PRETTY_FUNCTION__" as well as const char* c= "\n" __PRETTY_FUNCTION__ " %d day(s) %h:%m:%s.%n\n"; The same code works as I expected with MSVC. The following code works well with gcc const char* c= "\n" "f" " %d day(s) %h:%m:%s.%n\n"; const char* c2= BOOST_CURRENT_FUNCTION; as well as this one const char* c= "\n" __FILE__" %d day(s) %h:%m:%s.%n\n"; Is there something wrong? Does gcc manage __PRETTY_FUNCTION__ and __FILE__ differently? Does someone knows a workaround? Best, _____________________ Vicente Juan Botet Escribá

2 3

[python] const-correctness and get_signature
by Jim Bosch 16 Jan '10

16 Jan '10

I've been working on an idea to provide optional const-handling in boost.python wrapped classes. It's coming along pretty well, but I've run into one major sticking point: the get_signature functions that extract the argument types of member function pointers into mpl sequences remove any cv-qualification on the hidden 'this' argument. This seems to be intentional - from the comments in python/signature.hpp: // Note that cv-qualification is dropped from // the "hidden this" argument of member functions; that is a // necessary sacrifice to ensure that an lvalue from_python converter // is used. This doesn't actually seem necessary; for a normal wrapped class, the special-case lvalue converter will always be the highest priority, and for a const member function, supporting rvalue converters as a fall-back wouldn't do any harm that I can see (and would help me out considerably). Could this be a relic from before wrapped class lvalue conversions were handled as a special case? Anyhow, if my hypothesis is correct, and there isn't a need to drop the cv-qualifiers in get_signature, I'd like to make a ticket and submit a patch to change it - but I wanted to check here first to see if maybe that breaks something else. Thanks! Jim Bosch

1 0

[release] files from previous releases (was: Re: [ Fusion ] Extra files in "release"?)
by Tobias Schwinger 15 Jan '10

15 Jan '10

Joel de Guzman wrote: > Marshall Clow wrote: >> Hey Joel -- >> >> I noticed that there are a bunch of fusion files that only exist in >> the release branch, and not in the trunk. >> Is that on purpose? > Thanks for reporting! Seems a "release procedure issue" to me; the trunk has apparently been copied over an old release where those files were still present and needed. Those files can be deleted from the release branch (gone from trunk since February 09, last changes on Fusion in June 09). I just read that the release branch is about to freeze so posting to boost.devel for the Release Managers to join in. Also, there might be similar issues for other libraries. >> boost/fusion/functional/adapter/detail/pow2_explode.hpp >> boost/fusion/functional/adapter/detail/pt_def.hpp >> boost/fusion/functional/adapter/detail/pt_undef.hpp >> boost/fusion/functional/adapter/unfused_generic.hpp >> boost/fusion/functional/adapter/unfused_lvalue_args.hpp >> boost/fusion/functional/adapter/unfused_rvalue_args.hpp >> boost/fusion/functional/generation/make_unfused_generic.hpp >> boost/fusion/functional/generation/make_unfused_lvalue_args.hpp >> boost/fusion/functional/generation/make_unfused_rvalue_args.hpp >> >> libs/fusion/doc/html/fusion/functional/adapters/unfused_generic.html >> libs/fusion/doc/html/fusion/functional/adapters/unfused_lvalue_args.html >> libs/fusion/doc/html/fusion/functional/adapters/unfused_rvalue_args.html >> libs/fusion/doc/html/fusion/functional/generation/functions/mk_unfused_genrc.html >> >> libs/fusion/doc/html/fusion/functional/generation/functions/mk_unfused_lvargs.html >> >> libs/fusion/doc/html/fusion/functional/generation/functions/mk_unfused_rvargs.html >> >> libs/fusion/doc/html/fusion/functional/generation/metafunctions/mk_unfused_genrc.html >> >> libs/fusion/doc/html/fusion/functional/generation/metafunctions/mk_unfused_lvargs.html >> >> libs/fusion/doc/html/fusion/functional/generation/metafunctions/mk_unfused_rvargs.html >> >> libs/fusion/test/functional/make_unfused_generic.cpp >> libs/fusion/test/functional/make_unfused_lvalue_args.cpp >> libs/fusion/test/functional/make_unfused_rvalue_args.cpp >> libs/fusion/test/functional/unfused_generic.cpp >> libs/fusion/test/functional/unfused_lvalue_args.cpp >> libs/fusion/test/functional/unfused_rvalue_args.cpp >> Regards, Tobias

6 14

[python] patch modules_init.hpp to expand macros
by Neal Becker 15 Jan '10

15 Jan '10

This patch replaces use of ## and # with BOOST_PP_CAT and BOOST_PP_STRINGIZE. This is needed so that python module names can be programmatically generated. https://svn.boost.org/trac/boost/ticket/3843

1 0