Re: [HarfBuzz] New MSVC compile issue (with current git master)

[John Emmas]

Re-sent (as I wasn't subscribed...)

On 08/11/2018 17:59, John Emmas wrote:

Hi Behdad,

Back in September I flagged up a compilation problem I'd encountered 
when building with MSVC.  At the time, you were a bit confused because 
apparently you use 'bots' of some kind to check the MSVC compilations 
periodically.


I just updated again (from git master) and I've hit a new MSVC 
compilation issue.  It concerns this line in 'src/hb-set.hh' (approx 
line 370):-


memcpy (pages.arrayZ(), other->pages.arrayZ(), count * sizeof 
(pages.arrayZ()[0]));


In today's version it now looks like this:-

memcpy (pages, other->pages, count * sizeof (pages[0]));

MSVC is complaining because it seems to have found 4 x declarations 
for 'pages' and it doesn't know which one to use.  I can delve a bit 
deeper at the weekend when I'll have some more time available - but in 
the meantime, I just wondered if the bots are passing this okay? Regards,


John Emmas


___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz

[HarfBuzz] New MSVC compile issue (with current git master)

[John Emmas]

Hi Behdad,

Back in September I flagged up a compilation problem I'd encountered 
when building with MSVC.  At the time, you were a bit confused because 
apparently you use 'bots' of some kind to check the MSVC compilations 
periodically.


I just updated again (from git master) and I've hit a new MSVC 
compilation issue.  It concerns this line in 'src/hb-set.hh' (approx 
line 370):-


memcpy (pages.arrayZ(), other->pages.arrayZ(), count * sizeof 
(pages.arrayZ()[0]));


In today's version it now looks like this:-

memcpy (pages, other->pages, count * sizeof (pages[0]));

MSVC is complaining because it seems to have found 4 x declarations for 
'pages' and it doesn't know which one to use.  I can delve a bit deeper 
at the weekend when I'll have some more time available - but in the 
meantime, I just wondered if the bots are passing this okay? Regards,


John Emmas
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] pangoft2 link error (was - harfbuzz: Branch 'master')

[John Emmas]

I'm not sure what's changed but after updating from git master today the 
problem seems to have gone !


John

On 10/09/2018 10:44, Behdad Esfahbod wrote:
On Fri, Sep 7, 2018 at 5:22 PM, John Emmas <mailto:j...@creativepost.co.uk>> wrote:


On 07/09/2018 15:24, Behdad Esfahbod wrote:

  src/hb-subset.cc |3 +++
  1 file changed, 3 insertions(+)


Forgive me if this is unrelated - but when building with MSVC,
should I be building harfbuzz as a static library or as a DLL?


Up to you.

Currently I'm building as a static lib and up until a month ago
that always worked fine.  Then yesterday I downloaded again and
tried to build both harfbuzz and pango.  Unfortunately, pangoft2
is failing to link.  I see a lot of errors about symbols being
defined twice - i.e. pangoft2 has them defined when they're
already available in harfbuzz (so the linker doesn't know which
one to use).  The error messages are a bit long-winded but they
all seem to involve 'OT::Lookup::subset'


Don't compile hb-subset.cc.  I don't know how you are compiling.  But 
you shouldn't get duplicates anyway.


Am I right in thinking 'OT::Lookup::subset' Is something that's
been added recently?


It is new.  Not sure what's different about that though.



___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] MSVC compile issue with latest git master

[John Emmas]

On 10/09/2018 10:06, Behdad Esfahbod wrote:

I pushed a fix to master.  Please test.



Thanks Behdad, that seems to have fixed it.

John

On Sat, Sep 8, 2018 at 8:58 AM, John Emmas <mailto:j...@creativepost.co.uk>> wrote:


On 07/09/2018 19:43, Behdad Esfahbod wrote:


The cast is fine if you also add a static_assert (sizeof
(LONG) == sizeof (int), ""); right there.  Please submit a
github Pull Request if that works.




Sorry, I don't understand...

Where am I supposed to add the 'static_assert' line ?

John

___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org <mailto:HarfBuzz@lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/harfbuzz
<https://lists.freedesktop.org/mailman/listinfo/harfbuzz>




--
behdad
http://behdad.org/


___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] MSVC compile issue with latest git master

[John Emmas]

On 07/09/2018 19:43, Behdad Esfahbod wrote:


The cast is fine if you also add a static_assert (sizeof (LONG) ==
sizeof (int), ""); right there.  Please submit a github Pull
Request if that works.




