Embedded C: вопросы на собеседованиях

Когда-то отправлял в одну контору резюме сисадмина. Прислали тестовое с какими-то суровыми протоколами управления, вовсю используемыми в производственных контроллерах. А я в них вообще не разбирался, да и САУП админить как-то совсем не хотелось. Возможно, и у тебя выйдет что-то подобное.

Я не собираюсь собеседования проходить, мне просто интересно.

сколько ножек у транзистора

и как они называются

один раз про макросы container_of() и offsetof() спросили

с намеком на завалить кандидата

Каким будет результат выражения 0x80000000 == -0x80000000? Почему?

Пока что ещё никто правильно не ответил.

0x80000000 == -0x80000000? Почему?

0xблабла - это беззнаковый тип. Вот почему.

Пока что ещё никто правильно не ответил.

The negative of an unsigned quantity is computed by subtracting its value from 2^n, where n is the number of bits in the promoted operand.
The type of the result is the type of the promoted operand.

https://eel.is/c++draft/expr.unary.op#8

А если константу до 64 бит довести с помощью L? Сейчас не у компа, проверить не могу, но думаю, что результат изменится.

с намеком на завалить кандидата

Каким будет результат выражения 0x80000000 == -0x80000000? Почему?

Пока что ещё никто правильно не ответил.

Абсолютно бессмысленный вопрос для интервью. Как человек через которого прошли сотни людей позволю себе смелость заявить: (а) задачи «завалить» в принципе не должно стоять, и (б) к ответу на вопрос «а сможет ли человек для нас сделать что-то полезное» оно вас ни на йоту не приближает. Я, например, узнал что signed integer overflow is an UB спустя лет 15ти плотненькой такой разработки и многих сотен тысяч строк кода, к сожалению после того как оно выстрелило в проде. И что?

да, https://gcc.godbolt.org/z/hM7oajqr1

Ничего не смущает? Почему битность повлияла если в шестнадцатеричном представлении знак не важен? Почему компилятор на знак не ругается?

Почему битность повлияла

The negative of an unsigned quantity is computed by subtracting its value from 2^n, where n is the number of bits in the promoted operand.

https://eel.is/c++draft/expr.unary.op#8

Была бы там беззнаковая переменная, то да, был бы операнд. А в исходном коде похоже что просто два литерала. Если взять знаковую переменную и присвоить ей литерал с минусом в шестнадцатеричной форме, то и переменная будет отрицательной. Какой тогда смысл в утверждении, что в шестнадцатеричной форме только положительные значения задаются?

Почему битность повлияла если в шестнадцатеричном представлении знак не важен?

Если совсем на пальцах, то в 2-complement arithmetic -INT_MIN отображается сам в себя. Как и ноль собственно. Вопрос то в чём?

Это понятно. Сомнение в утверждении, что в шестнадцатеричной форме не может быть отрицательных зачений.

0x80000000 == -0x80000000? Почему?

А есть правильный ответ?

в 2-complement arithmetic -INT_MIN отображается сам в себя.

Следует ли компилятору в этом случае диагностировать переполнение?

Какой тогда смысл в утверждении, что в шестнадцатеричной форме только положительные значения задаются

Никакого. Я написал не то.

Тип литерала в hex форме будет первый тип, который подойдёт из списка.

• int
• unsigned int
• long int
• unsigned long int
• long long int
• unsigned long long int

0x80000000 = 2147483648

2147483648 не входит в int, поэтому выбирается unsigned int.

https://en.cppreference.com/w/cpp/language/integer_literal

Сомнение в утверждении, что в шестнадцатеричной форме не может быть отрицательных зачений.

Вопрос исключительно в типе hex literals. Уважаемый fsb4000 утверждает что оно unsigned. Я если честно - не помню, поэтому и всегда сопровождаю суффиксом ‘U’. Присвойте в int (на 32 или 64 битах) получите свой «минус».

первый тип, который подойдёт из списка.

А, ну вот, трошки сложнее, но оправдывает мою привычку быть explicit with the intent as much as possible.

There are no negative integer literals. Expressions such as -1 apply the unary minus operator to the value represented by the literal, which may involve implicit type conversions.

В общем, да. Отрицательных литералов вообще не бывает. В любой форме.

Следует ли компилятору в этом случае диагностировать переполнение?

Я считаю - однозначно. Если нет explicit cast.

с намеком на завалить кандидата — неочевидные или на хорошее знание стандарта.

Ну не обязательно неочевидные.

Просто даю на листочке код где обявлен массив из 10-ти элементов и присваивание значения элементу по индексу 10. Спрашиваю что тут не так - отсеивается больше половины. Ну и 2+2*2 того же порядка.

