This fixes some heap corruption observed in ReactOS
Signed-off-by: Fabian Maurer dark.shadow4@web.de
From: Fabian Maurer dark.shadow4@web.de
This fixes some heap corruption observed in ReactOS
Signed-off-by: Fabian Maurer dark.shadow4@web.de --- dlls/gdi32/uniscribe/shape.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dlls/gdi32/uniscribe/shape.c b/dlls/gdi32/uniscribe/shape.c index 912d3e6965b..77225537fac 100644 --- a/dlls/gdi32/uniscribe/shape.c +++ b/dlls/gdi32/uniscribe/shape.c @@ -3159,7 +3159,7 @@ static void ShapeCharGlyphProp_Thai( HDC hdc, ScriptCache *psc, SCRIPT_ANALYSIS /* Do not allow justification between marks and their base */ for (i = 0; i < cGlyphs; i++) { - if (!pGlyphProp[i].sva.fClusterStart) + if (!pGlyphProp[i].sva.fClusterStart && (i-dirL) >= 0) pGlyphProp[i-dirL].sva.uJustification = SCRIPT_JUSTIFY_NONE; } }
Hi,
It looks like your patch introduced the new failures shown below. Please investigate and fix them before resubmitting your patch. If they are not new, fixing them anyway would help a lot. Otherwise please ask for the known failures list to be updated.
The tests also ran into some preexisting test failures. If you know how to fix them that would be helpful. See the TestBot job for the details:
The full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=124965
Your paranoid android.
=== debian11 (32 bit report) ===
quartz: filtergraph.c:524: Test marked flaky: didn't get EOS filtergraph.c:529: Test marked flaky: expected 1243c8, got 0
=== debian11 (build log) ===
Use of uninitialized value $Flaky in addition (+) at /home/testbot/lib/WineTestBot/LogUtils.pm line 720, <$LogFile> line 24728. Use of uninitialized value $Flaky in addition (+) at /home/testbot/lib/WineTestBot/LogUtils.pm line 720, <$LogFile> line 24728. Use of uninitialized value $Flaky in addition (+) at /home/testbot/lib/WineTestBot/LogUtils.pm line 720, <$LogFile> line 24728.
Nikolay Sivov (@nsivov) commented about dlls/gdi32/uniscribe/shape.c:
/* Do not allow justification between marks and their base */ for (i = 0; i < cGlyphs; i++) {
if (!pGlyphProp[i].sva.fClusterStart)
if (!pGlyphProp[i].sva.fClusterStart && (i-dirL) >= 0) pGlyphProp[i-dirL].sva.uJustification = SCRIPT_JUSTIFY_NONE;
I think it's more concerning that pGlyphProp[i].sva.fClusterStart is 0 for i == 0, assuming that's a case this is meant to catch.
On Thu Oct 13 17:13:56 2022 +0000, Nikolay Sivov wrote:
I think it's more concerning that pGlyphProp[i].sva.fClusterStart is 0 for i == 0, assuming that's a case this is meant to catch.
Sorry, I don't think I understand what you mean. Wasn't that part of the original code?
On Thu Oct 13 17:23:57 2022 +0000, Fabian Maurer wrote:
Sorry, I don't think I understand what you mean. Wasn't that part of the original code?
What I mean is that (i-dirL) is negative only when i == 0 and dirL == 1, which would matter only if pGlyphProp[0].sva.fClusterStart == 0, which I think is strange. So if you're really getting -1 index there, it's better to check why fClusterStart is 0 for a first glyph.
On Thu Oct 13 17:32:06 2022 +0000, Nikolay Sivov wrote:
What I mean is that (i-dirL) is negative only when i == 0 and dirL == 1, which would matter only if pGlyphProp[0].sva.fClusterStart == 0, which I think is strange. So if you're really getting -1 index there, it's better to check why fClusterStart is 0 for a first glyph.
Ah, I understand. Good point, I'll look into that!
On Thu Oct 13 17:45:39 2022 +0000, Fabian Maurer wrote:
Ah, I understand. Good point, I'll look into that!
It happens because in `OpenType_GDEF_UpdateGlyphProps` we go into `case MarkGlyph`, which sets fClusterStart to 0. Guess that is not tested against single characters. How do we continue here?
On Fri Oct 14 16:57:30 2022 +0000, Fabian Maurer wrote:
It happens because in `OpenType_GDEF_UpdateGlyphProps` we go into `case MarkGlyph`, which sets fClusterStart to 0. Guess that is not tested against single characters. How do we continue here?
I'd continue by testing shaping with this font and this text on Windows, to see how properties are set.
On Fri Oct 14 17:29:08 2022 +0000, Nikolay Sivov wrote:
I'd continue by testing shaping with this font and this text on Windows, to see how properties are set.
What exactly would I test for that? I know basically nothing about font shaping..
On Fri Oct 14 19:03:48 2022 +0000, Fabian Maurer wrote:
What exactly would I test for that? I know basically nothing about font shaping..
You'll need to know which font triggers this. Then you'll use same font and same text, pass them to ScriptShape(), and see what comes out for glyph properties, and fClusterStart in particular.
On Fri Oct 14 19:08:02 2022 +0000, Nikolay Sivov wrote:
You'll need to know which font triggers this. Then you'll use same font and same text, pass them to ScriptShape(), and see what comes out for glyph properties, and fClusterStart in particular.
The font is not part of your normal Wine/Linux install though, how to we handle this? Ship the font (license allows it), find another affected font or something different?
On Fri Oct 14 19:24:33 2022 +0000, Fabian Maurer wrote:
The font is not part of your normal Wine/Linux install though, how to we handle this? Ship the font (license allows it), find another affected font or something different?
No need to bundle anything, I'm only asking to test on Windows and see if we can fix properties accordingly. Bundling some minimal fonts that test corner case would be ideal, but we don't do that, and I don't expect you to .
-
Fabian Maurer -
Fabian Maurer (＠DarkShadow44)
-
Marvin -
Nikolay Sivov (＠nsivov)