Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #107795

Re: Reliable C tutorial for beginners

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>

Show all headers | View raw


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


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