Как человек через которого прошли сотни людей позволю себе смелость заявить: (а) задачи «завалить» в принципе не должно стоять

Это способ не напрямую отказать неадеквату.

Это способ не напрямую отказать неадеквату.

По факту много (очень много) отсеивается на pre-screening. Т.е. люди с которыми я разговариваю уже должны «что-то понимать в этой жизни». Проблема в том что мы бы может и рады были бы нанять, так нЕкого. У меня даже разнарядка «понижать планку» спущена сверху, а толку…

задачи «завалить» в принципе не должно стоять

У меня начальство просило какой-то формальный признак для сравнения кандидатов. Соответственно, я сделал тест с десятью маленькими примерами кода, в которых были проблемы, и кандидат должен был их найти и объяснить. Но там было проще, типа на знание, что в си строки нулём заканчиваются. Могу пару таких примеров вспомнить.

if(a > b > c) some_func();

for(i = 0; i < n; i++);
    some_func();

Что касается именно Embedded, то я спрашивал про работу АЦП, ЦАП, протоколов передачи данных типа UART, SPI. Это чтобы разговорить, понять что человек реально работал с микроконтроллерами. Если надо крутого спеца, то спрашивать про I2C, CAN, USB, Ethernet.

У меня даже разнарядка «понижать планку» спущена сверху, а толку

Вероятно, вакансия скучная, вот и приходит всякий сброд. Надо чем-то интересным завлекать, если зарплату выше предложить не получается. На вакансию, связанную с машинным зрением, у нас намного больше пришло толкового народа, чем на вакансию, связанную просто с микроконтроллерами.

Странные к тебе люди приходят. Такое даже для джуна слишком.

Это си или плюсы? Я про си спрашивал.

Это си или плюсы? Я про си спрашивал.

И в чём разница?

Вроде таблички одинаковые для hexadecimal литерала без суффикса.

https://en.cppreference.com/w/c/language/integer_constant

https://en.cppreference.com/w/cpp/language/integer_literal

Я не знаю плюсов и что они там под ковром делают тоже не знаю. Может и нет разницы, а ссылки были на cpp.

Я, например, узнал
спустя лет 15ти плотненькой такой разработки
после того как оно выстрелило в проде.
И что?

Тот неловкий момент, когда системное программирование превращается в веб-макакинг.

Спросить что человек писал в озвученных в резюме проектах.

Спросить что человек писал в озвученных в резюме проектах.

Спасибо за хороший вопрос! В озвученных в резюме проектах я писал код. У вас ещё остались какие-то вопросы?

Я, например, узнал что signed integer overflow is an UB спустя лет 15ти плотненькой такой разработки и многих сотен тысяч строк кода, к сожалению после того как оно выстрелило в проде. И что?

значит ты плохой программист

у хорошего оно бы в проде не выстрелило

Нет, мы вам перезвоним.

Не знаю, может я всю жизнь общаюсь с натуральными обезьянами, но ещё не видел программиста, у которого что-нибудь не выстрелило бы на проде.

Но у вас же нет моего номера…

это с каких пор I2C стал сложнее UART, SPI, АЦП и ЦАП, что его на следующий уровень сложности отнесли?

и ещё показать нужное место в исходниках на гитхабе :)

что-нибудь другое бы выстрелило, не это :)

Это ошибка не возможна в современных C/C++, потому что санитайзеры просто крашат приложение.

https://gcc.godbolt.org/z/oq95PeboP

google сделав санитайзеры очень помог экосистеме С/С++. Хорошо что gcc и MSVC интегрировали код от google в свои комплиляторы…

значит ты плохой программист

Возможно. Как это формально измерить?

у хорошего оно бы в проде не выстрелило

Один довольно умный человек как-то сказал: «мы даём безусловную гарантию что в нашем софте есть баги» (происходило при обсуждении контракта на поддержку с клиентом). От себя могу добавить что я даже единственного безглючного HelloWorld не видел, что уж говорить о multi-MLOC проектах.

Правильно. Чтобы завалить, надо спрашивать справочные данные, которые нет смысла запоминать.

Эта ошибка не возможна в современных C/C++, потому что санитайзеры просто крашат приложение.

Вы только что опровергли теорему Тьюринга. И в runtime все варианты входных данных заранее проверить невозможно.

ну одно дело баги по невнимательности, это у всех бывает

другое дело баги от незнания матчасти

второе хуже

это не справочные, это элементарные знания

это элементарные знания

Какой из транзисторов?

все какие знаешь :)

База, сход/исход, сток/исток. Как-то так. Обычно ножки 3.