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


Groups > comp.lang.c > #140557

Re: strict aliasing rule on buffers

From Ben Bacarisse <ben.usenet@bsb.me.uk>
Newsgroups comp.lang.c
Subject Re: strict aliasing rule on buffers
Date 2019-02-05 14:36 +0000
Organization A noiseless patient Spider
Message-ID <87va1yi9og.fsf@bsb.me.uk> (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


slacked.misha@gmail.com writes:

>     #include <stdio.h>
>
>     struct msg
>     {
>         int a;
>         int b;
>     };
>
>     /* simulate receiving data from another pc (serial, network etc)
>      */
>     void read_data(void *buf)
>     {
>         int i;
>         char *b = buf;
>
>         for (i = 0; i != sizeof(struct msg); ++i)
>         {
>             b[i] = i;
>         }
>     }
>
>     void process_data(void *buf)
>     {
>         /* now does it break strict aliasing rule? (void *) can be casted
>          * to any type, but here (char *) was casted to (void *) and then
>          * to (struct msg *)
>          */
>         struct msg *m = buf;
>         printf("%d, %d\n", m->a, m->b);
>     }
>
>     int main(void)
>     {
>         char b[128] = {0};
>         read_data(b);
>         process_data(b);
>         return 0;
>     }

There are no aliasing issues that I can see.  But you do have an
alignment issue.: you can't be sure that b is suitable aligned for a
struct msg object.  In the actual code, it's possible that b will be
allocated by malloc, in which case all is fine, but if you need to
declare b (and you don't have C11's new alignment control), put b into a
union:

  union { char b[128]; struct msg _dummy } u = {0};
  read_data(u.b);
  process_data(u.b);

> And please, let's not talk about other problems this code has, like endianess,
> padding, int size etc. Please, only consider aliasing problem.

You don't exclude alignment, so I talked about it!

-- 
Ben.

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