ICU booleans

[donarturo11]

Compiling files from ICU eg. TextCodecICU throws compilation error: 'TRUE' was not declared in this scope. I tried to add umachine.h to include, but it doesn't help. When I tried to add boolean definitions to compile flags, compiles without problem. According to ICU reference, uppercase booleans are deprecated and standard lowcase (true, false) are recommended. @clbr, what do you think about rewriting all uppercase booleans to lowcase booleans? Some time ago, I proposed similar changes as pull requests. I think about define uppercase booleans to config.h. Which idea will be better?

[clbr]

Those are also defined in standard headers somewhere, perhaps stdio.h.

[donarturo11]

I made a simple example in cpp and c: code in c and c++:

#include <stdio.h>
#include <stdbool.h>

int main()
{
    printf("TRUE: %i", TRUE);
    printf("FALSE: %i", FALSE);

	return 0;
}

I tried to compile a simple example with latest gcc/g++ and gcc5. Always I have compiler error. Output with gcc5:

[art@art-desktop booleans]$ gcc-5 -o test1 test1.c
test1.c: In function ‘main’:
test1.c:6:24: error: ‘TRUE’ undeclared (first use in this function)
     printf("TRUE: %i", TRUE);
                        ^
test1.c:6:24: note: each undeclared identifier is reported only once for each function it appears in
test1.c:7:25: error: ‘FALSE’ undeclared (first use in this function)
     printf("FALSE: %i", FALSE);

Output with latest g++ but in standard c++98:

[art@art-desktop booleans]$ g++ test1.cpp -o test1 -std=c++98
test1.cpp: In function ‘int main()’:
test1.cpp:6:24: error: ‘TRUE’ was not declared in this scope
    6 |     printf("TRUE: %i", TRUE);
      |                        ^~~~
test1.cpp:7:25: error: ‘FALSE’ was not declared in this scope
    7 |     printf("FALSE: %i", FALSE);

I copied umachine.h to test directory and added to include – compiled successful. Unluckily adding to eg. TextCodecICU.cpp #include <utypes.h>, which consists umachine.h (where TRUE/FALSE are defined) does give no effects. It helps only direct define these booleans in source file or by CXXFLAGS from terminal (I use second way, to not edit source files).

[clbr]

Oh, seems I remembered wrong, it was the lowercase booleans that were defined in std headers.

I don't want to make big changes in common files that would complicate updating from webkit upstream. So s/TRUE/true/ is out. Defines in common files, well, supporting newer ICU versions is not really important to me at this point. So I would suggest you use older ICU, or keep a local change for this.

Just curious, what use cases do you have with webkitfltk?

[donarturo11]

I'm trying to ressurect fifth. I fascinated with fltk because is lightweight and good for older PC. I think about make desktop environment based on fltk, and fifth would be a good browser to it. And webkitfltk is necessary. Sure I can make own patches, but I think, that make some changes is a good idea. I read about older standards and lowercase boolean are present over 30 years. So I think that s/TRUE/true/ is very good solution. Not every distros has older ICU, so better define directly in common header (eg. TextCodec.h) or rewrite s/TRUE/true/. I know that you have no enough time, so I could fix these files.

[donarturo11]

BTW I don't know, why adding #include <unicode/utypes.h> or similar, doesn't fix this issue, so way of headers is utypes.h -> umachine.h .

listing of line 214-228 of umachine.h

/*==========================================================================*/
/* Boolean data type                                                        */
/*==========================================================================*/

/** The ICU boolean type @stable ICU 2.0 */
typedef int8_t UBool;

#ifndef TRUE
/** The TRUE value of a UBool @stable ICU 2.0 */
#   define TRUE  1
#endif
#ifndef FALSE
/** The FALSE value of a UBool @stable ICU 2.0 */
#   define FALSE 0
#endif 

[donarturo11]

Just curious, what use cases do you have with webkitfltk?

A propos your question, fifth browser was very good browser, because is very simple. I ran fifth, but I'm going to build with debug mode to find reasons of SEGFAULTs.

[clbr]

s/TRUE/true/ is probably fine for your goals, you'd just have to keep it in your fork. We have different goals, so it's totally fine to diverge on parts. You can work faster with just your own fork, not having to run everything by me. I'm low on time yeah, so webkitfltk and fifth haven't gotten much work in a while.

I'm still using Fifth as my primary browser - writing this in it - but it does keep getting more incompatible with sites. The segfaults I know of are mostly bugs in the JS engine, which would likely be solved by newer webkit code. Some happen if you use a too new gcc, gcc-5 is recommended currently. The JS engine bugs are probably too hard to track for us, if you find it's from those files, it may not be good use of your time to hunt it.

[donarturo11]

Thank you