Да что вы прицепились к стандарту языка, которому уже много лет. Он пережил разный endian, разную разрядность и много чего еще. Все его UB просто следствие необходимости работы в очень разном окружении, которое не ограничивается Linux на amd64/arm64. Проблема не в стандарте. Проблема в избыточной оптимизации, ломающей логику работы. А подобные проблему будут у абсолютно любого языка, когда он достигнет зрелости. Только вот... Большинство умирает молодыми и просто не доживут до этой прекрасной поры. Ну устаю повторять про python при переходе со 2-ой на 3-ю версию. Он уже поломался. В отличии от дряхлого старичка, который держится.
Впрочем - ну его нафиг. Я не буду ввязываться в очередной раз в эти войны. Вообще учить детей сегодня С или плюсам - ну так себе идея. Сюда надо ЗАХОТЕТЬ погрузиться. Это очень специфические языки для очень специфических задач. Это не то, с чем есть шанс случайно встретиться. Удел инженеров. С старом смысле этого слова.
Да уж. К сожалению, та малая часть программирования, которая использует в решении своих задач достаточно низкоуровневые языки, все больше и больше помимо непосредственно программирования занимается борьбой с компиляторами. Стремление максимально оптимизировать код оборачивается тем, что компилятор все чаще и чаще приходится бить по рукам.
Впрочем, это порождает "проблему вагонетки" в мире кода - что лучше, выдать неверный результат на определенной итерации или упасть и прекратить дальнейшую работу совсем. Плохо только, что вот такими скрытыми оптимизациями решает ту дилемму не разработчик (который должен был бы проверить на ноль, если не сразу то после N-ого падения). От него-то как раз проблему спрятали и сильно усложнили отладку. Хорошо когда результат вот так запросто воспроизводится. А если вычисляется? Да из множества переменных? Впрочем, в таком варианте этой проблемы вроде бы и возникнуть не должно.
Где-то мир свернул не туда. Иногда очень хочется вернуться к славному ассемблеру, где только ты был автором.
... а в не идеальном, к сожалению, по другому просто невозможно. И это ровно то, на чем всех ловят, и на чем основано 99% методов "социальной инженерии".
В наших краях, видимо, они были экзотикой. А вот эти вполне себе ставили и разрабатывали железки с ними.И даже программировали и отлаживали без BIOS/DOS. Что характерно документация на них была вполне доступна. Да, традиционно под NDA, но доступна. И при желании их вполне можно было применять. Другое дело, что желание их применять не всегда совпадало с возможностью производственных линий - но это уже другая тема. Впрочем до определенного момента они были избыточны, а потом как-то резко стали недостаточны.
Хехе. 386EX в спутниковом телефоне выглядел эпичнее:
Еще эпичнее было обнаружить его в отечественном GPS приемнике. Вообще довольно популярный камушек. И точно более популярный, чем его конкурент ELAN SC300 от AMD. Правда их 400-ая и тем более 500-ая прямых конкурентов не имели. Впрочем, и потребность в подобных решений уже вызывала некоторые сомнения. Что хорошо и видно - так, некоторое количество плат в факторе PC104/PCI104 и не более того.
На самом деле надо исходить из простого - о тебе не знает или ленивый, или тот, кому ты не интересен. Все остальные о тебе знают все - от паспортных данных (привет ЖКУ, сотовые операторы, медицина) до интересов и мест, где ты бываешь (привет соц.сети, не свои так друзей). А самый главный аргумент сегодня - это всякие Deep Fake. В мире, где оное присутствует, напугать чем-то человека знающего что он открытая книга - крайне сложно. Легкость сопоставления реального персонажа с DeepFake ровно так же работает и в другую сторону. Она же становится сложностью в части сопоставить меня с файлом. Чем некоторые наши руководители активно пользуются. Особенно с учетом современной реальности и законов о фейках.
А эта и ей подобные статьи просто нагнетают уровень паранойи и нервозности. Смысла от них нет. Не мешайте "Счастливой Мэри" жить ее жизнью. Получать удовольствие от волонтерской деятельности и не прятаться по углам, как последней воровке. А то вы становитесь не безопасниками, а надзирателми. Чтоб не сказать более подходящий в данном случае термин из блатного жаргона.
Единственная деталь - все же этот таймер использовать как таймер общего назначения - ну в специальных случаях. А вот оценить время реакции кода на событие - это его основная задача, с которой он очень успешно справляется. Выдавая прямо мечту любого embedder'а - количество тиков. И тут, как правило, отрезка даже в секунду более чем достаточно.
Отличный ответ! Жму руку. И мысли, в принципе, такие же. А у той функции есть ряд подводных камней. Например, если таймерный callback меняет очередь, в первую голову удаляя из нее самого себя...
Но реально есть ощущение, что это мало интересно. В лучшем случае в очередной раз породит срач на тему "как просто это сделать на Rust". Нашего брата здесь совсем не много.
Я бы уточнил - все, это ВООБЩЕ ВСЕ, включая SyTick, Watchdog и прочие. А вот про организацию программных таймеров я бы уточнил. Первый случай - не хватает одного-двух и на заранее известные интервалы. Другой случай - нужно в разные моменты во время выполнения программы, и на разные (рассчитываемые) временные промежутки. Как быть в первом и втором случае. Желательно с подсветкой раскиданных граблей.
Говорят абсолютный слух - проклятие. Так что все в нашей жизни относительно.
А свой шарм есть и в игре на не очень аккуратно настроенном инструменте. Владимир Семенович не даст соврать... А другой Владимир, который Шахрин (Чайф) в одном из интервью говорил что за свою жизнь трижды учил ноты и трижды их счастливо забывал за ненадобностью. И это мы еще не касались всяких атональных произведений и прочих специфических тем. Где все ровно наоборот.
Я лишь утверждаю, что оба способа позволяют извлекать звуки. Ну или ноты, если такая терминология вам ближе. И в общем случае ни один из них не является гарантией того, что результат будет принят или не принят слушателем. Никто ж не скажет, что звук (ноты) качественной музыкальной шкатулки или аудио проигрывателя противен. А они вырожденный случай механического запоминания, абсолютно без понимания сути.
И то и другое заставляет воздух колебаться с заданным набором частот. Мне, как "не лирику", этого достаточно для того чтобы считать эти сущности одинаковыми.
P.S.
В целом аккорд - это минимум три ноты, звучащие одновременно. А уж "первый блатной" он, Am, или Ля-минор для меня уже не принципиально.
Пузырь блокчайна уже лопнул? Никому ножки не обожгло?
</САРКАЗМ>
Кажется современный мир научился справляться с пузырями достаточно эффективно. Остальное списывается на особенности строя. Но это уже тема совсем другого разговора.
Можно свалить все на С. Но это не его проблема. Это проблема специфики аппаратуры. В данном случае ARM7TDMI (ARMv4T) просто аппаратно не поддерживает такое и сваливается в DATA ABORT. А дальше есть варианты... Либо ловить это исключение и в нем исправлять особенности архитектуры или править код, усложняя его. Сам по себе язык тут не при делах. Он как раз делает ровно то, что должен.
Есть дискуссионный вопрос должен ли компилятор предупреждать и возможных проблемах и в каких именно случаях. Но это реально очень дискуссионный вопрос.
А по упаковке... Ну взять тот же ModBus. Там даже добавление лидирующего паддинга не всегда решает. К счастью с появлением семейства Cortex-M эта проблема в контроллерах ушла. Потому и исходный вопрос был бы задан только тем, у кого в резюме есть опыт работы с соответствующими чипами. И да, это реально вопрос "со звездочкой" который добавить баллов может, а отнять точно нет.
... архитектура не позволяет кривой доступ, то компилер один фиг выравняет ...
Нет. Компилятор сделает ровно тот код, который от него просят. Размер t_quest будет ровно 7 байт. А var будет выровнена в соответствии с правилами выравнивания по умолчанию (обычно 4 байта). Во всяком случае я другого никогда не встречал. И передать или принять такую структуру, скажем через тот же UART можно запросто.
Да, компилятор даже не поперхнется (надо только добавить забытый мной stdbool.h). В тот момент, когда это было актуально никакие -WExtra -Wpedantic и их аналоги для компиляторов других производителей ситуацию не исправляли. Код собирался предельно чисто. Что доставляло интересных моментов в процессе отладки.
Да что вы прицепились к стандарту языка, которому уже много лет. Он пережил разный endian, разную разрядность и много чего еще. Все его UB просто следствие необходимости работы в очень разном окружении, которое не ограничивается Linux на amd64/arm64. Проблема не в стандарте. Проблема в избыточной оптимизации, ломающей логику работы. А подобные проблему будут у абсолютно любого языка, когда он достигнет зрелости. Только вот... Большинство умирает молодыми и просто не доживут до этой прекрасной поры. Ну устаю повторять про python при переходе со 2-ой на 3-ю версию. Он уже поломался. В отличии от дряхлого старичка, который держится.
Впрочем - ну его нафиг. Я не буду ввязываться в очередной раз в эти войны. Вообще учить детей сегодня С или плюсам - ну так себе идея. Сюда надо ЗАХОТЕТЬ погрузиться. Это очень специфические языки для очень специфических задач. Это не то, с чем есть шанс случайно встретиться. Удел инженеров. С старом смысле этого слова.
Да уж. К сожалению, та малая часть программирования, которая использует в решении своих задач достаточно низкоуровневые языки, все больше и больше помимо непосредственно программирования занимается борьбой с компиляторами. Стремление максимально оптимизировать код оборачивается тем, что компилятор все чаще и чаще приходится бить по рукам.
Впрочем, это порождает "проблему вагонетки" в мире кода - что лучше, выдать неверный результат на определенной итерации или упасть и прекратить дальнейшую работу совсем. Плохо только, что вот такими скрытыми оптимизациями решает ту дилемму не разработчик (который должен был бы проверить на ноль, если не сразу то после N-ого падения). От него-то как раз проблему спрятали и сильно усложнили отладку. Хорошо когда результат вот так запросто воспроизводится. А если вычисляется? Да из множества переменных? Впрочем, в таком варианте этой проблемы вроде бы и возникнуть не должно.
Где-то мир свернул не туда. Иногда очень хочется вернуться к славному ассемблеру, где только ты был автором.
Проверил для "младшего брата"
константа в коде. Четко как в статье. gcc (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0
Справедливости ради - в реальном коде такое встретить сложно, но... Если угораздит, то седых волос при отладке добавит.
И да, для учебного примера куда лучше сгодился бы вариант
или его аналог на плюсах. Тут и проблемы бы не было, и потенциальные грабли подсвечиваются ближе к реальной жизни.
... а в не идеальном, к сожалению, по другому просто невозможно. И это ровно то, на чем всех ловят, и на чем основано 99% методов "социальной инженерии".
В наших краях, видимо, они были экзотикой. А вот эти вполне себе ставили и разрабатывали железки с ними.И даже программировали и отлаживали без BIOS/DOS. Что характерно документация на них была вполне доступна. Да, традиционно под NDA, но доступна. И при желании их вполне можно было применять. Другое дело, что желание их применять не всегда совпадало с возможностью производственных линий - но это уже другая тема. Впрочем до определенного момента они были избыточны, а потом как-то резко стали недостаточны.
Еще эпичнее было обнаружить его в отечественном GPS приемнике. Вообще довольно популярный камушек. И точно более популярный, чем его конкурент ELAN SC300 от AMD. Правда их 400-ая и тем более 500-ая прямых конкурентов не имели. Впрочем, и потребность в подобных решений уже вызывала некоторые сомнения. Что хорошо и видно - так, некоторое количество плат в факторе PC104/PCI104 и не более того.
Ох уж мне эти безопасники....
На самом деле надо исходить из простого - о тебе не знает или ленивый, или тот, кому ты не интересен. Все остальные о тебе знают все - от паспортных данных (привет ЖКУ, сотовые операторы, медицина) до интересов и мест, где ты бываешь (привет соц.сети, не свои так друзей). А самый главный аргумент сегодня - это всякие Deep Fake. В мире, где оное присутствует, напугать чем-то человека знающего что он открытая книга - крайне сложно. Легкость сопоставления реального персонажа с DeepFake ровно так же работает и в другую сторону. Она же становится сложностью в части сопоставить меня с файлом. Чем некоторые наши руководители активно пользуются. Особенно с учетом современной реальности и законов о фейках.
А эта и ей подобные статьи просто нагнетают уровень паранойи и нервозности. Смысла от них нет. Не мешайте "Счастливой Мэри" жить ее жизнью. Получать удовольствие от волонтерской деятельности и не прятаться по углам, как последней воровке. А то вы становитесь не безопасниками, а надзирателми. Чтоб не сказать более подходящий в данном случае термин из блатного жаргона.
Спасибо, просто и со вкусом.
Единственная деталь - все же этот таймер использовать как таймер общего назначения - ну в специальных случаях. А вот оценить время реакции кода на событие - это его основная задача, с которой он очень успешно справляется. Выдавая прямо мечту любого embedder'а - количество тиков. И тут, как правило, отрезка даже в секунду более чем достаточно.
Отличный ответ! Жму руку. И мысли, в принципе, такие же. А у той функции есть ряд подводных камней. Например, если таймерный callback меняет очередь, в первую голову удаляя из нее самого себя...
Но реально есть ощущение, что это мало интересно. В лучшем случае в очередной раз породит срач на тему "как просто это сделать на Rust". Нашего брата здесь совсем не много.
А вариант exec(sha256sum argv[0]) с перехватом stdout в таком варианте не прокатит? Как самый простой вариант?
И да - реализовывать лень, да и не на чем. Очень уж задачка "для плохих собеседований", если такой алгоритм устроит.
Хороший вариант, а может это быть вызвано плохим монтажом компонента? Лучше с пояснениями.
Мне, право слово, не очень хочется вести собеседование в комментариях. Да и с наймом сейчас откровенно не очень. Я готов продолжать, но надо ли?
Я бы уточнил - все, это ВООБЩЕ ВСЕ, включая SyTick, Watchdog и прочие. А вот про организацию программных таймеров я бы уточнил.
Первый случай - не хватает одного-двух и на заранее известные интервалы. Другой случай - нужно в разные моменты во время выполнения программы, и на разные (рассчитываемые) временные промежутки. Как быть в первом и втором случае. Желательно с подсветкой раскиданных граблей.
Говорят абсолютный слух - проклятие. Так что все в нашей жизни относительно.
А свой шарм есть и в игре на не очень аккуратно настроенном инструменте. Владимир Семенович не даст соврать... А другой Владимир, который Шахрин (Чайф) в одном из интервью говорил что за свою жизнь трижды учил ноты и трижды их счастливо забывал за ненадобностью. И это мы еще не касались всяких атональных произведений и прочих специфических тем. Где все ровно наоборот.
Я лишь утверждаю, что оба способа позволяют извлекать звуки. Ну или ноты, если такая терминология вам ближе. И в общем случае ни один из них не является гарантией того, что результат будет принят или не принят слушателем.
Никто ж не скажет, что звук (ноты) качественной музыкальной шкатулки или аудио проигрывателя противен. А они вырожденный случай механического запоминания, абсолютно без понимания сути.
И то и другое заставляет воздух колебаться с заданным набором частот. Мне, как "не лирику", этого достаточно для того чтобы считать эти сущности одинаковыми.
P.S.
В целом аккорд - это минимум три ноты, звучащие одновременно. А уж "первый блатной" он, Am, или Ля-минор для меня уже не принципиально.
Но таких подавляющее меньшинство. Остальные знают, даже если в их терминологии это "блатные аккорды".
<САРКАЗМ>
Пузырь блокчайна уже лопнул? Никому ножки не обожгло?
</САРКАЗМ>
Кажется современный мир научился справляться с пузырями достаточно эффективно. Остальное списывается на особенности строя. Но это уже тема совсем другого разговора.
Несомненно. Я с этим даже спорить не пытаюсь. Да и вопрос был про операционные системы, а не про квалификацию пректировщика.
Можно свалить все на С. Но это не его проблема. Это проблема специфики аппаратуры. В данном случае ARM7TDMI (ARMv4T) просто аппаратно не поддерживает такое и сваливается в DATA ABORT. А дальше есть варианты... Либо ловить это исключение и в нем исправлять особенности архитектуры или править код, усложняя его. Сам по себе язык тут не при делах. Он как раз делает ровно то, что должен.
Есть дискуссионный вопрос должен ли компилятор предупреждать и возможных проблемах и в каких именно случаях. Но это реально очень дискуссионный вопрос.
А по упаковке... Ну взять тот же ModBus. Там даже добавление лидирующего паддинга не всегда решает. К счастью с появлением семейства Cortex-M эта проблема в контроллерах ушла. Потому и исходный вопрос был бы задан только тем, у кого в резюме есть опыт работы с соответствующими чипами. И да, это реально вопрос "со звездочкой" который добавить баллов может, а отнять точно нет.
Самое главное пропустил.
Нет. Компилятор сделает ровно тот код, который от него просят. Размер t_quest будет ровно 7 байт. А var будет выровнена в соответствии с правилами выравнивания по умолчанию (обычно 4 байта). Во всяком случае я другого никогда не встречал. И передать или принять такую структуру, скажем через тот же UART можно запросто.
Да, компилятор даже не поперхнется (надо только добавить забытый мной stdbool.h). В тот момент, когда это было актуально никакие -WExtra -Wpedantic и их аналоги для компиляторов других производителей ситуацию не исправляли. Код собирался предельно чисто. Что доставляло интересных моментов в процессе отладки.