void bytes_dump_in_hex()
{
for(int i=0; i<bytes_size; i++)
{
if(!(i%16)) printf("\n");

printf("%02x ", bytes[i]);
}
}

in the code above seem that those inner () in if(!(i%16)) are needed

why is that so?

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: i2pn2 (i2pn.org) (3:633/280.2@fidonet)

On 30/03/2024 21:44, fir wrote:

ÿvoid bytes_dump_in_hex()
ÿ {
ÿÿÿ for(int i=0; i<bytes_size; i++)
ÿÿÿ {
ÿÿÿÿÿ if(!(i%16)) printf("\n");

ÿÿÿÿÿ printf("%02x ", bytes[i]);
ÿÿÿ }
ÿ }

in the code above seem that those inner () in if(!(i%16)) are needed

why is that so?

Without them !i%16 will be parsed as (!i)%16.


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

bart wrote:

On 30/03/2024 21:44, fir wrote:

void bytes_dump_in_hex()
{
for(int i=0; i<bytes_size; i++)
{
if(!(i%16)) printf("\n");

printf("%02x ", bytes[i]);
}
}

in the code above seem that those inner () in if(!(i%16)) are needed

why is that so?

Without them !i%16 will be parsed as (!i)%16.

and does it have sense?


if ! is boolean operator and % is arithmetic then converting things to
bolean and then do arithmetoc on it seems not much reasonable...

overally isnt arithmetoc stronger than boolean like a*b < c*d ?


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: i2pn2 (i2pn.org) (3:633/280.2@fidonet)

On 30/03/2024 22:49, fir wrote:

bart wrote:

On 30/03/2024 21:44, fir wrote:

ÿ void bytes_dump_in_hex()
ÿÿ {
ÿÿÿÿ for(int i=0; i<bytes_size; i++)
ÿÿÿÿ {
ÿÿÿÿÿÿ if(!(i%16)) printf("\n");

ÿÿÿÿÿÿ printf("%02x ", bytes[i]);
ÿÿÿÿ }
ÿÿ }

in the code above seem that those inner () in if(!(i%16)) are needed

why is that so?

Without them !i%16 will be parsed as (!i)%16.

and does it have sense?

It's a unary operator. Usually they are applied before binary ones. So
'++ p + n' means '(++p)+n' not '++(p+n)' which wouldn't work anyway.

And -2-3 means (-2)-3 or -5, not -(2-3) which would be +1.

However whether it makes sense is beside the point. It's how C has
always worked.

if ! is boolean operator and % is arithmetic then converting things to bolean and then do arithmetoc on it seemsÿ not much reasonable...

Some people think that ! should work like that, so that here:

not a<b and b<c

the 'not' applies to the entire expression: not(a<b and b<c), rather
than (not a)<b and b<c.

But honestly, there are lots of things that are worse about C's set of precedences.


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

bart wrote:

On 30/03/2024 22:49, fir wrote:

bart wrote:

On 30/03/2024 21:44, fir wrote:

void bytes_dump_in_hex()
{
for(int i=0; i<bytes_size; i++)
{
if(!(i%16)) printf("\n");

printf("%02x ", bytes[i]);
}
}

in the code above seem that those inner () in if(!(i%16)) are needed

why is that so?

Without them !i%16 will be parsed as (!i)%16.

and does it have sense?

It's a unary operator. Usually they are applied before binary ones. So
'++ p + n' means '(++p)+n' not '++(p+n)' which wouldn't work anyway.

And -2-3 means (-2)-3 or -5, not -(2-3) which would be +1.

However whether it makes sense is beside the point. It's how C has
always worked.

if ! is boolean operator and % is arithmetic then converting things to
bolean and then do arithmetoc on it seems not much reasonable...

Some people think that ! should work like that, so that here:

not a<b and b<c

the 'not' applies to the entire expression: not(a<b and b<c), rather
than (not a)<b and b<c.

But honestly, there are lots of things that are worse about C's set of precedences.

i remember i answered then go to sleep now i dont see my answer

never thinked on this operator precedences but as i said for sure
thise "relative" (< > ==) and logical (and or not) should be last
after bitwise (and or xor not) and arithmetic (+-*/%)
and this is as i say no matter of they do like that but the fact
thet the output of relatives and logical is boleean and boolean is not
to much use (if any) for arithmetic of bitwise - so this is for sure

