Use safe length measure function and fix length usage.

* We may get non-terminated strings so we need to use the
UTF8NextCharLen() version that works with a length. Previously we may
have read beyond buffers, possibly leading to crashes.
* Also the length parameter is used as an actual length and not as
buffer size. The length check was wrong before, which resulted in the
function returning too early if an offset was supplied.
* Added a comment about the guaranteed 0 termination in one case.
* Minor cleanup.

Fix passing non-terminated string to font functions.

The string that is built for hashing the escapements for missing
chars was not 0 terminated, leading to accesses past the string.
Depending on what followed an allocation that could lead to too long
strings being sent to the app_server for evaluation (where, due to
defensive, programming nothing bad would actually happen). In the
unfortunate case that nothing followed the allocation (i.e. end of
heap area), it could also lead to an application crash.

Therefore ensure 0 termination of the string, check for allocation
failure and use memcpy() instead of a for loop to copy the bytes from
one string to the other.

Closing #2334:
* fix incorrect implicit type extension in WidthBuffer::CharToCode() that led
to some values not being represented correctly (depending on input chars)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38034 a95241bf-73f2-0310-859d-f6bbb57e9c96

* cleanup and style fixes in WidthBuffer

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38033 a95241bf-73f2-0310-859d-f6bbb57e9c96

Use the Bfont object to discriminate between fonts (as in Dano)
and not just size and code. Style cleanups.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37369 a95241bf-73f2-0310-859d-f6bbb57e9c96

* The WidthBuffer lock was unnecessarily static. Made it an object member.
* Automatic whitespace cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34367 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Moved the global BPrivate::WidthBuffer from BTextView into BPrivate as
gWidthBuffer.
* Tracker PoseView now uses BPrivate::gWidthBuffer instead of it's own
instance.
* TextView.h and PoseView.h are now a little cleaner.
* InterfaceDefs.cpp now deletes gWidthBuffer in _fini_interface_kit_().
* Added binary compatibility support for NetPositive in WidthBuffer.h and .cpp.
Obviously it kind of defeats the purpose of having WidthBuffer neatly tucked
away in the BPrivate namespace, but Haiku should run NetPositive, I guess.
Fixes #2879.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28532 a95241bf-73f2-0310-859d-f6bbb57e9c96

Move WidthBuffer and TextGapBuffer into BPrivate and use them from there in BPoseView and BTextView. This (correctly) fixes the previous gcc4 build issues.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27675 a95241bf-73f2-0310-859d-f6bbb57e9c96

Quite a cleanup action to avoid polluting the global namespace with private
BTextView classes:

* Declared the directly used BTextView helper classes as private BTextView
classes and changed all affected files.
* Realized that Tracker's BPoseView was (accidentally?) using what used to
be _BWidthBuffer_. It had declared it's own class with the same name and
same members/size in headers/private/tracker/TextViewSupport.h, but the
implementation was nowhere to be found. I can only explain this that
the BTextView implementation was then actually linked and used. But the big
problem was that it was used without locking (unlike in BTextView)! When
many Tracker windows opened during system startup or later and they happened
to each request characters not yet in the cache, I imagine things could have
gone bad and corrupted memory. Anyways, since I can see the usefulness of
the cache, BPoseView uses BTextView::WidthBuffer on purpose now. And I moved
the locking inside BTextView::WidthBuffer::StringWidth().
* Adjusted InterfaceDefs.cpp accordingly.
* TODO: Move subsequent classes into BTextView namespace as well, ie derived
classes that BTextView doesn't directly know about. All stuff in src/kits/
inteface/textview_support/
* Added preliminary and not yet implemented layout friendly BTextView
constructors.
* I will try to handle the insets imposed by BTextView::fTextRect a bit
differently when used inside the new layout management framework. For this,
I added BTextView::SetInsets() and GetInsets(). SetInsets() doesn't do
anything yet.

So far, everything seems to work still... ;-)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27654 a95241bf-73f2-0310-859d-f6bbb57e9c96

and there, the usual forgotten debug stuff...\n

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24097 a95241bf-73f2-0310-859d-f6bbb57e9c96

Turns out #1804 was fixed, but I broke it again with a "cleanup" commit. Fixed for real.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24096 a95241bf-73f2-0310-859d-f6bbb57e9c96

In the last commit I introduced a bug: charCount wasn't incremented
correctly in some cases inside HashEscapements(). Also, when looking for
a value in the hash, we checked the same position twice in some
cases (did not cause any problem, was just a bit slower).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24079 a95241bf-73f2-0310-859d-f6bbb57e9c96

removed debug leftover

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24072 a95241bf-73f2-0310-859d-f6bbb57e9c96

such a long debugging session for such a silly error: the new hashed_escapements struct was never put into the width table when we grew the hash. The BWidthBufferTest now works. Simplified a bit the code.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24071 a95241bf-73f2-0310-859d-f6bbb57e9c96

this should complete the work on password mode for BTextView:
* fixed +/- 1 bug in _BTextGapBuffer_::GetString()
* used the correct text and offsets in BTextView whenever the visible
text is to be used
* when copying to the clipboard, copy the bullets
* when dragging the text, drag the bullets
TODO:
* test more with UTF8 chars in the original text (I am unsure if fSelStart
and so on is really in bytes rather than glyphs)
* test with multiple font styles



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22787 a95241bf-73f2-0310-859d-f6bbb57e9c96

Renamed BTextView folder to textview_support


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18663 a95241bf-73f2-0310-859d-f6bbb57e9c96

