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

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

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

Great! Thanks...

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

;-)