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 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-16 12:47 -0800 |
| Message-ID | <54abc489-5c40-46a1-b69d-b31c6332fdb5@googlegroups.com> |
| In reply to | #78783 |
On Tuesday, December 15, 2015 at 6:30:38 PM UTC-6, Keith Thompson wrote: > Assuming for the sake of argument that these are useful, I don't think > it's necessary to add some new "directive" syntax to the language to > deal with them. Instead, I might suggest adding some new conditional > feature macros on top of the ones that are already defined in N1570 > 6.10.8.3. For example, an implementation might predefine: > > * __STDC_NULL_POINTER_IS_ZERO__ if zeroing a pointer object (of any > type?) sets it to null, > > * __STDC_FLOAT_ZERO_IS_ZERO__ if zeroing a floating-point > object (of any type?) sets it to 0.0, > > * __STDC_UNIQUE_INTEGER_REPRESENTATIONS__ if two integer objects with > the same value are guaranteed to have the same value, There are a few advantages to having programs specify requirements: 1. Having implementations adjust behavior based upon the specified requirements may be more convenient than merely receiving an error message that indicates that the compiler doesn't meet requirements as configured, but says nothing about whether it could be configured to meet requirements. If an implementation refuses to compile a program that specifies requirements it can't handle as configured, it will be in a much better position to indicate whether something might be done to let it meet requirements. 2. If a program refuses to compile on some compilers because it hits an #error directive, it may be difficult to say whether such refusal is a consequence of the program not being strictly-extended-C conformant. By contrast, if there exists a combination of features/guarantees which would be free of contradictions, and the program would work correctly on all compilers which provide/honor those features/guarantees, then the program could be defined as being strictly-extended-C conformant subject to those specific requirements. 3. Efficient code generation may require having directives or intrinsics that act as something other than no-ops. For example, if a programmer needs to allow things written as any type before code reaches a certain point must be readable as any type afterward, that could be accomplished by using the equivalent of no-strict-aliasing for the entire translation unit, but a directive which merely required a compiler to apply the stated semantics at a particular spot in the code could be accommodated with much less effect on performance. If the language adds a normative requirement that code *should* use certain directives to mark places where a compiler would need to acknowledge aliasing of different types, along with a directive that would authorize a compiler to assume that all such places within a translation unit--even those which use character types--have been so marked, that would provide a migration path toward a language where compilers could make many more useful assumptions about aliasing than are possible today, but which also allowed programmer far more ability to use various kinds of aliasing to their advantage.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-15 14:32 -0800 |
| Message-ID | <c1a2b55b-d186-4ca8-85fd-10c927ab378b@googlegroups.com> |
| In reply to | #78773 |
Apologies for failed word-wrap. The list, Take Two Zeroing memory holding pointers sets them to null. Zeroing memory holding floats sets them to valid zero. Integer representations are unique [looser requirement than no padding; allows memcmp to check if arrays of integers hold equal values] Pointer representations are unique [so memcmp can be used to check if arrays of pointers hold equal pointers] Unrelated-pointer comparisons rank all objects in non-overlapping fashion. Unrelated-pointer comparisons yield a transitive ranking which does not necessarily distinguish pointers to different objects. Unrelated-pointer comparisons will yield zero or one in some fashion, with no other side-effect. Conversions from unsigned to signed and vice versa are representation- preserving, and narrowing conversions to signed types preserve the lower bits while dropping the upper ones. Overflowed integer calculations which cannot yield correct results trap in a fashion that can prevent calculation of seemingly-valid-but-wrong output [I think some historical machines did this, and some code relied upon it] Overflowed integer calculations will be reduced in two's-complement fashion. Overflowed integer calculations yield some kind of value with no side- effect; storing such a value to a variable may truncate it to any size at least as large as the variable, but after that the variable will hold the value written. Overflowed integer calculations yield a partially-indeterminate value whose lower bits will be accurate mod 2^n but whose upper bits may appear different each time they're read back, but neither the calculation nor reading of such a value will have any other side-effect. Overflowed integer calculations yield an indeterminate value which, if stored, may appear different each time it's read back, but neither the calculation nor the reading of the value will have any other side- effect. Right-shift works in two's-complement arithmetic sign-extended fashion. Left-shift of negative numbers works in two's-complement form, blindly discarding upper bits. Left-shift of negative numbers works in two's-cmplement form if all discarded bits match the upper bit of the result. Applying most operators, including multiplication, to any values of any unsigned types will always yield a value which, if assigned to that the same unsigned type, will yield mod-reduced result, even in cases where integer promotions would cause Undefined Behavior. All pointers types have the same representation, and conversions among them are representation-conserving. The rules restricting the use of pointers for type punning are not considered applicable to things written outside a function and read within it, or things written inside a function and read outside it. An object of any integer type which has heap storage class or is part of an array may be read or written with any other integer type [a weakening of the rules which would fix many problematic situations while allowing many useful optimizations]. A pointer of any type which has heap storage class or is part of an array may be read as any other pointer type with the same level of indirection; a pointer with "void" at the bottom shall be for purposes of aliasing be regarded a a "universal" pointer for that level of indirection (thus being able to identify a pointer to more-deeply- indirected type). The pointer returned from realloc may be compared to the pointer passed in, and if they match all existing pointers to the object or parts thereof will remain valid. If a pointer identifies part of an object which was moved via realloc, the difference between that pointer and the old base pointer of the allocation may be computed afterward and will be the same as it was before [so (char*)inside_ptr-(char*)old_base+(char*)new_base will identify the same part of the relocated object as inside_ptr had identified in the old]. If one unsigned type is twice as large as another, the layout of the latter type will be equivalent to two of the smaller type stored consecutively, with one member of the smaller type holding the upper value bits and the other holding the lower value bits, each half will have its bits in the same order of the original, and for all types in a system the ordering will be consistently big-endian or consistently little-endian. Calling memcpy with identical source and destination operands may or may not do the copy, but will have no other side-effects. If memcpy or memmove is called with a size of zero it will ignore its pointer operands. Each element of a structure will be placed at the first location which satisfies its alignment, and arrays will have the same alignment requirements as individual elements.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-12-09 08:09 -0800 |
| Message-ID | <70e04f06-9d81-4efa-8b67-2c81dbb7ad8b@googlegroups.com> |
| In reply to | #78219 |
On Wednesday, 9 December 2015 06:15:55 UTC+2, Stephen Sprunk wrote: > > 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? It would be possible fix nice readable words (like 'byte', 'short', 'int' and 'long') to have exact meanings and leave the hairy names (like 'int_fast16_t') for optimizations. If the computer science evolves and discovers that six trits are far superior than eight bits then we would need to reform something anyway. > > 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? Yes, and those too. Types with saturating silent NANs or trap representations are likely possible to emulate anywhere. However it is unclear why those should share names with types that on 99.9% of cases lack those capabilities. Result is that big part of simple math is undefined or implementation defined behavior. > > There's a _reason_ C is the way it is. Sure, there is. However now we are in situation where some coding standards (like MISRA C) outright forbid lot of us to use those nice readable names because C is the way it is.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-09 09:10 -0800 |
| Message-ID | <9057b577-3434-4607-bebe-8741ee293a36@googlegroups.com> |
| In reply to | #78253 |
On Wednesday, December 9, 2015 at 10:10:22 AM UTC-6, Öö Tiib wrote:
> Sure, there is. However now we are in situation where some coding standards
> (like MISRA C) outright forbid lot of us to use those nice readable names
> because C is the way it is.
Suppose one is writing a hash or checksum function that needs to compute the
product of two 16-bit values mod 65536. Do you see a problem with the
following code? I'm unaware of anything in MISRA that would catch it:
uint16_t mul16(uint16_t x, uint16_y y)
{
return (uint16_t)(x*y);
}
On a system where "int" is 16 bits, the behavior of the above code would
be well-defined in case x and y were 65533. Because 65533*65533 is
4294574089, and 4294574089 mod 65536 is 9, the return value would be well-
defined as 9. How about on a 32-bit system, though?
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-12-09 10:38 -0800 |
| Message-ID | <d5e96e96-db88-4275-9c65-a457c7bc2afe@googlegroups.com> |
| In reply to | #78261 |
On Wednesday, 9 December 2015 19:10:54 UTC+2, supe...@casperkitty.com wrote:
> On Wednesday, December 9, 2015 at 10:10:22 AM UTC-6, Öö Tiib wrote:
> > Sure, there is. However now we are in situation where some coding standards
> > (like MISRA C) outright forbid lot of us to use those nice readable names
> > because C is the way it is.
>
> Suppose one is writing a hash or checksum function that needs to compute the
> product of two 16-bit values mod 65536. Do you see a problem with the
> following code? I'm unaware of anything in MISRA that would catch it:
>
> uint16_t mul16(uint16_t x, uint16_y y)
> {
> return (uint16_t)(x*y);
> }
No, MISRA don't catch anything (assuming that 'uint16_y' was fast typing
tyop).
>
> On a system where "int" is 16 bits, the behavior of the above code would
> be well-defined in case x and y were 65533. Because 65533*65533 is
> 4294574089, and 4294574089 mod 65536 is 9, the return value would be well-
> defined as 9. How about on a 32-bit system, though?
I trust there is overflow on 32-bit computer since 4294574089 does not
fit into 'signed int' that is result of 'x*y'. So it is undefined
behavior AFAIK.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-09 11:18 -0800 |
| Message-ID | <d32ed8e4-984f-4cca-873c-da3afcd6c42d@googlegroups.com> |
| In reply to | #78266 |
On Wednesday, December 9, 2015 at 12:38:57 PM UTC-6, Öö Tiib wrote: > I trust there is overflow on 32-bit computer since 4294574089 does not > fit into 'signed int' that is result of 'x*y'. So it is undefined > behavior AFAIK. It is. I would suggest that there should be something in *some* standard somewhere, which would mandate that compilers generating code for automotive or other safety-critical uses, must not treat such code as Undefined Behavior. Some good may come in some cases from allowing compilers to trap such computations in Implementation-Defined fashion, but I see no way in which the present rules are better than what would result from saying that if the result of certain operators or combinations thereof is coerced to a result no larger than "unsigned int", the computation must be performed on unsigned types unless the result would differ from using signed types in some defined (possibly Implementation-Defined) fashion. Note that such a rule would not change the effect of any code whose behavior is defined on any particular platform, and would not impose any burden upon compilers except to refrain from certain optimizations which would be unlikely to help code perform required tasks efficiently but would be much more likely to cause code to fail at its required tasks.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-12-09 19:14 +0000 |
| Message-ID | <n49uig$u2h$1@speranza.aioe.org> |
| In reply to | #78253 |
Öö Tiib <ootiib@hot.ee> wrote: > On Wednesday, 9 December 2015 06:15:55 UTC+2, Stephen Sprunk wrote: >> 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? > It would be possible fix nice readable words (like 'byte', 'short', 'int' > and 'long') to have exact meanings and leave the hairy names (like > 'int_fast16_t') for optimizations. You mean like Java? Java also defines floating point to be IEEE 754 single and double precision. Rumors are that IBM added IEEE (they call it BFP, or Binary Floating Point) to ESA/390 so it could run Java. I haven't heard complaints from PDP-10 users about not being able to run Java. > If the computer science evolves and discovers that six trits are far > superior than eight bits then we would need to reform something > anyway. (snip) -- glen
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-09 11:27 -0800 |
| Message-ID | <fbfac6c9-d8a9-4643-af9d-7ca45cf8f0fe@googlegroups.com> |
| In reply to | #78273 |
On Wednesday, December 9, 2015 at 1:14:37 PM UTC-6, glen herrmannsfeldt wrote: > > It would be possible fix nice readable words (like 'byte', 'short', 'int' > > and 'long') to have exact meanings and leave the hairy names (like > > 'int_fast16_t') for optimizations. > > You mean like Java? A good language should have primary integer types which size themselves according to the implementation, but should *also* have integer types whose representation and behaviors can be specified, as loosely or tightly as required, in platform-agnostic fashion. Java has the latter, but not the former; C has the former, but not the latter. Making the latter really workable for C may require a major revisiting of type-based aliasing rules, but since they already pose problems with the existing type system (e.g. even on a platform where "int32_t", "int", and "long" all have bit-identical representations, there is no defined safe way to have a function from one library which expects an "int*" to operate on the same array as a second library which expects an "int32_t*" and a third which expects a "long*") adding ways to specify what things may alias what other things would be a useful addition in any case.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-12-09 15:03 -0600 |
| Message-ID | <n4a4pj$ged$1@dont-email.me> |
| In reply to | #78253 |
On 09-Dec-15 10:09, Öö Tiib wrote: > Stephen Sprunk wrote: >> 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? > > It would be possible fix nice readable words (like 'byte', 'short', > 'int' and 'long') to have exact meanings and leave the hairy names > (like 'int_fast16_t') for optimizations. There are _existing_ C implementations with different meanings for those words for good reason, though, so picking any particular meaning means that either C is no longer usable on any other platforms--or programs would incur substantial overhead (to emulate the chosen behavior) even when that isn't necessary. That path seems unwise. The closest I'll come to agreeing here is that, IMHO, C should have separated chars from bytes, but if it was too late to do that 25 years ago, it's certainly too late to do so now. >> 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? > > Yes, and those too. Types with saturating silent NANs or trap > representations are likely possible to emulate anywhere. However it > is unclear why those should share names with types that on 99.9% of > cases lack those capabilities. _Today_ it may be 99.9%, but what if it isn't tomorrow? C has survived enormous change in the industry precisely because it is so adaptable. If it had been fossilized based on what happened to be popular at any particular point in time, it could not have adapted to the next thing that became popular--or to things that are unpopular generally but useful in particular niches. 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 | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-12-10 01:23 -0800 |
| Message-ID | <7b39ca67-c8a3-4df2-be1a-c1deb1ef5e77@googlegroups.com> |
| In reply to | #78290 |
On Wednesday, 9 December 2015 23:03:19 UTC+2, Stephen Sprunk wrote: > On 09-Dec-15 10:09, Öö Tiib wrote: > > Stephen Sprunk wrote: > >> 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? > > > > It would be possible fix nice readable words (like 'byte', 'short', > > 'int' and 'long') to have exact meanings and leave the hairy names > > (like 'int_fast16_t') for optimizations. > > There are _existing_ C implementations with different meanings for those > words for good reason, though, so picking any particular meaning means > that either C is no longer usable on any other platforms--or programs > would incur substantial overhead (to emulate the chosen behavior) even > when that isn't necessary. That path seems unwise. It can be as simple to implement C if some subset of hairy types (like [u]int_least8_t, [u]int_least16_t, [u]int_fast16_t, [u]int_fast32_t and [u]int_least64_t) are required to be implemented and the nice names (with potential implementation and runtime overhead) are not required to be implemented. IOW about same situation like now just the names that coding standards forbid to use anyway can be useful (if implemented) again. > > The closest I'll come to agreeing here is that, IMHO, C should have > separated chars from bytes, but if it was too late to do that 25 years > ago, it's certainly too late to do so now. Yes, even adding 'byte' into language can conflict with lot of existing code and cause rework with compilers. > > >> 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? > > > > Yes, and those too. Types with saturating silent NANs or trap > > representations are likely possible to emulate anywhere. However it > > is unclear why those should share names with types that on 99.9% of > > cases lack those capabilities. > > _Today_ it may be 99.9%, but what if it isn't tomorrow? Tomorrow in current situation is like that the subset of code that assumes anyway that things are like today do not work. The subset of code that uses hairy names that have more guarantees won't compile (since the guarantees are expensive to implement). My change would just make it incorrect to call six trits with trap representations, silent NANs and what not as 'char' or 'byte'. So the implementers have to use more fitting name ... like 'brute'. ;) > > C has survived enormous change in the industry precisely because it is > so adaptable. If it had been fossilized based on what happened to be > popular at any particular point in time, it could not have adapted to > the next thing that became popular--or to things that are unpopular > generally but useful in particular niches. I trust that it is all about being procedural and imperative (that most people grasp most quickly) and being easy to implement for any turing-machine. You misunderstood if you think that I did propose to change any of that.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-12-10 20:21 +0000 |
| Message-ID | <5669decd.28477031@news.xs4all.nl> |
| In reply to | #78253 |
=?ISO-8859-1?Q?=D6=F6_Tiib?= <ootiib@hot.ee> wrote: > On Wednesday, 9 December 2015 06:15:55 UTC+2, Stephen Sprunk wrote: > > > There's a _reason_ C is the way it is. > > Sure, there is. However now we are in situation where some coding standards > (like MISRA C) outright forbid lot of us to use those nice readable names > because C is the way it is. Frankly, that's MISRA's problem (one of many), not C's. Richard
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-12-09 13:06 -0800 |
| Message-ID | <kfnoadztjr3.fsf@x-alumni2.alumni.caltech.edu> |
| 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. 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. I acknowledge your comments. I still make the same recommendation.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-12-09 00:00 +0000 |
| Message-ID | <n47qul$8k1$1@speranza.aioe.org> |
| In reply to | #78186 |
Tim Rentsch <txr@alumni.caltech.edu> wrote: > supercat@casperkitty.com writes: (snip) >> 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. I don't know about supercat, but there are some things I remember that way. They might be more in Fortran, which I learned before C, but there are some things that need to be known at compile time, and by remembering the needs for generating the object code, it is easy to remember which things those are. > 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. Yes, but if you do that, then you miss what needs to be able to be done at compile time. Why is it that C didn't allow for variable length arrays until so recently? Other languages that allow for dynamic (auto) allocation allow for them, when the size is known at block entry. On the other hand, static arrays obviously need a constant expression for their dimensions. -- glen
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-08 16:27 -0800 |
| Message-ID | <f6e4e7db-d017-482e-a459-2bf7e26b4120@googlegroups.com> |
| In reply to | #78206 |
On Tuesday, December 8, 2015 at 6:00:35 PM UTC-6, glen herrmannsfeldt wrote: > Why is it that C didn't allow for variable length arrays until so > recently? Other languages that allow for dynamic (auto) allocation > allow for them, when the size is known at block entry. Having automatic allocation at block entry is not possible unless either (1) a language has a defined means of handling or predicting an inability to allocate the necessary space or predict failure, or (2) nobody cares about being able to handle nor predict such failures. Some languages take the first approach. C99 took the second. IMHO, the second approach is pretty much worthless in a "standard", but other people may differ.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-12-09 01:18 +0000 |
| Message-ID | <87si3c5siq.fsf@bsb.me.uk> |
| In reply to | #78208 |
supercat@casperkitty.com writes: > On Tuesday, December 8, 2015 at 6:00:35 PM UTC-6, glen herrmannsfeldt wrote: >> Why is it that C didn't allow for variable length arrays until so >> recently? Other languages that allow for dynamic (auto) allocation >> allow for them, when the size is known at block entry. > > Having automatic allocation at block entry is not possible unless either > (1) a language has a defined means of handling or predicting an inability > to allocate the necessary space or predict failure, or (2) nobody cares > about being able to handle nor predict such failures. > > Some languages take the first approach. C99 took the second. How does C90 handle or predict the inability to allocate the necessary space for an auto array? Or was your "some languages ... C99" contrast simply intended to mislead one into thinking the specific version actually mattered? > IMHO, the > second approach is pretty much worthless in a "standard", but other people > may differ. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-08 19:13 -0800 |
| Message-ID | <lnsi3cmi0k.fsf@kst-u.example.com> |
| In reply to | #78208 |
supercat@casperkitty.com writes:
> On Tuesday, December 8, 2015 at 6:00:35 PM UTC-6, glen herrmannsfeldt wrote:
>> Why is it that C didn't allow for variable length arrays until so
>> recently? Other languages that allow for dynamic (auto) allocation
>> allow for them, when the size is known at block entry.
>
> Having automatic allocation at block entry is not possible unless either
> (1) a language has a defined means of handling or predicting an inability
> to allocate the necessary space or predict failure, or (2) nobody cares
> about being able to handle nor predict such failures.
>
> Some languages take the first approach. C99 took the second. IMHO, the
> second approach is pretty much worthless in a "standard", but other people
> may differ.
C90 automatic objects (arrays or otherwise) have exactly the same
behavior: if allocation fails, the behavior is undefined.
For some usage patterns, VLAs can make the problem less severe.
In C90, you might define an automatic array that's big enough for
any possible usage; in C99, you can define a VLA that's no bigger
than it needs to be.
--
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-12-09 13:04 -0800 |
| Message-ID | <kfnsi3btjtu.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #78206 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > Tim Rentsch <txr@alumni.caltech.edu> wrote: >> supercat@casperkitty.com writes: > > (snip) > >>> 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. > > I don't know about supercat, but there are some things I remember > that way. > > They might be more in Fortran, which I learned before C, but there > are some things that need to be known at compile time, and by > remembering the needs for generating the object code, it is easy > to remember which things those are. > >> 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. > > Yes, but if you do that, then you miss what needs to be able > to be done at compile time. > > Why is it that C didn't allow for variable length arrays until so > recently? Other languages that allow for dynamic (auto) allocation > allow for them, when the size is known at block entry. > > On the other hand, static arrays obviously need a constant expression > for their dimensions. These comments strike me as being pretty tangential. There is no reason you can't pick any particular machine model you like as being "the abstract machine", as long as the compiler isn't overly smart and as long as it is remembered that the actual machine may be more specific in some areas (eg, having a hardware stack) than the abstract machine. The key is to start with the most simple-minded elaboration, and ignore any issues that come up related to optimization.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-12-10 20:07 +0000 |
| Message-ID | <5669d939.27049421@news.xs4all.nl> |
| In reply to | #77259 |
Tim Rentsch <txr@alumni.caltech.edu> wrote: > Keith Thompson <kst-u@mib.org> writes: > > > 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. While to me, it clearly doesn't access the _old_ stored value of the object, because all it does is clobber over it without looking what it was. The _new_ stored value is accessed, yes, but it's also defined. > > 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: "If such a representation is produced by a side effect that modifies all or any part of the object by an lvalue expression that does not have character type, the behavior is undefined." If you can generate a trap representation and assign it to any object _without_ involving side effects, you're a cleverer programmer than I. Richard
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-23 17:03 +0000 |
| Message-ID | <87k2p8k5qs.fsf@bsb.me.uk> |
| In reply to | #76981 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 11/22/2015 07:58 PM, Ben Bacarisse wrote:
>> Stephen Sprunk <stephen@sprunk.org> writes:
>>
>>> On 21-Nov-15 18:58, Ben Bacarisse wrote:
>>>> Stephen Sprunk <stephen@sprunk.org> writes:
>>>>> On 21-Nov-15 04:17, Ben Bacarisse wrote:
>>>>>> It may well be able to re-order the writes but that does not make
>>>>>> the code shown undefined. It might break something else in the
>>>>>> program, but the example is too brief to know.
>>>>>
>>>>> Okay, here's a very simple example:
>>>>>
>>>>> void foo(float *fp, int *ip) {
>>>>> *fp = 42.0;
>>>>> *ip = 42;
>>>>> printf("%d\n", *ip);
>>>>> }
>>>>>
>>>>> If the compiler doesn't reorder the assignments, then the read is
>>>>> well-defined. However, it is allowed to assume fp and ip are not
>>>>> aliases and thus reorder the assignments, but if they actually are
>>>>> aliases, then the read would become undefined. Correct?
>>>>
>>>> I don't think so. If ip and fp alias then they refer to some common
>>>> object. If that has a declared type of int, then the assignment
>>>> through *fp is undefined because it violates a "shall" in the
>>>> standard. Similarly if it's an object declared to be float. The read
>>>> of *ip is not involved in any of that -- the code is already
>>>> undefined before it gets there.
>
> And the undefined behavior might take the form of causing this function
> to malfunction because the writes are re-ordered. The fact that the
> order only matters if they violate 6.5p7 is what allows the reordering.
>
>>> Thanks; that explains why the pointers' origin matters.
>>>
>>>> But there is an other case. If ip and fp both point to the same
>>>> properly sized and aligned allocated storage, then there is nothing
>>>> wrong with the above code. The effective type rules mean that
>>>> allocated storage gets it's effective type from the type of the
>>>> lvalue expression last used to write it.
>
> 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.
I disagree. Paragraph 6 tells you *how* to determine the effective
type, then paragraph 7 tells you how to use that information. From
paragraph 6:
"If a value is stored into an object having no declared type through
an lvalue having a type that is not a character type, then the type of
the lvalue becomes the effective type of the object for that access
and for subsequent accesses that do not modify the stored value."
Had your meaning been intended, the exclusion of subsequent accesses
that *do* modify the stored value would not be there. It could also
have simply stated the rule for objects that do not yet have an
effective type rather than for those that have no declared type. There
are several ways to convey your reading, and all of the them seem to me
simpler than the words actually used.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-23 15:39 -0800 |
| Message-ID | <73ad97f9-0441-4ff9-93e5-0b3eb7dc3593@googlegroups.com> |
| In reply to | #77010 |
On Monday, November 23, 2015 at 11:03:47 AM UTC-6, Ben Bacarisse wrote:
> Had your meaning been intended, the exclusion of subsequent accesses
> that *do* modify the stored value would not be there. It could also
> have simply stated the rule for objects that do not yet have an
> effective type rather than for those that have no declared type. There
> are several ways to convey your reading, and all of the them seem to me
> simpler than the words actually used.
How would you interpret the following code:
// A real re-entrant memory manager would need to be more than this of
// course...
volatile void *next_block; // Assume it gets initialized somehow
void *quick_alloc(void) { void *result = *q; *q=0; return result; }
void quick_free(void* ptr) { next_block = ptr; }
int test(FILE *someFile)
{
float *fp = quick_alloc();
*fp = 12.34;
quick_free(fp);
int *ip = quick_alloc();
fread(ip, sizeof(int), 1, someFile);
int ii = *ip;
quick_free(ip);
return ii;
}
Would anything in the Standard require that the write to fp occur before
the fread? If the second quick_alloc returns a different block from the
first (which could happen, since the pointer source is volatile) then it
won't matter if the write to fp is deferred. If the second alloc returns
the same block, the effective type of that block will be "float" before
the fread, which presumably writes the data using some character type,
which would be permissible, but I don't see anything in the Standard that
would indicate that the fread would then cause the succeeding usage as
type "int" to be legitimate.
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web