Use safe length measure function and fix length usage.

* We may get non-terminated strings so we need to use the
UTF8NextCharLen() version that works with a length. Previously we may
have read beyond buffers, possibly leading to crashes.
* Also the length parameter is used as an actual length and not as
buffer size. The length check was wrong before, which resulted in the
function returning too early if an offset was supplied.
* Added a comment about the guaranteed 0 termination in one case.
* Minor cleanup.

Fix passing non-terminated string to font functions.

The string that is built for hashing the escapements for missing
chars was not 0 terminated, leading to accesses past the string.
Depending on what followed an allocation that could lead to too long
strings being sent to the app_server for evaluation (where, due to
defensive, programming nothing bad would actually happen). In the
unfortunate case that nothing followed the allocation (i.e. end of
heap area), it could also lead to an application crash.

Therefore ensure 0 termination of the string, check for allocation
failure and use memcpy() instead of a for loop to copy the bytes from
one string to the other.

Closing #2334:
* fix incorrect implicit type extension in WidthBuffer::CharToCode() that led
to some values not being represented correctly (depending on input chars)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38034 a95241bf-73f2-0310-859d-f6bbb57e9c96

* cleanup and style fixes in WidthBuffer

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38033 a95241bf-73f2-0310-859d-f6bbb57e9c96

Use the Bfont object to discriminate between fonts (as in Dano)
and not just size and code. Style cleanups.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37369 a95241bf-73f2-0310-859d-f6bbb57e9c96

* The WidthBuffer lock was unnecessarily static. Made it an object member.
* Automatic whitespace cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34367 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Moved the global BPrivate::WidthBuffer from BTextView into BPrivate as
gWidthBuffer.
* Tracker PoseView now uses BPrivate::gWidthBuffer instead of it's own
instance.
* TextView.h and PoseView.h are now a little cleaner.
* InterfaceDefs.cpp now deletes gWidthBuffer in _fini_interface_kit_().
* Added binary compatibility support for NetPositive in WidthBuffer.h and .cpp.
Obviously it kind of defeats the purpose of having WidthBuffer neatly tucked
away in the BPrivate namespace, but Haiku should run NetPositive, I guess.
Fixes #2879.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28532 a95241bf-73f2-0310-859d-f6bbb57e9c96

Move WidthBuffer and TextGapBuffer into BPrivate and use them from there in BPoseView and BTextView. This (correctly) fixes the previous gcc4 build issues.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27675 a95241bf-73f2-0310-859d-f6bbb57e9c96

Quite a cleanup action to avoid polluting the global namespace with private
BTextView classes:

* Declared the directly used BTextView helper classes as private BTextView
classes and changed all affected files.
* Realized that Tracker's BPoseView was (accidentally?) using what used to
be _BWidthBuffer_. It had declared it's own class with the same name and
same members/size in headers/private/tracker/TextViewSupport.h, but the
implementation was nowhere to be found. I can only explain this that
the BTextView implementation was then actually linked and used. But the big
problem was that it was used without locking (unlike in BTextView)! When
many Tracker windows opened during system startup or later and they happened
to each request characters not yet in the cache, I imagine things could have
gone bad and corrupted memory. Anyways, since I can see the usefulness of
the cache, BPoseView uses BTextView::WidthBuffer on purpose now. And I moved
the locking inside BTextView::WidthBuffer::StringWidth().
* Adjusted InterfaceDefs.cpp accordingly.
* TODO: Move subsequent classes into BTextView namespace as well, ie derived
classes that BTextView doesn't directly know about. All stuff in src/kits/
inteface/textview_support/
* Added preliminary and not yet implemented layout friendly BTextView
constructors.
* I will try to handle the insets imposed by BTextView::fTextRect a bit
differently when used inside the new layout management framework. For this,
I added BTextView::SetInsets() and GetInsets(). SetInsets() doesn't do
anything yet.

So far, everything seems to work still... ;-)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27654 a95241bf-73f2-0310-859d-f6bbb57e9c96

and there, the usual forgotten debug stuff...\n

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24097 a95241bf-73f2-0310-859d-f6bbb57e9c96

Turns out #1804 was fixed, but I broke it again with a "cleanup" commit. Fixed for real.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24096 a95241bf-73f2-0310-859d-f6bbb57e9c96

In the last commit I introduced a bug: charCount wasn't incremented
correctly in some cases inside HashEscapements(). Also, when looking for
a value in the hash, we checked the same position twice in some
cases (did not cause any problem, was just a bit slower).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24079 a95241bf-73f2-0310-859d-f6bbb57e9c96

removed debug leftover

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24072 a95241bf-73f2-0310-859d-f6bbb57e9c96

such a long debugging session for such a silly error: the new hashed_escapements struct was never put into the width table when we grew the hash. The BWidthBufferTest now works. Simplified a bit the code.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24071 a95241bf-73f2-0310-859d-f6bbb57e9c96

this should complete the work on password mode for BTextView:
* fixed +/- 1 bug in _BTextGapBuffer_::GetString()
* used the correct text and offsets in BTextView whenever the visible
text is to be used
* when copying to the clipboard, copy the bullets
* when dragging the text, drag the bullets
TODO:
* test more with UTF8 chars in the original text (I am unsure if fSelStart
and so on is really in bytes rather than glyphs)
* test with multiple font styles



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22787 a95241bf-73f2-0310-859d-f6bbb57e9c96

Renamed BTextView folder to textview_support


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18663 a95241bf-73f2-0310-859d-f6bbb57e9c96