Page MenuHomePhabricator

Eina_Bool type
Open, TODOPublic

Description

Does this type need to exist in the year 2018 or can we use a more standardized bool type?

Related Objects

StatusAssignedTask
OpenNone
OpenNone
zmike created this task.Jul 13 2018, 9:17 AM
zmike triaged this task as TODO priority.

completely agree on this one.

herdsman added a subscriber: herdsman.EditedJul 16 2018, 4:38 AM

Fwiw, please consider that for bitfields of one bit (e.g. bool changed: 1;) the values will be 0 and -1 due to bool being a signed char. If we ensure consistency on usage it shouldn't be an issue.

herdsman added a comment.EditedJul 16 2018, 6:04 AM

Okay, I feel less concerned now. I assumed the treatment is the same as it was to a signed char.
However, upon further testing, the bitfield bool value was converted from the stored 1 to 1 (or: true), as opposed to -1, (which I expected it to be).
Looks like C99 adds an implicit conversion for bool types.

Couldn't find an exact mention of this in neither stdbool.h nor GNU99 docs, but some text implies such behavior.

In any case, I guess i'm on board :)

raster added a subscriber: raster.Jul 16 2018, 6:14 AM

until efl 2.0 ... can't happen. abi problems like @herdsman says. for then - sure. until then - can't.

zmike edited projects, added efl: data types; removed efl.Jul 24 2018, 10:03 AM

btw - check on arm. chars are unsigned by default there for example - different architectures may be different... but for existing efl - no. shouldn't change. efl 2.0 - anything goes. :)

zmike added a comment.Jul 25 2018, 9:17 AM

I don't know why there are comments here related to changing this in current EFL when this is obviously a subtask of T7142?

jayji added a subscriber: jayji.Aug 3 2018, 11:55 AM

+1 on this one!
Btw, I don't understand one would like to write a bool bitfield instead of using a proper integer type .

@jayji - you don't think bool x:1; is good? it definitely saves space especially if you have a lot of flags and want to pack them at the end of a struct etc. ... and the value then can only be true or false, no other values possible. :)

Well, its basically a tradeoff, you *maybe* safe memory, while wasting performance, (the assembly created for that purpose is quite horrible, which is needed, but still not nice...)

For getting the same things you could also just have constants that you or / and onto a data word in you struct.
Which would result in clear or and and instructions in the assembly, without the need of shifting a value to the possition so it can be OR'ed into the memory segment of the struct.
And result in a more compact definition.

jayji added a comment.Aug 5 2018, 12:05 PM

I'd prefer to use unsigned x : 1; instead of bool x : 1;.
I personally am not a fan of bitfields, because of their undefined and implementation-defined behaviors and the fact they are not always well-handled by compilers (e.g. Diab).

i've never found a compiler that doesn't handle them that would be used to compile my code (e.g. for linux and other posix systems) - so never ran into that... and i have never noted undefined behavior if i just use the bitfield as a boolean like if (x->field) a(); else b();. it's rare i use more than 1 but (but have done so to pack stuff more to save space).

as for instructions ... it depends on architecture. i remember the 68k having a btst instruction to test a single bit in a register which would be used as the cmp instruction to base the next jsr off, so it would be no extra code there. x86 has the tst instruction to test a single bit being on, and arm also has a tst instruction too that updates condition flags based on bits being set in the logical and. otherwise it would depend. like the above if's could do something like (in pseudo-assembly):

andbi #4, addr0, reg0; //and immediate byte value with 4 (3rd lowest bit) and store in reg0
jsr true_path; // and will set the status register based on any bits being true during the and

or if status reg isn't set:

andbi #4, addr0, reg0; //and immediate byte value with 4 (3rd lowest bit) and store in reg0
cmpbi #i, reg0; // compare register with immediate value 4 (is the bit on)
jsr true_path; // and will set the status register based on any bits being true during the and

without the bitfield you could just cmpbi directly on the value compare to 1... every instruction set i can remember seeing has some kind of immediate constant value operations for add, sub, mov etc. etc. so the compiler can nicely know the exact byte location and stick to just using small 8bit immediates... but yeah - without bit test instruction it's and extra instruction, but i suspect that the cost of that is dwarfed by the savings in cache misses. have som data structs in efl that have like 20 or so bit fields... that'd eat up 20 bytes of space without bitfields, and with only uses 4 bytes. a cache miss is 100-300 cycles these days. i am sure extending data structs to be fatter is going to cause some misses more and thus i'd say in the end makes up for the extra instruction :)