Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #103912 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2017-02-14 15:37 -0800 |
| Last post | 2017-04-26 09:58 -0700 |
| Articles | 20 on this page of 147 — 26 participants |
Back to article view | Back to comp.lang.c
What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-14 15:37 -0800
Re: What if pre-processor was moved to parser? fir <profesor.fir@gmail.com> - 2017-02-15 00:05 -0800
Re: What if pre-processor was moved to parser? fir <profesor.fir@gmail.com> - 2017-02-15 00:57 -0800
Re: What if pre-processor was moved to parser? fir <profesor.fir@gmail.com> - 2017-02-15 07:21 -0800
Re: What if pre-processor was moved to parser? fir <profesor.fir@gmail.com> - 2017-02-15 07:24 -0800
Re: What if pre-processor was moved to parser? fir <profesor.fir@gmail.com> - 2017-02-15 08:10 -0800
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 03:05 -0800
Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-15 11:38 +0000
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 04:28 -0800
Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-15 13:22 +0000
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 05:47 -0800
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 10:06 -0800
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 05:24 -0800
Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-15 13:57 +0000
Re: What if pre-processor was moved to parser? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-19 10:27 -0800
Re: What if pre-processor was moved to parser? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-15 15:16 +0000
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 08:14 -0800
Re: What if pre-processor was moved to parser? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-15 18:01 +0000
Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-15 18:25 +0000
Re: What if pre-processor was moved to parser? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-15 19:14 +0000
Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-15 10:25 -0800
Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-15 18:45 +0000
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-15 20:03 +0100
Re: What if pre-processor was moved to parser? jameskuyper@verizon.net - 2017-02-15 10:12 -0800
Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-15 10:51 -0800
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 12:14 -0800
Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-15 20:25 +0000
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 12:50 -0800
Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-16 11:50 +0000
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-16 04:44 -0800
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-16 05:28 -0800
Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-16 14:32 +0000
Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-16 09:13 -0800
Re: What if pre-processor was moved to parser? Keith Thompson <kst-u@mib.org> - 2017-02-16 10:38 -0800
Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-16 11:55 -0800
Re: What if pre-processor was moved to parser? Keith Thompson <kst-u@mib.org> - 2017-02-16 12:24 -0800
Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-02-16 21:32 +0100
Re: What if pre-processor was moved to parser? Keith Thompson <kst-u@mib.org> - 2017-02-16 12:55 -0800
Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-02-16 22:41 +0100
Re: What if pre-processor was moved to parser? Keith Thompson <kst-u@mib.org> - 2017-02-16 14:02 -0800
Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-16 15:08 -0800
Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-16 13:32 -0800
Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-17 21:19 +1300
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-17 12:01 +0100
Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-17 09:16 -0800
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-17 18:55 +0100
Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-18 08:07 +1300
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-17 20:12 +0100
Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-18 11:04 +1300
Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-17 22:38 +0000
Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-18 11:47 +1300
Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-17 14:55 -0800
Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-18 12:11 +1300
Re: What if pre-processor was moved to parser? "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-02-17 15:26 -0800
Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-17 16:15 -0800
Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-18 13:22 +1300
Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-17 16:37 -0800
Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-02-18 11:57 +0100
Re: What if pre-processor was moved to parser? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-18 07:13 +0000
Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-18 20:26 +1300
Re: What if pre-processor was moved to parser? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-18 09:17 +0000
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-18 01:18 +0100
Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-18 13:23 +1300
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-18 01:45 +0100
Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-18 16:18 +1300
Re: What if pre-processor was moved to parser? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-18 07:19 +0000
Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-18 20:30 +1300
Re: What if pre-processor was moved to parser? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-18 09:18 +0000
Re: What if pre-processor was moved to parser? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-18 07:15 -0800
Re: What if pre-processor was moved to parser? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-24 09:24 -0800
Re: What if pre-processor was moved to parser? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-24 17:51 +0000
Re: What if pre-processor was moved to parser? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-24 10:08 -0700
Re: What if pre-processor was moved to parser? Richard Heathfield <rjh@cpax.org.uk> - 2017-04-24 18:58 +0100
Re: What if pre-processor was moved to parser? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-04-26 05:03 +0000
Re: What if pre-processor was moved to parser? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 11:21 -0700
Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-25 09:15 +1300
Re: What if pre-processor was moved to parser? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-24 17:29 -0800
Re: What if pre-processor was moved to parser? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-26 06:19 -0700
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-26 16:04 +0200
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-04-26 07:08 -0700
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-26 16:46 +0200
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-04-26 09:32 -0700
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-26 20:19 +0200
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-04-26 11:29 -0700
Re: What if pre-processor was moved to parser? scott@slp53.sl.home (Scott Lurndal) - 2017-04-26 18:51 +0000
Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-04-27 09:32 +1200
Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-04-27 11:01 +0200
Re: What if pre-processor was moved to parser? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-04-27 02:23 -0700
Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-04-27 21:31 +1200
Re: What if pre-processor was moved to parser? Ike Naar <ike@iceland.freeshell.org> - 2017-04-27 16:15 +0000
Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-04-27 09:35 -0700
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-28 15:12 +0200
Re: What if pre-processor was moved to parser? Gareth Owen <gwowen@gmail.com> - 2017-04-27 19:13 +0100
Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-04-27 11:37 +0200
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-27 15:18 +0200
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-18 08:43 +0100
Re: What if pre-processor was moved to parser? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-18 09:22 +0000
Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-18 09:44 -0800
Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-18 11:33 +0000
Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-02-18 13:25 +0100
Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-18 13:47 +0000
Re: What if pre-processor was moved to parser? Jean-Marc Bourguet <jm@bourguet.org> - 2017-02-18 15:23 +0100
Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-18 14:53 +0000
Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-18 16:56 +0000
Re: What if pre-processor was moved to parser? Robert Wessel <robertwessel2@yahoo.com> - 2017-02-18 22:50 -0600
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-19 09:45 +0100
Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-02-19 13:35 +0100
Re: What if pre-processor was moved to parser? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-18 11:24 -0500
Re: What if pre-processor was moved to parser? Robert Wessel <robertwessel2@yahoo.com> - 2017-02-18 22:48 -0600
Re: What if pre-processor was moved to parser? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-18 10:04 -0800
Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-02-19 17:12 +0100
Re: What if pre-processor was moved to parser? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-19 11:11 -0800
Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-02-19 21:14 +0100
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-19 21:22 +0100
Re: What if pre-processor was moved to parser? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-19 12:33 -0800
Re: What if pre-processor was moved to parser? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-19 12:31 -0800
Re: What if pre-processor was moved to parser? fir <profesor.fir@gmail.com> - 2017-02-19 13:14 -0800
Re: What if pre-processor was moved to parser? fir <profesor.fir@gmail.com> - 2017-02-19 14:50 -0800
Re: What if pre-processor was moved to parser? fir <profesor.fir@gmail.com> - 2017-02-19 15:04 -0800
Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-02-20 10:13 +0100
Re: What if pre-processor was moved to parser? Gareth Owen <gwowen@gmail.com> - 2017-02-19 21:09 +0000
Re: What if pre-processor was moved to parser? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-23 15:32 -0800
Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-24 12:44 +1300
Re: What if pre-processor was moved to parser? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-19 21:04 -0800
Re: What if pre-processor was moved to parser? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-19 21:14 -0800
Re: What if pre-processor was moved to parser? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-02-16 14:48 -0800
Re: What if pre-processor was moved to parser? Keith Thompson <kst-u@mib.org> - 2017-02-16 15:46 -0800
Re: What if pre-processor was moved to parser? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-23 16:16 -0800
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-20 04:18 -0800
Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-20 06:47 -0800
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-20 09:50 -0800
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-21 04:33 -0800
Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-21 15:41 +0100
Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-21 09:39 -0800
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-21 09:59 -0800
Re: What if pre-processor was moved to parser? TickleMe Elmo <tmelmosfire@gmail.com> - 2017-02-21 10:22 -0800
Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-20 15:49 +0000
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-20 09:43 -0800
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 12:31 -0800
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-16 03:33 -0800
Re: What if pre-processor was moved to parser? jameskuyper@verizon.net - 2017-02-15 12:47 -0800
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 13:06 -0800
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 13:15 -0800
Re: What if pre-processor was moved to parser? "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-02-18 12:36 +0100
Re: What if pre-processor was moved to parser? "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-02-18 12:41 +0100
Re: What if pre-processor was moved to parser? John Bode <jfbode1029@gmail.com> - 2017-04-26 09:42 -0700
Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-04-26 09:58 -0700
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-16 15:08 -0800 |
| Message-ID | <c91d3f82-d1e7-4e85-b79f-077018297c10@googlegroups.com> |
| In reply to | #104040 |
On Thursday, February 16, 2017 at 3:41:32 PM UTC-6, David Brown wrote:
> On 16/02/17 21:55, Keith Thompson wrote:
> Supercat said that it "requires [that it] yields UB", which I
> interpreted as him thinking the compiler /had/ to leave the behaviour
> here without definition. It is not defined by the C Standards, but
> there is no requirement for an implementation to leave it without a
> definition.
I got two related concepts tangled up:
1. Once a union member has been accessed, access to any other member
"requires" that it first be constructed with placement new.
2. Once a union member has been accessed, access to any other member
without first be constructing the latter with placement new "yields
UB".
From what I can tell, unions only exist in C++ for the purpose of allowing
C++ to interact with C code that uses such types. C needs to allow for the
possibility that code will reuse storage without using something like a
placement new to let the compiler know, because C doesn't *have* anything
like a placement new that code *could* use to let the compiler know storage
will be reused.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-16 13:32 -0800 |
| Message-ID | <441a3035-55ea-41e6-a140-2030367ba799@googlegroups.com> |
| In reply to | #104033 |
On Thursday, February 16, 2017 at 2:32:48 PM UTC-6, David Brown wrote: > Regarding access to POD members with no constructors or destructors, C++ > treats unions mostly like C89 - if you have a union of a float and an > int, and assign to the float, you are not allowed to read out the > representation as the int. (In C89, this is implementation-defined > behaviour - in C++, it is not discussed and therefore undefined.) This > is hardly surprising, since C++ effectively forked from C89, and the > "type punning" feature of unions was not standardised until C99. Type punning, whether via pointers or unions, is crucial in some kinds of programming, but not needed at all in others. Further, the cost of supporting it can be much larger on some platforms than others (e.g. on systems with separate floating-point and integer pipes, support for type punning may necessitate code that forces one pipeline to stall while waiting for an action on the other to complete). Consequently, what behaviors would be reasonable for an implementation will depend upon the target platform and application field. > However, the reason "type punning" via unions was standardised in C99 is > that compilers already implemented it and people relied upon it. I > suspect you will find that any C++ compiler will support type punning > via unions, at least when constructors and destructors are not involved > - if you use type punning to gain access to an invalid object, that will > be UB. Certainly C++ does not /require/ that such type punning is UB. A guiding principle behind C89 seems to have been that if some implementations define a behavior for some actions but others might benefit from not having to do so, then absent some reason to change the status quo, the actions should be deemed to invoke Undefined Behavior. I see no evidence that the authors of C89 were intending that C89 be regarded as exhaustively describing all the guarantees that any programmer would ever be entitled to expect even when using implementations that were supposed to be suitable for things like system programming. I think most compiler writers in the 1990s understood that. Neither the C Standard nor the C++ Standard requires compilers to generate bogus code in cases where an implementation that processed things according to a precise load-store model would yield a predictable result, but since the C++ Standard was written to describe a new language rather than an existing one, the concept of "Undefined Behavior" used to be viewed a bit differently from how it used to be viewed in C.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-02-17 21:19 +1300 |
| Message-ID | <egnq1dFht9oU2@mid.individual.net> |
| In reply to | #104039 |
On 02/17/17 10:32 AM, supercat@casperkitty.com wrote: > On Thursday, February 16, 2017 at 2:32:48 PM UTC-6, David Brown wrote: >> Regarding access to POD members with no constructors or destructors, C++ >> treats unions mostly like C89 - if you have a union of a float and an >> int, and assign to the float, you are not allowed to read out the >> representation as the int. (In C89, this is implementation-defined >> behaviour - in C++, it is not discussed and therefore undefined.) This >> is hardly surprising, since C++ effectively forked from C89, and the >> "type punning" feature of unions was not standardised until C99. > > Type punning, whether via pointers or unions, is crucial in some kinds of > programming, but not needed at all in others. One reason C++ is gaining std::variant (a type-safe union). -- Ian
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-02-17 12:01 +0100 |
| Message-ID | <20170217120120.b9bbf85eda05d8bda121396a@gmail.com> |
| In reply to | #104055 |
On Fri, 17 Feb 2017 21:19:56 +1300 Ian Collins <ian-news@hotmail.com> wrote: > On 02/17/17 10:32 AM, supercat@casperkitty.com wrote: > > On Thursday, February 16, 2017 at 2:32:48 PM UTC-6, David Brown wrote: > >> Regarding access to POD members with no constructors or destructors, C++ > >> treats unions mostly like C89 - if you have a union of a float and an > >> int, and assign to the float, you are not allowed to read out the > >> representation as the int. (In C89, this is implementation-defined > >> behaviour - in C++, it is not discussed and therefore undefined.) This > >> is hardly surprising, since C++ effectively forked from C89, and the > >> "type punning" feature of unions was not standardised until C99. > > > > Type punning, whether via pointers or unions, is crucial in some kinds of > > programming, but not needed at all in others. > > One reason C++ is gaining std::variant (a type-safe union). > > -- > Ian Nothing is safe from bad programmers... In the new technology field too many people believe "new" means "better" because they don't understand how it works. I consider C++ (and C11 too with annex K) as a regression since it postulates the programmer is stupid.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-17 09:16 -0800 |
| Message-ID | <9b2a8f26-3904-4b39-a37b-9e20d5c174f4@googlegroups.com> |
| In reply to | #104059 |
On Friday, February 17, 2017 at 5:03:17 AM UTC-6, GOTHIER Nathan wrote:
> Nothing is safe from bad programmers... In the new technology field too many
> people believe "new" means "better" because they don't understand how it works.
> I consider C++ (and C11 too with annex K) as a regression since it postulates
> the programmer is stupid.
I question the value of taking badly designed library functions like
strncat and define bounds-checked versions which retain the original
problems, rather than providing well-designed bounds-checked versions.
I also think that in many cases a model where functions behave safely
[e.g. clipping an over-length string] but set a latching error flag
would likely be more amenable to optimization than one which uses
error handlers. A compiler given code like:
action1();
action2();
if (!error) ....
would be able to perform action1 and action2 in parallel, but a compiler
would have to run the actions in sequence if action1() might call an error
handler that never returns.
Nonetheless, I don't see Annex K as being nearly as harmful as the notion
that the Standard makes any effort to forbid all forms of unreasonable
behavior, and that the quality of a implementation is not reliant upon its
creator using good judgment as to what behaviors are reasonable for a
particular target platform and application field.
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-02-17 18:55 +0100 |
| Message-ID | <20170217185502.ac705121dc96e38cdfaa6fc5@gmail.com> |
| In reply to | #104075 |
On Fri, 17 Feb 2017 09:16:53 -0800 (PST) supercat@casperkitty.com wrote: > Nonetheless, I don't see Annex K as being nearly as harmful as the notion > that the Standard makes any effort to forbid all forms of unreasonable > behavior, and that the quality of a implementation is not reliant upon its > creator using good judgment as to what behaviors are reasonable for a > particular target platform and application field. Like a security belt, bounds-checked functions provide a false security and can be source of collateral domages. They have been included in C11 only because of Microsoft's bad programmers. Consequently, the C committee failed in providing de facto standard to C programmers.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-02-18 08:07 +1300 |
| Message-ID | <egovvrF7ke0U1@mid.individual.net> |
| In reply to | #104059 |
On 02/18/17 12:01 AM, GOTHIER Nathan wrote: > On Fri, 17 Feb 2017 21:19:56 +1300 > Ian Collins <ian-news@hotmail.com> wrote: > >> On 02/17/17 10:32 AM, supercat@casperkitty.com wrote: >>> On Thursday, February 16, 2017 at 2:32:48 PM UTC-6, David Brown wrote: >>>> Regarding access to POD members with no constructors or destructors, C++ >>>> treats unions mostly like C89 - if you have a union of a float and an >>>> int, and assign to the float, you are not allowed to read out the >>>> representation as the int. (In C89, this is implementation-defined >>>> behaviour - in C++, it is not discussed and therefore undefined.) This >>>> is hardly surprising, since C++ effectively forked from C89, and the >>>> "type punning" feature of unions was not standardised until C99. >>> >>> Type punning, whether via pointers or unions, is crucial in some kinds of >>> programming, but not needed at all in others. >> >> One reason C++ is gaining std::variant (a type-safe union). >> > Nothing is safe from bad programmers... In the new technology field too many > people believe "new" means "better" because they don't understand how it works. > I consider C++ (and C11 too with annex K) as a regression since it postulates > the programmer is stupid. That response proves it... -- Ian
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-02-17 20:12 +0100 |
| Message-ID | <20170217201227.93e1b5cd23e83e7c007cac84@gmail.com> |
| In reply to | #104083 |
On Sat, 18 Feb 2017 08:07:39 +1300 Ian Collins <ian-news@hotmail.com> wrote: > > Nothing is safe from bad programmers... In the new technology field too many > > people believe "new" means "better" because they don't understand how it works. > > I consider C++ (and C11 too with annex K) as a regression since it postulates > > the programmer is stupid. > > That response proves it... > > -- > Ian Your anger against my answer only prove the fact that you need diapers to write C-like programs with C++. :-P
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-02-18 11:04 +1300 |
| Message-ID | <egpabpF7ke0U2@mid.individual.net> |
| In reply to | #104084 |
On 02/18/17 08:12 AM, GOTHIER Nathan wrote:
> On Sat, 18 Feb 2017 08:07:39 +1300
> Ian Collins <ian-news@hotmail.com> wrote:
>
>>> Nothing is safe from bad programmers... In the new technology field too many
>>> people believe "new" means "better" because they don't understand how it works.
>>> I consider C++ (and C11 too with annex K) as a regression since it postulates
>>> the programmer is stupid.
>>
>> That response proves it...
{please don't quote signatures}
> Your anger against my answer only prove the fact that you need diapers to write
> C-like programs with C++. :-P
There was no anger and we don't have diapers in my part of the world.
While there wasn't any anger there is incredulity that some programmers
continue to resist language features designed to make programming both
easier and safer. Mind you I'm still amazed at the resistance I
encounter to writing unit tests.
I guess there will always be people who refuse to wear their seat-belts
when they drive, so I shouldn't really be surprised at anything these days.
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-17 22:38 +0000 |
| Message-ID | <o87ttq$mh3$1@dont-email.me> |
| In reply to | #104091 |
On 17/02/2017 22:04, Ian Collins wrote: > On 02/18/17 08:12 AM, GOTHIER Nathan wrote: > >> Your anger against my answer only prove the fact that you need diapers >> to write >> C-like programs with C++. :-P > > There was no anger and we don't have diapers in my part of the world. > > While there wasn't any anger there is incredulity that some programmers > continue to resist language features designed to make programming both > easier and safer. Mind you I'm still amazed at the resistance I > encounter to writing unit tests. > I guess there will always be people who refuse to wear their seat-belts > when they drive, so I shouldn't really be surprised at anything these days. People use C for various reasons including extra control, and that might require not wearing a seat-belt. Otherwise there are plenty of languages that are easier and safer than either C or C++. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-02-18 11:47 +1300 |
| Message-ID | <egpcs5F7ke0U4@mid.individual.net> |
| In reply to | #104098 |
On 02/18/17 11:38 AM, BartC wrote: > On 17/02/2017 22:04, Ian Collins wrote: >> On 02/18/17 08:12 AM, GOTHIER Nathan wrote: > >> >>> Your anger against my answer only prove the fact that you need diapers >>> to write >>> C-like programs with C++. :-P >> >> There was no anger and we don't have diapers in my part of the world. >> >> While there wasn't any anger there is incredulity that some programmers >> continue to resist language features designed to make programming both >> easier and safer. Mind you I'm still amazed at the resistance I >> encounter to writing unit tests. > >> I guess there will always be people who refuse to wear their seat-belts >> when they drive, so I shouldn't really be surprised at anything these days. > > People use C for various reasons including extra control, and that might > require not wearing a seat-belt. > > Otherwise there are plenty of languages that are easier and safer than > either C or C++. But they aren't used in the same space. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-17 14:55 -0800 |
| Message-ID | <0803062f-9117-4a58-86f5-d78c40b2b3d2@googlegroups.com> |
| In reply to | #104098 |
On Friday, February 17, 2017 at 4:38:40 PM UTC-6, Bart wrote: > People use C for various reasons including extra control, and that might > require not wearing a seat-belt. More importantly, it might require using some kind of restraint which doesn't meet all the applicable safety standards that would be applicable to seat belts, but would nonetheless meet the requirements of the purpose to which they would be put. Unfortunately, to continue the analogy, some car makers seem to feel that any seat belts which didn't meet the official safety standards should be considered useless, and a car should make itself "more efficient" by eliminating them altogether.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-02-18 12:11 +1300 |
| Message-ID | <egpe9aF7ke0U5@mid.individual.net> |
| In reply to | #104101 |
On 02/18/17 11:55 AM, supercat@casperkitty.com wrote: > On Friday, February 17, 2017 at 4:38:40 PM UTC-6, Bart wrote: >> People use C for various reasons including extra control, and that might >> require not wearing a seat-belt. > > More importantly, it might require using some kind of restraint which doesn't > meet all the applicable safety standards that would be applicable to seat > belts, but would nonetheless meet the requirements of the purpose to which > they would be put. At least if the seat belt, even a compromised one, is fitted the driver has a choice. If it's not there, no matter how careful the driver, he is still at risk... -- Ian
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-02-17 15:26 -0800 |
| Message-ID | <o880n0$2d4$1@dont-email.me> |
| In reply to | #104102 |
On 2/17/2017 3:11 PM, Ian Collins wrote: > On 02/18/17 11:55 AM, supercat@casperkitty.com wrote: >> On Friday, February 17, 2017 at 4:38:40 PM UTC-6, Bart wrote: >>> People use C for various reasons including extra control, and that might >>> require not wearing a seat-belt. >> >> More importantly, it might require using some kind of restraint which >> doesn't >> meet all the applicable safety standards that would be applicable to seat >> belts, but would nonetheless meet the requirements of the purpose to >> which >> they would be put. > > At least if the seat belt, even a compromised one, is fitted the driver > has a choice. If it's not there, no matter how careful the driver, he > is still at risk... > Must think about a reason why some want to keep the corks on the end of all the forks in a language as a whole. Well, we have to keep unsafe programmers safe, and C is too dangerous for basically any programmer to use correctly; Some postulate: C is far too great in its generosity wrt access to programmability. Imvvho, that type of mentality should not be used to destroy C, and/or C++.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-17 16:15 -0800 |
| Message-ID | <2e29b499-27c0-4e60-918b-e0efc6a8cd0c@googlegroups.com> |
| In reply to | #104102 |
On Friday, February 17, 2017 at 5:11:47 PM UTC-6, Ian Collins wrote:
> On 02/18/17 11:55 AM, supercat wrote:
> > On Friday, February 17, 2017 at 4:38:40 PM UTC-6, Bart wrote:
> >> People use C for various reasons including extra control, and that might
> >> require not wearing a seat-belt.
> >
> > More importantly, it might require using some kind of restraint which doesn't
> > meet all the applicable safety standards that would be applicable to seat
> > belts, but would nonetheless meet the requirements of the purpose to which
> > they would be put.
>
> At least if the seat belt, even a compromised one, is fitted the driver
> has a choice. If it's not there, no matter how careful the driver, he
> is still at risk...
The problem is that modern C compilers will sometimes use the fact that a
code path doesn't check for and avoid overflow in one computation whose
result will end up being irrelevant to requirements as justification for
omitting programmer-supplied overflow checks in cases where they would
actually matter.
For example, if a programmer needs a function which returns x*y+L if
x and y are in the range +/- 10,000, or any value otherwise, the code most
compilers would naturally generate given:
long long mulcomp(int x, int y, long long z) { return x*y + z; }
would satisfy that requirement except in cases where the compiler percolates
overflow-based assumptions to the surrounding code. Depending upon nearby
register usage, it might be faster for the compiler to use a multiply
instruction that yields a 32-bit result and sign-extend it, or use one that
yields a 64-bit result, and given the application requirements it would be
helpful to let the compiler choose whichever one it saw fit.
The problem is that if modern C compilers happen to realize that x would
need to be within a certain range to prevent overflow, they may decide to
omit checks elsewhere that would try to ensure x doesn't exceed 60,000.
The only way a programmer can ensure that a compiler won't omit the checks
that are actually needed would be to make the code needlessly slow and
clunky in cases where it shouldn't matter.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-02-18 13:22 +1300 |
| Message-ID | <egpienF7ke0U6@mid.individual.net> |
| In reply to | #104107 |
On 02/18/17 01:15 PM, supercat@casperkitty.com wrote: > On Friday, February 17, 2017 at 5:11:47 PM UTC-6, Ian Collins wrote: >> On 02/18/17 11:55 AM, supercat wrote: >>> On Friday, February 17, 2017 at 4:38:40 PM UTC-6, Bart wrote: >>>> People use C for various reasons including extra control, and that might >>>> require not wearing a seat-belt. >>> >>> More importantly, it might require using some kind of restraint which doesn't >>> meet all the applicable safety standards that would be applicable to seat >>> belts, but would nonetheless meet the requirements of the purpose to which >>> they would be put. >> >> At least if the seat belt, even a compromised one, is fitted the driver >> has a choice. If it's not there, no matter how careful the driver, he >> is still at risk... > > The problem is that modern C compilers will sometimes use the fact that a > code path doesn't check for and avoid overflow in one computation whose > result will end up being irrelevant to requirements as justification for > omitting programmer-supplied overflow checks in cases where they would > actually matter. That wasn't the topic of this sub-thread. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-17 16:37 -0800 |
| Message-ID | <3f110fd5-aaa7-41fe-a6cc-f4cf27c80881@googlegroups.com> |
| In reply to | #104110 |
On Friday, February 17, 2017 at 6:22:59 PM UTC-6, Ian Collins wrote: > On 02/18/17 01:15 PM, supercat wrote: > > On Friday, February 17, 2017 at 5:11:47 PM UTC-6, Ian Collins wrote: > >> On 02/18/17 11:55 AM, supercat wrote: > >>> On Friday, February 17, 2017 at 4:38:40 PM UTC-6, Bart wrote: > >>>> People use C for various reasons including extra control, and that might > >>>> require not wearing a seat-belt. > >>> > >>> More importantly, it might require using some kind of restraint which doesn't > >>> meet all the applicable safety standards that would be applicable to seat > >>> belts, but would nonetheless meet the requirements of the purpose to which > >>> they would be put. > >> > >> At least if the seat belt, even a compromised one, is fitted the driver > >> has a choice. If it's not there, no matter how careful the driver, he > >> is still at risk... > > > > The problem is that modern C compilers will sometimes use the fact that a > > code path doesn't check for and avoid overflow in one computation whose > > result will end up being irrelevant to requirements as justification for > > omitting programmer-supplied overflow checks in cases where they would > > actually matter. > > That wasn't the topic of this sub-thread. It is precisely the subject of my earlier analogy: the compiler decides to eliminate the safety-check code (seatbelt) because it decides that there isn't enough safety-check code to satisfy it, even though there would have been enough to meet requirements if the compiler had just left it alone.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-18 11:57 +0100 |
| Message-ID | <o8996j$rqj$1@dont-email.me> |
| In reply to | #104112 |
On 18/02/17 01:37, supercat@casperkitty.com wrote: > On Friday, February 17, 2017 at 6:22:59 PM UTC-6, Ian Collins wrote: >> On 02/18/17 01:15 PM, supercat wrote: >>> On Friday, February 17, 2017 at 5:11:47 PM UTC-6, Ian Collins wrote: >>>> On 02/18/17 11:55 AM, supercat wrote: >>>>> On Friday, February 17, 2017 at 4:38:40 PM UTC-6, Bart wrote: >>>>>> People use C for various reasons including extra control, and that might >>>>>> require not wearing a seat-belt. >>>>> >>>>> More importantly, it might require using some kind of restraint which doesn't >>>>> meet all the applicable safety standards that would be applicable to seat >>>>> belts, but would nonetheless meet the requirements of the purpose to which >>>>> they would be put. >>>> >>>> At least if the seat belt, even a compromised one, is fitted the driver >>>> has a choice. If it's not there, no matter how careful the driver, he >>>> is still at risk... >>> >>> The problem is that modern C compilers will sometimes use the fact that a >>> code path doesn't check for and avoid overflow in one computation whose >>> result will end up being irrelevant to requirements as justification for >>> omitting programmer-supplied overflow checks in cases where they would >>> actually matter. >> >> That wasn't the topic of this sub-thread. > > It is precisely the subject of my earlier analogy: the compiler decides > to eliminate the safety-check code (seatbelt) because it decides that there > isn't enough safety-check code to satisfy it, even though there would have > been enough to meet requirements if the compiler had just left it alone. > You /think/ it is precisely the subject of /every/ thread in this group. We've heard it all before. And do you write your shopping lists like your function specifications? "If the bananas are not too green, buy 4 - if not, any number of bananas will do".
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-02-18 07:13 +0000 |
| Message-ID | <o88s41$tpb$1@dont-email.me> |
| In reply to | #104102 |
On 17/02/17 23:11, Ian Collins wrote: > On 02/18/17 11:55 AM, supercat@casperkitty.com wrote: >> On Friday, February 17, 2017 at 4:38:40 PM UTC-6, Bart wrote: >>> People use C for various reasons including extra control, and that might >>> require not wearing a seat-belt. >> >> More importantly, it might require using some kind of restraint which >> doesn't >> meet all the applicable safety standards that would be applicable to seat >> belts, but would nonetheless meet the requirements of the purpose to >> which >> they would be put. > > At least if the seat belt, even a compromised one, is fitted the driver > has a choice. If it's not there, no matter how careful the driver, he > is still at risk... What a terrible analogy! A computer programmer has many advantages over a driver. He can drive the journey in perfect safety a million times, creating all kinds of artificial hazards for his car to negotiate. Whenever there is a smash and virtual bodies end up strewn over the landscape, he can chuckle to himself that he's glad he's not an analogy while he investigates which particular hazard caused which particular problem. Then the virtual corpses pick themselves up, dust themselves down, and get willingly back into the car for another crack at it. They say the coward dies a thousand deaths, but the test dummy is much braver, and dies a million. Only when they can safely negotiate every hazard he can imagine (and quite a few that his pals Janet and Charlie can imagine because their imaginations are more fevered than his) will he even consider letting the car go into production. Next you'll be saying that assertions are like lifeboats. (And I'm ready for you if you do!) Unit tests, young man! Learn all about unit tests! Then you'll find that you crash a lot more than before, but you will do so in the safety of the lab, where men are fake men, women are fake women, and small furry creatures from Alpha Centauri are /fake/ small furry creatures from Alpha Centauri. -- Richard Heathfield "Usenet is a strange place" - dmr 29 July 1999 No small, furry creatures from Alpha Centauri were harmed during the writing of this article.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-02-18 20:26 +1300 |
| Message-ID | <egqb91F7ke0U9@mid.individual.net> |
| In reply to | #104119 |
On 02/18/17 08:13 PM, Richard Heathfield wrote: > On 17/02/17 23:11, Ian Collins wrote: >> On 02/18/17 11:55 AM, supercat@casperkitty.com wrote: >>> On Friday, February 17, 2017 at 4:38:40 PM UTC-6, Bart wrote: >>>> People use C for various reasons including extra control, and that might >>>> require not wearing a seat-belt. >>> >>> More importantly, it might require using some kind of restraint which >>> doesn't >>> meet all the applicable safety standards that would be applicable to seat >>> belts, but would nonetheless meet the requirements of the purpose to >>> which >>> they would be put. >> >> At least if the seat belt, even a compromised one, is fitted the driver >> has a choice. If it's not there, no matter how careful the driver, he >> is still at risk... > > What a terrible analogy! Well maybe, but it didn't start out as an analogy, more of a reflection on my continuing amazement at the stupidity of the human race :) You can lead a horse to water and all that... > A computer programmer has many advantages over a driver. He can drive > the journey in perfect safety a million times, creating all kinds of > artificial hazards for his car to negotiate. Whenever there is a smash > and virtual bodies end up strewn over the landscape, he can chuckle to > himself that he's glad he's not an analogy while he investigates which > particular hazard caused which particular problem. Then the virtual > corpses pick themselves up, dust themselves down, and get willingly back > into the car for another crack at it. > > They say the coward dies a thousand deaths, but the test dummy is much > braver, and dies a million. > > Only when they can safely negotiate every hazard he can imagine (and > quite a few that his pals Janet and Charlie can imagine because their > imaginations are more fevered than his) will he even consider letting > the car go into production. > > Next you'll be saying that assertions are like lifeboats. (And I'm ready > for you if you do!) > > Unit tests, young man! Learn all about unit tests! Then you'll find that > you crash a lot more than before, but you will do so in the safety of > the lab, where men are fake men, women are fake women, and small furry > creatures from Alpha Centauri are /fake/ small furry creatures from > Alpha Centauri. Did you miss: "Mind you I'm still amazed at the resistance I encounter to writing unit tests." :) -- Ian
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web