relative should be before logical becouse for example

a<10 & a>-10 //say % is logical ias for me there is damn error in c and
& should be logical and && eventually could be bitwise

is common usage (so fron this 4 types mentioned logical is 4.
and relative is 3. )

as to arythmetic vs bitwice

7*9 & 78+90

im not sure

bitwise generally not fit here to much at all (to all 3 arithmetic,
logical, and relative..so possiby as this is a bit outside here
it ebventually could go first to beoutside it

like

a&0xff+b&0xff00+c&0xff0000

common usage to work

so

1. bitwise
2. arithmetic
3. relative
4. logical




--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: i2pn2 (i2pn.org) (3:633/280.2@fidonet)

fir wrote:

bart wrote:

On 30/03/2024 22:49, fir wrote:

bart wrote:

On 30/03/2024 21:44, fir wrote:

void bytes_dump_in_hex()
{
for(int i=0; i<bytes_size; i++)
{
if(!(i%16)) printf("\n");

printf("%02x ", bytes[i]);
}
}

in the code above seem that those inner () in if(!(i%16)) are needed >>>>>
why is that so?

Without them !i%16 will be parsed as (!i)%16.

and does it have sense?

It's a unary operator. Usually they are applied before binary ones. So
'++ p + n' means '(++p)+n' not '++(p+n)' which wouldn't work anyway.

And -2-3 means (-2)-3 or -5, not -(2-3) which would be +1.

However whether it makes sense is beside the point. It's how C has
always worked.

if ! is boolean operator and % is arithmetic then converting things to
bolean and then do arithmetoc on it seems not much reasonable...

Some people think that ! should work like that, so that here:

not a<b and b<c

the 'not' applies to the entire expression: not(a<b and b<c), rather
than (not a)<b and b<c.

But honestly, there are lots of things that are worse about C's set of
precedences.

i remember i answered then go to sleep now i dont see my answer

never thinked on this operator precedences but as i said for sure
thise "relative" (< > ==) and logical (and or not) should be last
after bitwise (and or xor not) and arithmetic (+-*/%)
and this is as i say no matter of they do like that but the fact
thet the output of relatives and logical is boleean and boolean is not
to much use (if any) for arithmetic of bitwise - so this is for sure

relative should be before logical becouse for example

a<10 & a>-10 //say % is logical ias for me there is damn error in c and
& should be logical and && eventually could be bitwise

is common usage (so fron this 4 types mentioned logical is 4.
and relative is 3. )

as to arythmetic vs bitwice

7*9 & 78+90

im not sure

bitwise generally not fit here to much at all (to all 3 arithmetic,
logical, and relative..so possiby as this is a bit outside here
it ebventually could go first to beoutside it

like

a&0xff+b&0xff00+c&0xff0000

common usage to work

so

1. bitwise
2. arithmetic
3. relative
4. logical

there are yet assigment ones

a=b+c
for sure it should go after arithmetic and bitwise
it also should before relative becouse the same reason - assigment of
boolean is small use

so

1. bitwise
2. arithmetic
3. assigment
4. relative
5. logical

what else those lik . for member or * & for pointers should be first
(0.) and ?: should be lowest i guess



and how it look like in c:


arithmetic seem be higher then relational then bitwise then logical and assigment but with some exceptions

2.(ar)4(rel).1(bit).5(logg).3.(assign)

2.4.5. is in order so one should ship bitwise and be aware of assigment


quite funny if i treat bitwisa & | as logical it still work
becouse at least

arithm < rel < log

assigment also shoudl work partially (as to arithmetic and new logical)

i would need to check it in practice what work as here above its written
much approximately









--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: i2pn2 (i2pn.org) (3:633/280.2@fidonet)

so yet in short the general

"ar rel log" (as it should be) seem to be preserved in c


there is problem with assigment that should be before rel and is last

there is also problem with bitwise (except they are use as logical)
as bitwise should b first and is after relative

and also this problem with logical not here spotted in title of the post
at should go after arithmetic and for some reason its not

it seems there is more right than wrong but are wew errors that need to
be listed than could be memorized


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: i2pn2 (i2pn.org) (3:633/280.2@fidonet)