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

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
    Re: why &| dont work and its possible to make it work fir <profesor.fir@gmail.com> - 2026-10-22 17:29 +0200
      Re: why &| dont work and its possible to make it work scott@slp53.sl.home (Scott Lurndal) - 2026-10-22 19:40 +0000
        Re: why &| dont work and its possible to make it work Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-22 20:13 +0000
          Re: why &| dont work and its possible to make it work fir <profesor.fir@gmail.com> - 2026-10-22 23:13 +0200
            Re: why &| dont work and its possible to make it work fir <profesor.fir@gmail.com> - 2026-10-22 23:28 +0200
        Re: why &| dont work and its possible to make it work fir <profesor.fir@gmail.com> - 2026-10-22 22:46 +0200
        Re: why &| dont work and its possible to make it work David Brown <david.brown@hesbynett.no> - 2026-10-23 08:55 +0200
          Re: why &| dont work and its possible to make it work fir <profesor.fir@gmail.com> - 2026-10-23 09:39 +0200
            Re: why &| dont work and its possible to make it work fir <profesor.fir@gmail.com> - 2026-10-23 09:44 +0200
              Re: why &| dont work and its possible to make it work fir <profesor.fir@gmail.com> - 2026-10-23 09:51 +0200
                Re: why &| dont work and its possible to make it work David Brown <david.brown@hesbynett.no> - 2026-10-23 11:23 +0200
                  Re: why &| dont work and its possible to make it work fir <profesor.fir@gmail.com> - 2026-10-23 14:25 +0200
        Re: why &| dont work and its possible to make it work "chine.bleu" <chine.bleu@yahoo.com> - 2026-10-24 03:16 -0700
          Re: why &| dont work and its possible to make it work fir <profesor.fir@gmail.com> - 2026-10-24 15:00 +0200
          Re: why &| dont work and its possible to make it work Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-24 22:22 +0000

Page 1 of 2  [1] 2  Next page →

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

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

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

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

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

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

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

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

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

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

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

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

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] | [next] | [standalone]

#403448

sady this plan of using | & failed becouse its said that here for example

     if(target<0 ||target>=bag_max ||!bag[target].enabled)   {}

if target is -1 in case of | the last one will be evalueated too
and it may be segfault

so it needs language change..this overally is a flop in c

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

#403453

fir <profesor.fir@gmail.com> writes:
>sady this plan of using | & failed becouse its said that here for example
>
>     if(target<0 ||target>=bag_max ||!bag[target].enabled)   {}
>
>if target is -1 in case of | the last one will be evalueated too
>and it may be segfault

If the first test is true, the remaining tests will not be
executed.

If you knew C, you'd have known that.

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

#403455

On 2026-10-22, Scott Lurndal <scott@slp53.sl.home> wrote:
> fir <profesor.fir@gmail.com> writes:
>>sady this plan of using | & failed becouse its said that here for example
>>
>>     if(target<0 ||target>=bag_max ||!bag[target].enabled)   {}
>>
>>if target is -1 in case of | the last one will be evalueated too
>>and it may be segfault
>
> If the first test is true, the remaining tests will not be
> executed.
>
> If you knew C, you'd have known that.

Problem is fir said "in case of |"; i.e. "if the operator | is
substituted for || in the above expression".

It's hard to spot things like this in the broken/loose english with low
punctuation and capitalization.

A token substitution in the syntax requiring us to edit, recompile and
redeploy the program image is not exactly a "case"; we normally
don't talk about it that way, let alone as an apparently subordinate
condition to a run time value like target == -1.

"If we change || to | in the above, and then hit the value target == -1
at run-time, then bag[target] is still evaluated, with the out-of-bounds
target index."

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

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

#403457

Kaz Kylheku pisze:
> On 2026-10-22, Scott Lurndal <scott@slp53.sl.home> wrote:
>> fir <profesor.fir@gmail.com> writes:
>>> sady this plan of using | & failed becouse its said that here for example
>>>
>>>      if(target<0 ||target>=bag_max ||!bag[target].enabled)   {}
>>>
>>> if target is -1 in case of | the last one will be evalueated too
>>> and it may be segfault
>>
>> If the first test is true, the remaining tests will not be
>> executed.
>>
>> If you knew C, you'd have known that.
> 
> Problem is fir said "in case of |"; i.e. "if the operator | is
> substituted for || in the above expression".
> 
> It's hard to spot things like this in the broken/loose english with low
> punctuation and capitalization.
> 
> A token substitution in the syntax requiring us to edit, recompile and
> redeploy the program image is not exactly a "case"; we normally
> don't talk about it that way, let alone as an apparently subordinate
> condition to a run time value like target == -1.
> 
> "If we change || to | in the above, and then hit the value target == -1
> at run-time, then bag[target] is still evaluated, with the out-of-bounds
> target index."
> 

