Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #83785
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c++ |
| Subject | Re: getline() problem |
| Date | 2022-04-26 15:52 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <t48tea$e4a$1@dont-email.me> (permalink) |
| References | (7 earlier) <Kwz9K.23424$x9Ea.11744@fx45.iad> <t46np1$5uj$1@dont-email.me> <t480p6$1gdc$1@gioia.aioe.org> <t487du$7ps$1@dont-email.me> <t48de1$11f9$1@gioia.aioe.org> |
On 26/04/2022 11:18, Juha Nieminen wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> UB "takes precedence" over /everything/ - it basically says there are no
>> guarantees of anything.
>
> The more I think about it, the more ridiculous that becomes.
>
> If the compiler is allowed to do *anything* it wants when it encounters
> Undefined Behavior, doesn't that mean that it can, for example, compile
> the entire program into a single "main() { return 0; }"?
Yes.
But an implementation that does that is unlikely to be very popular!
>
> Imagine a million-line program where the compiler finds one single
> extremely obscure and mostly innocuous case of UB (eg. overflowing
> of a signed integer), and that allows it to optimize the *entire program*
> away, into a literal on-liner that does absolutely nothing?
>
> After all, if there are no guarantees of *anything*, and the compiler can
> do whatever it wants, optimizing the entire program away is "whatever the
> compiler wants", and part of "no guarantees of anything".
>
> Nobody would use such a compiler. There has to be *some* limits to what
> the compiler is allowed to do even if it encounters some very minor and
> innocuous "technically speaking, if we take the absolute strict letter
> of the standard, this is undefined behavior".
>
> (Even if there's some kind of caveat like "the undefined behavior can
> only happen if that particular piece of code is executed", it's perfectly
> possible for the minor UB (eg. signed integer overflow) to happen at
> the beginning of main(), after which "nothing is guaranteed". Meaning
> that the compiler could just optimize the entire rest of the million-line
> program into a single "return 0;" Nobody would use such a compiler.)
(You can have code in your program that, if executed, would have UB.
The problem only comes when trying to execute it.)
I think you are - as many people seem to do when thinking about UB -
taking your concerns to the extremes.
In the programming world, there is the phrase "garbage in, garbage out"
- that's all this is, nothing more. It's not new or special (Charles
Babbage wrote about the concept in regard to his mechanical difference
engine). Programming is about taking a specification, and writing code
that implements the specification.
If I say "write a function "int_square_root" that takes an int between 0
and 1000 and returns its square root, rounded down", then you can write
code that does that. What should I expect of the code if I call it with
an argument of 1001? Or -1? I have /no/ expectations, and you give me
/no/ guarantees. Maybe the function won't return. Maybe it will crash.
Maybe it will give a "reasonable" result. Who knows?
A compiler is a program with the specification "given an input that is
valid source code conforming to the standards, generate object code that
implements the input program". If your code tries to execute undefined
behaviour, you are asking the compiler for something outside its
specifications. You are asking for the integer that is the square root
of -1. You are asking for the object code for source code that does not
make sense according to the language definitions. The compiler can't
give you an answer, because there is no answer.
Maybe the compiler can make some guesses, or give you helpful feedback,
or skip that bit and carry on. But there is no way the compiler can
give you a /correct/ answer, and the standards abdicate any guarantees
on the matter.
A compiler that spots inevitable UB and generates an empty program might
be correct, but it is unlikely to be popular. One that gives an error
message during compilation would more helpful to most people. Because
the standards give no definition, compilers are free to do as they want
here - such as generate run-time errors to aid debugging. (Contrast
this with languages like Java that attempt to eliminate UB - common
errors such as integer overflow are defined behaviour and the compiler
must do what the language standards require, rather than helping the
programmer find the bugs.) Equally, the compiler can assume states that
lead to UB cannot occur if that aids optimisation, and at no point do
you get any guarantee about what might happen because the compiler
cannot promise to give you the result you expect from what is
essentially meaningless code.
Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
getline() problem Jivanmukta <jivanmukta@poczta.onet.pl> - 2022-04-23 19:07 +0200
Re: getline() problem Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-23 10:17 -0700
Re: getline() problem Jivanmukta <jivanmukta@poczta.onet.pl> - 2022-04-23 19:40 +0200
Re: getline() problem Jivanmukta <jivanmukta@poczta.onet.pl> - 2022-04-23 19:59 +0200
Re: getline() problem Paavo Helde <eesnimi@osa.pri.ee> - 2022-04-23 21:47 +0300
Re: getline() problem Juha Nieminen <nospam@thanks.invalid> - 2022-04-25 06:00 +0000
Re: getline() problem Öö Tiib <ootiib@hot.ee> - 2022-04-25 00:12 -0700
Re: getline() problem Paavo Helde <eesnimi@osa.pri.ee> - 2022-04-25 11:40 +0300
Re: getline() problem James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-25 11:37 -0400
Re: getline() problem Vir Campestris <vir.campestris@invalid.invalid> - 2022-04-25 16:54 +0100
Re: getline() problem James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-25 12:29 -0400
Re: getline() problem scott@slp53.sl.home (Scott Lurndal) - 2022-04-25 17:29 +0000
Re: getline() problem Manfred <noname@add.invalid> - 2022-04-25 20:17 +0200
Re: getline() problem Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-04-25 10:19 -0700
Re: getline() problem Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-25 10:41 -0700
Re: getline() problem Paavo Helde <eesnimi@osa.pri.ee> - 2022-04-25 21:58 +0300
Re: getline() problem scott@slp53.sl.home (Scott Lurndal) - 2022-04-25 15:56 +0000
Re: getline() problem James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-25 13:12 -0400
Re: getline() problem Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-25 11:03 -0700
Re: getline() problem scott@slp53.sl.home (Scott Lurndal) - 2022-04-25 19:05 +0000
Re: getline() problem Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-25 12:48 -0700
Re: getline() problem Ben <ben.usenet@bsb.me.uk> - 2022-04-25 21:46 +0100
Re: getline() problem Juha Nieminen <nospam@thanks.invalid> - 2022-04-26 05:43 +0000
Re: getline() problem David Brown <david.brown@hesbynett.no> - 2022-04-26 09:36 +0200
Re: getline() problem Juha Nieminen <nospam@thanks.invalid> - 2022-04-26 09:18 +0000
Re: getline() problem Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-26 02:47 -0700
Re: getline() problem Juha Nieminen <nospam@thanks.invalid> - 2022-04-26 11:06 +0000
Re: getline() problem David Brown <david.brown@hesbynett.no> - 2022-04-26 15:52 +0200
Re: getline() problem Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-26 07:04 -0700
Re: getline() problem Manfred <noname@add.invalid> - 2022-04-26 16:49 +0200
Re: getline() problem James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-26 12:01 -0400
Re: getline() problem James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-26 11:49 -0400
Re: getline() problem Manfred <noname@add.invalid> - 2022-04-25 20:23 +0200
Re: getline() problem Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-25 10:33 -0700
Re: getline() problem "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2022-04-25 10:52 -0700
Re: getline() problem Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-25 11:08 -0700
Re: getline() problem "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2022-04-25 21:18 -0700
Re: getline() problem Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-25 22:04 -0700
Re: getline() problem Paavo Helde <eesnimi@osa.pri.ee> - 2022-04-25 22:06 +0300
Re: getline() problem Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-25 13:02 -0700
Re: getline() problem Barry Schwarz <schwarzb@delq.com> - 2022-04-23 12:54 -0700
Re: getline() problem Montmorency <none@none.com> - 2022-04-23 14:45 -0700
Re: getline() problem Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-23 16:49 -0700
Re: getline() problem Ben <ben.usenet@bsb.me.uk> - 2022-04-24 01:04 +0100
Re: getline() problem Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-04-23 18:24 -0700
Re: getline() problem Ben <ben.usenet@bsb.me.uk> - 2022-04-24 03:16 +0100
Re: getline() problem Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-24 22:51 -0700
Re: getline() problem Ben <ben.usenet@bsb.me.uk> - 2022-04-25 11:07 +0100
Re: getline() problem Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-23 17:15 -0700
Re: getline() problem Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-23 18:23 -0700
Re: getline() problem Jivanmukta <jivanmukta@poczta.onet.pl> - 2022-04-24 05:28 +0200
Re: getline() problem Jivanmukta <jivanmukta@poczta.onet.pl> - 2022-04-25 12:41 +0200
Re: getline() problem Paavo Helde <eesnimi@osa.pri.ee> - 2022-04-25 14:33 +0300
Re: getline() problem Jivanmukta <jivanmukta@poczta.onet.pl> - 2022-04-25 18:53 +0200
Re: getline() problem Paavo Helde <eesnimi@osa.pri.ee> - 2022-04-25 22:08 +0300
Re: getline() problem Jivanmukta <jivanmukta@poczta.onet.pl> - 2022-04-26 09:01 +0200
Re: getline() problem Paavo Helde <eesnimi@osa.pri.ee> - 2022-04-26 11:15 +0300
csiph-web