From Newsgroup: comp.lang.c

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
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir <[email protected]> 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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-10-22, Scott Lurndal <[email protected]> wrote:

fir <[email protected]> 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: @[email protected]
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Scott Lurndal pisze:

fir <[email protected]> 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



--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Kaz Kylheku pisze:

On 2026-10-22, Scott Lurndal <[email protected]> wrote:

fir <[email protected]> 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) {}






--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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)







--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 22/10/2026 21:40, Scott Lurndal wrote:

fir <[email protected]> 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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

David Brown pisze:

On 22/10/2026 21:40, Scott Lurndal wrote:

fir <[email protected]> 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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

David Brown pisze:

On 22/10/2026 21:40, Scott Lurndal wrote:

fir <[email protected]> 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

ofc i get used to it but if they do that - they should do that on their
own, dont mix it up with me: bulshit of your production is yours not
mine, also bulshit mental degrading ''ways' are of their own not mine

Anything else is just a critical flaw in C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

fir pisze:

David Brown pisze:

On 22/10/2026 21:40, Scott Lurndal wrote:

fir <[email protected]> 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

ofc i get used to it but if they do that - they should do that on their
own, dont mix it up with me: bulshit of your production is yours not
mine, also bulshit mental degrading ''ways' are of their own not mine

some shouldnt be not surprised if someone imposes his own bulshit on me
im getting a bit angry or disgusted ..its quite common reaction not only
mine (though if its common i probably should avoid that some way (as i
said i dont like common), im not sure yet becouse this bulshit in a way
should be repelled so i dont know and im not in a modd to think up
inventive ways here as im focused on some other things

Anything else is just a critical flaw in C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 23/10/2026 09:51, fir wrote:

<snip rubbish>

When you post rubbish, you get rubbish responses. When you post
something interesting and C related, you will (sometimes) get
interesting responses - mostly because people think that there might be
more readers that could be interested.

Get over your pettiness and narcissism. No one cares what mood you are
in, or what you like or don't like. Most people ignore your posts
entirely because of the continuous meaningless streams of line noise you write. As long as you post like a spoiled child, you can expect to be
treated like one.

But you do, sometimes, post interesting C questions that can lead to interesting discussions. Keep making these.



--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

David Brown pisze:

On 23/10/2026 09:51, fir wrote:

<snip rubbish>

When you post rubbish, you get rubbish responses.  When you post
something interesting and C related, you will (sometimes) get
interesting responses - mostly because people think that there might be
more readers that could be interested.

Get over your pettiness and narcissism.  No one cares what mood you are
in, or what you like or don't like.  Most people ignore your posts
entirely because of the continuous meaningless streams of line noise you write.  As long as you post like a spoiled child, you can expect to be treated like one.

But you do, sometimes, post interesting C questions that can lead to interesting discussions.  Keep making these.

youre quite narcussyic thinking yout posts are less 'rubbish' than
mine..so it make your answer here quite commical here...

its like all the kt team..they are not so very bright yet thay jump on
things above their heads

its not a problem as i said but keep your bulshit to you own - im not
takin the bulshit ..nor i dont value people for whom bulskit is a base level --- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

[email protected] (Scott Lurndal) wrote:

fir <[email protected]> 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.

I prefer the visibility of ?: to the implicitness of || &&
--
Siri Seal of Disavowal #777-000. Disavowed. Denied. @
NO KINGS For I desire mercy not sacrifice. /|\
The Church of the Holey Apple .signature 5.5 / \
of Discordian Mysteries. This post insults Islam. Mohamed
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

chine.bleu pisze:

[email protected] (Scott Lurndal) wrote:

fir <[email protected]> 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.

I prefer the visibility of ?: to the implicitness of || &&

&& you may replace by sequence

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

which i like and maybe could use generally


|| sadly cant be replaced afair, and as i said maybe its sad it cant be replaced by ,

if(x<0, x>=w, y<0, y>=h) return

instead

if(x<0 || x>=w || y<0 || y>=h)


here maybe first dont seem more readable but it is also matter of being
used to something

if could be replaced by "any" or "some" or "none" or "all" keywords here
also

those keywords liek higher level and human thinks more high level here
than getting down do or and and so code intentions would improve

if none (x<0, x>=w, y<0, y>=h)
{
SetPixel(x,y)
}


also there could be "non" maybe added and if so also or and and as a
keywords fit here

thise and and or more fit to keywords here than most other c keywords as
they have stright corespondence for native language keywords

eventually "if" can be skipped assuming after binary logic construct you
may just add {} liek after if

a or b {} else {}

all a b c {}






--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Sat, 24 Oct 2026 03:16:51 -0700, chine.bleu wrote:

I prefer the visibility of ?: to the implicitness of || &&

Ada has separate operators which explicitly do shortcut evaluation
(“and then”, “or else”) versus ones which don’t (“and”, “or”).
--- Synchronet 3.22a-Linux NewsLink 1.2