What will happen to "1 << (-1)" in G++?

[Mr. Ken]

Left shift by negative numbers, will I get 1/2?

Thanks.

 

[Robert J. Hansen]

Left shift by negative numbers, will I get 1/2?

Why not try it for yourself? The great virtue of computer science is
that in many ways it's an experimental discipline, not a purely
theoretical one.

 

[Heinz Ozwirk]

Left shift by negative numbers, will I get 1/2?

The result of a shift expression is undefined if its right operand is
negative or greater than or equal to the number of bits used to represent
its left operand.

Heinz

 

[Mr. Ken]

The result of a shift expression is undefined if its right operand is
negative or greater than or equal to the number of bits used to represent
its left operand.

Heinz

Thank you.

 

[Mr. Ken]

Why not try it for yourself? The great virtue of computer science is
that in many ways it's an experimental discipline, not a purely
theoretical one.

I received code from other people, but it has the probability of 1 << (-1)..
that's why I asked.

 

[Nick Keighley]

Why not try it for yourself? The great virtue of computer science is
that in many ways it's an experimental discipline, not a purely
theoretical one.

this is Really Bad Advice. I you want t to know what a language
construct
is supposed to do then check out a reference. The language standard
itself
is often the best. If you distrust your implementation you may want to
run
a test to verify that your implementation is conforming.

Since "1 << (-1)" has undefined behaviour no amount of empirical
testing
will tell you anything. This weeks test may be invalidated next week by
a
change of platform, compiler version or optimisation settings. In
principal
an implementation could be even worse than that. It may depend on some
obscurity in the hardware.


--
Nick Keighley

Egon: Try to imagine all life as you know it stopping instantaneously
and
every molecule in your body exploding at the speed of light.
Ray: Total protonic reversal....
[DS9000K: Behaviour of Negative Shift]

 

[=?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?=]

Why not try it for yourself? The great virtue of computer science is
that in many ways it's an experimental discipline, not a purely
theoretical one.

Sometimes a bad advice.
You then draw conclution based up on your particular
environment.
That's especially bad if you assume how things work when you perform
(unknowingly) undefined behavior.

 

[Kaz Kylheku]

Left shift by negative numbers, will I get 1/2?

Lame troll.

 

[Robert J. Hansen]

Why not try it for yourself? The great virtue of computer science is

this is Really Bad Advice.

It is really _good_ advice, given that he specifically asked a question
tied to a specific implementation. If he wants to know what happens in
G++ when this is done, the best way is to try it for yourself. It's
not as if the compiler costs a lot of money to download.

 

[Robert J. Hansen]

Sometimes a bad advice.

Yes. If he were to be asking "according to the Standard, what happens
when...?", then I would have given him an answer citing the Standard.

But if you're going to ask compiler-specific questions, then "try it
yourself and see" is perfectly reasonable advice. Especially when the
real answer is "it's undefined and the compiler can do anything, and so
the only answer to this question of 'what will G++ do with this?' is
'give it to G++ and see'."

 

[Clark S. Cox III]

Yes. If he were to be asking "according to the Standard, what happens
when...?", then I would have given him an answer citing the Standard.

But if you're going to ask compiler-specific questions, then "try it
yourself and see" is perfectly reasonable advice. Especially when the
real answer is "it's undefined and the compiler can do anything, and so
the only answer to this question of 'what will G++ do with this?' is
'give it to G++ and see'."

Except that G++ could do it differently each and every time you run the
program.

 

[Robert J. Hansen]

Except that G++ could do it differently each and every time you run the
program.

Yes, it could. And if you try it a few times, you'll discover if it
does.

I do not understand this hostility towards discovering how your
compiler handles one particular kind of undefined behavior.

 

[Clark S. Cox III]

Yes, it could. And if you try it a few times, you'll discover if it
does.

You *still* won't know for sure. It could be the same 20 times in a row,
and then be different on the 21st.

