www.digitalmars.com         C & C++   DMDScript  

c++.stlsoft - BC++ 6 basic_file_path_buffer bug

reply "Pablo Aguilar" <paguilarg hotmail.com> writes:
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
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
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 to

 260 (just tested it...) so, what's up with that 5?

Oct 07 2004
parent reply "Pablo Aguilar" <paguilarg hotmail.com> writes:
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
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
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
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"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
parent reply "Pablo Aguilar" <paguilarg hotmail.com> writes:
 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 ... ;)

Have fun!
Oct 07 2004
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Pablo Aguilar" <paguilarg hotmail.com> wrote in message
news:ck4mpu$d0n$1 digitaldaemon.com...
 Heavens only knows why Borland generates the code that it does.

 I should have picked it up in unit-testing though, and not blame



 compiler, however odd it behaves on a regular basis.

Hmm. I did implement that check it in the unittest. Even more odd.


 more investigations necessary ... ;)

Have fun!

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.
Oct 09 2004