unbalanced #endif's

[Begasus]

When trying to build htmltidy on Haiku for gcc2 (v2.95.) I'm getting some unbalanced #endif's for the language_ header files, for gcc5* it's ok, any way to fix these?
PS, this is for latest version 5.6.0

[Begasus]

haikuports/haikuports#1932

[Begasus]

build output: https://pastebin.com/4Zu6tU7U

[geoffmcl]

@Begasus well reading around it seems Haiku gcc2 2.95 was released circa 2001, now 16 years old, but really that does not seem to explain the unbalanced #endif in the language_* header files, that later compilers do not find...

The earliest I have for testing is gcc-4.8 and it compiles without errors, or warnings, as do a few other later versions I have...

It is almost as if the 2.95 compiler skips the first line in each of these files...

They all start with an #ifndef ..., as the very first line... so you could try adding a newline, or comment like /* nl */, at the beginning of each... test and report...

But then I note you show another error in tidylib.c, namely bomEnc is undefined. I have found at least one old compiler, MSVC10, that likewise flags this error. But it is fixed by moving its declaration up one line, to before the doc->pConfigChangeCallback = NULL...

While we may consider the second change for bomEnc, I do not know what we can do about the first errors... it may be a case where you must apply your own local patches to use this old 2.95 compiler...

And some of the warnings are strange, like messageobj.h:66: warning: parameter has incomplete type, repeated several times, but as usual they may not actually be a problem...

HTH... and look forward to your further feedback... thanks...

[Begasus]

@geoffmcl thanks for the reply, will check later and report back 👍

[geoffmcl]

@Begasus since tidy is intended as a simple pure C project, in essence it should be compilable by all versions of gcc...

And would welcome any PR to make it so...

Look forward to your further feedback... thanks...

[Begasus]

@geoffmcl for the unbalanced #endif it was ok to remove the whitespace in front of the first line, still need to investigate the other errors, thanks for the pointer!

[geoffmcl]

@Begasus ah, ha, thanks for the further feedback...

On more carefully checking I find 6 source files have a UTF-8 BOM - language_en_gb.h, language_es.h, language_es_mx.h, language_fr.h, language_pt_br.h, language_zh_cn.h - that is they start with hex ef bb bf, and I guess that is what you are referring to as whitespace in front of the first line...

And I guess that is what gcc 2.95 trips on...

Reading around it seems adding a UTF-8 BOM is not necessary, and see some suggestions that it should not be added, as it can cause problems with older software...

These language files were added by @balthisar, and maybe he could comment on its possible removal... I think it is being added by a generation tool he uses... thanks...

I will try to get around to removing it just to check my windows compilers will have not problems with utf-8 without it...

Look forward to further feedback on the other errors... thanks...

[geoffmcl]

@Begasus, @balthisar, just a quick follow-up...

I made the small change for bomEnc, and removed the BOM from those 6 files, and everything built fine using MSVC10 and MSVC14, in both 32-bits and 64-bits...

Have pushed this to the issue-663 branch for testing in all environments... Note this issue-663 is based on next, version 5.7.0, but at this time this is the same as release 5.6.0 aside from this version number...

Look forward to further feedback... thanks...

[Begasus]

@geoffmcl thanks!, will check with the latest commit :)

[geoffmcl]

Have now had a chance to build issue-663 branch in -

1. Ubuntu 14.04 64-bit, gcc 4.8.4, no errors or warnings - clean build
2. Raspbian 8, 32-bit, gcc 4.9.2, no errors or warnings - clean build
3. Ubuntu 16.04, 32-bit, gcc 5.4.0, no errors or warnings - clean build

Still to light up my OLD Windows XP system, and try with MSVC8 2005 - will get to that - but expect no errors, but a language*.h warning about the #pragma execution_character_set("utf-8"), which it seems was not added until a later MSVC version...

All this seems to suggest the UTF-8 BOM can be safely removed...

@Begasus hope you have good luck with gcc 2.95, or any other compilers you have... please advise when you have time...

[Begasus]

@geoffmcl this issue can be closed as far for Haiku, no unbalanced #endif's now 👍
And works ok also for gcc5* here ..
Only error I run into now with gcc 2.95 is

/sources/tidy-html5-7af9e1843b0ddcb96d235ee9a2f73eb6630f7227/src/tidylib.c:1138: parse error before `struct'

/sources/tidy-html5-7af9e1843b0ddcb96d235ee9a2f73eb6630f7227/src/tidylib.c:1142: `sbuf' undeclared (first use in this function)

But maybe I could add a different issue for that one?