Sorry, I don't understand...

Where am I supposed to add the 'static_assert' line ?

John
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master'

[John Emmas]

On 07/09/2018 15:24, Behdad Esfahbod wrote:

  src/hb-subset.cc |3 +++
  1 file changed, 3 insertions(+)



Forgive me if this is unrelated - but when building with MSVC, should I 
be building harfbuzz as a static library or as a DLL?


Currently I'm building as a static lib and up until a month ago that 
always worked fine.  Then yesterday I downloaded again and tried to 
build both harfbuzz and pango.  Unfortunately, pangoft2 is failing to 
link.  I see a lot of errors about symbols being defined twice - i.e. 
pangoft2 has them defined when they're already available in harfbuzz (so 
the linker doesn't know which one to use).  The error messages are a bit 
long-winded but they all seem to involve 'OT::Lookup::subset'


Am I right in thinking 'OT::Lookup::subset' Is something that's been 
added recently?


John
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] MSVC compile issue with latest git master

[John Emmas]

On 07/09/2018 15:39, Behdad Esfahbod wrote:



Can you check if just removing the cast works?



Hi Behdad,

Unfortunately no -  removing the cast (by itself) doesn't work. However, 
if I remove the cast and then change line 258 to this, it then works:-


  mutable LONG v;

Previously, line 258 was this:-

  mutable int v;

Hope that helps,

John
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz

[HarfBuzz] MSVC compile issue with latest git master

[John Emmas]

Apologies if this comes through twice (yesterday, I accidentally posted 
while being unsubscribed). Here's a link on MSDN which might be helpful...


https://msdn.microsoft.com/en-us/library/191ca0sk.aspx

On 06/09/2018 15:19, John Emmas wrote:
I updated from git today and I've hit a problem when building with 
MSVC...


Trying to compile almost any source file produces the following 
compiler error at lines 255 and 256 of 'hb-atomic.hh':-


   error C2664: 'InterlockedExchangeAdd' : cannot convert parameter 1 
from 'unsigned int *' to 'volatile LONG *'


Here are the relevant lines:-

   inline int inc (void) { return hb_atomic_int_impl_add (, 1); }
   inline int dec (void) { return hb_atomic_int_impl_add (, -1); }

and here's how 'hb_atomic_int_impl_add()' looks (at line 109):-

   #define hb_atomic_int_impl_add(AI, V)    InterlockedExchangeAdd 
