1. Си / Говнокод #21658

    −52

    1. 1
    2. 2
    3. 3
    4. 4
    static volatile stm32f4_usart *usart_get_regs(const console_tbl *ct)
{
  return (stm32f4_usart *) ct->ulCtrlPort1;
}

    А если будет замест volatile - inline, возможен вариант, что компилятор выкинет эту функцию?

    Запостил: MiD, 07 Ноября 2016

    Комментарии (26) RSS

    • ava Gay 07.11.2016 16:35 # −66

      показать все, что скрытоУ какой национальности самый большой процент широких анусов?
      Ответить

    • ava bormand 07.11.2016 17:29 # +1

      volatile же не к функции относится, а к возвращаемому типу...

      volatile stm32f4_usart *
      Ответить

      • ava MiD 07.11.2016 17:36 # 0

        ам...т.е. чуваки подумали, что указатель типа stm32f4_usart может быть выкинут компилятором? И что тогда, функция которая должна что-то возвращать, не будет возвращать..бред какой-то...

        з.ы. взято отседова:
        https://devel.rtems.org/browser/rtems/c/src/lib/libbsp/arm/stm32f4/console/usart.c?rev=1485a58ce30c4ced71446976036f 03a5c32f451d
        Ответить

        • ava bormand 07.11.2016 17:41 # +3

          Не, они хотели чтобы операции с полями этой структуры (а это memory mapped порты железки) не оптимизировались:
          stm32f4_usart *foo = usart_get_regs(...);

foo->some_reg = 5; // конпелятор с чистой совестью выкинет эту строку
foo->some_reg = 42; // потому что старое значение затёрли записью 42

foo->some_reg = 5;
r = foo->some_reg; // конпелятор тупо положит в r пятёрку и не будет перечитывать some_reg
          С volatile эти обращения будут работать так, как задумано.
          Ответить

          • ava MiD 07.11.2016 17:51 # 0

            возможно херню спрошу, правильно ли я понимаю. У них там встречаются такие вот дела:

            union {
            struct {
            uint32_t val1 :1;
            uint32_t val2 :5;
            uint32_t val3 :8;
            ....
            } fields;
            uint32_t reg;
            };

            где val1, val2...valN - это битовые поля внутри регистра, заданной длины. Если я буду, конфигурирую регистр, через битовые поля и не использую volatile, очень велика вероятность, что компилятор может каким то образом всё мне поломать? А если может, то как, например?)
            Ответить

            • ava MiD 07.11.2016 17:54 # 0

              А, всё, догнал. Пора идти домой, туплю:)
              Ответить

            • ava bormand 07.11.2016 17:56 # +3

              > то как, например
              Может склеить несколько обращений к битовым полям в одну операцию над целым регистром. Обычно на это насрать, только быстрее работать будет... Но если в даташите, например, написано "заполните все биты кроме enable, а затем установите enable", то может получиться факап.
              Ответить

            • ava Soul_re@ver 07.11.2016 17:59 # +2

              Может в С89 или С++. Не может в С99 или С11.
              Например может сломать так:
              this_union foo;
foo.reg = 0;
foo.fields.val1 = 1;
foo.fields.val1 = 2;
foo.fields.val1 = 3;
printf("%d", foo.reg);
// Печатает 0. А что, ложил в reg ты 0, что ещё ожидаешь увидеть?

              Теоретически индеец ещё может поломать. И то что положение битовых полей в структуре не определено ЕМНИП.
              Ответить

              • ava bormand 07.11.2016 18:01 # 0

                Ужас то какой... А есть компиляторы, которые реально так делают?

                Гцц, например, явно оговаривал, что можно такие махинации через юнион гонять...
                Ответить

                • ava Soul_re@ver 07.11.2016 18:08 # 0

                  Вряд ли. Гцц разрешал это с незапамятных времён в С, С++ ведёт себя как можно ближе к С. Шланг копирует поведение гцц. MS следует за лидерами вроде как.

                  Реально можно напороться на проблемы если у тебя есть указатель на поле юниона. Большинство компиляторов теперь следуют strict-aliasing и запись/чтение несовпадающих типов может не работать.
                  Ответить

                  • ava bormand 07.11.2016 18:11 # 0

                    Ну про указатель то понятно. Но тут у ОП'а, как я понял, совсем другой кейс - этот union помещается прямо поверх memory mapped порта некой железки и код через него оперирует с нужными битами. Т.е. это не ради каста, а ради удобства, чтобы сдвиги и логику не писать.
                    Ответить

                    • ava Soul_re@ver 07.11.2016 18:16 # +1

                      В таком случае, как с любыми memory mapped устройствами, volatile нужно таки поставить.
                      Ответить

                      • ava bormand 07.11.2016 18:17 # +1

                        Ну да, иначе первое же ожидание какого-нибудь ready бита повешает всё к хуям :)
                        Ответить

                        • ava MiD 07.11.2016 18:38 # +1

                          А если объект уже проинициализирован как volatile, нужно ли указатель на него тоже volatile делать?
                          Ответить

                          • ava Soul_re@ver 07.11.2016 18:41 # 0

                            Сам указатель нет, на что указывает — да. Хотя без volatile компилятор не даст сделать, будет ругаться на отбрасывание cv-qualifiers.
                            Ответить

              • ava bormand 07.11.2016 18:05 # +2

                Ну индеец да положение полей всё-таки implementation defined, не UB. Т.е. под конкретный компилятор/семейство чипов можно запинать. А больше эмбедщикам и не надо.
                Ответить

                • ava dxd 07.11.2016 22:44 # 0

                  А вот извлечение из юниона не того, что положили, всё же UB. Because fuck you, that's why.
                  Ответить

                  • ava barop 07.11.2016 23:07 # −63

                    показать все, что скрытоVanished
                    Ответить

                  • ava bormand 07.11.2016 23:33 # +3

                    But gcc (at least) explicitely specifies behavior of this pattern :3

                    The practice of reading from a different union member than the one most recently written to (called “type-punning”) is common. Even with -fstrict-aliasing, type-punning is allowed, provided the memory is accessed through the union type.

                    https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Optimize-Options.html
                    Ответить

    Добавить комментарий