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 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-09 15:49 -0800 |
| Message-ID | <c9165096-d2ff-4182-8a36-4dc17667c703@googlegroups.com> |
| In reply to | #78311 |
On Wednesday, December 9, 2015 at 5:18:15 PM UTC-6, glen herrmannsfeldt wrote: > There is a claim, I believe for Fortran, that: > > echo "Implementation limit exceeded." > > is a valid, but as you note useless, compiler. I am not sure about C. It's almost true for C. There are only two caveats: (1) A compliant C compiler must be able to translate and run at least one C program, though the one program that a compiler translates need not have any purpose beyond producing the same message that would be produced on an invalid program; (2) an #error directive is required to make the compiler output a message that follows it; I think it's required to apply preprocessor substitutions as well. That implies a compiler would need to do a little bit of work, but wouldn't need to do much of anything useful. > > The uintN_t types are forbidden from including padding, so a 36-bit > > machine couldn't emulate a 32-bit one. Further, the Standard mandates > > the existence of two different kinds of "uintN_t" types--those where N > > is smaller than the number of bits in "int", and those where N is not. > > A lot of existing code expects that uint32_t is of the latter kind, and > > may fail in interesting ways if it is not. > > As far as I know, a 36 bit machine can emulate a 32 bit machine, > but it can't half emulate one. If the Standard defined a category of types that behaved like algebraic rings mod 2^N but didn't specify padding or lack thereof, then any machine could offer such types in arbitrary sizes which need not have any relation to the word size. A 36-bit machine could probably perform computations on a 36-bit wrapping type more efficiently than a on a 35-bit or 32-bit one, but would be capable of acting on any such type just fine. Further, if the Standard defined a standard means of specifying multi-byte integer types, and a program said "I need a type composed of two subsections, in big- endian order, each of which comprises an aligned pair of "char" values holding 8 bits each in big-endian order, code using such a type could work on any machine regardless of whether it used an 8-bit, 12-bit, or 16-bit "char" type. Operations on such types would be inefficient on machines where the specified format did not match the implementation's native format but on machines whose native format did match such code would be faster than any code that would be portable in today's C, and on machines where it didn't match such code would still work, unlike code which assumes native format. > A machine with uint32_t has to have a CHAR_BIT of 8, 16, or 32, > and so can't have a 36 bit unsigned int. It can have an unsigned int with 36 value bits and some padding bits. What it couldn't have would be a uint36_t, since uintN_t is forbidden from having padding bits. Unfortunately, there aren't any types which are specified as behaving as modular rings of a particular bit length, but are allowed to have padding in their storage. Such things could be very useful when porting some types of code to systems with different sizes of integers. An implementation would be allowed to have an "int" type with 32 value bits, one sign bits, and 31 padding bits, an "unsigned int" type with 32 value bits and 32 padding bits, and an "unsigned short" type with the same representation. Such a type would have the interesting property that incrementing it when it held its maximum value would yield Undefined Behavior.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-12-10 12:44 -0600 |
| Message-ID | <n4ch1c$n52$1@dont-email.me> |
| In reply to | #78297 |
On 09-Dec-15 15:17, supercat@casperkitty.com wrote: > Stephen Sprunk wrote: >>> No--merely provide a means by which C implementations can report >>> what features and guarantees they do and do not support. ... >> >> 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 > > I think that kind of thing is essential for the Standard to mean > something; the tricky part is how to resolve questions of what should > or should not be included. True, but IMHO one should start with a list of all IB, US and UB, and then have to justify _not_ covering any of them. How far to go beyond that is a more nebulous question. > What I'd like to see would be a syntax which, while clunky, would > allow existing compilers that support required features to be used > without any modification beyond the addition of some header files, > and would result in compilers that can't support such features > refusing compilation. Many important things can already be detected, just a bit verbosely, but many of the ones that can't would require compiler support. On the plus side, the latter should be a trivial change. > For compilers where support is controlled by command-line switches > or pragmas, a demand for a feature could either enable it via pragma > or check for the proper command-line switch setting (and refuse > compilation if the switch wasn't set properly). One thought for the #require version above is that a compiler that _normally_ doesn't meet a requirement could automatically enable an option that would allow meeting it in response to such a directive. For the #ifndef version, if the compiler doesn't have the right flags, all the program can do is #error out and hope the user will figure out the right compiler switches and retry. 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-10 11:12 -0800 |
| Message-ID | <35df6424-14c4-4cf6-a3c3-fda6d5d1a201@googlegroups.com> |
| In reply to | #78353 |
On Thursday, December 10, 2015 at 12:44:33 PM UTC-6, Stephen Sprunk wrote: > On 09-Dec-15 15:17, supercat wrote: > > What I'd like to see would be a syntax which, while clunky, would > > allow existing compilers that support required features to be used > > without any modification beyond the addition of some header files, > > and would result in compilers that can't support such features > > refusing compilation. > > Many important things can already be detected, just a bit verbosely, but > many of the ones that can't would require compiler support. A lot can't. While "hope for the best" semantics generally suffice because--contrary to appearances--most compiler writers aren't actually evil, the present Standard provides no mechanism for programs to ensure that e.g. conversion from "uint16_t" to "int16_t" will always use two's- complement reduction. It would be legitimate for a compiler to document that it will almost always do so except in some weird bizarre cases, if its generated code matched such documentation; I don't think there's any way a programmer could hope to anticipate such behavior. > On the plus side, the latter should be a trivial change. Alternatively, a compiler which can't doesn't have macros to test command-line settings but does allow pragmas to override them could specify that code needing certain options must use "-dOPTIONNAME" to define macros enabling those options, and then have its <tcsb.h> file invoke the appropriate pragmas if those options are set. > > For compilers where support is controlled by command-line switches > > or pragmas, a demand for a feature could either enable it via pragma > > or check for the proper command-line switch setting (and refuse > > compilation if the switch wasn't set properly). > > One thought for the #require version above is that a compiler that > _normally_ doesn't meet a requirement could automatically enable an > option that would allow meeting it in response to such a directive. Even if a compiler required settings to be configured on the command line, the compiler's error message--even if they were generated by the compiler's header file, could supply compiler-specific information about how to set those options. > For the #ifndef version, if the compiler doesn't have the right flags, > all the program can do is #error out and hope the user will figure out > the right compiler switches and retry. Still a huge improvement, though, over having a program that mostly works but fails at weird times for no apparent reason, wouldn't you say?
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-12-10 20:18 +0000 |
| Message-ID | <5669dbb8.27688187@news.xs4all.nl> |
| In reply to | #78286 |
Stephen Sprunk <stephen@sprunk.org> wrote: > 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. Not necessarily for implementations that don't, though - and you'd have to be careful in picking which options get this treatment. Two's complement, sure. (But why discriminate? In that case, one's comp and S/M as well.) But how about how far the register keyword is followed? What happens when you modify a string literal? Which order function call parameters are evaluated in (and good luck specifying the optimisation- prone edge cases!)? Some people insist on knowing that last one... which is not always even possible. Richard
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-10 12:29 -0800 |
| Message-ID | <778a62a4-d26b-44c9-a912-2af9b1a8449a@googlegroups.com> |
| In reply to | #78364 |
On Thursday, December 10, 2015 at 2:18:33 PM UTC-6, Richard Bos wrote: > Not necessarily for implementations that don't, though - and you'd have > to be careful in picking which options get this treatment. Two's > complement, sure. (But why discriminate? In that case, one's comp and > S/M as well.) But how about how far the register keyword is followed? > What happens when you modify a string literal? Which order function call > parameters are evaluated in (and good luck specifying the optimisation- > prone edge cases!)? Some people insist on knowing that last one... which > is not always even possible. All the Standard would need to do is say that any implementation need do to satisfy its obligations is refuse to compile any program whose requirements it will not satisfy; for a program to be a strictly conforming Universal Extensible C program, it must meet two requirements: 1. Compile (and work correctly) with at least one existing implementation. 2. Specify its requirements such that it will work correctly on every compiler which legitimately compiles it. If a reasonable number of behaviors were defined, I would think the percentage of programs which could be "strictly conforming" under that definition would be at least an order of magnitude greater than would be practical under today's definition.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-12-10 16:19 -0600 |
| Message-ID | <n4ctk8$do1$1@dont-email.me> |
| In reply to | #78364 |
On 10-Dec-15 14:18, Richard Bos wrote: > Stephen Sprunk <stephen@sprunk.org> wrote: >> 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. > > Not necessarily for implementations that don't, though It's even more trivial for them; in the former case, don't define the specified macros (i.e. do nothing), and in the latter case, refuse to compile the program at all. Sure, they might instead _choose_ to emulate the desired behavior, but that seems like a QoI issue, not a conformance issue. > - and you'd have to be careful in picking which options get this > treatment. Of course. > Two's complement, sure. (But why discriminate? In that case, one's > comp and S/M as well.) Fairness and thoroughness are admirable, but one should also consider usefulness. Does anyone write programs that _only_ work with those? > But how about how far the register keyword is followed? Why? All that does is prohibit taking the object's address. > What happens when you modify a string literal? Compilers ancient enough to allow that aren't getting updates. > Which order function call parameters are evaluated in (and good luck > specifying the optimisation-prone edge cases!)? Some people insist > on knowing that last one... which is not always even possible. Why? There's already a trivial way to force evaluation of arguments in whichever order you want, so it doesn't seem useful. 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 | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-12-10 22:49 +0000 |
| Message-ID | <566a00ef.37214640@news.xs4all.nl> |
| In reply to | #78379 |
Stephen Sprunk <stephen@sprunk.org> wrote: > On 10-Dec-15 14:18, Richard Bos wrote: > > Stephen Sprunk <stephen@sprunk.org> wrote: > >> #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. > > - and you'd have to be careful in picking which options get this > > treatment. > > Which order function call parameters are evaluated in (and good luck > > specifying the optimisation-prone edge cases!)? Some people insist > > on knowing that last one... which is not always even possible. > > Why? There's already a trivial way to force evaluation of arguments in > whichever order you want, so it doesn't seem useful. Yes, but you know damned well that there'd be an outcry for its inclusion. Whether it would be justified is another matter, but the very same people who now complain about such matters not being concrete-bound _would_ rag on the Committee for not including this very option. Richard
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-10 14:58 -0800 |
| Message-ID | <4693f232-e623-4b2a-a3f0-fa7b2be533be@googlegroups.com> |
| In reply to | #78384 |
On Thursday, December 10, 2015 at 4:49:09 PM UTC-6, Richard Bos wrote: > Stephen Sprunk wrote: > > Why? There's already a trivial way to force evaluation of arguments in > > whichever order you want, so it doesn't seem useful. > > Yes, but you know damned well that there'd be an outcry for its > inclusion. Whether it would be justified is another matter, but the very > same people who now complain about such matters not being concrete-bound > _would_ rag on the Committee for not including this very option. So, simply define define a directive which would require a compiler to either use left-right argument evaluation or refuse compilation (and define another for right-left), and likewise for evaluation of terms within an expression. Any compiler that can honor the requirement could compile code with that directive. Those that can't would refuse compilation.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-12-15 18:25 +0000 |
| Message-ID | <56705b24.13307687@news.xs4all.nl> |
| In reply to | #78385 |
supercat@casperkitty.com wrote: > On Thursday, December 10, 2015 at 4:49:09 PM UTC-6, Richard Bos wrote: > > Stephen Sprunk wrote: > > > Why? There's already a trivial way to force evaluation of arguments in > > > whichever order you want, so it doesn't seem useful. > > > > Yes, but you know damned well that there'd be an outcry for its > > inclusion. Whether it would be justified is another matter, but the very > > same people who now complain about such matters not being concrete-bound > > _would_ rag on the Committee for not including this very option. > > So, simply define define a directive which would require a compiler ...right on cue. Richard
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-15 10:50 -0800 |
| Message-ID | <437e61c3-c8b6-435c-9680-cdee8e0c01d9@googlegroups.com> |
| In reply to | #78764 |
On Tuesday, December 15, 2015 at 12:26:16 PM UTC-6, Richard Bos wrote: > supercat wrote: > > So, simply define define a directive which would require a compiler > > ...right on cue. What's the problem? Rather than having a committee try to guess what features people are going to want, what's wrong with assigning tags rather freely to proposed features, which compilers could then implement or not as they see fit, but know that if they do opt to implement them and other compilers do so as well, the implementations would be compatible? Right now, a compiler vendor that might be inclined to create a new language extension runs the risk that the Committee might decide to extend the language to achieve the same purpose, but do so in a way that is incompatible with the vendor's extension. If the committee were more open to documenting optional extensions, compiler vendors who are considering implementing an extension may not be certain that it would ever be used widely enough to justify the effort, but they would at least have some assurance that if they implement an extension for which a demand exists, their extension would be able to fulfill that demand without being rendered obsolete by a different extension in the standard.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-15 11:32 -0800 |
| Message-ID | <lnwpsfbj90.fsf@kst-u.example.com> |
| In reply to | #78765 |
supercat@casperkitty.com writes:
> On Tuesday, December 15, 2015 at 12:26:16 PM UTC-6, Richard Bos wrote:
>> supercat wrote:
>> > So, simply define define a directive which would require a compiler
>>
>> ...right on cue.
>
> What's the problem?
The problem is that you would add so many directives to the language
that they would practically constitute a new language on top of the
existing one.
--
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-15 12:20 -0800 |
| Message-ID | <41f56c91-61fb-44a1-a7bc-1bd9e943cbc3@googlegroups.com> |
| In reply to | #78768 |
On Tuesday, December 15, 2015 at 1:32:44 PM UTC-6, Keith Thompson wrote: > supercat writes: > > On Tuesday, December 15, 2015 at 12:26:16 PM UTC-6, Richard Bos wrote: > >> supercat wrote: > >> > So, simply define define a directive which would require a compiler > >> > >> ...right on cue. > > > > What's the problem? > > The problem is that you would add so many directives to the language > that they would practically constitute a new language on top of the > existing one. The existing standard is hardly small, and some parts of it impose some pretty significant burdens on compiler writers. My proposed "standard" might have a lot more directives, but most of them would impose *ZERO* obligation on compiler writers beyond refraining from treating identifiers associated with such directives as having any meaning contrary to the Standard. Compiler writers would likely want to look through lists of directives and pro-actively implement ones which may be useful for customers, but they could also see what kinds of directives their customers ask for, or what directives are used by owners of competing compilers.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-15 13:08 -0800 |
| Message-ID | <lnoadrbetk.fsf@kst-u.example.com> |
| In reply to | #78772 |
supercat@casperkitty.com writes:
> On Tuesday, December 15, 2015 at 1:32:44 PM UTC-6, Keith Thompson wrote:
>> supercat writes:
>> > On Tuesday, December 15, 2015 at 12:26:16 PM UTC-6, Richard Bos wrote:
>> >> supercat wrote:
>> >> > So, simply define define a directive which would require a compiler
>> >>
>> >> ...right on cue.
>> >
>> > What's the problem?
>>
>> The problem is that you would add so many directives to the language
>> that they would practically constitute a new language on top of the
>> existing one.
>
> The existing standard is hardly small, and some parts of it impose
> some pretty significant burdens on compiler writers. My proposed
> "standard" might have a lot more directives, but most of them would
> impose *ZERO* obligation on compiler writers beyond refraining from
> treating identifiers associated with such directives as having any
> meaning contrary to the Standard. Compiler writers would likely want
> to look through lists of directives and pro-actively implement ones
> which may be useful for customers, but they could also see what kinds
> of directives their customers ask for, or what directives are used by
> owners of competing compilers.
And what directives have users actually asked 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 | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-15 13:24 -0800 |
| Message-ID | <a18b4f45-96ce-437e-9bf2-5a24de09b275@googlegroups.com> |
| In reply to | #78773 |
On Tuesday, December 15, 2015 at 3:08:26 PM UTC-6, Keith Thompson wrote: > And what directives have users actually asked for? Well, as a starting point, I've seen lots of complaints regarding behavior in case of overflow or violations of the "effective type" rules which were obviously written by people who had never done systems-level programming.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-15 14:35 -0800 |
| Message-ID | <lnfuz3basc.fsf@kst-u.example.com> |
| In reply to | #78775 |
supercat@casperkitty.com writes:
> On Tuesday, December 15, 2015 at 3:08:26 PM UTC-6, Keith Thompson wrote:
>> And what directives have users actually asked for?
>
> Well, as a starting point, I've seen lots of complaints regarding behavior
> in case of overflow or violations of the "effective type" rules which were
> obviously written by people who had never done systems-level programming.
That doesn't sound like requests for directives.
--
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-15 15:34 -0800 |
| Message-ID | <ad40027e-295e-48c9-9099-0f5d73ce9769@googlegroups.com> |
| In reply to | #78779 |
On Tuesday, December 15, 2015 at 4:35:24 PM UTC-6, Keith Thompson wrote: > That doesn't sound like requests for directives. It indicates a desire to have certain kinds of code regarded as legitimate. Do you disagree? A lot of programmers have historically relied upon the fact that in many cases where most platforms worked the same way in cases not covered by the Standard, compilers for such a platform would work that same way whether or not the Standard compelled such behavior. Sometimes the people writing compilers for such platforms documented the behavior; sometimes they didn't. Many modern compiler writers, however, take the view that requiring compilers to expose the corner-case behaviors of the underlying platforms on the off chance that programmers might conceivably care about such behaviors would substantially and needlessly impede optimization, and from what I understand they would be correct in that view, *if* there were some means of identifying the rare but important cases where the Standard presently imposes no requirements, but where programmers nonetheless need a behavior satisfying certain constraints. Otherwise, if there's no way for programmers to identify the cases where they need a behavioral guarantee which goes beyond the Standard, C will effectively split into two languages--one which offers such guarantees in all cases, including the 99% of cases where they would impose a needless performance drain, and one which can run some kinds of code faster but won't work with code that occasionally needs some extra guarantees.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-12-16 00:00 +0100 |
| Message-ID | <n4q5u1$srf$1@dont-email.me> |
| In reply to | #78775 |
On 15/12/15 22:24, supercat@casperkitty.com wrote: > On Tuesday, December 15, 2015 at 3:08:26 PM UTC-6, Keith Thompson wrote: >> And what directives have users actually asked for? > > Well, as a starting point, I've seen lots of complaints regarding behavior > in case of overflow or violations of the "effective type" rules which were > obviously written by people who had never done systems-level programming. > I've seen lots of complaints about that too, in this newsgroup. The complaints have been almost entirely from one poster, but there have been no shortage of them! You can be confident that to the extent there are such problems, and the people doing systems-level programming really are complaining, then such "directives" would already exist in the compiler most used for systems-level programming - gcc. It turns out that gcc already has support for this sort of thing through command line switches like "-fno-strict-aliasing". And for more detailed control, attributes such as "may_alias" offer suitable extension. You can also use functions like memcpy(), knowing that you get char-style aliasing while still generating optimal code (in cases where the compiler has enough information).
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-15 15:47 -0800 |
| Message-ID | <bb16ed29-4de5-44e0-84d4-0c43b37a299d@googlegroups.com> |
| In reply to | #78780 |
On Tuesday, December 15, 2015 at 5:00:51 PM UTC-6, David Brown wrote:
> You can be confident that to the extent there are such problems, and the
> people doing systems-level programming really are complaining, then such
> "directives" would already exist in the compiler most used for
> systems-level programming - gcc.
Unfortunately, such directives are not standardized and represent something
of a sledge-hammer approach. Further, if compiler writers want to gain
new optimization opportunities they should start encouraging programmers to
use directives when they care about certain guarantees the Standard offers
but which require the generation of a lot of useless code. Consider, for
example, a program written for a 16-bit system assuming MISRA or similar
rules that require the use of fixed-size types:
for (int16_t i=start; i<lim; i+=2) { }
On a 16-bit system, the loop will invoke Undefined Behavior if i is advanced
past 32767. On a typical two's-complement 32-bit system, it will have
defined behavior in that case, wrapping from 32766 to -32768. The
requirement that "i" wrap cleanly will likely require adding one or two
instructions to every loop iteration, and will also impair many forms of
loop induction and unrolling. If there existed a 16-bit type which
expressly waived any guarantees of behavior when assigned an out-of-range
value, however, a programmer could use such a type to allow such
optimizations if wrap-around behavior was not required.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-12-16 11:08 +0100 |
| Message-ID | <n4rd30$7da$1@dont-email.me> |
| In reply to | #78782 |
On 16/12/15 00:47, supercat@casperkitty.com wrote:
> On Tuesday, December 15, 2015 at 5:00:51 PM UTC-6, David Brown wrote:
>> You can be confident that to the extent there are such problems, and the
>> people doing systems-level programming really are complaining, then such
>> "directives" would already exist in the compiler most used for
>> systems-level programming - gcc.
>
> Unfortunately, such directives are not standardized and represent something
> of a sledge-hammer approach.
Standardisation is not necessarily an important matter. When you are
doing the sort of programming where you might want aliasing behaviour
that has different specifications from the C standards, then you are
looking at implementation-dependent behaviour and/or compiler
extensions. These are normal in such low-level code. It is perfectly
reasonable to say the code is only correct for a given compiler (or
other compatible compilers), or only for particular targets.
The C standards committee can't cover this sort of thing - it is
inevitably implementation-specific. At best, the standards could give a
specific format for reserved optional directives or command-line
switches - but that would be of no help to tools that currently have
suitable switches and extensions, and irritate tool vendors that have
something different. So there are good reasons why these things are not
part of the main C standards.
But there /is/ a practical, useful sort-of standard here - the gcc
"standard". If your low-level stuff is very system specific, then you
use the compiler's extensions or switches - no standard is needed. If
you are doing something that has to support a few different targets,
then you are almost certainly using gcc, or one of the many compilers
that follow its lead for attributes and at least some switches, such as
clang/llvm, icc, CodeWarrior, etc. Even MSVC should support them as
they move to the clang front end.
I agree that "-fno-strict-alias" is a sledge-hammer approach. Some
projects (such as the Linux kernel) find it a good idea - for others,
something like the (fairly new) "may_alias" attribute is a better choice.
> Further, if compiler writers want to gain
> new optimization opportunities they should start encouraging programmers to
> use directives when they care about certain guarantees the Standard offers
> but which require the generation of a lot of useless code. Consider, for
> example, a program written for a 16-bit system assuming MISRA or similar
> rules that require the use of fixed-size types:
>
> for (int16_t i=start; i<lim; i+=2) { }
>
> On a 16-bit system, the loop will invoke Undefined Behavior if i is advanced
> past 32767. On a typical two's-complement 32-bit system, it will have
> defined behavior in that case, wrapping from 32766 to -32768. The
> requirement that "i" wrap cleanly will likely require adding one or two
> instructions to every loop iteration, and will also impair many forms of
> loop induction and unrolling. If there existed a 16-bit type which
> expressly waived any guarantees of behavior when assigned an out-of-range
> value, however, a programmer could use such a type to allow such
> optimizations if wrap-around behavior was not required.
>
Compiler writes don't care if the generated code is sub-optimal when the
programmer writes incorrect source code! Compilers can generate optimal
code for such loops precisely because they can assume the programmer
will never try to advance i beyond 32767.
Certainly compilers could try to encourage better programming by making
suggestions that could improve code. For example, it might be able to
suggest that adding a "restrict" would improve code (gcc can suggest a
few attributes or new C++ "final" and "override" directives) - but
that's hard to implement well, and would only help in a few cases, so I
doubt if it is a major priority for compiler developers.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-16 09:45 -0800 |
| Message-ID | <4b376a10-933f-42fc-b7e2-f8c9a26dc1e0@googlegroups.com> |
| In reply to | #78791 |
On Wednesday, December 16, 2015 at 4:09:10 AM UTC-6, David Brown wrote:
> The C standards committee can't cover this sort of thing - it is
> inevitably implementation-specific. At best, the standards could give a
> specific format for reserved optional directives or command-line
> switches - but that would be of no help to tools that currently have
> suitable switches and extensions, and irritate tool vendors that have
> something different. So there are good reasons why these things are not
> part of the main C standards.
For what percentage of platforms would it be impractical for a compiler to
implement an "aliasing barrier" with the semantics that the bytes comprising
an object written as any type before the barrier could be reinterpreted
and/or reused as any other type after? I would suggest that it's very common
to have a loop which may need to use cross-type aliasing with things written
before the loop or read afterward, but not with anything that is both written
and read within the loop. The performance impact of barriers placed around
the loop would be minor compared with that of requiring compilers to assume
implicit barriers within the loop.
More narrowly-defined barriers could allow for more optimizations than crude
ones, but I'm not sure to what extent they'd be worthwhile. On the other
hand, directives to say "this pointer variable will be used in the following
code to access things of other types written before this point" or "things
have been written by this pointer that will be used as other types after
this point" would offer some documentation advantages versus full-barrier
directives, and wouldn't impose any additional burden on compilers (since
compilers that wanted to implement fine-grained barriers could do so, but
those that didn't could simply regard partial-barrier directives as full
barriers).
> But there /is/ a practical, useful sort-of standard here - the gcc
> "standard". If your low-level stuff is very system specific, then you
> use the compiler's extensions or switches - no standard is needed. If
> you are doing something that has to support a few different targets,
> then you are almost certainly using gcc, or one of the many compilers
> that follow its lead for attributes and at least some switches, such as
> clang/llvm, icc, CodeWarrior, etc. Even MSVC should support them as
> they move to the clang front end.
I have something of a love/hate relationship with gcc. It does introduce
a lot of good and useful ideas, but it fails to make clear what sorts of
predictable responses to UB should or should not be considered extensions.
Many programs written for gcc operate under the fundamental semantics
"When given valid data, yield valid results; when given invalid data, yield
arbitrary results without exposing security weaknesses." It is often not
possible to optimize code written to avoid numerical overflow nearly as
much it would be possible to optimize code which was written so that it could
meet requirements given a wide (but not unlimited) range of overflow
behaviors; having the authors of gcc say that programmers have no right to
any behavioral expectations in case of overflow is unhelpful.
> I agree that "-fno-strict-alias" is a sledge-hammer approach. Some
> projects (such as the Linux kernel) find it a good idea - for others,
> something like the (fairly new) "may_alias" attribute is a better choice.
Is there any reason type attributes should be better either semantically or
from an optimization standpoint than memory barriers or pointer qualifiers?
Or, for that matter, adding a rule which would fit what I think some
compilers already did which is to say that if a pointer to a thing of one
type is cast to another type, it retains the ability to operate on things of
both types. An explicit cast to void* would give a pointer the ability to
operate on things of any type. If compilers are required to keep track of
"extended abilities" only for local variables, and are allowed to keep track
of specific abilities for void* parameters and return values, I would think
that the required static analysis should be straightforward, and a lot of
code which would otherwise require "-fno-strict-alias" could be made to work
without having to block all forms of TBAa.
> > Further, if compiler writers want to gain
> > new optimization opportunities they should start encouraging programmers to
> > use directives when they care about certain guarantees the Standard offers
> > but which require the generation of a lot of useless code. Consider, for
> > example, a program written for a 16-bit system assuming MISRA or similar
> > rules that require the use of fixed-size types:
> >
> > for (int16_t i=start; i<lim; i+=2) { }
> >
> > On a 16-bit system, the loop will invoke Undefined Behavior if i is advanced
> > past 32767. On a typical two's-complement 32-bit system, it will have
> > defined behavior in that case, wrapping from 32766 to -32768. The
> > requirement that "i" wrap cleanly will likely require adding one or two
> > instructions to every loop iteration, and will also impair many forms of
> > loop induction and unrolling. If there existed a 16-bit type which
> > expressly waived any guarantees of behavior when assigned an out-of-range
> > value, however, a programmer could use such a type to allow such
> > optimizations if wrap-around behavior was not required.
>
> Compiler writes don't care if the generated code is sub-optimal when the
> programmer writes incorrect source code! Compilers can generate optimal
> code for such loops precisely because they can assume the programmer
> will never try to advance i beyond 32767.
If "int" is 32 bits, then incrementing i beyond 32767 is required to either
yield an implementation-defined value or raise an implementation-defined
signal. It *doesn't* invoke Undefined Behavior. I would expect that in
the majority of cases where an oversized value is stored into a short signed
int programmers would be perfectly happy if compilers chose in unspecified
fashion from among a significant range of behaviors, but the Standard does
not allow that.
I would like to see a set of integer types whose behavior would be largely
implementation-independent. At present, C has integer types which have
rigidly-defined *storage formats*, but their behaviors vary all over the
place. For example, on most platforms, x*=x; has defined behavior for all
values of all small signed types, and all full-sized unsigned types, but
Undefined Behavior for some values of small unsigned types or full-sized
signed types. Is there any good reason, semantically, why small types
should behave the opposite of large ones?
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web