Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #76449 > unrolled thread
| Started by | supercat@casperkitty.com |
|---|---|
| First post | 2015-11-18 11:25 -0800 |
| Last post | 2015-11-19 23:07 +0000 |
| Articles | 20 on this page of 158 — 18 participants |
Back to article view | Back to comp.lang.c
Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-11-18 11:25 -0800
Re: Understanding C89/C99 aliasing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-19 01:39 +0000
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-11-18 19:55 -0800
Re: Understanding C89/C99 aliasing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-19 14:37 +0000
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-11-19 07:07 -0800
Re: Understanding C89/C99 aliasing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-19 22:58 +0000
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-11-18 20:00 -0800
Re: Understanding C89/C99 aliasing Nick Bowler <nbowler@draconx.ca> - 2015-11-19 15:44 +0000
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-11-19 09:46 -0800
Re: Understanding C89/C99 aliasing Martin Shobe <martin.shobe@yahoo.com> - 2015-11-19 13:28 -0600
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-11-19 11:54 -0800
Re: Understanding C89/C99 aliasing Martin Shobe <martin.shobe@yahoo.com> - 2015-11-19 14:41 -0600
Re: Understanding C89/C99 aliasing Martin Shobe <martin.shobe@yahoo.com> - 2015-11-19 14:46 -0600
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-11-19 13:16 -0800
Re: Understanding C89/C99 aliasing Nick Bowler <nbowler@draconx.ca> - 2015-11-19 21:11 +0000
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-11-19 13:34 -0800
Re: Understanding C89/C99 aliasing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-19 23:12 +0000
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-11-19 15:18 -0800
Re: Understanding C89/C99 aliasing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-20 02:21 +0000
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-11-19 18:40 -0800
Re: Understanding C89/C99 aliasing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-21 00:32 +0000
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-11-20 16:47 -0800
Re: Understanding C89/C99 aliasing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-21 01:14 +0000
Re: Understanding C89/C99 aliasing Stephen Sprunk <stephen@sprunk.org> - 2015-11-20 20:25 -0600
Re: Understanding C89/C99 aliasing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-21 10:17 +0000
Re: Understanding C89/C99 aliasing Stephen Sprunk <stephen@sprunk.org> - 2015-11-21 18:11 -0600
Re: Understanding C89/C99 aliasing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-22 00:58 +0000
Re: Understanding C89/C99 aliasing Stephen Sprunk <stephen@sprunk.org> - 2015-11-22 14:41 -0600
Re: Understanding C89/C99 aliasing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-23 00:58 +0000
Re: Understanding C89/C99 aliasing Stephen Sprunk <stephen@sprunk.org> - 2015-11-22 19:33 -0600
Re: Understanding C89/C99 aliasing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-26 01:16 +0000
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-11-25 21:57 -0800
Re: Understanding C89/C99 aliasing Stephen Sprunk <stephen@sprunk.org> - 2015-11-26 18:01 -0600
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-11-27 10:17 -0800
Re: Understanding C89/C99 aliasing Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-27 23:38 -0800
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-11-28 07:22 -0800
Re: Understanding C89/C99 aliasing Tim Rentsch <txr@alumni.caltech.edu> - 2015-12-08 08:51 -0800
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-11-22 18:34 -0800
Re: Understanding C89/C99 aliasing James Kuyper <jameskuyper@verizon.net> - 2015-11-23 06:48 -0500
Re: Understanding C89/C99 aliasing Keith Thompson <kst-u@mib.org> - 2015-11-23 08:28 -0800
Re: Understanding C89/C99 aliasing Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-27 09:21 -0800
Re: Understanding C89/C99 aliasing raltbos@xs4all.nl (Richard Bos) - 2015-11-27 17:45 +0000
Re: Understanding C89/C99 aliasing Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-27 10:13 -0800
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-11-27 10:50 -0800
Re: Understanding C89/C99 aliasing Keith Thompson <kst-u@mib.org> - 2015-11-27 13:46 -0800
Re: Understanding C89/C99 aliasing Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-28 08:57 -0800
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-11-28 11:00 -0800
Re: Understanding C89/C99 aliasing Tim Rentsch <txr@alumni.caltech.edu> - 2015-12-08 09:04 -0800
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-12-08 10:42 -0800
Re: Understanding C89/C99 aliasing Keith Thompson <kst-u@mib.org> - 2015-12-08 10:54 -0800
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-12-08 11:44 -0800
Re: Understanding C89/C99 aliasing glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-09 00:11 +0000
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-12-08 16:39 -0800
Re: Understanding C89/C99 aliasing Keith Thompson <kst-u@mib.org> - 2015-12-08 19:15 -0800
Re: Understanding C89/C99 aliasing glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-09 04:21 +0000
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-12-09 09:04 -0800
Re: Understanding C89/C99 aliasing Stephen Sprunk <stephen@sprunk.org> - 2015-12-08 22:15 -0600
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-12-09 07:04 -0800
Re: Understanding C89/C99 aliasing Stephen Sprunk <stephen@sprunk.org> - 2015-12-09 14:29 -0600
Re: Understanding C89/C99 aliasing Keith Thompson <kst-u@mib.org> - 2015-12-09 13:06 -0800
Re: Understanding C89/C99 aliasing glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-09 22:58 +0000
Re: Understanding C89/C99 aliasing Stephen Sprunk <stephen@sprunk.org> - 2015-12-10 11:35 -0600
Re: Understanding C89/C99 aliasing James Kuyper <jameskuyper@verizon.net> - 2015-12-10 12:58 -0500
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-12-10 10:12 -0800
Re: Understanding C89/C99 aliasing Stephen Sprunk <stephen@sprunk.org> - 2015-12-10 13:39 -0600
Re: Understanding C89/C99 aliasing raltbos@xs4all.nl (Richard Bos) - 2015-12-10 22:45 +0000
Re: Understanding C89/C99 aliasing Stephen Sprunk <stephen@sprunk.org> - 2015-12-11 12:27 -0600
Re: Understanding C89/C99 aliasing James Kuyper <jameskuyper@verizon.net> - 2015-12-10 20:30 -0500
Re: Understanding C89/C99 aliasing Stephen Sprunk <stephen@sprunk.org> - 2015-12-10 13:54 -0600
Re: Understanding C89/C99 aliasing James Kuyper <jameskuyper@verizon.net> - 2015-12-10 20:57 -0500
Re: Understanding C89/C99 aliasing glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-11 03:44 +0000
Re: Understanding C89/C99 aliasing James Kuyper <jameskuyper@verizon.net> - 2015-12-11 07:26 -0500
Re: Understanding C89/C99 aliasing Stephen Sprunk <stephen@sprunk.org> - 2015-12-11 11:58 -0600
Re: Understanding C89/C99 aliasing Richard Damon <Richard@Damon-Family.org> - 2015-12-11 23:17 -0500
Re: Understanding C89/C99 aliasing James Kuyper <jameskuyper@verizon.net> - 2015-12-11 14:00 -0500
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-12-09 13:17 -0800
Re: Understanding C89/C99 aliasing Keith Thompson <kst-u@mib.org> - 2015-12-09 14:22 -0800
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-12-09 15:06 -0800
Re: Understanding C89/C99 aliasing glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-09 23:18 +0000
Re: Understanding C89/C99 aliasing James Kuyper <jameskuyper@verizon.net> - 2015-12-09 18:48 -0500
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-12-09 15:49 -0800
Re: Understanding C89/C99 aliasing Stephen Sprunk <stephen@sprunk.org> - 2015-12-10 12:44 -0600
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-12-10 11:12 -0800
Re: Understanding C89/C99 aliasing raltbos@xs4all.nl (Richard Bos) - 2015-12-10 20:18 +0000
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-12-10 12:29 -0800
Re: Understanding C89/C99 aliasing Stephen Sprunk <stephen@sprunk.org> - 2015-12-10 16:19 -0600
Re: Understanding C89/C99 aliasing raltbos@xs4all.nl (Richard Bos) - 2015-12-10 22:49 +0000
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-12-10 14:58 -0800
Re: Understanding C89/C99 aliasing raltbos@xs4all.nl (Richard Bos) - 2015-12-15 18:25 +0000
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-12-15 10:50 -0800
Re: Understanding C89/C99 aliasing Keith Thompson <kst-u@mib.org> - 2015-12-15 11:32 -0800
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-12-15 12:20 -0800
Re: Understanding C89/C99 aliasing Keith Thompson <kst-u@mib.org> - 2015-12-15 13:08 -0800
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-12-15 13:24 -0800
Re: Understanding C89/C99 aliasing Keith Thompson <kst-u@mib.org> - 2015-12-15 14:35 -0800
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-12-15 15:34 -0800
Re: Understanding C89/C99 aliasing David Brown <david.brown@hesbynett.no> - 2015-12-16 00:00 +0100
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-12-15 15:47 -0800
Re: Understanding C89/C99 aliasing David Brown <david.brown@hesbynett.no> - 2015-12-16 11:08 +0100
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-12-16 09:45 -0800
Re: Understanding C89/C99 aliasing David Brown <david.brown@hesbynett.no> - 2015-12-17 13:51 +0100
Re: Understanding C89/C99 aliasing Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-17 05:10 -0800
Re: Understanding C89/C99 aliasing Richard Heathfield <rjh@cpax.org.uk> - 2015-12-17 13:46 +0000
Re: Understanding C89/C99 aliasing David Brown <david.brown@hesbynett.no> - 2015-12-17 15:24 +0100
Re: Understanding C89/C99 aliasing Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-17 09:57 -0500
Re: Understanding C89/C99 aliasing Les Cargill <lcargill99@comcast.com> - 2015-12-17 09:39 -0600
Re: Understanding C89/C99 aliasing Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-17 12:12 -0500
Re: Understanding C89/C99 aliasing Les Cargill <lcargill99@comcast.com> - 2015-12-17 12:27 -0600
Re: Understanding C89/C99 aliasing Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-17 14:22 -0500
Re: Understanding C89/C99 aliasing Les Cargill <lcargill99@comcast.com> - 2015-12-17 17:58 -0600
Re: Understanding C89/C99 aliasing Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-17 20:26 -0500
Re: Understanding C89/C99 aliasing Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-17 20:35 -0500
Re: Understanding C89/C99 aliasing Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-17 21:49 -0500
Re: Understanding C89/C99 aliasing Les Cargill <lcargill99@comcast.com> - 2015-12-17 20:52 -0600
Re: Understanding C89/C99 aliasing Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-17 22:01 -0500
Re: Understanding C89/C99 aliasing Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-17 20:55 -0800
Re: Understanding C89/C99 aliasing Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-18 08:40 -0500
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-12-17 09:10 -0800
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-12-15 14:27 -0800
Re: Understanding C89/C99 aliasing Keith Thompson <kst-u@mib.org> - 2015-12-15 16:30 -0800
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-12-16 12:47 -0800
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-12-15 14:32 -0800
Re: Understanding C89/C99 aliasing Öö Tiib <ootiib@hot.ee> - 2015-12-09 08:09 -0800
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-12-09 09:10 -0800
Re: Understanding C89/C99 aliasing Öö Tiib <ootiib@hot.ee> - 2015-12-09 10:38 -0800
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-12-09 11:18 -0800
Re: Understanding C89/C99 aliasing glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-09 19:14 +0000
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-12-09 11:27 -0800
Re: Understanding C89/C99 aliasing Stephen Sprunk <stephen@sprunk.org> - 2015-12-09 15:03 -0600
Re: Understanding C89/C99 aliasing Öö Tiib <ootiib@hot.ee> - 2015-12-10 01:23 -0800
Re: Understanding C89/C99 aliasing raltbos@xs4all.nl (Richard Bos) - 2015-12-10 20:21 +0000
Re: Understanding C89/C99 aliasing Tim Rentsch <txr@alumni.caltech.edu> - 2015-12-09 13:06 -0800
Re: Understanding C89/C99 aliasing glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-09 00:00 +0000
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-12-08 16:27 -0800
Re: Understanding C89/C99 aliasing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-09 01:18 +0000
Re: Understanding C89/C99 aliasing Keith Thompson <kst-u@mib.org> - 2015-12-08 19:13 -0800
Re: Understanding C89/C99 aliasing Tim Rentsch <txr@alumni.caltech.edu> - 2015-12-09 13:04 -0800
Re: Understanding C89/C99 aliasing raltbos@xs4all.nl (Richard Bos) - 2015-12-10 20:07 +0000
Re: Understanding C89/C99 aliasing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-23 17:03 +0000
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-11-23 15:39 -0800
Re: Understanding C89/C99 aliasing Stephen Sprunk <stephen@sprunk.org> - 2015-11-23 18:11 -0600
Re: Understanding C89/C99 aliasing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-24 01:13 +0000
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-11-24 09:29 -0800
Re: Understanding C89/C99 aliasing Stephen Sprunk <stephen@sprunk.org> - 2015-11-20 09:10 -0600
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-11-20 10:08 -0800
Re: Understanding C89/C99 aliasing Stephen Sprunk <stephen@sprunk.org> - 2015-11-21 19:02 -0600
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-11-21 18:17 -0800
Re: Understanding C89/C99 aliasing Stephen Sprunk <stephen@sprunk.org> - 2015-11-21 20:52 -0600
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-11-21 19:28 -0800
Re: Understanding C89/C99 aliasing Stephen Sprunk <stephen@sprunk.org> - 2015-11-22 20:00 -0600
Re: Understanding C89/C99 aliasing Keith Thompson <kst-u@mib.org> - 2015-11-20 19:12 -0800
Re: Understanding C89/C99 aliasing Stephen Sprunk <stephen@sprunk.org> - 2015-11-20 23:10 -0600
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-11-20 23:07 -0800
Re: Understanding C89/C99 aliasing Stephen Sprunk <stephen@sprunk.org> - 2015-11-21 18:37 -0600
Re: Understanding C89/C99 aliasing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-21 10:29 +0000
Re: Understanding C89/C99 aliasing supercat@casperkitty.com - 2015-11-21 10:04 -0800
Re: Understanding C89/C99 aliasing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-21 19:35 +0000
Re: Understanding C89/C99 aliasing Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-19 23:07 +0000
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-27 09:21 -0800 |
| Message-ID | <kfnio4n1hox.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #77003 |
Keith Thompson <kst-u@mib.org> writes: > James Kuyper <jameskuyper@verizon.net> writes: > [...] >> And 6.5p7 is violated by any attempt to write to that same location >> using a type other than one of the ones listed in 6.5p7 - and if it >> is one of those types, then the effective type remains unchanged. >> The relevant verb is "access", which includes both reads and >> writes. It's therefore only possible to set the effective type >> allocated memory; once set, it cannot be changed. > > [...] > > The definition of "access" (3.1) is: > > <execution-time action> to read or modify the value of an object > > 6.5p7 says (emphasis added): > > An object shall have *its stored value* accessed only by an lvalue > expression that has one of the following types: > ... > > Writing to an object certainly accesses the object, but I wouldn't say > that it accesses the value of the object. In fact I don't think > "accessing a value" is even defined. > > int i; > i = 42; > > The assignment accesses the object i, but not its value. To me 'i = 42;' clearly accesses the stored value of the object associated with 'i', because the assignment sets it. > The value > before the assignment is indeterminate, and could be a trap > representation, but no undefined behavior occurs. The assignment /writes/ the stored value. It is only /reading/ a stored value that is a trap representation that is undefined behavior. If an operation generates a trap representation and the result is assigned, the assignment succeeds and a trap representation is stored (at least, I don't see anything in the Standard that causes undefined behavior in such circumstances). > It's plausible that 6.5p7 is *intended* to refer to accessing the > object rather than its value (i.e., that it's meant to apply to > both reads and writes), but the wording is not as clear as it > should be. To me 6.5p7 obviously is meant to apply to both reads and writes. How could it be otherwise, given the definition of 'access'? > Perhaps 6.5p7 should be reworded to: > > An object shall be accessed only by an lvalue expression that > has one of the following types: > ... Since the Standard uses different language, that suggests that there is some salient difference between the two wordings. I don't know why you sometimes leave out the word "stored" in talking about the value of an object. To me the phrase "stored value" seems, fairly clearly, to be meant as "the (or an) object representation corresponding to a value of the given type". Assigning to an object, or lvalue conversion to get the value of an object, accesses the "stored value". Using memcpy() to copy an object (either to or from) does access the object but does not access the stored value of the object, in the sense of converting a value to or from the object representation of some type. The rules in 6.5p7 apply only to "regular" accesses of an object, not to things like memcpy(), which is always allowed.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-11-27 17:45 +0000 |
| Message-ID | <56589677.17800640@news.xs4all.nl> |
| In reply to | #77259 |
Tim Rentsch <txr@alumni.caltech.edu> wrote: > Keith Thompson <kst-u@mib.org> writes: > > > The value > > before the assignment is indeterminate, and could be a trap > > representation, but no undefined behavior occurs. > > The assignment /writes/ the stored value. It is only /reading/ a > stored value that is a trap representation that is undefined > behavior. If an operation generates a trap representation and > the result is assigned, the assignment succeeds and a trap > representation is stored (at least, I don't see anything in the > Standard that causes undefined behavior in such circumstances). 6.2.6.1#5: both the reading _and_ the production of a trap value have undefined behaviour. Richard
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-27 10:13 -0800 |
| Message-ID | <kfna8pz1fak.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #77263 |
raltbos@xs4all.nl (Richard Bos) writes: > Tim Rentsch <txr@alumni.caltech.edu> wrote: > >> Keith Thompson <kst-u@mib.org> writes: >> >>> The value >>> before the assignment is indeterminate, and could be a trap >>> representation, but no undefined behavior occurs. >> >> The assignment /writes/ the stored value. It is only /reading/ a >> stored value that is a trap representation that is undefined >> behavior. If an operation generates a trap representation and >> the result is assigned, the assignment succeeds and a trap >> representation is stored (at least, I don't see anything in the >> Standard that causes undefined behavior in such circumstances). > > 6.2.6.1#5: both the reading _and_ the production of a trap value have > undefined behaviour. Absolutely right. I was too hasty in my double checking.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-27 10:50 -0800 |
| Message-ID | <9d93616a-e949-44a5-9bd1-96f6f1bbb26d@googlegroups.com> |
| In reply to | #77263 |
On Friday, November 27, 2015 at 11:45:28 AM UTC-6, Richard Bos wrote:
> 6.2.6.1#5: both the reading _and_ the production of a trap value have
> undefined behaviour.
Given the code:
int *p;
void set_p(int ip)
{
p = (int*)ip;
}
If the set_p method were allowed to invoke Undefined Behavior for some values
of ip, that would suggest that the conversion from an int to a pointer always
yields Undefined Behavior [since an implementation need not define any
values of integer type which, when cast to a pointer type, would yield a
non-trap representation]. While I don't think any useful purpose is served
by saying that the above method must "succeed" for any value of ip, but need
not have any possibility of storing a value into p that wouldn't trap when
read, the language which makes the behavior Implementation-Defined would be
superfluous if that weren't the case.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-27 13:46 -0800 |
| Message-ID | <ln7fl3yv38.fsf@kst-u.example.com> |
| In reply to | #77259 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> James Kuyper <jameskuyper@verizon.net> writes:
>> [...]
>>> And 6.5p7 is violated by any attempt to write to that same location
>>> using a type other than one of the ones listed in 6.5p7 - and if it
>>> is one of those types, then the effective type remains unchanged.
>>> The relevant verb is "access", which includes both reads and
>>> writes. It's therefore only possible to set the effective type
>>> allocated memory; once set, it cannot be changed.
>>
>> [...]
>>
>> The definition of "access" (3.1) is:
>>
>> <execution-time action> to read or modify the value of an object
>>
>> 6.5p7 says (emphasis added):
>>
>> An object shall have *its stored value* accessed only by an lvalue
>> expression that has one of the following types:
>> ...
>>
>> Writing to an object certainly accesses the object, but I wouldn't say
>> that it accesses the value of the object. In fact I don't think
>> "accessing a value" is even defined.
>>
>> int i;
>> i = 42;
>>
>> The assignment accesses the object i, but not its value.
>
> To me 'i = 42;' clearly accesses the stored value of the object
> associated with 'i', because the assignment sets it.
An interesting, and perhaps plausible, interpretation. I'd have to
study how it interacts with the rest of the standard to comment further.
Perhaps later.
My interpretation is/was that the value of i is 42, and `i = 42;` does
not access that value. Of course it accesses (writes) the new value.
The definition of "access" (N1570 3.1) is:
access
<execution-time action> to read or modify the value of an object
My reading of that is that it's the object, not its value, that's
accessed. Reading the value of an object accesses the object.
Modifying the value of an object accesses the object. Note 3:
"Expressions that are not evaluated do not access objects." supports
the idea that it's the object, not its value, that's accessed.
But then 6.5p7 says "An object shall have its stored value accessed
only ...".
IMHO the standard should be more precise in this area.
>> The value
>> before the assignment is indeterminate, and could be a trap
>> representation, but no undefined behavior occurs.
>
> The assignment /writes/ the stored value. It is only /reading/ a
> stored value that is a trap representation that is undefined
> behavior. If an operation generates a trap representation and
> the result is assigned, the assignment succeeds and a trap
> representation is stored (at least, I don't see anything in the
> Standard that causes undefined behavior in such circumstances).
>
>> It's plausible that 6.5p7 is *intended* to refer to accessing the
>> object rather than its value (i.e., that it's meant to apply to
>> both reads and writes), but the wording is not as clear as it
>> should be.
>
> To me 6.5p7 obviously is meant to apply to both reads and writes.
> How could it be otherwise, given the definition of 'access'?
>
>> Perhaps 6.5p7 should be reworded to:
>>
>> An object shall be accessed only by an lvalue expression that
>> has one of the following types:
>> ...
>
> Since the Standard uses different language, that suggests that
> there is some salient difference between the two wordings. I
> don't know why you sometimes leave out the word "stored" in
> talking about the value of an object.
Why is leaving out the word "stored" a problem? What's the difference
between an object's value and its stored value? What other value does
it have?
> To me the phrase "stored
> value" seems, fairly clearly, to be meant as "the (or an) object
> representation corresponding to a value of the given type".
Representations are two different (but closely related) things.
A particular representation *represents* the value, but is not itself
that value. The stored value of an object is the value represented
by its current representation. The value of an object is exactly
the same thing.
What distinction am I missing?
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-28 08:57 -0800 |
| Message-ID | <kfn8u5ixdsf.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #77286 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: >> Keith Thompson <kst-u@mib.org> writes: >>> James Kuyper <jameskuyper@verizon.net> writes: >>> [...] >>>> And 6.5p7 is violated by any attempt to write to that same location >>>> using a type other than one of the ones listed in 6.5p7 - and if it >>>> is one of those types, then the effective type remains unchanged. >>>> The relevant verb is "access", which includes both reads and >>>> writes. It's therefore only possible to set the effective type >>>> allocated memory; once set, it cannot be changed. >>> >>> [...] >>> >>> The definition of "access" (3.1) is: >>> >>> <execution-time action> to read or modify the value of an object >>> >>> 6.5p7 says (emphasis added): >>> >>> An object shall have *its stored value* accessed only by an lvalue >>> expression that has one of the following types: >>> ... >>> >>> Writing to an object certainly accesses the object, but I wouldn't say >>> that it accesses the value of the object. In fact I don't think >>> "accessing a value" is even defined. >>> >>> int i; >>> i = 42; >>> >>> The assignment accesses the object i, but not its value. >> >> To me 'i = 42;' clearly accesses the stored value of the object >> associated with 'i', because the assignment sets it. > > An interesting, and perhaps plausible, interpretation. I'd have to > study how it interacts with the rest of the standard to comment further. > Perhaps later. > > My interpretation is/was that the value of i is 42, and `i = 42;` does > not access that value. Of course it accesses (writes) the new value. > > The definition of "access" (N1570 3.1) is: > > access > <execution-time action> to read or modify the value of an object > > My reading of that is that it's the object, not its value, that's > accessed. Reading the value of an object accesses the object. > Modifying the value of an object accesses the object. Note 3: > "Expressions that are not evaluated do not access objects." supports > the idea that it's the object, not its value, that's accessed. > > But then 6.5p7 says "An object shall have its stored value accessed > only ...". > > IMHO the standard should be more precise in this area. > >>> The value >>> before the assignment is indeterminate, and could be a trap >>> representation, but no undefined behavior occurs. >> >> The assignment /writes/ the stored value. It is only /reading/ a >> stored value that is a trap representation that is undefined >> behavior. If an operation generates a trap representation and >> the result is assigned, the assignment succeeds and a trap >> representation is stored (at least, I don't see anything in the >> Standard that causes undefined behavior in such circumstances). >> >>> It's plausible that 6.5p7 is *intended* to refer to accessing the >>> object rather than its value (i.e., that it's meant to apply to >>> both reads and writes), but the wording is not as clear as it >>> should be. >> >> To me 6.5p7 obviously is meant to apply to both reads and writes. >> How could it be otherwise, given the definition of 'access'? >> >>> Perhaps 6.5p7 should be reworded to: >>> >>> An object shall be accessed only by an lvalue expression that >>> has one of the following types: >>> ... >> >> Since the Standard uses different language, that suggests that >> there is some salient difference between the two wordings. I >> don't know why you sometimes leave out the word "stored" in >> talking about the value of an object. > > Why is leaving out the word "stored" a problem? What's the > difference between an object's value and its stored value? What > other value does it have? > >> To me the phrase "stored >> value" seems, fairly clearly, to be meant as "the (or an) object >> representation corresponding to a value of the given type". > > Representations are two different (but closely related) things. A > particular representation *represents* the value, but is not > itself that value. The stored value of an object is the value > represented by its current representation. The value of an object > is exactly the same thing. > > What distinction am I missing? Let me explain my model (or view, if you will), and then go back and match it up with terms and so forth in the Standard. There are two distinct spaces of "things" that are of interest. Let's call the two spaces "values" and "bits". A value is an abstract mathematical entity, like the number 3. Values can't be stored anywhere, they "just are". For emphasis I will use the term "abstract value", which means the same thing as value, but it underscores the different space in which values "live". In contrast, bits are things that can be stored in computers. Each bit is what you think it, a selection between two distinct states. We might call the two states "zero" and "one", but that's just a naming convention, for our convenience. Let's call a fixed-size collection of bits "a representation". We want to think of our programs as dealing with abstract values, but at a hardware level what computers deal with is bits. To bridge the gap between the two spaces, we define a mapping (actually several mappings, but that isn't important right now) between abstract values and sets of bits, aka representations. There is a close association between entities in the two spaces. In many cases each representation in one mapping correspods to a distinct abstract value; for example, two's complement integers have this property. Because entities in the two spaces are associated in this way it often happens that the distinction between them is ignored, and they are viewed as more or less interchangeable. But please keep the distinction in mind, because it is important when dealing with different types. An aspect I glossed over earlier is that what the mapping is between the two spaces depends on the type used to access a particular memory location (ie, "object' in ISO C terminology). If the memory location is viewed as an 'unsigned char' we use one mapping, but a different mapping if viewed as a 'signed char'. A given representation can, and often does, correspond to different abstract values, depending on what type the memory location is interpreted as being. Keeping this last point in mind, a memory location (aka "object") doesn't in and of itself have an abstract value. What it does have is a bit-set configuration, aka representation. We might use other terms for this idea: we might say the "contents" of an object, or the "stored value" of an object. All of these boil down to the same things, namely, the settings of each of the various bits that make up the object. Where the Standard uses the term "stored value", what I think it's referring to is the settings of bits that make up the object in question. Similarly, in the definition for access, the Standard uses the term "value", but what I think is meant is the bit settings, or "contents", or "stored value", or (making up a new term) "stored representation" of the memory being accessed. Whatever abstract value we are dealing with gets mapped, using the mapping of the type used to effect the access, to a representation (or from a representation in the case of a read access), so that the access can be done in terms of bits rather than abstract values. Hopefully all the above makes sense. Please ask me if it doesn't. Now, finally, in answer to your question, the distinction that I think is important here is that accessing an object performs a read or a write of bits, aka representation, aka "stored value", aka contents, of/in the object's memory. When the Standard talks about stored value, it is referring to those bits, not the abstract value to/from which those bits are mapped. The notion of "the abstract value of an object" is not well-defined, because it depends on the type used to perform the access. But the notion of "the bits held in an object" always means the same thing no matter what type is used, and it is this notion that "stored value" is meant to refer to. How did I do? Clear enough?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-28 11:00 -0800 |
| Message-ID | <587e1cad-46d3-41d0-8b5f-defd495d5f98@googlegroups.com> |
| In reply to | #77326 |
On Saturday, November 28, 2015 at 10:57:36 AM UTC-6, Tim Rentsch wrote: > Now, finally, in answer to your question, the distinction that I > think is important here is that accessing an object performs a > read or a write of bits, aka representation, aka "stored value", > aka contents, of/in the object's memory. When the Standard talks > about stored value, it is referring to those bits, not the > abstract value to/from which those bits are mapped. The notion > of "the abstract value of an object" is not well-defined, because > it depends on the type used to perform the access. But the > notion of "the bits held in an object" always means the same > thing no matter what type is used, and it is this notion that > "stored value" is meant to refer to. I think it's necessary to add another concept for things that can hold values--and that entity is distinct from bits. Fundamentally, I would suggest that the key complication in C is that while there is an abstract machine where everything is made up of bits, code does not access main memory directly. Instead it has the ability to behave as though it is fetching things from memory before they are needed, and defers writes to physical memory until convenient. If code attempts to write to a memory location from which data has been pre-fetched and the nature of the reads and writes is such that the compiler is required to recognize the aliasing, a compiler must discard or update the pre-fetched data. If code tries to read a location to which a write is pending and the compiler is required to recognize the aliasing, the compiler must either perform the write before the read or grab the data from the pending write rather than the data stored in memory. If code attempts to write a location to which another write is pending, and a compiler is required to recognize the aliasing, the compiler must ensure that no read that would be required to see the effect of the second write sees any effect from the first. What's most important in this model (which very closely mirrors reality) is knowing in what cases the compiler is required to ensure that code sees behaviors consistent with sequential execution. Unfortunately, the Standard is written in rather opaque terms that behave as though each location in allocated storage keeps a persistent record of its "effective type", which makes it difficult for a compiler writer to identify the situations in which aliasing does or does not need to be accounted for.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-12-08 09:04 -0800 |
| Message-ID | <kfnr3iwx45q.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #77336 |
supercat@casperkitty.com writes: > On Saturday, November 28, 2015 at 10:57:36 AM UTC-6, Tim Rentsch wrote: >> Now, finally, in answer to your question, the distinction that I >> think is important here is that accessing an object performs a >> read or a write of bits, aka representation, aka "stored value", >> aka contents, of/in the object's memory. When the Standard talks >> about stored value, it is referring to those bits, not the >> abstract value to/from which those bits are mapped. The notion >> of "the abstract value of an object" is not well-defined, because >> it depends on the type used to perform the access. But the >> notion of "the bits held in an object" always means the same >> thing no matter what type is used, and it is this notion that >> "stored value" is meant to refer to. > > I think it's necessary to add another concept for things that can > hold values--and that entity is distinct from bits. > > Fundamentally, I would suggest that the key complication in C is > that while there is an abstract machine where everything is made > up of bits, code does not access main memory directly. Instead it > has the ability to behave as though it is fetching things from > memory before they are needed, and defers writes to physical > memory until convenient. [...] I think I finally see why you have such difficulty identifying and describing how C is and what you think is wrong with it. For whatever reason you understand the language semantics in terms of compiled code rather than the behavior of the abstract machine. The difficulty is that the semantics of C is defined in terms of what happens in the abstract machine, not how code is (or might be) compiled. It would be better for you (IMO, in case that needs saying) to change your perspective and think primarily in terms of what happens in the abstract machine, not what happens in a compiler.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-08 10:42 -0800 |
| Message-ID | <76931ca0-302c-4a9e-888f-0f6106ceebb5@googlegroups.com> |
| In reply to | #78186 |
On Tuesday, December 8, 2015 at 11:04:58 AM UTC-6, Tim Rentsch wrote: > The difficulty is that the semantics of C is defined in terms of > what happens in the abstract machine, not how code is (or might > be) compiled. It would be better for you (IMO, in case that > needs saying) to change your perspective and think primarily in > terms of what happens in the abstract machine, not what happens > in a compiler. The whole purpose of most C compilers is to produce executable code that will run on real machines. Since C was designed for systems programming, K&R clearly intended that constructs in the language which map cleanly to constructs on a real machine should use those constructs, and those which do not should be virtualized as needed. I think some of the people on the first Standards Committee had a rather different vision for the language, with an abstract machine that is rather more abstract than what K&R intended. The net effect is a language which simultaneously forces programmers to jump through hoops to do things that should be very easy, but also forces compilers to go generate extra code to handle a lot of corner-case situations programmers don't care about. I think there's far too much emphasis on trying to pretend C is one language rather than a family of dialects, when what is *needed* is a family of dialects, and what would be helpful would be to unify the dialects such that anything which can be expressed in one dialect can be expressed in a way which will in all other dialects either have the same meaning *or be rejected altogether*. Failure to acknowledge that different dialects will be required for different purposes has fragmented the language far more than would recognition of such differences.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-08 10:54 -0800 |
| Message-ID | <ln1tawojnv.fsf@kst-u.example.com> |
| In reply to | #78194 |
supercat@casperkitty.com writes:
> On Tuesday, December 8, 2015 at 11:04:58 AM UTC-6, Tim Rentsch wrote:
>> The difficulty is that the semantics of C is defined in terms of
>> what happens in the abstract machine, not how code is (or might
>> be) compiled. It would be better for you (IMO, in case that
>> needs saying) to change your perspective and think primarily in
>> terms of what happens in the abstract machine, not what happens
>> in a compiler.
>
> The whole purpose of most C compilers is to produce executable code that
> will run on real machines.
The purpose of a C compiler is to generate an executable program that
behaves as the source program specifies. Generating CPU instructions is
how it achieves that purpose.
Attempting to define the behavior of C code in terms of actual CPU
instructions is in my opinion impractical, since target systems vary so
widely, and in ways that are outside the scope of a language standard.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-08 11:44 -0800 |
| Message-ID | <d0e3a0fb-d299-46e4-9f31-3f10a4cc2622@googlegroups.com> |
| In reply to | #78197 |
On Tuesday, December 8, 2015 at 12:54:52 PM UTC-6, Keith Thompson wrote: > Attempting to define the behavior of C code in terms of actual CPU > instructions is in my opinion impractical, since target systems vary so > widely, and in ways that are outside the scope of a language standard. Certain things vary widely among target systems. Some other things do not. If 90+% of systems can readily support certain features, 5% could emulate them, and 5% can't accommodate them at all, if all new systems routinely accommodate the features by design, and if algorithms could be expressed more cleanly using such features than without them, is there any reason that code which will never have to run on the 5% of machines that can't handle those features shouldn't use them? As written, the C Standard mostly operated on an abstract machine where memory is made up of char-sized units, and almost all statements had behavior which could be characterized in terms of reading some memory locations, performing some computations upon the values read, and writing other memory locations, or else making calls to outside libraries. If one is willing to grant a compiler freedom in reordering and consolidating operations, provided that certain programmer-specified constraints are upheld, what else would one need to change about that execution model to make it "practical"?
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-12-09 00:11 +0000 |
| Message-ID | <n47rjs$9ub$1@speranza.aioe.org> |
| In reply to | #78197 |
Keith Thompson <kst-u@mib.org> wrote: > supercat@casperkitty.com writes: >> On Tuesday, December 8, 2015 at 11:04:58 AM UTC-6, Tim Rentsch wrote: >>> The difficulty is that the semantics of C is defined in terms of >>> what happens in the abstract machine, not how code is (or might >>> be) compiled. It would be better for you (IMO, in case that >>> needs saying) to change your perspective and think primarily in >>> terms of what happens in the abstract machine, not what happens >>> in a compiler. >> The whole purpose of most C compilers is to produce executable code that >> will run on real machines. > The purpose of a C compiler is to generate an executable program that > behaves as the source program specifies. Generating CPU instructions is > how it achieves that purpose. OK, but consider the restriction on shift values, that they be non-negative and less than the bit width of the value being shifted. In the case of an abstract machine, why not an abstract machine that can do negative or large shifts? But the people who build real machines often don't allow for that. There are some that allow for negative shift amount, but most have separate left and right shift instructions. (For comparision purposes, the Fortran ISHFT function allows for either positive or negative shift amounts, and less than or equal to the width of the value being shifted. That complicates the generated code in the case of variable shifts.) > Attempting to define the behavior of C code in terms of actual CPU > instructions is in my opinion impractical, since target systems vary so > widely, and in ways that are outside the scope of a language standard. In general, C is much easier to learn for people who have previously done assembly programming. They are used to thinking about addresses and what happens at an addresed locatation. Also, as above, the properties of instructions like shift. The allowable operations in C tend to be close to those of actual machines, unlike some other languages that I don't need to mention. Most C statements generate code approximately proportional to the size of the C statements. Again, unlike many other languages. -- glen
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-08 16:39 -0800 |
| Message-ID | <41bf6867-7aa0-49af-bb58-48820ec8be28@googlegroups.com> |
| In reply to | #78207 |
On Tuesday, December 8, 2015 at 6:11:53 PM UTC-6, glen herrmannsfeldt wrote: > OK, but consider the restriction on shift values, that they be > non-negative and less than the bit width of the value being shifted. Historically, on 99% of compilers, shifts larger than integer size S would be evaluated one of two ways: dat >> count = dat >> (count-S) [likewise for left-shift] dat >> count = (dat >> (count-1) >>1) [likewise for left-shift] Even if one's hardware used one or the other, that didn't necessarily imply that compilers would behave likewise in all cases (especially when the shift amount was constant) but until recently compilers which would not yield an unspecified choice of one or the other were very rare [note that the generated code on a platform using the latter formulation might take a *very* long time to execute if the shift-count is very large or negative] What's more puzzling is why on a two's-complement machine compilers should be allowed to regard a signed left shift of a negative number as doing anything other than shifting left in cases where all the bits shifted into, out of, and through the sign bit match. > The allowable operations in C tend to be close to those of actual > machines, unlike some other languages that I don't need to mention. > > Most C statements generate code approximately proportional to the > size of the C statements. Again, unlike many other languages. That depends whether one is referring to the language defined by K&R 2nd Edition or the one defined by ANSI et al. In the former kind of C, on typical machines (according to both K&R and my own experience), a suitably- aligned pointer to long may be used to read a group of four consecutive bytes, without regard for how they were written. Such a thing would fit well with what is possible in assembly language. In the latter kind of C, attempting to use a "*long" to read something written as a different type, even using a pointer to an integer which has the same representation, may cause the code to fail in arbitrary ways that have nothing whatsoever to do with any kind of restriction imposed by the processor platform.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-08 19:15 -0800 |
| Message-ID | <lnoae0mhw7.fsf@kst-u.example.com> |
| In reply to | #78207 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> wrote:
[...]
>> The purpose of a C compiler is to generate an executable program that
>> behaves as the source program specifies. Generating CPU instructions is
>> how it achieves that purpose.
>
> OK, but consider the restriction on shift values, that they be
> non-negative and less than the bit width of the value being shifted.
>
> In the case of an abstract machine, why not an abstract machine
> that can do negative or large shifts? But the people who build real
> machines often don't allow for that.
Of course the characteristics of the C abstract machine are influenced
by real machines.
[...]
> In general, C is much easier to learn for people who have previously
> done assembly programming. They are used to thinking about addresses
> and what happens at an addresed locatation. Also, as above, the
> properties of instructions like shift.
>
> The allowable operations in C tend to be close to those of actual
> machines, unlike some other languages that I don't need to mention.
>
> Most C statements generate code approximately proportional to the
> size of the C statements. Again, unlike many other languages.
That's usually true, but I still find it easier to think about C
programs in terms of their behavior rather than the code the compiler
happens to generate for them. (I don't always even know or care what
target CPU I'm generating code for.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-12-09 04:21 +0000 |
| Message-ID | <n48a7e$4it$1@speranza.aioe.org> |
| In reply to | #78217 |
Keith Thompson <kst-u@mib.org> wrote: >> Keith Thompson <kst-u@mib.org> wrote: >>> The purpose of a C compiler is to generate an executable program that >>> behaves as the source program specifies. Generating CPU instructions is >>> how it achieves that purpose. (snip, then I wrote) >> OK, but consider the restriction on shift values, that they be >> non-negative and less than the bit width of the value being shifted. >> In the case of an abstract machine, why not an abstract machine >> that can do negative or large shifts? But the people who build real >> machines often don't allow for that. > Of course the characteristics of the C abstract machine are influenced > by real machines. As noted, not all languages do that. In the case of shift, there might be a high overhead for a case that never actually occurs. C forces the programmer to consider that case only when necessary, though one does have to remember. My first contribution to the Hercules IBM mainframe emulator was remembering that S/360 does shifts modulo 64, even on 32 bit values. Trying to run OS/360, it failed at some point. > [...] >> In general, C is much easier to learn for people who have previously >> done assembly programming. They are used to thinking about addresses >> and what happens at an addresed locatation. Also, as above, the >> properties of instructions like shift. >> The allowable operations in C tend to be close to those of actual >> machines, unlike some other languages that I don't need to mention. >> Most C statements generate code approximately proportional to the >> size of the C statements. Again, unlike many other languages. > That's usually true, but I still find it easier to think about C > programs in terms of their behavior rather than the code the compiler > happens to generate for them. (I don't always even know or care what > target CPU I'm generating code for.) To me, mostly it is that you don't have to think about it. In some languages, it is very easy to write something very inefficient in a small number of statements, and not realize it. Not so easy to do in C. -- glen
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-09 09:04 -0800 |
| Message-ID | <bc84f78b-581b-40a2-9658-5d1a541ea39d@googlegroups.com> |
| In reply to | #78220 |
On Tuesday, December 8, 2015 at 10:21:11 PM UTC-6, glen herrmannsfeldt wrote:
> In the case of shift, there might be a high overhead for a case
> that never actually occurs. C forces the programmer to consider
> that case only when necessary, though one does have to remember.
Suppose a programmer wants an expression which yields:
(y & __UNSPECIFIED_INT) >= 32 ? 0 : x << (y & 31);
in time proportional to, at worst, (unsigned)y. A typical scenario would
be a program like an audiovisual decoder which is allowed to generate
arbitrary pixel/sample data when given invalid input but should not expose
any security holes. I would guess that on 99+% of processors, the most
natural and efficient way of computing x>>y would abide the above
requirements, and I'd be surprised if there were any where abiding by those
requirements for unknown values of y would have more than 20% speed penalty
or two-instruction code-space penalty versus allowing unbounded UB [the only
scenario I can see where there would be any penalty would be in an
implementation which used a jump table for shift-by-n, and abiding the
requirements would require adding a "masking" instruction].
Imposing any specific behavior, whether at the compiler or user-code level,
will impair efficiency, but the cost of constraining the behavior to a level
sufficient to prevent security holes would be negligible.
> In some languages, it is very easy to write something very inefficient
> in a small number of statements, and not realize it. Not so easy
> to do in C.
int buff_size;
unsigned char *buff;
void get_buff(unsigned char *dest)
{
for (int i=0; i<buff_size; i++)
dest[i] = buff[i];
}
Can you spot the inefficiency which could, on a good compiler, cause an
order-of-magnitude slowdown compared with optimal code?
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-12-08 22:15 -0600 |
| Message-ID | <n489oj$tg4$1@dont-email.me> |
| In reply to | #78194 |
On 08-Dec-15 12:42, supercat@casperkitty.com wrote: > Tim Rentsch wrote: >> The difficulty is that the semantics of C is defined in terms of >> what happens in the abstract machine, not how code is (or might be) >> compiled. It would be better for you (IMO, in case that needs >> saying) to change your perspective and think primarily in terms of >> what happens in the abstract machine, not what happens in a >> compiler. > > The whole purpose of most C compilers is to produce executable code > that will run on real machines. Since C was designed for systems > programming, K&R clearly intended that constructs in the language > which map cleanly to constructs on a real machine should use those > constructs, and those which do not should be virtualized as needed. > I think some of the people on the first Standards Committee had a > rather different vision for the language, with an abstract machine > that is rather more abstract than what K&R intended. I think the abstract machine thing is a red herring. K&R wrote a language for one machine, then it was ported to another, then another, and eventually there were dozens of C implementations written by many different folks that behaved similarly in most cases but notably not _all_ cases. K&R and then ANSI/ISO tried to bring order to this mess, but in practice that has mostly amounted to documenting the behavior common to most/all existing implementations and leaving the rest as implementation-defined, unspecified or undefined. > The net effect is a language which simultaneously forces programmers > to jump through hoops to do things that should be very easy, but also > forces compilers to go generate extra code to handle a lot of > corner-case situations programmers don't care about. The abstract machine is merely an explanatory device, and it was the obvious intent that each operation in the abstract machine could be mapped to a wide variety of concrete machines. The more concrete machines look like the abstract machine, which has been an overwhelming trend for the last 30+ years, the easier that mapping gets, but at the same time C retained its ability to run on concrete machines that look very different. > I think there's far too much emphasis on trying to pretend C is one > language rather than a family of dialects, when what is *needed* is > a family of dialects, and what would be helpful would be to unify > the dialects Trying to unify the bewildering variety of C dialects was the entire point of standardization! I can't figure out if you're arguing that standardization went too far or not far enough--or perhaps both at the same time. > such that anything which can be expressed in one dialect can be > expressed in a way which will in all other dialects either have the > same meaning *or be rejected altogether*. Does that mean you want to eliminate all implementation-defined, unspecified and undefined behavior? For instance, should we define an int as exactly 32 bits, and every implementation would be required to have that--even if that meant enormous overhead on systems with another natural size? For instance, should we prohibit trap representations, making it impossible to implement C on systems that have them? Or should we mandate that all systems implement trap representations--even if that meant enormous overhead to fake them on systems that don't? There's a _reason_ C is the way it is. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-09 07:04 -0800 |
| Message-ID | <b5c72dd8-cfaf-4d1e-b9ad-2d6a84c8c936@googlegroups.com> |
| In reply to | #78219 |
On Tuesday, December 8, 2015 at 10:15:55 PM UTC-6, Stephen Sprunk wrote: > > such that anything which can be expressed in one dialect can be > > expressed in a way which will in all other dialects either have the > > same meaning *or be rejected altogether*. > > Does that mean you want to eliminate all implementation-defined, > unspecified and undefined behavior? I would like to replace most of it with Testably Specified Behavior and Testably Constrained Behavior. For most forms of IB or UB, 90% of implementations will do, or can be configured to do, one of a small number of things (some of which may be defined in vague terms, such as "yield an unspecified value"). A standard can't hope to predict everything that might happen, but there's no reason it shouldn't handle the 90% of cases that it can. > For instance, should we define an int as exactly 32 bits, and every > implementation would be required to have that--even if that meant > enormous overhead on systems with another natural size? No, but there should be a way for a program to say that it needs a type which behaves the way a uint32 behaves on a system where "int" is 32 bits and indicate whether or not padding is acceptable. If code which could accept padding used a type which allowed for that, 36-bit implementations could then run such code without modification by adding masking instructions. > For instance, should we prohibit trap representations, making it > impossible to implement C on systems that have them? Or should we > mandate that all systems implement trap representations--even if that > meant enormous overhead to fake them on systems that don't? > > There's a _reason_ C is the way it is. No--merely provide a means by which C implementations can report what features and guarantees they do and do not support. That way programs which can be written more cleanly via use of guarantees that will be satisfied by the systems to which they're likely to be targeted can be written more cleanly than would be possible in today's C, while still guaranteeing that they won't behave erroneously on other systems (if a program needs to be ported to a system where it refuses compilation, fixing it will be a lot easier than if it compiles clean but simple fails in weird and bizarre fashion).
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-12-09 14:29 -0600 |
| Message-ID | <n4a2qs$8as$1@dont-email.me> |
| In reply to | #78244 |
On 09-Dec-15 09:04, supercat@casperkitty.com wrote: > Stephen Sprunk wrote: >>> such that anything which can be expressed in one dialect can be >>> expressed in a way which will in all other dialects either have >>> the same meaning *or be rejected altogether*. >> >> Does that mean you want to eliminate all implementation-defined, >> unspecified and undefined behavior? > > I would like to replace most of it with Testably Specified Behavior > and Testably Constrained Behavior. For most forms of IB or UB, 90% > of implementations will do, or can be configured to do, one of a > small number of things (some of which may be defined in vague terms, > such as "yield an unspecified value"). A standard can't hope to > predict everything that might happen, but there's no reason it > shouldn't handle the 90% of cases that it can. That is what the Standard _already_ does: the vast majority of behavior is defined (because every implementation does the same thing), and a tiny minority is left to implementations' discretion. You seem to accept _some_ things will never be fully defined, so it seems you're just arguing that the line needs to be moved slightly, not that the line needs to go away, which is an entirely different thing. >> For instance, should we define an int as exactly 32 bits, and >> every implementation would be required to have that--even if that >> meant enormous overhead on systems with another natural size? > > No, but there should be a way for a program to say that it needs a > type which behaves the way a uint32 behaves on a system where "int" > is 32 bits and indicate whether or not padding is acceptable. If > code which could accept padding used a type which allowed for that, > 36-bit implementations could then run such code without modification > by adding masking instructions. AFAIK, there is nothing stopping a 36-bit implementation from offering uint32_t via emulation. If none do, that would seem to indicate that nobody cares. >> For instance, should we prohibit trap representations, making it >> impossible to implement C on systems that have them? Or should we >> mandate that all systems implement trap representations--even if >> that meant enormous overhead to fake them on systems that don't? > > No--merely provide a means by which C implementations can report what > features and guarantees they do and do not support. That way programs > which can be written more cleanly via use of guarantees that will be > satisfied by the systems to which they're likely to be targeted can > be written more cleanly than would be possible in today's C, while > still guaranteeing that they won't behave erroneously on other > systems (if a program needs to be ported to a system where it refuses > compilation, fixing it will be a lot easier than if it compiles clean > but simple fails in weird and bizarre fashion). This much I think I actually agree with. For instance, I have no objection to a standardized mechanism to report _optional_ guarantees beyond the Standard's minima so one could do something like this: #ifndef __twos_complement #error "Platform not supported" #endif Heck, you could even sprinkle some syntactic sugar: #require twos-complement This seems like a reasonable proposal to the Committee--and a trivial change for implementations that already _do_ offer those optional guarantees, just via documentation rather than via code. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-09 13:06 -0800 |
| Message-ID | <lnbn9zl4bv.fsf@kst-u.example.com> |
| In reply to | #78286 |
Stephen Sprunk <stephen@sprunk.org> writes:
[...]
> AFAIK, there is nothing stopping a 36-bit implementation from offering
> uint32_t via emulation. If none do, that would seem to indicate that
> nobody cares.
uint32_t is not allowed to have padding bits, which means that
CHAR_BIT * sizeof (uint32_t) == 32
which means that the implementation would have to make CHAR_BIT
either 8, 16, or 32. Certainly it can do so via emulation, but
then it would impossible to define, for example, unsigned int with
a range of 0..2**36-1 and no padding bits.
I think the lack of 36-bit implementations offering uint32_t is a
symptom of the lack of 36-bit implementations. Are there any C99 or C11
implementations for such a system?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[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