Add SCI_GETTEXTRANGEFULL for 64-bit positions
47 views
Skip to first unread message
Neil Hodgson
May 6, 2022, 11:57:16 PM5/6/22
to Scintilla mailing list
When Scintilla implemented support for documents larger than 2GB, most of its APIs were able to support 64-bit positions. However, some were defined with structs containing fixed width position fields which were not changed. The key Sci_CharacterRange struct uses ‘long’ for positions which is 64-bit on 64-bit Unix systems but 32-bit on 64-bit Win32 systems.
The SCI_GETTEXTRANGE API was thus unable to retrieve text past the 2GB point in huge documents on Windows. This API is sometimes used between running applications for automation and accessibility purposes. This makes it more difficult to change since some applications would be compiled with the new definition and some with the old definition which would cause crashes.
SCI_GETTARGETTEXT could be used instead, but it is stateful requiring a call to set the target range first and its possible for a user or application action to move the target again before SCI_GETTARGETTEXT is called. Even within a single application, the target may be moved unexpectedly by a code change.
Since modifying SCI_GETTEXTRANGE is too likely to cause failures, it will be better to define a new 64-bit safe API and gradually migrate to the new API. A new SCI_GETTEXTRANGEFULL API is proposed along with Sci_CharacterRangeFull and Sci_TextRangeFull structs which use Sci_Position (ptrdiff_t) positions. The “…Full” naming can be replaced with better names if someone invents something clearer - “Full” is meant to imply “Full Range” and “…2” or “…Ex” are less descriptive. SCI_GETTEXTRANGE will be deprecated at some point (likely 6.0) and removed even later (7.0?).
There are another 2 APIs limited to 32-bit on Win32 64-bit: SCI_FINDTEXT and SCI_FORMATRANGE (printing), along with the corresponding structs Sci_TextToFind and Sci_RangeToFormat. These may also be extended in the future but are less commonly used.
The attached patch includes the changes that appear needed. Scintilla.iface uses a new textrangefull parameter type that could cause issues with programs that read it.
Neil
The SCI_GETTEXTRANGE API was thus unable to retrieve text past the 2GB point in huge documents on Windows. This API is sometimes used between running applications for automation and accessibility purposes. This makes it more difficult to change since some applications would be compiled with the new definition and some with the old definition which would cause crashes.
SCI_GETTARGETTEXT could be used instead, but it is stateful requiring a call to set the target range first and its possible for a user or application action to move the target again before SCI_GETTARGETTEXT is called. Even within a single application, the target may be moved unexpectedly by a code change.
Since modifying SCI_GETTEXTRANGE is too likely to cause failures, it will be better to define a new 64-bit safe API and gradually migrate to the new API. A new SCI_GETTEXTRANGEFULL API is proposed along with Sci_CharacterRangeFull and Sci_TextRangeFull structs which use Sci_Position (ptrdiff_t) positions. The “…Full” naming can be replaced with better names if someone invents something clearer - “Full” is meant to imply “Full Range” and “…2” or “…Ex” are less descriptive. SCI_GETTEXTRANGE will be deprecated at some point (likely 6.0) and removed even later (7.0?).
There are another 2 APIs limited to 32-bit on Win32 64-bit: SCI_FINDTEXT and SCI_FORMATRANGE (printing), along with the corresponding structs Sci_TextToFind and Sci_RangeToFormat. These may also be extended in the future but are less commonly used.
The attached patch includes the changes that appear needed. Scintilla.iface uses a new textrangefull parameter type that could cause issues with programs that read it.
Neil
Neil Hodgson
May 17, 2022, 12:13:52 AM5/17/22
to Scintilla mailing list
Committed new 64-bit safe APIs with
https://sourceforge.net/p/scintilla/code/ci/241398a1d33bb7644596826f61639bdff477b32c/ There will probably be a new release in a few days.
Neil
Reply all
Reply to author
Forward
0 new messages