Pull to refresh

Comments 33

Спасибо, Андрей и всей команде PVS Studio за отличный продукт. Будем стараться писать код без ошибок и надеемся скоро внедрить ваш анализатор в наш CI процесс.

А вашей команде спасибо за содействие при написании статьи и интерес к нашему продукту.

Будем стараться писать код без ошибок и надеемся скоро внедрить ваш анализатор в наш CI процесс.

А есть хоть какая то информация о том, когда flipper сможет купить простой смертный типа меня ? )))

Коллаб года, не иначе! Восхищаюсь обеими командами.

Графика в статье — отдельная прелесть.

Не могу уже дождаться, когда смогу потратить свой купон на флиппер. Беглое чтение кода вызывало лишь восхищение и желание попробовать "всё это дело в деле".

UFO just landed and posted this here

Обещали осенью 21-го же. Последняя рассылка по почте:

Prepare your coupon

You are receiving this mail because you pre-ordered Flipper Zero on shop.

Excellent news! We've finally got all the components required and started the mass production. More on that in the blog: blog.flipperzero.one/november-update/

 

We are now setting priority sales in motion

 

Since the world is still in the midst of an ongoing component shortage, we can only produce a limited number of devices. That is why we are opening sales only for those who have a pre-order coupon, including you.

  1. 💵 In the nearest future you'll be able to get your Flipper Zero. You will have to pay the remaining $119 of the discounted price 

  2. 📦 You will need to pay for shipping and taxes applicable in your country, which will be calculated automatically 

  3. 🛠 Silicone case, WiFi devboard and other add-ons will be available the same day we launch sales 

  4. 📅 The coupon can be redeemed until 28th February 2022

Further instructions will be provided in the coming two weeks, on the day we launch priority sales. We will send instructions by email which will also include your personal pre-order coupon in case you've lost it.

Оплатить уже можно, если есть купон и деньги карман жмут, но рассылать начнут ориентировочно в первом квартале следующего года.

Но это не точно.

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

Ожидаем, что в первом квартале 2022 можно будет купить в розницу.
Сразу после того как разошлем все заказы с Кикстарера и предзаказы.

Ожидаем, что в первом квартале 2022 можно будет купить в розницу.
Сразу после того как разошлем все заказы с Кикстарера и предзаказы.

спасибо, тогда ждем. Уж очень хочется получить девайс

Там только бета. Доставляют не во все страны

По поводу memcpy и strcpy. Это же ПО для контроллера. strcpy потребует наличие этой функции в библиотеке, что повлияет на размер прошивки. Вероятно, поэтому и был сделан выбор в пользу memcpy. Хотя strlen используется, так что интересно конечно услшать версию написавшего код.

Это была копипаста с другого блока, сейчас там strncpy

А я подумал, что это просто потому что strcpy должен проверять каждый на символ на нуль-терминал, а memcpy - копирует указанное количество байт без лишних проверок. Хотя, учитывая вызов strlen - да, мой аргумент нерелевантен.

У меня есть небольшой горячий код, где я заранее знаю длину строки, поэтому вызов memcpy вместо strcpy в нём оправдан.

FuriRecordDataDict_set_at(furi_record->records, name_str, new_record);
record_data = FuriRecordDataDict_get(furi_record->records, name_str);

Я не настоящий сварщик, но это выглядит как два поиска в коллекции там, где можно было обойтись одним, если бы set_at возвращала указатель на то, что вставила.

FuriRecordDataDict_set_at работает с POD типами и выполняет alloc + copy. Возращаем мы указатель на элемент контейнера и единственный метод получить его это запросить его после set_at.

А так да, в M-Lib есть немного черной магии.

Какую правку стоит сделать в любом случае — это однозначно заменить "%u" на "%zu" (см. описание функции sscanf).

А разве можно рассчитывать, что sizeof(size_t) == sizeof( uint32_t)?

Вроде ж нужно юзать штуки из inttypes.h?

В embedded, когда код под другой микроконтроллер (с другой разрядностью) всё равно придётся переписывать почти с нуля - можно. Но в библиотеке (которая потенциально может быть использована на разных МК и в разных проектах) и просто для красоты (чтобы код был читабельнее, size_t несёт гораздо более конкретную смысловую нагрузку для программиста, чем uint32_t) - лучше всё же использовать size_t.

PVS умеет как-то расписывать параметры, с которыми получается ошибка? Просто, например, Клокворк тебе покажет все условия, которые должны выполниться, чтобы вылезла ошибка. У PVS это всё выглядит так, что ошибка может быть, но откуда она падает - не расскажу

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

По собственным тестам (наконец удалось добраться) общим предупреждениям не хватает конкретики.

Взять тот же V575 с free. "V575 The null pointer is passed into 'free' function. Inspect the first argument "

Один из кейсов - всегда ptr = NULL. И это а) Временами найти сложно откуда ноги растут; б) Непонятно из проверки, потому что там отсутствует always, даже если это действительно так; в) Временами он может приходить не null, в таком случае непонятно о чём ошибка

UFO just landed and posted this here

В этом семействе достаточно много флеша и ОЗУ. Эти функции мелочи по сравнению с размерами стеков BLE/ZigBee/Thread

Нормально, там ещё и stl-я с контейнерами в аппликейшенах достаточно

Какие альтернативы? Вы предлагаете делать свой велосипед? Так он будет наверняка кривее и наверняка больше.

К слову, в embedded компиляторах (точнее, линкерах) есть способы "обезжиривания" stdlib. Для gcc, который во флиппере, есть ключик -specs=nano.specs, который подключает меньшую библиотеку (особым образом собранная gcc'шная newlib, список отличий сейчас сходу не найду). Для IAR и Keil также есть отдельные переключатели в настройках проекта, которые указывают, какие библиотеки использовать.

Кстати, @Andrey2008, вы в курсе, что не всякий embedded printf/scanf умеет все возможные опции форматирования? Если вы умеете вытягивать из среды настройки линкера, можно проверять ещё и это. Я один раз на это наступил (правда, там был самодельный sprintf, вы про такой точно не знаете :-) ).

Даже велосипед будет лучше чем newlibc которая идет в штатной поставке с тулчейном.

Есть одна большая проблема с большинством десктопных libc: они не предназначены для эмбеда и в компактной поставке не threadsafe и не reentrable. Что приводит к багам из ада.

Ну, написать threadsafe код, который будет работать на любой, заранее неизвестной, ОС (у нас же baremetal, RTOS у каждого своя любимая), задача нетривиальная.
Т.е. штуки, которые не трогают глобальные объекты (тот же memcpy и strlen), по умолчанию работают хорошо. printf тоже по идее должен быть без глобального буфера (ну да, будет putchar по каждому поводу дёргать). Вот malloc и free придётся самому делать, чтоб они знали, как именно в данной ОС принято делать критические секции и прочие мютексы.

PS полез почитать, чем всё-таки отличается newlib-nano из gcc none-aebi с arm.com. И не нашёл. В исходниках есть общее описание, но что конкретно выложено на arm.com, надо отдельно разбираться...

Надо сказать что мы пересмотрели все варианты слоя склеивающего newlib с низлежащей ОС и везде всё печально.

Лучший вариант исполнения у ChibiOS: они почти ничего не используют из стандартной библиотеки и всё строят на своих примитивах. Это одно из наиболее идеологически чистых и правильных решений, с абсолютным контролем над кодом и надежностью.

В долгосрочной перспективе мы стремимся к тому что в ChibiOS.

Оператор break и макрос логирования явно стоит поменять местами.

Похоже, макрос всё-таки после default должен был вызываться

Sign up to leave a comment.