I have personally seen all of the following:
- Undefined behavior that works one way on the development machine, the
production build machine, and several test machines; only to work in a
completely different way on a customer's machine.

- Undefined behavior that works one way with one build of the compiler,
and a different way with the next build.

- Undefined behavior that works one way with one optimization level, and
a different way with another.

I do not understand this hostility towards discovering how your
compiler handles one particular kind of undefined behavior.

Because finding that out provides you with a false sense of security,
and encourages people to write code that makes unwarranted assumptions.

 

[Robert J. Hansen]

You *still* won't know for sure. It could be the same 20 times in a row,

and then be different on the 21st.

Then you know it's not "each and every".

I have personally seen all of the following:

So have I.

Because finding that out provides you with a false sense of security,
and encourages people to write code that makes unwarranted assumptions.

It only encourages a false sense of security if you're dumb enough to
feel secure in undefined behavior. On the other hand, knowing that
"every time I've done this particular bit of undefined behavior in the
past, the results have been like this" is an incredible help in
debugging when you see that exact same pattern of behavior. It's not a
deterministic help, no, but it's an effective heuristic.

If you let the fear of a false sense of security prevent you from
learning how your compiler handles undefined behavior, you have
needlessly and pointlessly crippled yourself.

 

[Kaz Kylheku]

Yes, it could. And if you try it a few times, you'll discover if it
does.

If you try something on your compiler, you might also find that it
works the same way every time and appears to produce the expected
behavior.

If you know that the behavior is undefined, and you still require this
type of experimentation to convince yourself of something, it suggests
that you don't understand what it means for behavior to be undefined.

 

[Robert J. Hansen]

If you know that the behavior is undefined, and you still require this

type of experimentation to convince yourself of something, it suggests
that you don't understand what it means for behavior to be undefined.

There's nothing of which I need convincing with respect to undefined
behavior. Anyone who relies on undefined behavior is living in sin.

However, it's a simple fact that failures happen. Failures happen
_lots_. They happen when you write code and they happen when other
people write code which is then dumped in your lap. Understanding how
your compiler acts when pushed out of spec is valuable knowledge in
debugging. Understanding what the symptoms are (or "may be", since
undefined behavior is not required to be reproducible) is a good way to
equip yourself for spotting problems in the future.

As an example, while I would certainly never want to work with a
programmer who deliberately wrote off the end of arrays, I would
certainly never want to work with a programmer who had no idea what
problems a buffer overflow could create, or the symptoms of those
problems.

 

[Nick Keighley]

It is really _good_ advice, given that he specifically asked a question
tied to a specific implementation. If he wants to know what happens in
G++ when this is done, the best way is to try it for yourself. It's
not as if the compiler costs a lot of money to download.

this is comp.lang.c++. They don't discuss particular implementations.
Even if the question is confined to G++, my points (which you snipped)
about different versions of the compiler or optimisation levels still
apply. Undefined behaviour is, by definition, undefined.

 

[Gavin Deane]

Then you know it's not "each and every".

You don't know that if you only try it once or twice.

It only encourages a false sense of security if you're dumb enough to
feel secure in undefined behavior.

Or if you don't realise that the behaviour is undefined.

On the other hand, knowing that
"every time I've done this particular bit of undefined behavior in the
past, the results have been like this" is an incredible help in
debugging when you see that exact same pattern of behavior. It's not a
deterministic help, no, but it's an effective heuristic.

Absolutely true, if, and only if, you know beforehand that the
behaviour is undefined.

Knowing that "every time I've done this particular bit of code, the
results have been like this" is at best incredibly unhelpful and at
worst dangerous in debugging when you see a different pattern of
behaviour if you aren't pre-armed with the knowledge that "this
particular bit of code" has undefined behaviour.

To me, and I suspect to other respondants in this thread, it looked
like the OP was at risk of relying on some undefined behaviour because
he did not realise the behaviour of his code was undefined.

Gavin Deane