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


Groups > comp.lang.c > #140555

Re: strict aliasing rule on buffers

From David Brown <david.brown@hesbynett.no>
Newsgroups comp.lang.c
Subject Re: strict aliasing rule on buffers
Date 2019-02-05 15:33 +0100
Organization A noiseless patient Spider
Message-ID <q3c6ro$bln$1@dont-email.me> (permalink)
References <q3bl3g$gs4$1@dont-email.me> <gbt4iiFfhg9U4@mid.individual.net> <gbt4u3Ffhg9U5@mid.individual.net> <20190205123321.qqn6sepg75f4ytkd@c-ml-p3510.redembedded.pl>

Show all headers | View raw


On 05/02/2019 13:33, slacked.misha@gmail.com wrote:
<snip>
> The question is: does this code break strict aliasing rule? According to C
> standard, it is:
> 
>  - legal to cast anything to (void *) and then back to same anything. 
>  - legal to cast anything to (char *) but you cannot cast
>  - not legal to cast anything to (char *)
> 
> But in this example (char *) is casted to (void *) and then, that (void *)
> is casted to (struct msg *). Compiler doesn't complain about anything - thanks
> to those (void *) casts, but that doesn't mean it is ok.
> 
> So, does this code really break strict aliasing and is undefined behaviour?
> If so, are there any other options to case received data to struct waithout
> doing copies (like simple casting)? This doesn't seem to be the problem on
> big machines where Linux is running, but it may be a huge memory overheat on
> small microcontrollers.
> 
> And please, let's not talk about other problems this code has, like endianess,
> padding, int size etc. Please, only consider aliasing problem.
> 

But first, let us talk about a problem with the post.  You have made the
post as a reply to an existing post, thus starting a new thread in the
middle of another thread.  This is confusing and unhelpful - for a new
topic and a new question (which we greatly welcome in this group),
please start a new thread.

(You'll find it all much easier if you drop the horrendous "google
groups" interface and get a proper newsreader and newsserver.  I
recommend Thunderbird as a popular newsreader that works for any system,
and eternal-september.org as a free newserver.  Other people have
different choices, but those are fine to start with.)


On to the code.  As others have said, you don't have casts - you have
conversions.  A "cast" is just an explicit way to make a conversion,
while "conversion" is the general term and also applies when you assign
to and from "void*".

I believe a main point of your confusion is mixing the concepts of
converting pointers, and accessing data via pointers.  It is fine in C
to do the kinds of conversions of the pointers that you have in your
code.  But that does not mean that it is fine to use those pointers to
access data.  In particular, you can convert your pointer-to-char into a
pointer-to-void, and then into a pointer-to-struct, but that does not
mean that you can use it to access data via the pointer-to-struct.
About the only thing you can do (guaranteed by the C standards) is to
convert it back to a pointer-to-void and then back to a pointer-to-char.
 Even that is not guaranteed to give you the original pointer, though it
will do on almost all processors.

Separate your thoughts about what /accesses/ are allowed, and what
/conversions/ are allowed.  See if that helps you.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Compiler stress test jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-05 10:30 +0100
  Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-05 22:50 +1300
    Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-05 22:56 +1300
      strict aliasing rule on buffers slacked.misha@gmail.com - 2019-02-05 13:33 +0100
        Re: strict aliasing rule on buffers Richard Damon <Richard@Damon-Family.org> - 2019-02-05 08:13 -0500
        Re: strict aliasing rule on buffers Barry Schwarz <schwarzb@dqel.com> - 2019-02-05 06:00 -0800
        Re: strict aliasing rule on buffers David Brown <david.brown@hesbynett.no> - 2019-02-05 15:33 +0100
        Re: strict aliasing rule on buffers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-05 14:36 +0000
        Re: strict aliasing rule on buffers James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-05 07:27 -0800
    Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-07 08:28 +1300
      Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-06 19:48 +0000
      Re: Compiler stress test jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-06 22:11 +0100
        Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-07 00:34 +0100
          Re: Compiler stress test jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-07 07:13 +0100
            Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-07 08:32 +0100
              Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-07 12:06 +0000
                Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-07 14:08 +0100
                Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-07 13:49 +0000
                Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-07 17:01 +0100
                Re: Compiler stress test jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-07 22:26 +0100
                Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-07 23:24 +0100
                Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-07 23:20 +0000
                Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-08 10:42 +0100
                Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-08 16:37 +1300
                Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-08 12:30 +0100
                Re: Compiler stress test Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-08 08:18 -0800
                Re: Compiler stress test scott@slp53.sl.home (Scott Lurndal) - 2019-02-08 16:04 +0000
                Re: Compiler stress test Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-02-11 20:34 +0000
                Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-08 16:30 +1300
  Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-05 12:20 +0000
    Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-06 09:59 +1300
      Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-05 21:57 +0000
        Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-06 00:29 +0100
          Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-05 23:58 +0000
            Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-06 14:10 +1300
              Re: Compiler stress test Bart <bc@freeuk.com> - 2019-02-06 01:16 +0000
                Re: Compiler stress test Ian Collins <ian-news@hotmail.com> - 2019-02-06 14:21 +1300
                Re: Compiler stress test Paul <nospam@needed.invalid> - 2019-02-06 01:28 -0500
                Re: Compiler stress test Paul <nospam@needed.invalid> - 2019-02-08 03:51 -0500
            Re: Compiler stress test David Brown <david.brown@hesbynett.no> - 2019-02-06 08:13 +0100
      Re: Compiler stress test BGB <cr88192@hotmail.com> - 2019-02-06 13:13 -0600

csiph-web