Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #401687 > unrolled thread

why &| dont work and its possible to make it work

Started byfir <profesor.fir@gmail.com>
First post2026-09-07 15:39 +0200
Last post2026-09-10 20:13 +0000
Articles 12 — 5 participants

Back to article view | Back to comp.lang.c


Contents

  why &| dont work and its possible to make it work fir <profesor.fir@gmail.com> - 2026-09-07 15:39 +0200
    Re: why &| dont work and its possible to make it work bart <bc@freeuk.com> - 2026-09-07 16:42 +0100
      Re: why &| dont work and its possible to make it work fir <profesor.fir@gmail.com> - 2026-09-07 18:14 +0200
      Re: why &| dont work and its possible to make it work Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-09 07:14 +0000
        Re: why &| dont work and its possible to make it work Bonita Montero <Bonita.Montero@gmail.com> - 2026-09-09 11:15 +0200
        Re: why &| dont work and its possible to make it work bart <bc@freeuk.com> - 2026-09-09 11:23 +0100
          Re: why &| dont work and its possible to make it work fir <profesor.fir@gmail.com> - 2026-09-09 13:28 +0200
            Re: why &| dont work and its possible to make it work fir <profesor.fir@gmail.com> - 2026-09-09 14:01 +0200
    Re: why &| dont work and its possible to make it work Bonita Montero <Bonita.Montero@gmail.com> - 2026-09-07 17:49 +0200
      Re: why &| dont work and its possible to make it work fir <profesor.fir@gmail.com> - 2026-09-07 18:22 +0200
      Re: why &| dont work and its possible to make it work Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-09 06:07 +0000
    Re: why &| dont work and its possible to make it work Kaz Kylheku <046-301-5902@kylheku.com> - 2026-09-10 20:13 +0000

#401687 — why &| dont work and its possible to make it work

Fromfir <profesor.fir@gmail.com>
Date2026-09-07 15:39 +0200
Subjectwhy &| dont work and its possible to make it work
Message-ID<117mere$3a14a$1@dont-email.me>
as i once said i decided to not use && and || as it annoys me (same s == 
annoys me)

so i will decide to use & | insted but as i not code regullarry today i 
not yet maneged to test it throughly when it not work and
if it need big changes in languege to work

i mean one option is that & | should work for BOTH logical and bitwise

is it possible?

if not i wuld probably suggest using some other methods to make it work 
(i could eventually say that &| would better work for logical and && || 
for bitwise but im not saing this becouse it would alos be bad imo)
so maybe better it should work for both (?)

if it not brings some problems i suspect something like

3&4 has different meaning in logical (1) and bitwise (7) but is that a 
problem?