sad it not work
overally using this operators is wastefull imo and they not look to much 
good

some could for exampl maybe took

  if(target<0, target>=bag_max,!bag[target].enabled)

for and or or

or


if any(a,b,c,d) {}

if some(a,b,c) {}


if none(3,b,c,d) {}


eventually if (a,b,c,d) {} for or

coz and can be showed as

if(a) if (b) if(c) if (d) {}

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

#403458

fir pisze:
> if(a) if (b) if(c) if (d) {}

switch in such aspect as i said before could be done as


if(if(a) {}, if(b) {}, if(c) {}, if(d) {} } {/*some*/} else {/*none*/}

which maybe is kinda idiotic (some asumption also here the logical value 
have thise inner ifs not  blocks) but is kinda logical illustration
of possibilities here

coz it seems for example there ar more switches possible than this one 
from c (if im not wrong - and i may be wrong if those other reduce to 
the one..would need to check


forexample

is something like

if(if(a) {} & if(b) {} | if(c) {} & if(d) {} } {/*some*/} else {/*none*/}

to be presented by normal switch?


(to weary to check)

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

#403456

Scott Lurndal pisze:
> fir <profesor.fir@gmail.com> writes:
>> sady this plan of using | & failed becouse its said that here for example
>>
>>      if(target<0 ||target>=bag_max ||!bag[target].enabled)   {}
>>
>> if target is -1 in case of | the last one will be evalueated too
>> and it may be segfault
> 
> If the first test is true, the remaining tests will not be
> executed.
> 
> If you knew C, you'd have known that.
> 
and now what? i wouldnt say if some dont know sole pice of c dont know c

but as you do it bounces from the wall and hits you in the face, huh?

;c

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

#403464

On 22/10/2026 21:40, Scott Lurndal wrote:
> fir <profesor.fir@gmail.com> writes:
>> sady this plan of using | & failed becouse its said that here for example
>>
>>      if(target<0 ||target>=bag_max ||!bag[target].enabled)   {}
>>
>> if target is -1 in case of | the last one will be evalueated too
>> and it may be segfault
> 
> If the first test is true, the remaining tests will not be
> executed.
> 
> If you knew C, you'd have known that.

You missed the point.  || and && is ugly and for common, stupid people. 
Creative programmers like Fir need to be able to use whatever syntax 
they like at the time, and the compiler should know what they mean - the 
compiler should /know/ that when Fir writes |, he means ||.  It should 
be able to tell he means logical or, not bitwise or, and figure out 
which order the expressions should be evaluated regardless of how he 
writes them.

Anything else is just a critical flaw in C.

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

#403466

David Brown pisze:
> On 22/10/2026 21:40, Scott Lurndal wrote:
>> fir <profesor.fir@gmail.com> writes:
>>> sady this plan of using | & failed becouse its said that here for 
>>> example
>>>
>>>      if(target<0 ||target>=bag_max ||!bag[target].enabled)   {}
>>>
>>> if target is -1 in case of | the last one will be evalueated too
>>> and it may be segfault
>>
>> If the first test is true, the remaining tests will not be
>> executed.
>>
>> If you knew C, you'd have known that.
> 
> You missed the point.  || and && is ugly and for common, stupid people. 
> Creative programmers like Fir need to be able to use whatever syntax 
> they like at the time, and the compiler should know what they mean - the 
> compiler should /know/ that when Fir writes |, he means ||.  It should 
> be able to tell he means logical or, not bitwise or, and figure out 
> which order the expressions should be evaluated regardless of how he 
> writes them.

you think so? you shoul  better cut the bullshit

this is practice btw not much wise people do - they are unable tu 
understand things so they replace it with some bulshit of their own 
production and then answer to their own bulshit - its quite _common_ 
practice
> 
> Anything else is just a critical flaw in C.
> 

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web