NotPaidToPost

I was obviously not writing about poverty but about our impact on the planet and the environment...

11B from 7B is a 60% increase... But that's the usual sterile nitpicking. Do you want to argue about decimal points or address the actual point?

The important point is that this is a large increase when we already cannot manage now.

This is one of the major cause of the destruction of the environment we're seeing globally.

All forecasts predict another 60% (!!) increase in global population before it stabilises.

Forget about banning plastic straws or flying less (which are feel-good measures more than anything else) with such numbers... We need to take dramatic and effective steps.

There are 80 years left until the end of the century. This increase is far from being inevitable! But, again, we prefer to ignore these key issues and focus on marginal, feel-good measures instead.

> Politically, the timing of the crisis works quite well for the nationalist Tsai,

Err... Tsai is not in the 'nationalist' camp (KMT), she is from the DPP (Pan-Green coalition).

The rest of the article on Taiwan history is equally poor and confusing.

Why would the UN have a stance on this?

It's been hugely magnified the media, but it is no more than a government bringing a bill forward and people demonstrating against it.

This often happens in most Western countries and no-one asks the UN what they think about it.

Perhaps time to put things into perspective.

“The green reed which bends in the wind is stronger than the mighty oak which breaks in a storm.”

― Confucius

> But why limit it to 2^ and 10^ and not say literal^literal should always produce a warning?

You're suggesting that using the C language as specified and intended should produce a warning... That makes no sense.

It's not for you or the compiler to decide that 2^32 makes no sense. It is using ^ exactly as intended and is neither misleading nor ambiguous.

Stating that 32^2 should not trigger a warning while 2^32 should shows that this proposal has not been thought through.

It's not desirable or sensible to raise a warning on the premise that the expression might mean something else in another language, which is what this would do.

How do you do that?

The preprocessor does macro expansion, the compiler compiles the result.

The compiler does not see FLAG_BIT1 ^ FLAG_BIT3, it only sees the result, e.g. 2^32.

Therefore to catch only explicit 2^32 the warning should come from the preprocessor... Nice mess created right there.

'If' expects a condition so finding an assignment may be a red flag even if an assignment has a return value in the spec, which makes the construct valid.

On the other hand ^ expects integers so 2^32 is exactly what is expected.

Most the replies I saw here try to second-guess or claim that ^ should be used in a specific way. Not so, ^ is just doing XOR of two integers.

Apparently, I am having an incorrect opinion, though, so I will self-censor and remain silent.

> It's a warning not an error.

Many build environments are set to treat all warnings as errors.

The point is that 2^32 is a perfectly compliant C expression that is neither misleading nor ambiguous, and that also won't create any variable overflow. It uses ^ exactly as intended. Why should the compiler complain? Why should I get a warning/error when following the spec to the letter?

I don't think it would not be simple or a good idea to warn because these are perfectly valid expressions and it would lead to a flood of warnings if compilers started to display "Did you really mean that?" for an ever growing list of expressions (which is what it would become).

Better to leave this to code analysis tools.

Edit:

2^32 uses the ^ operator exactly as intended, and has perfectly legitimate uses, especially when dealing with registers of HW peripherals.

It's not the same as warning on "if (a=b)" as someone replied.

From a language perspective, 2^32 is exactly the same as 2+32.

The point of many of these cycle lanes is not to be useful to cyclists but to be useful to the council's PR.