overally seem oryginal C or even B was bests, then some populists come 
(i name them populists, people with medicore mind lower than oryginal c 
quality - who was many and this majority make c worse even in back times 
of first changes

[toc] | [next] | [standalone]


#401690

Frombart <bc@freeuk.com>
Date2026-09-07 16:42 +0100
Message-ID<117mm0k$3cu2d$1@dont-email.me>
In reply to#401687
On 07/09/2026 14:39, fir wrote:
> as i once said i decided to not use && and || as it annoys me (same s == 
> annoys me)
> 
> so i will decide to use & | insted but as i not code regullarry today i 
> not yet maneged to test it throughly when it not work and
> if it need big changes in languege to work
> 
> i mean one option is that & | should work for BOTH logical and bitwise
> 
> is it possible?

No, because they do different things. But if you can only have one, then 
& and | are  more flexible:

I think 'A && B' is equivalent to  '(!!A ? 1 : (!!B ? 1 : 0))', if a 
boolean result is needed.

You can't do '!!A & !!B' because && short-circuits.




> 
> if not i wuld probably suggest using some other methods to make it work 
> (i could eventually say that &| would better work for logical and && || 
> for bitwise but im not saing this becouse it would alos be bad imo)
> so maybe better it should work for both (?)
> 
> if it not brings some problems i suspect something like
> 
> 3&4 has different meaning in logical (1) and bitwise (7) but is that a 
> problem?

Yeah, it's a problem: 3&4 has result 0, but 3&&4 has result 1. But in 
this case, (!!3)&(!!4) can be used to give 1.

[toc] | [prev] | [next] | [standalone]


#401692

Fromfir <profesor.fir@gmail.com>
Date2026-09-07 18:14 +0200
Message-ID<117mnso$3dn0r$1@dont-email.me>
In reply to#401690
bart pisze:
> On 07/09/2026 14:39, fir wrote:
>> as i once said i decided to not use && and || as it annoys me (same s 
>> == annoys me)
>>
>> so i will decide to use & | insted but as i not code regullarry today 
>> i not yet maneged to test it throughly when it not work and
>> if it need big changes in languege to work
>>
>> i mean one option is that & | should work for BOTH logical and bitwise
>>
>> is it possible?
> 
> No, because they do different things. But if you can only have one, then 
> & and | are  more flexible:
> 
> I think 'A && B' is equivalent to  '(!!A ? 1 : (!!B ? 1 : 0))', if a 
> boolean result is needed.
> 
> You can't do '!!A & !!B' because && short-circuits.
> 
> 
> 
> 
>>
>> if not i wuld probably suggest using some other methods to make it 
>> work (i could eventually say that &| would better work for logical and 
>> && || for bitwise but im not saing this becouse it would alos be bad imo)
>> so maybe better it should work for both (?)
>>
>> if it not brings some problems i suspect something like
>>
>> 3&4 has different meaning in logical (1) and bitwise (7) but is that a 
>> problem?
> 
> Yeah, it's a problem: 3&4 has result 0, but 3&&4 has result 1. But in 
> this case, (!!3)&(!!4) can be used to give 1.
> 
> 

lol i misluked it - i thought 3&4 is 7

its kinda confusing

3&4 is logically true, so bitewise also should be true here t work, i guess

3|4 is logically also true , so bitewise it also should be true ?

to make it work?

"logical" operators and and or are for sure defined well in thsi sense
tahat A & B & C should be tru if all are true. otherwise false,
A|B|C should be true if only one or more is true.. though natural 
reading here is confusing becouse for me as i said 3&4 for me "reads"as 
7 (3|4 also "reads" as 7 probably)

it seems that those mathematical signs u and close to n (reversed u) 
could fir better 3u4 = 7 3n4 = 0

SO

it seems that indeed & and | would not work becouse

A & 3 & 4 & B when A and B are true should give true
(and i assume A and B would be presented as 1 so result is 0)

A |3 |4 |B will give 7  - so in this case its ok, so it seems | work but 
& fails

[toc] | [prev] | [next] | [standalone]


#401758

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2026-09-09 07:14 +0000
Message-ID<117r105$r8qb$3@dont-email.me>
In reply to#401690
On Mon, 7 Sep 2026 16:42:13 +0100, bart wrote:

> I think 'A && B' is equivalent to '(!!A ? 1 : (!!B ? 1 : 0))', if a
> boolean result is needed.

Why not just

    A ? B ? true : false : false

[toc] | [prev] | [next] | [standalone]


#401771

FromBonita Montero <Bonita.Montero@gmail.com>
Date2026-09-09 11:15 +0200
Message-ID<117r82s$104tb$1@raubtier-asyl.eternal-september.org>
In reply to#401758
Am 09.09.2026 um 09:14 schrieb Lawrence D’Oliveiro:

>      A ? B ? true : false : false

The coolest compilers do that with two cascaded conditional moves.

[toc] | [prev] | [next] | [standalone]


#401777

Frombart <bc@freeuk.com>
Date2026-09-09 11:23 +0100
Message-ID<117rc2j$11pku$1@dont-email.me>
In reply to#401758
On 09/09/2026 08:14, Lawrence D’Oliveiro wrote:
> On Mon, 7 Sep 2026 16:42:13 +0100, bart wrote:
> 
>> I think 'A && B' is equivalent to '(!!A ? 1 : (!!B ? 1 : 0))', if a
>> boolean result is needed.
> 
> Why not just
> 
>      A ? B ? true : false : false

Yes, that's better, and more correct. I think mine implemented OR not 
AND, and I also decided not to test it.

I used !! because I was aiming towards needing to use & and | but that 
didn't happen (!!A & !!B would be non-short-circuiting).

In any case, this is very different from A & B.

[toc] | [prev] | [next] | [standalone]


#401779

Fromfir <profesor.fir@gmail.com>
Date2026-09-09 13:28 +0200
Message-ID<117rftk$13d67$1@dont-email.me>
In reply to#401777
bart pisze:
> On 09/09/2026 08:14, Lawrence D’Oliveiro wrote:
>> On Mon, 7 Sep 2026 16:42:13 +0100, bart wrote:
>>
>>> I think 'A && B' is equivalent to '(!!A ? 1 : (!!B ? 1 : 0))', if a
>>> boolean result is needed.
>>
>> Why not just
>>
>>      A ? B ? true : false : false
> 
> Yes, that's better, and more correct. I think mine implemented OR not 
> AND, and I also decided not to test it.
> 
> I used !! because I was aiming towards needing to use & and | but that 
> didn't happen (!!A & !!B would be non-short-circuiting).
> 

i think probably in simple cases when you dont acll functions etc

like if(a<2 & b>7)

.. im not sure though but if compiler has optimising block it is rather 
useles to calc b>7

& probably be short-circuiting anyway
> In any case, this is very different from A & B.

[toc] | [prev] | [next] | [standalone]


#401782

Fromfir <profesor.fir@gmail.com>
Date2026-09-09 14:01 +0200
Message-ID<117rhq1$142g8$1@dont-email.me>
In reply to#401779
fir pisze:
> bart pisze:
>> On 09/09/2026 08:14, Lawrence D’Oliveiro wrote:
>>> On Mon, 7 Sep 2026 16:42:13 +0100, bart wrote:
>>>
>>>> I think 'A && B' is equivalent to '(!!A ? 1 : (!!B ? 1 : 0))', if a
>>>> boolean result is needed.
>>>
>>> Why not just
>>>
>>>      A ? B ? true : false : false
>>
>> Yes, that's better, and more correct. I think mine implemented OR not 
>> AND, and I also decided not to test it.
>>
>> I used !! because I was aiming towards needing to use & and | but that 
>> didn't happen (!!A & !!B would be non-short-circuiting).
>>
> 
> i think probably in simple cases when you dont acll functions etc
> 
> like if(a<2 & b>7)
> 
> .. im not sure though but if compiler has optimising block it is rather 
> useles to calc b>7
> 
> & probably be short-circuiting anyway

sorry i mixed line order (writing the one beginig .. in wrong place)

should be

  i think probably in simple cases when you dont acll functions etc

  like if(a<2 & b>7)

  & probably be short-circuiting anyway

  .. im not sure though but if compiler has optimising block it is rather
  useles to calc b>7



>> In any case, this is very different from A & B.
> 

[toc] | [prev] | [next] | [standalone]


#401691

FromBonita Montero <Bonita.Montero@gmail.com>
Date2026-09-07 17:49 +0200
Message-ID<117mmdu$3d2ek$1@raubtier-asyl.eternal-september.org>
In reply to#401687
Am 07.09.2026 um 15:39 schrieb fir:

> as i once said i decided to not use && and || as it annoys me (same s == 
> annoys me)
Sick !

[toc] | [prev] | [next] | [standalone]


#401693

Fromfir <profesor.fir@gmail.com>
Date2026-09-07 18:22 +0200
Message-ID<f1823b14-0a91-2555-9095-ff6678e516ab@gmail.com>
In reply to#401691
Bonita Montero pisze:
> Am 07.09.2026 um 15:39 schrieb fir:
> 
>> as i once said i decided to not use && and || as it annoys me (same s 
>> == annoys me)
> Sick !

well, it works, under some ciricumstances..and looks better and good 
look matter


from my post above it seems that | works in all cases (it is when you 
mix logical and bit components) but & will prbably not work if you will 
mix bit components which are even values/has lowest bit 0

(i would need to check it yet

also there mat be chaged operator precedence


as i said it is clear to me that && || are C language design flaw

some common rule here would be not mix bitwise with logical

[toc] | [prev] | [next] | [standalone]


#401754

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2026-09-09 06:07 +0000
Message-ID<117qt2t$r8qb$2@dont-email.me>
In reply to#401691
On Mon, 7 Sep 2026 17:49:18 +0200, Bonita Montero wrote:

> Am 07.09.2026 um 15:39 schrieb fir:
>
>> as i once said i decided to not use && and || as it annoys me (same
>> s == annoys me)
>>
> Sick !

    #include <iso646.h>

Then

    if
      (
            TheEntry->d_name[0] == '.'
        &&
            (
                TheEntry->d_name[1] == 0
            ||
                    TheEntry->d_name[1] == '.'
                &&
                    TheEntry->d_name[2] == 0
            )
      )
      {
      /* skip "." and ".." entries */
      }

becomes

    if
      (
            TheEntry->d_name[0] == '.'
        and
            (
                TheEntry->d_name[1] == 0
            or
                    TheEntry->d_name[1] == '.'
                and
                    TheEntry->d_name[2] == 0
            )
      )
      {
      /* skip "." and ".." entries */
      }

[toc] | [prev] | [next] | [standalone]


#401907

FromKaz Kylheku <046-301-5902@kylheku.com>
Date2026-09-10 20:13 +0000
Message-ID<20260910130747.60@kylheku.com>
In reply to#401687
On 2026-09-07, fir <profesor.fir@gmail.com> wrote:
> as i once said i decided to not use && and || as it annoys me (same s == 
> annoys me)
>
> so i will decide to use & | insted but as i not code regullarry today i 
> not yet maneged to test it throughly when it not work and
> if it need big changes in languege to work
>
> i mean one option is that & | should work for BOTH logical and bitwise

The predecessors to the C language had only the bitwise & and | which was
used for testing logical conditions. That's why those operators have
a strangely low precedence.

They work for the purpose, but you have to be fastidiously consistent
about your representation of true; e.g. ensure that true is always 1.

In code like:

  if ((status_reg & FOO_MASK) && (io_reg & BAR_MASK)) ..

we cannot blindly replace && with & because status_reg & FOO_MASK
might produce 0x40, and io_reg & BAR_MASK might produce 0x20.

The & and | operators also do not feature left-to-right sequencing. 
So we cannot replace && with & in code like

  if (ptr != 0 && ptr->foo == bar) ...

Both operands of the & will be evaluated regardless of the value of the
left operand.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.c


csiph-web