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?

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.

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 ?

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.

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

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

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