-
Notifications
You must be signed in to change notification settings - Fork 53
[x64 fix]: Scintilla structures required correction for x64 #75
Conversation
mahee96
commented
May 26, 2021
- ScNotification struct had incorrect data type 'int' for lineNumber, position, etc fields
- This might cause misinterpretation of data block eventually leading to corruption.
- IntPtr must have been used.
- Scintilla interface method signatures were incorrectly using int.
- This would cause truncation of data in x64 environment and possible data corruption.
- Enums in GatewayDomain.cs required [Flags] attribute to combine using OR.
- ScNotification struct had incorrect data type 'int' for lineNumber, position, etc fields - This might cause misinterpretation of data block eventually leading to corruption. - Scintilla interface method signatures were incorrectly using int. - This would cause truncation of data in x64 environment and possible data corruption. - Enums in GatewayDomain.cs required [Flags] attribute to combine using OR.
@@ -50,6 +50,10 @@ def ReadFromFile(self, name): | |||
currentCategory = "" | |||
currentComment = [] | |||
currentCommentFinished = 0 | |||
import os, os.path, inspect | |||
if '__file__' not in locals(): | |||
__file__ = inspect.getframeinfo(inspect.currentframe())[0] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
set cwd to script path for traversing relative file paths correctly such as ../../ etc
if t == "cells": return "Cells" | ||
if t == "colour": return "Colour" | ||
if t == "line": return "int" | ||
if t == "line": return "long" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
line and position types need to be atleast 64-bit wide which can accommodate both 32-bit data in x86 execution and 64-bit data in x64 execution.
Hence long is used instead of int.
IntPtr could have been used as suggested, but that complicates things with arithmetic operations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this the correct assumption if you build a 32bit and a64 bit version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you are right, there is a potential issue for set operations, if we allow the long to be used and user supplies a long value but the execution env is x86. This might result in overflow/truncation.
I was just focusing on get operation where the system returned type can fit on the target container for both x86 and x64.
So we are again left with only option of using IntPtr to make it work for both environment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have suggested alternative fix for this: see my reply below
@@ -100,6 +100,7 @@ def printEnumDefinitions(f): | |||
if v["FeatureType"] in ["enu"] and name not in ["Keys"]: # for all except excluded enums [conflicting] | |||
appendComment(indent, out, v) | |||
prefix = v["Value"] | |||
out.append(indent + "[Flags]") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Enums now have the [Flags] Attribute which makes them combinable with other constants of same enum type.
/// <summary>Is undo history being collected? (Scintilla feature SCWS_)</summary> | ||
[Flags] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[Flags] attribute inclusion for enum types
@@ -34,40 +34,40 @@ public interface IScintillaGateway | |||
|
|||
/* ++Autogenerated -- start of section automatically generated from Scintilla.iface */ | |||
/// <summary>Add text to the document at current position. (Scintilla feature 2001)</summary> | |||
unsafe void AddText(int length, string text); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
'long'(64-bits wider) type is much flexible than 'int'/'intPtr'(32 bits/64 bits speculative) in x86/x64.
Keeps the interface clean without requiring much changes due to change in data type.
@@ -47,7 +47,7 @@ public void InsertTextAndMoveCursor(string text) | |||
|
|||
public void SelectCurrentLine() | |||
{ | |||
int line = GetCurrentLineNumber(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same: using 'long' instead of 'int' for param and return types.
@@ -38,31 +38,32 @@ public struct ScNotificationHeader | |||
public struct ScNotification | |||
{ | |||
public ScNotificationHeader Header; | |||
private int position; /* SCN_STYLENEEDED, SCN_DOUBLECLICK, SCN_MODIFIED, SCN_MARGINCLICK, SCN_NEEDSHOWN, SCN_DWELLSTART, SCN_DWELLEND, SCN_CALLTIPCLICK, SCN_HOTSPOTCLICK, SCN_HOTSPOTDOUBLECLICK, SCN_HOTSPOTRELEASECLICK, SCN_INDICATORCLICK, SCN_INDICATORRELEASE, SCN_USERLISTSELECTION, SCN_AUTOCSELECTION */ | |||
private IntPtr position; /* SCN_STYLENEEDED, SCN_DOUBLECLICK, SCN_MODIFIED, SCN_MARGINCLICK, SCN_NEEDSHOWN, SCN_DWELLSTART, SCN_DWELLEND, SCN_CALLTIPCLICK, SCN_HOTSPOTCLICK, SCN_HOTSPOTDOUBLECLICK, SCN_HOTSPOTRELEASECLICK, SCN_INDICATORCLICK, SCN_INDICATORRELEASE, SCN_USERLISTSELECTION, SCN_AUTOCSELECTION */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ScNotification struct alignment and data type size issues fixes
@kbilsted Here is an attempt to resolve this issue using wrapper classes:
Changes to be made in source files to accommodate this:
After:
Caveats:
Advantages:
Other methods:
But our goal here should be that we should not often change the interface signature, so in that case I would vote for the wrapper classes method, which allows us(the maintainers) to make changes in the wrapper classes as required without changes to the interface signatures and wrapper class name itself. |
@kbilsted, Found another code where scintilla.iface content has been generated for cpp as ScintillaEdit.h:
Note the sptr_t which is ptrdiff_t or _int/_int64 based on platform type, equivalent would be IntPtr |
Closing this PR since making x86 and x64 code co-exist is non-trivial. Will deal with it in separate PR |