((unsigned *) (AI), (V)


If I change the above line to this, the compiler error goes away:-

   #define hb_atomic_int_impl_add(AI, V)    InterlockedExchangeAdd 
((volatile LONG *) (AI), (V)


I'm building with MSVC-8 so could someone check on some other versions 
please with a view to making the change permanent? Thanks.


John




___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz

[HarfBuzz] hb_fallback_shaper stuff

[John Emmas]

I just updated from Harfbuzz git master and tried to build with MSVC.  
When compiling src/hb-fallback-shape.cc it now gives me a lot of errors, 
starting with this at line 31:-


  error C2039: 'fallback' : is not a member of 'hb_shaper_data_t'

And there are other errors relating to 
'_hb_fallback_shaper_face_data_create' / 
'_hb_fallback_shaper_face_data_destroy' / 
'_hb_fallback_shaper_font_data_create' and 
'_hb_fallback_shaper_font_data_destroy' (all of them report "Identifier 
not found").  These ones seem to be due to the 
HB_SHAPER_DATA_ENSURE_DEFINE macros getting defined too early (if I move 
them so that they come after the relevant functions, those particular 
errors disappear).  However, I can't get rid of the errors which tell me 
that "fallback is not a member of 'hb_shaper_data_t".


Everything else still compiles okay AFAICT.

Any ideas..?

John
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] harfbuzz: Branch 'master' - 2 commits

[John Emmas]

Off-topic - but is anything happening about my recent report (regarding 
the introduction of strtof() in hb-common.cc):-


https://lists.freedesktop.org/archives/harfbuzz/2017-February/005885.html

I can fix it locally if this can't get fixed upstream for some reason?

John

On 17/02/2017 03:07, Behdad Esfahbod wrote:

  src/hb-ot-layout-gsubgpos-private.hh|
6 +++---
  src/hb-ot-shape-complex-indic-table.cc  |
7 +++
  test/shaping/fonts/sha1sum/3493e92eaded2661cadde752a39f9d58b11f0326.ttf 
|binary
  test/shaping/fonts/sha1sum/558661aa659912f4d30ecd27bd09835171a8e2b0.ttf 
|binary
  test/shaping/tests/fuzzed.tests |
1 +
  test/shaping/tests/indic-script-extensions.tests|
1 +
  6 files changed, 12 insertions(+), 3 deletions(-)

New commits:
commit 44f7d6ecde9bf7427a05cbe73ed5d668b8a72b2a
Author: jfkthame
Date:   Fri Feb 17 03:03:24 2017 +

 Guard against underflow when adjusting length (#421)
 
 * Guard against underflow when adjusting length
 
 With the fuzz-testcase in mozilla bug 1295299, we end up with a recursed lookup that removes 3 items, when `match_positions[idx]` is 0, which results in (unsigned) `end` wrapping to a huge value.
 
 Making `end` a signed int is probably the simplest route to a fix.
 
 Fixeshttps://bugzilla.mozilla.org/show_bug.cgi?id=1295299.
 
 * Add testcase for #421.


diff --git a/src/hb-ot-layout-gsubgpos-private.hh 
b/src/hb-ot-layout-gsubgpos-private.hh
index b7a0122..0c42352 100644
--- a/src/hb-ot-layout-gsubgpos-private.hh
+++ b/src/hb-ot-layout-gsubgpos-private.hh
@@ -959,7 +959,7 @@ static inline bool apply_lookup (hb_apply_context_t *c,
TRACE_APPLY (NULL);
  
hb_buffer_t *buffer = c->buffer;

-  unsigned int end;
+  int end;
  
/* All positions are distance from beginning of *output* buffer.

 * Adjust. */
@@ -998,8 +998,8 @@ static inline bool apply_lookup (hb_apply_context_t *c,
  
  /* Recursed lookup changed buffer len.  Adjust. */
  
-end = int (end) + delta;

-if (end <= match_positions[idx])
+end += delta;
+if (end <= int (match_positions[idx]))
  {
/* End might end up being smaller than match_positions[idx] if the 
recursed
 * lookup ended up removing many items, more than we have had matched.
diff --git 
a/test/shaping/fonts/sha1sum/558661aa659912f4d30ecd27bd09835171a8e2b0.ttf 
b/test/shaping/fonts/sha1sum/558661aa659912f4d30ecd27bd09835171a8e2b0.ttf
new file mode 100644
index 000..5d72fdf
Binary files /dev/null and 
b/test/shaping/fonts/sha1sum/558661aa659912f4d30ecd27bd09835171a8e2b0.ttf differ
diff --git a/test/shaping/tests/fuzzed.tests b/test/shaping/tests/fuzzed.tests
index 771ac2b..d9bace3 100644
--- a/test/shaping/tests/fuzzed.tests
+++ b/test/shaping/tests/fuzzed.tests
@@ -10,3 +10,4 @@ 
fonts/sha1sum/3511ff5c1647150595846ac414c595cccac34f18.ttf:--font-funcs=ot:U+004
  
fonts/sha1sum/fab39d60d758cb586db5a504f218442cd1395725.ttf:--font-funcs=ot:U+0041,U+0041:[gid0=0+1000|gid0=1+1000]
  
fonts/sha1sum/205edd09bd3d141cc9580f650109556cc28b22cb.ttf:--font-funcs=ot:U+0041:[gid0=0+1000]
  
fonts/sha1sum/217a934cfe15c548b572c203dceb2befdf026462.ttf:--font-funcs=ot:U+0061,U+0061,U+0061:[]
+fonts/sha1sum/558661aa659912f4d30ecd27bd09835171a8e2b0.ttf:--font-funcs=ot:U+FFFD,U+E0100,U+FFFD,U+E0010:[]
commit 45766b673f427bb791c9d5886cadedfac0447066
Author: jfkthame
Date:   Thu Feb 16 17:40:21 2017 +

 [indic] Add support for Grantha marks that may be used in Tamil to th… 
(#401)
 
 * [indic] Add support for Grantha marks that may be used in Tamil to the Indic table.
 
 Seehttps://bugzilla.mozilla.org/show_bug.cgi?id=1331339.
 
 Testcase: U+0BA4,U+0BC6,U+1133c,U+0BAA,U+1133c,U+0BC6,U+1133c
 
 * [indic] Add test for Grantha nukta that is allowed in Tamil by ScriptExtensions.txt


diff --git a/src/hb-ot-shape-complex-indic-table.cc 
b/src/hb-ot-shape-complex-indic-table.cc
index 80a6b25..e10a4d2 100644
--- a/src/hb-ot-shape-complex-indic-table.cc
+++ b/src/hb-ot-shape-complex-indic-table.cc
@@ -422,6 +422,13 @@ hb_indic_get_categories (hb_codepoint_t u)
if (hb_in_range (u, 0xAA60u, 0xAA7Fu)) return indic_table[u - 0xAA60u + 
indic_offset_0xaa60u];
break;
  
+case 0x11u:

+  // According to ScriptExtensions.txt, these Grantha marks may also be 
used in Tamil,
+  // so the Indic shaper needs to know their categories.
+  if (unlikely (u == 0x11303)) return _(Vs,R);
+  if (unlikely (u == 0x1133c)) return _(N,B);
+  break;
+
  default:
break;
}
diff --git 
a/test/shaping/fonts/sha1sum/3493e92eaded2661cadde752a39f9d58b11f0326.ttf 
b/test/shaping/fonts/sha1sum/3493e92eaded2661cadde752a39f9d58b11f0326.ttf
new file mode 100644
index 000..006adb6
Binary files /dev/null and 

Re: [HarfBuzz] Problem with strtof() (in src/hb-common.cc)

[John Emmas]

Just wondering if this came through okay..?

The relevant commit was #b3c0714b4b if that helps (21st Jan 2017)

John


On 02/02/2017 12:03, John Emmas wrote:

Hi guys,

When building from git master this morning (with MSVC) I noticed a 
minor problem in harfbuzz, src/hb-common.cc (at line 670):-


  v = strtof (p, );

For MSVC users, 'strtof()' didn't get introduced until VS2013. Prior 
to that, the nearest that MSVC offered was 'strtod()'. Could we maybe 
change the above line to this..?


  v = (float) strtod (p, );

Best regards,

John Emmas


___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz

[HarfBuzz] Problem with strtof() (in src/hb-common.cc)

[John Emmas]

Hi guys,

When building from git master this morning (with MSVC) I noticed a minor 
problem in harfbuzz, src/hb-common.cc (at line 670):-


  v = strtof (p, );

For MSVC users, 'strtof()' didn't get introduced until VS2013. Prior to 
that, the nearest that MSVC offered was 'strtod()'.  Could we maybe 
change the above line to this..?


  v = (float) strtod (p, );

Best regards,

John Emmas
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Windows build of harfbuzz with nmake

[John Emmas]

On 13/06/2016 13:51, Khaled Hosny wrote:

DirectWrite and Uniscribe backends should be disabled
by default since they are only for testing purposes

[...]

Or may be the issue is that you are using your own build system and just
included all the source files



Hi Khaled,

You're right to an extent.  I did include 'hb-directwrite.cc' in my VC 
sources but it was mostly because of something I read in README.txt:-


  DIRECTWRITE: Enable (experimental) DirectWrite platform shaper 
support,
  requires a rather recent Windows SDK, and 
at least Windows Vista


It looks like I misunderstood that because I took it to mean that 
'hb-directwrite.cc' should be buildable with the more recent Windows 
compilers.  Thanks for the clarification.


John
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Windows build of harfbuzz with nmake

[John Emmas]

On 13/06/2016 10:09, Juha Martikainen wrote:


I had a second build attempt where I made my own vcxproj file. There I 
get the following kind of errors:


1>..\..\src\hb-directwrite.cc(246): error C2039: 'directwrite' : is 
not a member of 'hb_shaper_data_t'
1>..\..\src\hb-directwrite.cc(257): error C3861: 
'hb_directwrite_shaper_face_data_ensure': identifier not found




Hi Juha, I think you accidentally posted off-list.

You're right about the above and it's hugely frustrating.  I build with 
MSVC-8 and I had to comment out the whole of 'hb-directwrite.cc' because 
I couldn't make it compile.  I added a note to say that I hoped it might 
build with some future version of MSVC but from what you're saying, it 
still won't compile.


Once again though...  commenting out the whole of 'hb-directwrite.cc' 
didn't seem to cause any problems.  I think it's a (comparatively) 
recent file so maybe its functionality isn't used very much as yet?  The 
file's author seems to be Ebrahim Byagowi. He needs to be made aware 
that it's unbuildable with MSVC.


John
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Windows build of harfbuzz with nmake

[John Emmas]

On 13/06/2016 08:36, Juha Martikainen wrote:


nmake /f Makefile.vc CFG=release /P

Resulting:
NMAKE : fatal error U1073: don't know how to make 'config.h.win32'
Stop.



Hi Juha,

In addition to what Cosimo said, it might be worthwhile to remember that 
it's not strictly necessary to have config.h for your eventual build.  
Wherever config.h gets #included in Harfbuzz, there's usually a guard, 
like this:-


  #ifdef HAVE_CONFIG_H
  #include "config.h"
  #endif

I build from git (using a VC project, rather than using nmake).  My 
project doesn't define HAVE_CONFIG_H and yet it's never caused any 
problems AFAIK.


John
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Compile issue with MSVC

[John Emmas]

On 22/05/2016 17:08, Behdad Esfahbod wrote:
On Thu, May 19, 2016 at 10:31 PM, John Emmas <john...@tiscali.co.uk 
<mailto:john...@tiscali.co.uk>> wrote:


Could you possibly email me the latest versions of those files and
some instructions for generating them from their respective ".rl"
files?  It looks like I need a utility called "Ragel" which I'm
not familiar with.


Emailed you off-list.



Updating to your new version of 'hb-ot-shape-complex-use-machine.hh' has 
fixed the problem. Thanks Behdad.


John
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Compile issue with MSVC

[John Emmas]

On 20/05/2016 06:31, John Emmas wrote:

After processing the ".rl" files, these files get generated AFAICT:-

  src/hb-ot-shape-complex-indic-machine.hh
  src/hb-ot-shape-complex-myanmar-machine.hh
  src/hb-ot-shape-complex-use-machine.hh
  src/hb-ot-shape-complex-use-machine.cc (interestingly, I don't 
seem to have this one!)


Could you possibly email me the latest versions of those files and 
some instructions for generating them from their respective ".rl" files?




Or maybe just a link to somewhere where I could download the latest 
versions?  Thanks,


John
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Compile issue with MSVC

[John Emmas]

On 19/05/2016 20:00, Behdad Esfahbod wrote:

Hi,

You need to regenerate hb-ot-shape-complex-use-machine.cc from the .rl 
source.




Thanks Behdad,

It looks like I never got around to generating those files (I probably 
just grabbed them from a tarball).  After processing the ".rl" files, 
these files get generated AFAICT:-


  src/hb-ot-shape-complex-indic-machine.hh
  src/hb-ot-shape-complex-myanmar-machine.hh
  src/hb-ot-shape-complex-use-machine.hh
  src/hb-ot-shape-complex-use-machine.cc (interestingly, I don't 
seem to have this one!)


Could you possibly email me the latest versions of those files and some 
instructions for generating them from their respective ".rl" files?  It 
looks like I need a utility called "Ragel" which I'm not familiar with.


I'm not in any rush BTW (my internet access isn't too good at the moment).

John
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz

[HarfBuzz] Compile issue with MSVC

[John Emmas]

I hope this is the right place for developer questions.

I just updated harbuzz from git (having last updated about a fortnight 
ago).  When I try building now with MSVC it gives me the following 
errors when I try to compile 'hb-ot-shape-complex-use.cc'


Compiling... hb-ot-shape-complex-use.cc
hb-ot-shape-complex-use-machine.rl(136) : error C2065: 
'consonant_cluster' : undeclared identifier
hb-ot-shape-complex-use-machine.rl(137) : error C2065: 
'vowel_cluster' : undeclared identifier


I couldn't see anything obviously wrong so I went back to the original 
version 1.2.7 (from 2nd May 2016) and it still builds fine.  
'hb-ot-shape-complex-use.cc' has changed in the past couple of weeks - 
but so have some of the files it depends on (so it's all a bit 
convoluted).  I just wondered if anyone can take a guess at what might 
be wrong?  For example is there something I need to #define now (which 
wasn't needed previously?)


BTW - my internet access will be very poor for the next few days, so 
apologies in advance if I'm a bit slow in responding.  Many thanks,


John Emmas
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Questionable use of DEBUG

[John Emmas]

On 29/04/2013 10:15, John Emmas wrote:


On 27/04/2013 21:37, Behdad Esfahbod wrote:


The debug is fine.  The if gets optimized out by the compiler. That's 
by design.




Hi Behdad.  Can I ask how confident you are about this (for example, 
is there something in the Harfbuzz code to guarantee that there won't 
be a DEBUG macro when we're building our Release code?)





FWIW I took a more detailed look into this and I now have a better 
understanding of what you meant by optimized out.  AFAICT any Harfbuzz 
statements that look something like this:-


if (DEBUG (BUFFER))

will effectively evaluate to this:-

if (0)

so yes, the compiler will (hopefully) optimize them away when building 
optimized code - but actually, that's not what I was worried about.  I 
was worrying about whether your custom DEBUG macro could ever get 
exposed to the outside world.  Let's say that one of the Harfbuzz public 
header files could eventually include that DEBUG macro.  If some 
unsuspecting programmer #included the public header, he could 
unwittingly have DEBUG defined without realizing it.  When interacting 
with other libraries, this could lead to some very subtle bugs which 
could be extremely difficult to track down.


The good news though is that after taking a more detailed look at 
Harfbuzz, I can't find any path where that could happen so (for now at 
least) the outside world is safe and I feel a lot more reassured!  ;-)


I just wanted to record it here, in case I need to remind myself in the 
future!


But if I'd written that macro I think I'd have been tempted to play safe 
and call it something else  ;-)


John
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Questionable use of DEBUG

[John Emmas]

On 30/04/2013 07:41, Konstantin Ritt wrote:

Hi Behdad,

John is probably right, having DEBUG macro defined in release mode 
could potentially lead to a hard-tracking issues. And this possibility 
grows when we're compiling Harfbuzz in instead of linking to it.

Maybe worth of renaming to HB_DEBUG?



Thanks for supporting me on this, Konstantin.

In defence of Harfbuzz I should emphasize that at present, there's 
absolutely no problem with the custom macro.  It gets defined in 
'hb-private.hh' which is never exposed through any of the public header 
files.  However, my fear is that this is the kind of thing which tends 
to get get forgotten over time.  In the future, somebody could take the 
macro out of 'hb-private.hh' and innocuously move it to some other 
header file - where it could end up causing havoc.  I totally agree with 
renaming it to HB_DEBUG.  Otherwise, there's effectively an accident 
waiting to happen.


John
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

Re: [HarfBuzz] Questionable use of DEBUG

[John Emmas]

On 27/04/2013 18:06, John Emmas wrote:

Line 568 of 'hb-private.hh looks like this:-

#define DEBUG(WHAT) (DEBUG_LEVEL (WHAT, 0))

It's making me feel uneasy because DEBUG will be defined, even for a 
Release build.  Is that the intended behaviour?




On 27/04/2013 21:37, Behdad Esfahbod wrote:


The debug is fine.  The if gets optimized out by the compiler.  That's 
by design.




Hi Behdad.  Can I ask how confident you are about this (for example, is 
there something in the Harfbuzz code to guarantee that there won't be a 
DEBUG macro when we're building our Release code?)  I discussed this 
with some colleagues this morning but the consensus was that a compiler 
itself can't be relied upon to optimize away the DEBUG macro.  But if 
Harfbuzz is written to take care of it, that should be fine.  Thanks.


John
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

[HarfBuzz] Missing header files

[John Emmas]

Hi Behdad, I hope you can help with a small build problem

I need to build Harfbuzz using MSVC.  Previously I'd already built it as 
part of pango - but since it got separated from pango, Harfbuzz seems to 
have grown quite a bit.  I've still got my original MSVC project so, in 
theory, to build the main Harfbuzz library should only be a matter of 
adding all those extra new source files and configuring any new #defines 
(such as HAVE_OT, which I only discovered yesterday).


Anyway, the build seems to be progressing well, except that there are 
some header files missing - specifically:-


hb-ot-shape-complex-indic-machine.hh
hb-ot-shape-complex-myanmar-machine.hh
hb-ot-shape-complex-sea-machine.hh

Instead, I seem to have 3 x files with similar names but with the 
extension .rl:-


hb-ot-shape-complex-indic-machine.rl
hb-ot-shape-complex-myanmar-machine.rl
hb-ot-shape-complex-sea-machine.rl

I assume these are some kind of input files from which the corresponding 
header files can be generated?  What needs to be done to the .rl files 
so that I can arrive at the .hh files?  It looks like it might just be 
a matter of text substitution perhaps.


John
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz

[HarfBuzz] Questionable use of DEBUG

[John Emmas]

Line 568 of 'hb-private.hh looks like this:-

#define DEBUG(WHAT) (DEBUG_LEVEL (WHAT, 0))

It's making me feel uneasy because DEBUG will be defined, even for a 
Release build.  Is that the intended behaviour?


John
___
HarfBuzz mailing list
HarfBuzz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/harfbuzz