Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #401687 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2026-09-07 15:39 +0200 |
| Last post | 2026-09-10 20:13 +0000 |
| Articles | 12 — 5 participants |
Back to article view | Back to comp.lang.c
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
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-07 15:39 +0200 |
| Subject | why &| 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]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-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]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-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]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-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]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2026-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]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-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]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-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]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-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]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2026-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]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-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]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-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]
| From | Kaz Kylheku <046-301-5902@kylheku.com> |
|---|---|
| Date | 2026-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