Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #107795
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Reliable C tutorial for beginners |
| Date | 2017-04-06 21:46 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <oc65oe$cda$1@dont-email.me> (permalink) |
| References | (3 earlier) <ac884c1c-c855-44a3-afd0-6459ccf91b2f@googlegroups.com> <oc3dar$bnl$2@dont-email.me> <b9c13165-7478-4b60-8239-a33ab137e6a3@googlegroups.com> <oc4ra7$a7s$1@dont-email.me> <7d77d426-509a-414c-89c9-7c104866a276@googlegroups.com> |
On 06/04/17 16:53, supercat@casperkitty.com wrote: > On Thursday, April 6, 2017 at 2:41:58 AM UTC-5, David Brown wrote: >> It is written in /C/. Specifically, C99, plus some extensions, plus >> some extra guarantees through specific flags. Not your pretend C, nor >> plain standard C. > > How does the 1974 C Reference Manual define structure member access? Is > there any evidence of anything earlier called "C" which only defines the > behavior in the cases where it would be defined in gcc's interpretation > of C99? "gcc's interpretation of C99", in this case, is the way C has always been defined since it was standardised. You are forever interpreting "old C did not define this" as meaning "old C worked the way I think", when in fact it simply means "this was undefined in old C". > >> For example, the kernel is compiled with gcc's >> "-fno-strict-alias" flag. It uses that for two reasons. One is that >> the kernel often needs to access memory in different ways, and the >> developers have found it convenient to change the rules of C to allow >> access to objects via incompatible pointers. Note carefully what I >> wrote there - they find it /convenient/ to /change the rules of C/. The >> second reason is that they are concerned that without that change, >> people might have written incorrect C code and introduced subtle bugs - >> they feel that the variation of C with this change is safer for their work. > > It is also a variation which, while there is no official standard for it, > is very widely supported. Yes, it is so widely supported that there are a range of compilers that can be used to compile the Linux kernel. Oh, wait, that's wrong - gcc is the /only/ compiler that can be used for the kernel, because it is the /only/ compiler to support this particular variant of C. There are plenty of older and more limited compilers that don't do type-based alias analysis - but that is because they are not sophisticated enough compilers, not because they intentionally and actively support a variant of C that defines access through incompatible pointers. And there are plenty of processors that have so few registers that access to objects is always "mindlessly translated", simply because there aren't enough registers to hold data anyway. > >> This does not mean, in any shape or form, that the C language was >> "designed" as the "-fno-strict-alias" variant. Nor does it mean that >> early C implementations guaranteed that behaviour (some might, but >> others might not). Nor does it mean that you /have/ to have this in >> order to write low-level code. > > Low-level memory management code would often invoke UB without it, though > usually in ways gcc would not exploit. Most embedded projects never need > to recycle or reinterpret storage for any reason, rendering the flag > irrelevant, but the development frameworks I've seen that used gcc set > -fno-strict-alias as part of their default options. In most cases, people set that flag because they don't really understand how C works and how compilers work, and they fiddle around with disabling optimisation until testing shows that the code works. I have seen /lots/ of code - including code delivered under expensive licenses - with notes about "disable optimisation for this file". It is because it is /bad/ code. > > If one has code that needs to acquire a block of memory that may last have > been used as some unknown type and treat it as a sequence of uint16_t[] > values that are initially populated with unspecified bit patterns, is there > any *efficient* means of accomplishing that without using behavior equivalent > to -fno-strict-alias (available on many compilers) or else a gcc extension > which would be available on fewer? > That is not what we are talking about here.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Reliable C tutorial for beginners MehdiAmini <atorrses@gmail.com> - 2017-04-04 15:08 +0430
Re: Reliable C tutorial for beginners Richard Heathfield <rjh@cpax.org.uk> - 2017-04-04 14:10 +0100
Re: Reliable C tutorial for beginners fir <profesor.fir@gmail.com> - 2017-04-04 09:12 -0700
Re: Reliable C tutorial for beginners MehdiAmini <atorrses@gmail.com> - 2017-04-05 16:49 +0430
Re: Reliable C tutorial for beginners Alla <vitale.alla@gmail.com> - 2017-04-05 16:41 +0300
Re: Reliable C tutorial for beginners raltbos@xs4all.nl (Richard Bos) - 2017-04-05 11:10 +0000
Re: Reliable C tutorial for beginners jm.bourguet@gmail.com - 2017-04-05 05:55 -0700
Re: Reliable C tutorial for beginners fir <profesor.fir@gmail.com> - 2017-04-05 08:01 -0700
Re: Reliable C tutorial for beginners supercat@casperkitty.com - 2017-04-05 09:45 -0700
Re: Reliable C tutorial for beginners Jean-Marc Bourguet <jm@bourguet.org> - 2017-04-05 20:04 +0200
Re: Reliable C tutorial for beginners David Brown <david.brown@hesbynett.no> - 2017-04-05 20:36 +0200
Re: Reliable C tutorial for beginners supercat@casperkitty.com - 2017-04-05 14:26 -0700
Re: Reliable C tutorial for beginners David Brown <david.brown@hesbynett.no> - 2017-04-06 09:41 +0200
Re: Reliable C tutorial for beginners supercat@casperkitty.com - 2017-04-06 07:53 -0700
Re: Reliable C tutorial for beginners scott@slp53.sl.home (Scott Lurndal) - 2017-04-06 15:12 +0000
Re: Reliable C tutorial for beginners Keith Thompson <kst-u@mib.org> - 2017-04-06 09:12 -0700
Re: Reliable C tutorial for beginners scott@slp53.sl.home (Scott Lurndal) - 2017-04-06 16:20 +0000
Re: Reliable C tutorial for beginners Keith Thompson <kst-u@mib.org> - 2017-04-06 09:26 -0700
Re: Reliable C tutorial for beginners Keith Thompson <kst-u@mib.org> - 2017-04-06 11:53 -0700
Re: Reliable C tutorial for beginners Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2017-04-06 12:26 -0400
Re: Reliable C tutorial for beginners scott@slp53.sl.home (Scott Lurndal) - 2017-04-06 17:09 +0000
Re: Reliable C tutorial for beginners supercat@casperkitty.com - 2017-04-06 10:37 -0700
Re: Reliable C tutorial for beginners scott@slp53.sl.home (Scott Lurndal) - 2017-04-06 18:50 +0000
Re: Reliable C tutorial for beginners David Brown <david.brown@hesbynett.no> - 2017-04-06 21:46 +0200
Re: Reliable C tutorial for beginners supercat@casperkitty.com - 2017-04-06 14:51 -0700
Re: Reliable C tutorial for beginners raltbos@xs4all.nl (Richard Bos) - 2017-04-09 13:42 +0000
Re: Linux and GCC Noob <root@127.0.0.1> - 2017-04-09 16:45 +0200
Re: Linux and GCC David Brown <david.brown@hesbynett.no> - 2017-04-09 16:50 +0200
Re: Linux and GCC Noob <root@127.0.0.1> - 2017-04-09 17:06 +0200
Re: Linux and GCC raltbos@xs4all.nl (Richard Bos) - 2017-04-14 11:39 +0000
Re: Linux and GCC Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-16 17:41 -0700
Re: Linux and GCC David Brown <david.brown@hesbynett.no> - 2017-04-17 17:46 +0200
Re: Linux and GCC David Brown <david.brown@hesbynett.no> - 2017-04-17 17:37 +0200
Re: Linux and GCC supercat@casperkitty.com - 2017-04-17 09:19 -0700
Re: Reliable C tutorial for beginners Keith Thompson <kst-u@mib.org> - 2017-04-05 13:50 -0700
Re: Reliable C tutorial for beginners supercat@casperkitty.com - 2017-04-05 14:47 -0700
Re: Reliable C tutorial for beginners David Brown <david.brown@hesbynett.no> - 2017-04-06 09:45 +0200
Re: Reliable C tutorial for beginners jm.bourguet@gmail.com - 2017-04-06 01:57 -0700
Re: Reliable C tutorial for beginners Real Troll <real.troll@trolls.com> - 2017-04-05 15:16 -0500
Re: Reliable C tutorial for beginners GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-06 11:56 +0200
Re: Reliable C tutorial for beginners Spiros Bousbouras <spibou@gmail.com> - 2017-04-06 14:14 +0000
Re: Reliable C tutorial for beginners "C-bot" <cbot@example.com> - 2017-04-08 01:18 +0000
Re: Reliable C tutorial for beginners Spiros Bousbouras <spibou@gmail.com> - 2017-04-08 14:54 +0000
Re: Reliable C tutorial for beginners Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-08 19:01 +0100
Re: Reliable C tutorial for beginners Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-09 00:04 +0100
Re: Reliable C tutorial for beginners Jean-Marc Bourguet <jm@bourguet.org> - 2017-04-09 14:03 +0200
Re: Reliable C tutorial for beginners Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-04-09 15:02 -0600
Re: Reliable C tutorial for beginners "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-04-09 14:13 -0700
Re: Reliable C tutorial for beginners Real Troll <real.troll@trolls.com> - 2017-04-09 17:30 -0400
Re: Reliable C tutorial for beginners Richard Heathfield <rjh@cpax.org.uk> - 2017-04-10 18:35 +0100
csiph-web