Thread overview | |||||||
---|---|---|---|---|---|---|---|
|
August 08, 2005 findfile_sequence bug in 1.8.5 | ||||
---|---|---|---|---|
| ||||
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 |
August 08, 2005 Re: findfile_sequence bug in 1.8.5 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Pablo Aguilar | "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 ...) |
August 09, 2005 Re: findfile_sequence bug in 1.8.5 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Pablo Aguilar Attachments: | "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. |
August 09, 2005 Re: findfile_sequence bug in 1.8.5 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | Great! Thanks... |
August 09, 2005 Re: findfile_sequence bug in 1.8.5 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Pablo Aguilar | "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? ;-) |
Copyright © 1999-2021 by the D Language Foundation