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?

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
be
> 260 (just tested it...) so, what's up with that 5?
>
>

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?

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

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

>> 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!

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

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.