Re: getline() problem

From	David Brown <david.brown@hesbynett.no>
Newsgroups	comp.lang.c++
Subject	Re: getline() problem
Date	2022-04-26 09:36 +0200
Organization	A noiseless patient Spider
Message-ID	<t487du$7ps$1@dont-email.me> (permalink)
References	(5 earlier) <t45de2$1sln$2@gioia.aioe.org> <t46f86$or8$1@dont-email.me> <Kwz9K.23424$x9Ea.11744@fx45.iad> <t46np1$5uj$1@dont-email.me> <t480p6$1gdc$1@gioia.aioe.org>

Show all headers | View raw

On 26/04/2022 07:43, Juha Nieminen wrote:
> Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>> It is the abstract language semantics implemented by the compiler. The
>> compiler that actively uses UB as an optimization opportunity at a
>> rather abstract level.
> 
> By the way, doesn't this break the rule that optimizations must not change
> the observable behavior of the program (other than by its execution time)?
> 
> (Granted, I haven't actually checked that the standard actually mandates
> that "optimizations must not change observable behavior". I'm not sure
> where I have got that idea from. I would assume that the standard does
> require this, in one form of another. Or does UB "take precedence" over
> that requirement, making it void?)

UB "takes precedence" over /everything/ - it basically says there are no 
guarantees of anything.  There was an attempt to distinguish between 
"bounded" and "unbounded" undefined behaviour in C (Annex L in the C11 
standards), but AFAIK no one implemented any of it.  The trouble is, 
even "bounded" undefined behaviour can quickly cause unbounded knock-on 
effects.  A relatively innocent-seeming arithmetic overflow might result 
in an incorrect pointer, which then results in a write to a completely 
unexpected part of the memory, and running unexpected code (imagine that 
a function pointer got stomped on).  You can easily see how this could 
affect the observable behaviour - perhaps the address written was a 
volatile variable.  You can see how it could affect even previous 
observable behaviour - your code may have written to a file, then run 
riot after UB and entered code that deleted the file, affecting 
historical observable behaviour before it even hit the disk surface.

Obviously one can hope that the worst consequences of UB are the least 
likely to happen, but the implementation can't rule out anything (unless 
it specifically adds features to turn UB into defined behaviour - such 
as gcc -fwrapv, or sanitizers, etc.)  The standards basically refuse to 
accept any responsibility for what might happen.

Trying to put strict limits on UB, or even to guarantee that past 
observable behaviour is still valid after the UB is executed, requires 
locking down the run-time environment significantly.  You need a virtual 
machine with strict limitations, or dedicated hardware (clearly things 
like memory protection units, fault traps, etc., go a long way towards 
this in practice - but not all C and C++ targets have these).  If you 
want a managed language or managed runtime environment, there are many 
available - C and C++ are aimed for maximal efficiency, not maximal 
safety.  ("With great power comes great responsibility", for the 
superhero fans.)

That doesn't mean that an implementation should not try to limit the 
consequences of executing UB, but it /does/ mean that it is not obliged 
to do so by the standards and can pick a balance between improving the 
efficiency of correct code verses being as helpful as possible to the 
developer in the face of incorrect code.

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