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

[Mr. Ken]

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

Thanks.

[Robert J. Hansen]

Clark S. Cox III wrote:

'give it to G++ and see'."

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]

Robert J. Hansen wrote:

Clark S. Cox III wrote:

>>'give it to G++ and see'."

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.

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.

--
Clark S. Cox III
cl*******@gmail .com

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

Robert J. Hansen wrote:

Clark S. Cox III wrote:

'give it to G++ and see'."

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.

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]

Robert J. Hansen wrote:

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.

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.
--
Nick Keighley

[Gavin Deane]

Robert J. Hansen wrote:

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".

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

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.

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