Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #83749
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Newsgroups | comp.lang.c++ |
| Subject | Re: getline() problem |
| Date | 2022-04-25 11:03 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <t46np1$5uj$1@dont-email.me> (permalink) |
| References | (3 earlier) <t41er4$35r34$1@portraits.wsisiz.edu.pl> <t41hkn$6p9$1@dont-email.me> <t45de2$1sln$2@gioia.aioe.org> <t46f86$or8$1@dont-email.me> <Kwz9K.23424$x9Ea.11744@fx45.iad> |
On 4/25/2022 8:56 AM, Scott Lurndal wrote: >> >> As a general rule, you should not write data to a text stream if it >> contains any feature invalidating that guarantee, and you should not >> read data from a text stream if it contains any of those things. > > As a general rule, your general rule only applies to Windows. On Unix > and Unix-like systems, there is no functional difference between text > and binary. That's catastrophically incorrect on more than one level. This is the same fallacy that is often used by numerous "UB deniers", claiming that on their hardware/OS platform some forms of "undefined behavior" are supposedly "perfectly defined" because they know how their platform/hardware/OS will react in some specific situation. They just can't grasp this little bit of understanding that the primary source of "undefined" in undefined behavior in _not_ their hardware/OS. 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. It doesn't even get to the hardware/OS level. Hardware/OS matter very little. The same reasoning can be applied to the matter of binary vs. text streams. For example, the very moment the abstract specification of text stream will provide optimization opportunities (or any other benefits) to the implementation of C or C++ standard library, this implementation might/will take advantage of these opportunities to make text streams work more efficiently than binary streams (within the spec, of course). It will break text vs. binary compatibility and it will do this with complete disregard to the fact that the underlying OS makes no difference between text and binary. I'm exaggerating, of course, because it something like this ever happens to Unix-like I/O, the raging uproar the affected parties will be deafening. (We've heard it before with strict aliasing, strict overflow, `memcpy` that copies backwards etc.) Nobody will dare to break binary-text equivalence of Unix-like systems (and POSIX won't allow this). But in essence... this is just a wall of entrenched incompetence too high to climb over. -- Best regards, Andrey Tarasevich
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