c++.stlsoft - BC++ 6 basic_file_path_buffer bug
- Pablo Aguilar (6/6) Oct 06 2004 I'm trying to use basic_file_path_buffer (winstl), but when using a
- Matthew (5/11) Oct 07 2004 Which compiler? Which OS? Any other info? Can you email me the test prg
- Pablo Aguilar (3/5) Oct 07 2004 I e-mailed you about it
- Matthew (4/9) Oct 07 2004 Worked around. I'll post a patch tonight.
- Matthew (2/15) Oct 07 2004
- Pablo Aguilar (1/6) Oct 07 2004 Have fun!
- Matthew (11/19) Oct 09 2004 some
I'm trying to use basic_file_path_buffer (winstl), but when using a variable's size method, it returns 5. I traced into the CPU view, and noticed that the constructor's passing 5 both when Win9x or WinNT are detected... I can't figure out where that 5 is coming from. _MAX_PATH's defined to be 260 (just tested it...) so, what's up with that 5?
Oct 06 2004
Which compiler? Which OS? Any other info? Can you email me the test prg src? "Pablo Aguilar" <paguilarg hotmail.com> wrote in message news:ck1q7e$961$1 digitaldaemon.com...I'm trying to use basic_file_path_buffer (winstl), but when using a variable's size method, it returns 5. I traced into the CPU view, and noticed that the constructor's passing 5 both when Win9x or WinNT are detected... I can't figure out where that 5 is coming from. _MAX_PATH's defined tobe260 (just tested it...) so, what's up with that 5?
Oct 07 2004
I e-mailed you about it "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:ck2ri8$uhk$1 digitaldaemon.com...Which compiler? Which OS? Any other info? Can you email me the test prg src?
Oct 07 2004
Worked around. I'll post a patch tonight. Heavens only knows why Borland generates the code that it does. I should have picked it up in unit-testing though, and not blame some compiler, however odd it behaves on a regular basis. "Pablo Aguilar" <paguilarg hotmail.com> wrote in message news:ck44kg$269i$1 digitaldaemon.com...I e-mailed you about it "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:ck2ri8$uhk$1 digitaldaemon.com...Which compiler? Which OS? Any other info? Can you email me the test prg src?
Oct 07 2004
"Matthew" <admin.hat stlsoft.dot.org> wrote in message news:ck4j4i$2vrd$1 digitaldaemon.com...Worked around. I'll post a patch tonight. Heavens only knows why Borland generates the code that it does.I should have picked it up in unit-testing though, and not blame some compiler, however odd it behaves on a regular basis.Hmm. I did implement that check it in the unittest. Even more odd. Even more investigations necessary ... ;)"Pablo Aguilar" <paguilarg hotmail.com> wrote in message news:ck44kg$269i$1 digitaldaemon.com...I e-mailed you about it "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:ck2ri8$uhk$1 digitaldaemon.com...Which compiler? Which OS? Any other info? Can you email me the test prg src?
Oct 07 2004
Have fun!Heavens only knows why Borland generates the code that it does.I should have picked it up in unit-testing though, and not blame some compiler, however odd it behaves on a regular basis.Hmm. I did implement that check it in the unittest. Even more odd. Even more investigations necessary ... ;)
Oct 07 2004
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> "Pablo Aguilar" <paguilarg hotmail.com> wrote in message news:ck4mpu$d0n$1 digitaldaemon.com...someHeavens only knows why Borland generates the code that it does.I should have picked it up in unit-testing though, and not blameEvencompiler, however odd it behaves on a regular basis.Hmm. I did implement that check it in the unittest. Even more odd.There was none to be had. Borland generates the correct code in the unit-test (which has no obviously different code context to your test program), but does not in your test code. Sigh! Well, we have a workaround that works, and is entirely benign (in terms of portability and efficiency), so I guess we'll just live with it. 1.8.2 coming soon.more investigations necessary ... ;)Have fun!
Oct 09 2004