Уничтожение EXE: 640 Байт для программы на C

В наше время разработчики уже не так беспокоятся о размере приложений. Некоторые простейшие приложения требуют под 200-300 МБ, а игра вообще может весить более 100 ГБ. Я уже не говорю про "Hello World", который иногда занимет под 180-260 КБ! К счастью, есть возможность сократить размер приложения. О мусоре в exe'шнике и о способах его удаления написано в этой статье.

https://habr.com/ru/articles/922320/

#exe #размер #windows #c #c++ #gcc #минимальный #бинарники #стандартная_библиотека

Go: не используйте http.Server.Serve и http.Server.ServeTLS одновременно

Эта заметка будет очень короткой. Но надеюсь, она кому-то спасёт несколько часов жизни. У меня был код. К счастью, это было в тесте, а не в боевом коде, поэтому никто не пострадал. Код создавал http.Server , запускал две гороутинки для обслуживания входящих соединений: go func() {srvr.Serve(p)}() go func() {srvr.ServeTLS(e, "", "")}() Ну и дальше создавал клиента, делал к серверу обращения ( HTTP GET ) попеременно используя http и https ну и чего-то там проверял. Всё прекрасно работало. До обновления с go1.23.8 до go1.24.2 , пришедшего с 42-й Федорой. А потом перестало. Стало время от времени (но отнюдь не всегда) вываливать разнообразные ошибки. Например, вот такие: Get "https://127.0.0.1:46167/": unexpected EOF . Или такие: Get "https://127.0.0.1:34757/": write tcp 127.0.0.1:54770->127.0.0.1:34757: write: connection reset by peer . Или даже вот такие, совсем загадочные: Get "https://127.0.0.1:42447/": http2: client conn could not be establish . HTTP/2 там, разумеется никто не включал и не собирался. А иногда всё работало и тест проходил правильно. Самое поганое, что ошибка была плавающей. В общем, не буду грузить подробностями, как я эту ошибку ловил. Но итог такой. Хотя это нигде и не документировано, но одновременно использовать http.Server.Serve и http.Server.ServeTLS на одном и том же экземпляре сервера нельзя. Тот из них, кто успеет прокрутиться первым, чего-то там инициализирует внутри сервера, прежде, чем уйти в accept loop, и второй после этого ломается. Ломается всегда ServeTLS, не-TLS-овскому Serve вроде как пофигу. Так что будьте осторожны, и надеюсь, что эта заметка сохранила вам несколько часов жизни :)

https://habr.com/ru/articles/906796/

#Go #стандартная_библиотека

[Перевод] Ужасное состояние двоичной совместимости Linux (и что с ним делать)

Двоичная совместимость в Linux омрачена одним аспектом, который часто упускаю из виду при рассмотрении выпуска ПО для Linux. В этой статье я расскажу, как можно увидеть этот аспект, как решать эту проблему при выпуске современного ПО и что же именно нужно сделать, чтобы устранить её полностью.

https://habr.com/ru/articles/893720/

#двоичная_совместимость #дистрибутивы_linux #linux #libc #стандартная_библиотека

C++ и кризис стандартизации

У меня на ладони лежит очень горячий сотовый телефон, который разогрелся из‑за того, что мессенджер отображает статичное сообщение с пузырем и текстом на экране при помощи браузерного движка и безумного количества сторонних библиотек. При этом я отлично помню время, когда десктоп был в 10 раз менее производительным, чем этот сотовый, а не‑кроссплатформенные мессенджеры тех времен, написанные на С++, отображали текст не нагружая эти допотопные процессоры и на 10%. Я считаю, что в такой деградации виноват в первую очередь комитет по стандартизации C++. Их близорукие решения и неспособность адаптироваться к реальным потребностям разработчиков привели к парадоксальной ситуации: несмотря на постоянное увеличение мощности компьютеров, программы работают медленнее и потребляют больше ресурсов, чем их аналоги десятилетней давности, а С++‑разработчики не могут создать даже простой мессенджер, который будет работать на 2–3 распространенных операционных системах, не используя массы сторонних библиотек. C++ задумывался как язык, который должен был дать программистам возможность писать эффективный код с высоким уровнем абстракции. Однако комитет по стандартизации своими действиями превратил его в переусложненный инструмент, непригодный для решения базовых задач современного программирования. Давайте рассмотрим, как именно комитет саботирует развитие языка. Комитет создал порочную практику бесконтрольного добавления новых возможностей без удаления устаревших. C++ превратился в настоящего монстра, где даже для такой базовой операции как создание строки или умного указателя существует множество способов. Такое разнообразие не только затрудняет обучение языку, но и создает реальные проблемы при разработке, когда разные библиотеки используют разные подходы к решению одних и тех же задач.

https://habr.com/ru/articles/884994/

#с++ #стандартная_библиотека

[Перевод] Анатомия Hello World на языке C

Эта статья посвящена программе Hello World, написанной на C. Это максимальный уровень, на который можно добраться с языком высокого уровня, не беспокоясь при этом о том, что конкретно язык делает в интерпретаторе/компиляторе/JIT перед выполнением программы. Изначально я хотел написать статью так, чтобы она была понятна любому, умеющему кодить, но теперь думаю, что читателю полезно иметь хотя бы некоторые знания по C или ассемблеру.

https://habr.com/ru/companies/ruvds/articles/808399/

#ruvds_переводы #стандартная_библиотека #системные_вызовы #дизассемблер #компиляция

Не пора ли валить с gnu libc на что‑то другое?

Пользуюсь открытым ПО значительное время. Сижу на Линуксе. Но в последнее время настолько часто сталкиваюсь с различными багами, что думается иногда, а как оно вообще в принципе работает? Последний эпизод коснулся совсем уж системного кода - стандартной библиотеки libc от GNU. Системнее может быть только ядро. История такая. Собрал Хромиум (не быстро). Когда наконец сборка завершилась с попутным решением проблем, думал: ну вот наконец щас запущу, посмотрю как работают интересующие меня вещи. И тут произошёл облом. Хром падал почти в самом начале запуска с ошибкой доступа к памяти. Довольно быстро удалось выяснить, что падение происходит из-за ошибки обращения по нулевому указателю. И происходит оно в динамическом загрузчике, то бишь в libdl, при загрузке библиотеки через dlopen . libdl.so является одной из компонент пакета стандартной библиотеки и понятно, самой системной библиотекой в ОС. Подробности всей ситуации я описал в вопросе на stackoverflow . Вкратце: при загрузке библиотеки libXcursor.so подтягиваются непонятно откуда взявшиеся зависимости, не имеющие никакого отношения к упомянутой библиотеке. И зависимости эти не инициализированы корректно. Откуда и происходит обращение по нулевому указателю. Впоследствии выяснилось, что проблема начинается с несовпадающих версий библиотек libQt5Core, в результате чего libdl делает полный отбой с попыткой отката всех изменений. Но, видимо, этот откат реализован из рук вон плохо, поскольку после него начинают происходить весьма странные вещи. И загрузка неинициализированной зависимости с нулевыми указателями лишь одна из них. Я ещё сделал пробник в виде простого приложения, которое пытается воспроизвести ситуацию. И в этом пробнике также происходил сбой, но уже при инициализации (вызов init или конструктор в их терминологии) либы libpthread.so (тоже очень системная) - потерян адрес глобального на процесс хранилища либ.

https://habr.com/ru/articles/792980/

#linux #libc #linker #elf_linux #library #библиотека #стандартная_библиотека