• Pablo Aguilar <pablo.dot.aguilar gmail.dot.com> Aug 08 2005
• "Matthew" <admin.hat stlsoft.dot.org> Aug 08 2005
• "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Aug 08 2005
• Pablo Aguilar <pablo.dot.aguilar gmail.dot.com> Aug 09 2005
• "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Aug 09 2005

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

"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 ...)

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

Pablo Aguilar <pablo.dot.aguilar gmail.dot.com> writes:

Great! Thanks...

"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?

;-)