Fix: Build error with bool boolean conversion. #126441

Aleksi Venäläinen · 2024-08-17T22:06:34+02:00

Aleksi Venäläinen commented

2024-08-17 22:06:34 +02:00

First-time contributor

Similar error was ex. on pull request #118464

Aleksi Venäläinen added 1 commit 2024-08-17 22:06:52 +02:00

Fix: Build error with bool boolean conversion. 95cef645b7

Similar error was  ex. on pull request #118464

Iliya Katushenock added the

Interest

Images & Movies

label 2024-08-17 22:09:51 +02:00

Iliya Katushenock added this to the Core project 2024-08-17 22:10:05 +02:00

Bastien Montagne commented

2024-08-21 17:00:17 +02:00

I would be good to have a bit more info/context where current code fails? Preferably in the commit message itself.

Aleksi Venäläinen commented

2024-08-21 17:59:22 +02:00

First-time contributor

I would be good to have a bit more info/context where current code fails? Preferably in the commit message itself.

Right here we go.

This boolean bool boolean conversions (implicit conversion from integral types to bool) can be made as error on example GCC 11.5.0 compiler or Clang >> notice referenced pull.

This pull makes the file which included in commit section (Files Changed - look it up) up to spec so it will compile ( i wrote build error in as subject.. so thats already existing answer to your question where ) with compilers which might not allow implicit conversions.. like the referenced pull file originally had as well.

Whats wrong?
Boolean as integer can be any number more than just 0 or 1. So it can lead to errors which why example GCC is more stricter these days. But we doing the opposite way? You will get the point still.

Just an example part..
Look at here in File Changes..

--jpeg_start_compress(cinfo, true);
++jpeg_start_compress(cinfo, TRUE);

This code is from library it references..

jpeg_start_compress JPP((j_compress_ptr cinfo,
				      boolean write_all_tables));

libjpeg waits there boolean but originally the code tries give just bool (false).

GCC and others can have in coming updates way more (like they have kept advancing to limit mistakes) stricter type-checking features and might issue warnings or errors depending on the compiler settings.

> I would be good to have a bit more info/context where current code fails? Preferably in the commit message itself. Right here we go. This boolean bool boolean conversions (**implicit conversion from integral types to bool**) can be made as error on example GCC 11.5.0 compiler or Clang >> notice referenced pull. This pull makes the file which included in commit section (Files Changed - look it up) up to spec so it will compile ( i wrote **build error** in as subject.. so thats already existing answer to your question `where` ) with compilers which might not allow implicit conversions.. like the referenced pull file originally had as well. Whats wrong? Boolean as integer can be any number more than just 0 or 1. So it can lead to errors which why example GCC is more stricter these days. But we doing the opposite way? You will get the point still. **Just an example part..** Look at here in File Changes.. ``` --jpeg_start_compress(cinfo, true); ++jpeg_start_compress(cinfo, TRUE); ``` This code is from library it references.. ``` jpeg_start_compress JPP((j_compress_ptr cinfo, boolean write_all_tables)); ``` libjpeg waits there boolean but originally the code tries give just bool (false). GCC and others can have in coming updates way more (like they have kept advancing to limit mistakes) stricter type-checking features and might issue warnings or errors depending on the compiler settings.

Bastien Montagne commented

2024-08-22 11:09:40 +02:00

What I was requesting was specific information about compilers/system that do fail to build Blender currently without this 'fix'.

'Preventive' fix for potential future compiler changes and/or building with non-default, stricter options are also fine, but then I'd rather see another solution than re-introducing in our code-base hacks that were removed years ago when we fully supported C99 (not to mention that our codebase is now in C++).

Why not rather do some explicit conversion? boolean(true) if that works, or static_cast<boolean>(true)?

Point being, I'd rather not have things like TRUE re-introduced in our code for the sake of some random library that is still stuck in some hack around the missing bool type...

What I was requesting was specific information about compilers/system that do fail to build Blender currently without this 'fix'. 'Preventive' fix for potential future compiler changes and/or building with non-default, stricter options are also fine, but then I'd rather see another solution than re-introducing in our code-base hacks that were removed years ago when we fully supported C99 (not to mention that our codebase is now in C++). Why not rather do some explicit conversion? `boolean(true)` if that works, or `static_cast<boolean>(true)`? Point being, I'd rather not have things like `TRUE` re-introduced in our code for the sake of some random library that is still stuck in some hack around the missing `bool` type...

Aleksi Venäläinen commented

2024-08-22 16:22:57 +02:00

First-time contributor

GCC11.5.0 and Clang mentioned. --

Forcing bool into boolean and hoping compiler supports it is then not a hack? Wrapping bool to turn into boolean is better way -- well it works too. -- removed nonsense baby rage and misunderstanding, my apologies i am easy to be such one--

Thank you.

GCC11.5.0 and Clang mentioned. -- Forcing bool into boolean **and hoping compiler supports it** is then not a hack? Wrapping bool to turn into boolean is better way -- well it works too. -- removed nonsense baby rage and misunderstanding, my apologies i am easy to be such one-- Thank you.

Thomas Dinges commented

2024-08-22 16:31:24 +02:00

@Aleksi-Venalainen I am asking you to take a look at our code of conduct. https://developer.blender.org/docs/handbook/communication/code_of_conduct/

Aleksi Venäläinen closed this pull request

2024-08-22 19:07:48 +02:00