www.digitalmars.com         C & C++   DMDScript  

c++.stlsoft - findfile_sequence bug in 1.8.5

reply Pablo Aguilar <pablo.dot.aguilar gmail.dot.com> writes:
It seems the following constructor overload:

basic_findfile_sequence(   char_type const *directory
                        ,   char_type const *pattern
                        ,   ws_int_t        flags
                        )

Has problems when the directory argument is empty.

It does this:

	traits_type::get_full_path_name(directory
                                        , m_directory.size()
                                        , &m_directory[0]
                                        );

Which fails if directory is empty, and leaves m_directory uninitialized. 
Later, in const_iterator's operator++, there's

traits_type::str_copy(&search[0]
                      , stlsoft_ns_qual(c_str_ptr)(m_list->m_directory)
                      );
traits_type::ensure_dir_end(&search[0]);
traits_type::str_n_cat(&search[0], m_pattern0, m_pattern1 - m_pattern0);

Which concatenates at the end of uninitialized data, and since there's 
no guarantee that there's a NULL somewhere, well, you get an Access 
Violation...

So... either I believe that this should, either work using a sensible 
default for the directory (maybe ".", but then I could write that myself 
if that's what I wanted, so...), assert on an empty argument, or, at the 
very least, initialize m_directory properly (to empty) so that Windows 
will handle the empty directory situation.

I know my code shouldn't be sending an empty directory as an argument, 
and I'll check that out, but still I think the library needs some 
tweaking in this department...


Pablo
Aug 08 2005
next sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Pablo Aguilar" <pablo.dot.aguilar gmail.dot.com> wrote in message
news:dd8bjk$4qs$1 digitaldaemon.com...
 It seems the following constructor overload:

 basic_findfile_sequence(   char_type const *directory
                        ,   char_type const *pattern
                        ,   ws_int_t        flags
                        )

 Has problems when the directory argument is empty.

 It does this:

 traits_type::get_full_path_name(directory
                                        , m_directory.size()
                                        , &m_directory[0]
                                        );

 Which fails if directory is empty, and leaves m_directory uninitialized.
Later, in const_iterator's operator++, 
 there's

 traits_type::str_copy(&search[0]
                      , stlsoft_ns_qual(c_str_ptr)(m_list->m_directory)
                      );
 traits_type::ensure_dir_end(&search[0]);
 traits_type::str_n_cat(&search[0], m_pattern0, m_pattern1 - m_pattern0);

 Which concatenates at the end of uninitialized data, and since there's no
guarantee that there's a NULL somewhere, 
 well, you get an Access Violation...

 So... either I believe that this should, either work using a sensible default
for the directory (maybe ".", but then I 
 could write that myself if that's what I wanted, so...), assert on an empty
argument, or, at the very least, 
 initialize m_directory properly (to empty) so that Windows will handle the
empty directory situation.

 I know my code shouldn't be sending an empty directory as an argument, and
I'll check that out, but still I think the 
 library needs some tweaking in this department...

No argument. Bugger! (1.8.6 coming up ...)
Aug 08 2005
prev sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Pablo Aguilar" <pablo.dot.aguilar gmail.dot.com> wrote in message 
news:dd8bjk$4qs$1 digitaldaemon.com...
 It seems the following constructor overload:

 basic_findfile_sequence(   char_type const *directory
                        ,   char_type const *pattern
                        ,   ws_int_t        flags
                        )

 Has problems when the directory argument is empty.

 It does this:

 traits_type::get_full_path_name(directory
                                        , m_directory.size()
                                        , &m_directory[0]
                                        );

 Which fails if directory is empty, and leaves m_directory 
 uninitialized.
 Later, in const_iterator's operator++, there's

 traits_type::str_copy(&search[0]
                      , 
 stlsoft_ns_qual(c_str_ptr)(m_list->m_directory)
                      );
 traits_type::ensure_dir_end(&search[0]);
 traits_type::str_n_cat(&search[0], m_pattern0, m_pattern1 - 
 m_pattern0);

 Which concatenates at the end of uninitialized data, and since 
 there's
 no guarantee that there's a NULL somewhere, well, you get an 
 Access
 Violation...

Fixed. I'll be releasing an update in a few days, but this should do for now.
 So... either I believe that this should, either work using a 
 sensible
 default for the directory (maybe ".", but then I could write that 
 myself
 if that's what I wanted, so...), assert on an empty argument, or, 
 at the
 very least, initialize m_directory properly (to empty) so that 
 Windows
 will handle the empty directory situation.

It intercepts (NULL == directory || '\0' == *directory), and repoints directory to ".";
 I know my code shouldn't be sending an empty directory as an 
 argument,
 and I'll check that out, but still I think the library needs some
 tweaking in this department...

Absolutely. There's no excuse for it bumming out on that parameter. I'm adding a case to the unit test for ffs.
Aug 08 2005
parent reply Pablo Aguilar <pablo.dot.aguilar gmail.dot.com> writes:
Great! Thanks...
Aug 09 2005
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Pablo Aguilar" <pablo.dot.aguilar gmail.dot.com> wrote in message 
news:dd9r2v$1p19$1 digitaldaemon.com...
 Great! Thanks...

nw. You tried the MFC adaptors yet? ;-)
Aug 09 2005