Один из разработчиков из компании Google поднял (http://lists.llvm.org/pipermail/llvm-dev/2019-June/133269.html) в списке рассылки LLVM тему разработки многоплатформенной стандартной Си-библиотеки (Libc) в рамках проекта LLVM. По ряду причин Google не устраивают текущие libc (glibc, musl) и компания на пути к разработке новой реализации, которую предлагается развивать в рамках проекта LLVM.
Наработки LLVM последнее время используются в качестве основы для построения сборочного инструментария Google. Основной идеей является то, что если Google уже начал развивать свою libc, то почему бы ему сразу не развивать свою систему в составе LLVM, который уже развивает свою стандартную билиотеку для С++ (Libc++), но не имеет аналогичной стандартной библиотеки для Си (Libc).Разработку планируется вести поэтапно, постепенно наращивая функциональность. Первые варианты предлагается оформить в виде прослойки между приложением и системной Libc, из которой будут заимствоваться ещё не реализованные возможности. После достижения определённого уровня в функциональности новая Libc сможет применяться в качестве полной замены системной Libc. Начать планируется с поддержки архитектуры x86-64, Linux и статического связывания (динамическая загрузка, компоновка и дополнительные архитектуры будут реализованы во вторую очередь).
Проект пока на начальной стадии развития, но уже определены базовые цели:
- Модульность и развитие в соответствии с философией поставки гранулированной библиотеки, а не монолитного набора;
- Поддержка статического связывания в режимах с PIE (https://en.wikipedia.org/wiki/Position-independent_code#PIE) (Position-independent executables) и без PIE. Предоставление CRT (C runtime) и загрузчика PIE для статически связываемых исполняемых файлов;
- Поддержка большей части функций стандартной Си-библиотеки с дополнениями POSIX и некоторыми специфичными для систем расширениями, востребованными в существующих приложениях;
- Осторожное отношение к специфичным для производителей расширениям и их добавление только при необходимости. В отношении поддержки сторонних расширений предлагается применять подход проектов Clang и libc++;- Использование образцовых практик в разработке с использованием инструментария LLVM, таких как применение sanitizer и fuzzing-тестирования с самого начала.
Один из активных разработчиков LLVM указал (https://lists.llvm.org/pipermail/llvm-dev/2019-June/133282.h... что поставка libc в составе инструментария LLVM не лишены смысла, но обычно при подобной необходимости используют библиотеку musl, которая качественно написана, поддерживает различные архитектуры и предоставляет необходимую функциональность, в том числе поддерживает динамическое связывание. Оправданным может быть встраивание musl в LLVM и развитие его как синхронизированного с основным проектом форка.
Своё мнение также выразил (http://lists.llvm.org/pipermail/llvm-dev/2019-June/133308.html) автор проекта Musl, который попытался аргументировать почему предложение Google и включение Libc в поставку LLVM являются очень плохими идеями:
- Разработка и сопровождение корректной, совместимой и высококачественной Libc является очень трудной задачей. Проблема не в объёме кода, а в обеспечении корректного поведения и трудностях с реализацией интерфейсов с учётом огромного пласта когда-либо написанных приложений на С/C++, а также приложений на других языках, runtime которых использует Libc. Подход в лоб без учёта нюансов лишь приведёт к тому, что многие существующие программы не смогут работать с Libc, но тогда такой проект не будет интересен потребителям.- Корпоративная разработка может испорить Libc, но протолкнуть для широкого использования, итогом чего станет необходимость добавления хаков для обеспечения совместимости в приложениях. Разработка под эгидой корпоративного открытого проекта будет тянуть одеяло в сторону потребностей и решений компании, в ущерб интересов сообщества. Например, в случае выявления проблемы, которая вызвана ошибкой в другой своей программе, в подконтрольной разработке проще обеспечить совместимость Libc с этой ошибкой, чем исправить саму ошибку. Apple использует для этих целей форк BSD libc, а Google применяет в Fuchsia форк musl. Опыт разработчика musl готовит то том, что с ним связывались в основном юристы для уточнения вопросов лицензирования, но не никогда не обращались для уточнения технических деталей перед внесением в свои ответвления бесполезных и нарушающих работу изменений.
- Отсутствие монокультуры при разработке libc и ориентация на развиваемые на основе достижения консенсуса стандарты, вместо единоличного управления, что мотивирует разработчиков прикладных приложений использовать стандарты, а не привязываться к конкретным реализациям. Именно поэтому автор musl против включения его библиотеки в состав LLVM, как и против разработки libc в рамках LLVM, так как в этом случае утрачивается независимый характер libc и определённая реализация становится решением первого класса для LLVM, а все остальные второго.
URL: https://news.ycombinator.com/item?id=20280487
Новость: https://www.opennet.dev/opennews/art.shtml?num=50970
Rich Felker дело говорит. Я думаю, к его мнению многие прислушаются.
> Rich Felker дело говорит.Безусловно.
> Я думаю, к его мнению многие прислушаются.
Хотелось бы, но совсем не удивлюсь, если не прислушаются.
> Я думаю, к его мнению многие прислушаются.Многие, но не Google.
>Многие, но не Google.Ну и бох с ними - пусть пишут свой 101 велосипед, только она будет вне LLVM.
У них же вроде и так есть Bionic.
Она, по-моему, только часть Android. Тут же речь идёт про LLVM в целом...
Да и честно говоря лично у меня были немалые трудности при использовании Bionic после долгой работы с glibc, хотя там имела место привычка юзать _np функции из glibc.
Ага со сливом всего проходящего через либу на google.com
Браузера им мало, ещё и libc хотят монополизировать?
Они хотят свой особый libc, в который они могут вносить свои правки ни с кем не считаясь.libc (да и musl, в принципе, тоже, т.к. обещает совместимость) штука очень консервативная, ибо фундамент, и чтобы в ней что-то менять нужны очень веские основания и консенсус всех участников разработки. Гуглу это не нравится.
> чтобы в ней что-то менять нужны очень веские основания и консенсус всех участников разработкиЯсен пень, т.к. спецификацию на libc делают не разработчики libc, она даётся из вне и должна работать так как описано в стандарте. Иначе такая libc не нужна. Это вам не IE6, где можно быстренько поправить скриптик в блокноте.
>Браузера им мало, ещё и libc хотят монополизировать?Ещё мой дед говаривал мудрые поговорки, мало чего помю, но вроде звучали они как-то так:
-Не можешь победить, возглавь!
-Если за дело взялся Гугл, жди беды!
-Бойтесь Гуглайцев, дары приносящих...
О Гугле хорошо или за остальное забанят ваще везде.
Я пользуюсь Firefox
Я не одобряю увеличение влияние гугла. Отказать!
Исполнено. Гуглу отказано. Спасибо за написанное вами здесь, не одобрительное сообщение.
Почему не форкнуть и не рефакторнуть musl, если уж на то пошло.
А, понял. Им проще форкнуть Bionic.
А почему бы им просто не пойти в попу?
Вы там аккуратнее с предложениями, они ведь могут и выполнить.
В тексте и так написано, что гугл форкнул musl. Все, кто когда-нибудь работал с Android NDK, знают, какой там творится ад.
Вот как раз недавно пришлось работать с ним, поддерживаю... Сама по себе Bionic тоже далеко не торт.
>По ряду причин Google не устраивают текущие libcНужно больше зондов! И чтоб подлиннее!
Без объяснения этого ряда причин звучит просто как NIH.
Кстати поиск гугла сильно хуже чем 10 лет назад... с чего бы... может, мало велосипедов написано...
Ты точно яндекс не видел?
Он заблочен... а что с ним? Он лучше?
однако, да, музыку яндекс ищет лучше...
понимаю, что пиратсво плохо, но еще хуже когда нет свободы.
> что пиратсво плохоПиратство, это когда ты продаёшь не лицензионные копии.
И плохо это только потому, что какой-то левый тип получает деньги ни за что.А скачивать музыку из сети, положив писюн на "правообладателей" - это хорошо, нравственно и правильно.
> И плохо это только потому, что какой-то левый тип получает деньги ни за что.А можете внятно объяснить, почему плохо, когда кто-то получает халявные деньги???
>> И плохо это только потому, что какой-то левый тип получает деньги ни за что.
> А можете внятно объяснить, почему плохо, когда кто-то получает халявные деньги???Мама с папой говорили, что деньги надо -- за работу.
А кода не работая - деньги....
....невидимая рука рынка творит сплошь какую-то фигню.Вот, на это наше АйТи взгляните. Видите?!
>> И плохо это только потому, что какой-то левый тип получает деньги ни за что.
> А можете внятно объяснить, почему плохо, когда кто-то получает халявные деньги???Для кого плохо? Для того, кто получает - это, безусловно, хорошо.
Для правообладателей плохо, потому что деньги платят не им. Но их не очень-то и жалко.
Для тех, кто, собственно, пришёл за музыкой (ну или чем-то ещё - не суть) это плохо потому что надо платить. Причём, не музыканту, не "правообладателю" (который хотя бы формально при делах), а кому-то совершенно левому.
В мире, где примерно всё скачивается с торрентов вариант как с правообладателем, так и с пиратом слегка идиотский и финансировать что тех, что других незачем. Единственное, в случае с пиратом немного больше лицемерия. Правообладатель изначально преподносит себя как жадный кондом-вредитель, а пират наверняка строит из себя борцуна за свободу.
>Для тех, кто, собственно, пришёл за музыкой (ну или чем-то
>ещё - не суть) это плохо потому что надо платить. Причём, не музыканту,
>не "правообладателю" (который хотя бы формально при делах),
>а кому-то совершенно левому.А можно выстроить такие отношения, когда вы поддерживаете копейкой непосредственно своего любимого музыканта, пользоваться разными инструментами, типа прямых донатов, патреонов, или же не совсем напрямую, типа Flattr, если к подобному стилю больше душа лежит, было бы желание! Когда музыканты и прочие создатели контента увидят, что получить таким образом можно гораздо больше и такие методы более продуктивны, они сами откажутся от кабальных контрактов со всякими паразитами-прилипалами, типа современных продюссеров и правообладателей, вот кто больше похожь на настоящих пиратов, грабит и отнимает то, что им не пренадлежит!
> Когда музыканты и прочие создатели контента увидятВот учёные давным давно с приходом Интернета получили такую возможность. Например, https://arxiv.org А всё равно давятся, даже платят(!) журналам, да при этом ещё и бесплатно рецензируют статьи коллег. Абсурд!
> скачивать музыку из сети, положив писюн на "правообладателей" - это хорошо, нравственно и правильно.При этом вы кладете его и на авторов музыки.
>> скачивать музыку из сети, положив писюн на "правообладателей" - это хорошо, нравственно и правильно.
> При этом вы кладете его и на авторов музыки.Значительное число пока ещё живых исполнителей, которых я слушаю, одобряют распространение музыки через сеть забесплатно. Или, по крайней мере, относятся к этому с пониманием.
Понравившимся исполнителям я могу так просто задонатить, посетить их концерт или купить лицензионный диск, в бОльшей степени ради оформления и для коллекции.
В любом случае не вижу смысла позволять им зарабатывать на копировании, стоимость которого равна нулю. Особенно, если их цель была заработать, а не высказаться (почти наверняка подобная музыка мне и не зайдёт в любом случае).
>Значительное число пока ещё живых исполнителей, которых я слушаю, одобряют распространение музыки через сеть забесплатно.Они одобряют воровство? Ну чтож.. нашли друг друга как говорится...
Есть исполнители, которые распространяют свою музыку сами. И никаких проблем с правообладателями.
А вот те, что сперва раскрутились за счет дяди, а потом заявили что дескать они не против что у дяди который дал им жизнь воруют - это как история с MySQL AB.
>>Значительное число пока ещё живых исполнителей, которых я слушаю, одобряют распространение музыки через сеть забесплатно.
> Они одобряют воровство? Ну чтож.. нашли друг друга как говорится...Копирование не является воровством. Как бы я не презирал столлмана, в данном случае он прав, ибо тиражирует очевидную вещь.
> Есть исполнители, которые распространяют свою музыку сами. И никаких проблем с правообладателями.
Например, бесплатно через интернет, ага.
> А вот те, что сперва раскрутились за счет дяди, а потом заявили что дескать они не против что у дяди который дал им жизнь воруют - это как история с MySQL AB.
Открою тебе страшную тайну: дядя не дал им жизнь. Если, конечно, речь не о тупейшей коммерции. Подавляющее большинство групп слушают за их музыку, а на дядю-шакала-трупоеда всем наплевать.
Есть, конечно, странные примеры, типа металики, которая раскрутилась за счёт того, что их музыку бесплатно копировали и распространяли подпольно, а потом она включила копирастию 9000го уровня и даже напстер что ли засудила. Но как по мне, такие примеры - ещё один аргумент в пользу того, что я говорю, а не против.
> Пиратство, это когда ты продаёшь не лицензионные копии.Пиратство — это когда ты нападаешь на морское или речное судно в целях завладения чужим имуществом с применением насилия либо с угрозой его применения.
Согласен и пиратство и кража - это когда у кого-то что-то отнимают, а не копируют. Пираством Поднебесная занимается на государственном уровне так что сказки про "воровство" и "пиратсво" в сфере IT оставьте полным отморозкам, жаждущих денег за их "гениальные" произведения и мысли.
>> нападаешь на морское или речное судно в целях завладения чужим
> Согласен и пиратство и кража - это когда у кого-то что-то отнимают,
> а не копируют. Пираством Поднебесная занимается на государственном уровне такВот ты гений-то! Браво. Специальный олимпиец.
> Кстати поиск гугла сильно хуже чем 10 лет назад... с чего бы...Поиск хуже, чем еще пару лет назад.
Особенно заметно стало после недавней (для меня - хз насколько у гугля это уже "индивидуализированно") модернизации интерфейса и (особенно) в "безЖСном" режиме, где уже вообще не выставить никаких фильтров (менюшку убрали) плюс оно теперь не показывает "нет результатов, увы" или "вот 2 результата по точному запросу, а вот отсюда и далее уже приблизительно", а просто показывает что-то типа "ищем не там где потерали, а за углом, где есть фонарь!".
вот это бесит, плюсы и кавычки уже пару лет не работают
> Кстати поиск гугла сильно хуже чем 10 лет назад... с чего бы.с того что десять лет назад ты так не усердствовал с защитой от трекинга
залогинься обратно в акаунт, заблудшая душа - и поиск будет просто великолепен.
особенно, если ты, как все, используешь наш, самый правильный, браузер.
> Начать планируется с поддержки архитектуры x86-64, Linux и статического связыванияНа этом и закончат.
Раньше утверждал - чем меньше в компьютере мс, тем лучше. Теперь к компании добавился гугл.
Корпорация Добра перешла на Темную сторону, Люк...
она там всегда и была. просто хорошо маскировалась :)
> Корпорация Добра перешла на Темную сторону, Люк...https://www.engadget.com › 2015/10/02 › alphabet-do-the-right-thing
> Alphabet replaces Google's 'Don't be evil' with 'Do the right thing'На третий день Зоркий Глаз … ;)
...вот только их "right" какое-то ультралевое...
mariadb тоже зло?под винду точно работает лучше чем оракловский mysql
под centos еще ни разу не слетатал ни тот ни другой
А почему не на Go??
Потому что если они будут писать код на Go, то сдохнет Go, а не приложения написанные на Си под андроидом.
Так и запишем, нежелание использовать свободное по и открывать код.
> и открывать код.Давно BSD лицензия LLVM стала не открытой?
Но есть такие, как Гугель. Они-то могут одним движением руки превратить то, что под ней в закрытое.
Они могли бы просто не открывать исходники своей libc. Но их план более коварен: сначала открыть, а потом — взять и закрыть.
много в этом поможет GPL если авторство будет принадлежать гуглу?
Apache 2.0 License with LLVM exceptions.
Долой руки копирастов от свободного кода libc.
Всё равно напишут своё. И потом все свои проекты прибьют гвоздями к этой новой libc, как уже прибивают к BoringSSL и clang. У Google хронический NIH синдром.
Попахвает https://ru.wikipedia.org/wiki/Embrace,_Extend,_and_Extinguish
И у меня сразу возникла та же мысль...
Он уже не попахивает а довольно сильно воняет. Причём уже длительно время. Начиная с гугла, заканчивая майкрософтом в последнее время (добрались таки).
А с учётом того что гугл почти монополист во многих областях (веб, десктопы [браузеры, electron], мобилки) то диктовать свои правила они не боятся совершенно.
Наверно их все пошлют подальше и как было сказано выше на этом все закончится.
> Наверно их все пошлютСогласен. Как уже послали с Андроидом, Хромом, Гмейлом...
Кстати, да -- осталось с остатков гмайла в качестве всеядного mx свалить.
правильно, на скрепную яндекс-почту!
Было бы не плохо что бы гугл запилил бы себе какой ни будь свой интернет и там и отдуплялся, барыжил бы выдачу, клики, пузырял бы пузыри информационные, кантачил бы с гнидой из амазона, решал бы вопросы с марком цукерфакером, а вот от интернетов бы шоб ручки свои шаловливые чтоб убрал под своё пропуканое одеяло, вот то было-б дело делов!...
так мы вроде и того, уже ж?В смысле, это ведь наш интернет, и в нем все примерно так и есть!
На самом деле это ближе чем вы думаете. У них уже есть на пару с Facebook свой глобальный бэкбон.
Этот ваш "гугл" напоминает наше правительство с роскомзапретами
согласен совсем о роскомзапретились)))
> Подход в лоб без учёта нюансов лишь приведёт к тому, что многие существующие программы не смогут работать с Libc, но тогда такой проект не будет интересен потребителям.Ну тогда это шанс. Корпорации в общем и гугл в частности - это настолько крупные потребители, что они могут забить на интересы прочих мелких потребителей. И наконец-то выпустят libc который работает по стандартам, а не по принципу обратной совместимости костылей. И если разработчик отказывается следовать стандарту, и его программа падает - тем хуже для разработчика, гуглу это что слону дробинка.
а стандартами будет то, что мы укажем. Костыли-не костыли - жрать что дали и не вякать!
И кто-то ругает до сих пор MS? Последние хоть не паразитировали на открытом коде. Просто пишут закрытый/открытый код как им хочется.Если LLVM прогнется, то пошли они в лес. Кто-то так или иначе форкнет как OpenLLVM или LibreLLVM. Проверено сообществом.
Майкрософт со временем тоже начнёт свою паразитарную деятельность в опенсорсе/свободном ПО (WSL и прочие ништяки уже на подходе). А по LLVM Столлман уже давно выразил свою позицию и не считает его свободным (поскольку лицензия не копилефт). И творить с LLVM могут что угодно, не считаясь с остальными.
Майкрософт уже внезапно главный контрибьютор в экосистему раста, по объему кода если правильно помню, да и сам actix — ключевой фреймворк. И WSL — это посто-таки подарок для пользователей винды, мс в этом большие молодцы.
Ну гугл тоже активный участник (например в ядре), что это меняет?
> Ну гугл тоже активный участник (например в ядре), что это меняет?Это значит, что ему нужно быть скромнее, меньше активничать.
А что?....
Право на форк. Ответ рабочего класса буржуям. Гугл стремится к монополии и контролю. Ну и как вам живется при капитализме, товарищи? ( В.И. Ленин).
Действительно, КПСС быстро бы запретили всё это. Гугл был бы быстро национализирован, а его топ менеджмент — раскулачен и сослан в ГУЛАГ. Только код писать бы некому было.
топменеджмент научать в ГУЛАГ-е писать код.Совсем чтоль без головы ? Где код, а где топменеджмент ?
Шарашка - как решение проблемы!
Вы все страшилки которые навыдумывали собирали в одну кучу? Почему ещё не добавили передача сотрудниц гугла в общее пользование, программерские трудодни, гонения по нац^W и^W рел^W признаку симпатии к ОС. Ну и прочие перестроечные байки из журнала огонек.
Это, конечно, всё хорошо, но где объяснение причин для собственной libc? Заявления типа "у нас в гугле возникают проблемы с использованием glibc" как-то не выглядят особо убедительно. Какую конкретно проблему решит новая реализация libc?
>Какую конкретно проблему решит новая реализация libc?Как я понял из письма, они хотят разбиение libc на мелкие компоненты и статическую линковку. В последнем случае glibc отпадает, потому что статическая линковка там нормально не поддерживается. Чем им musl не угодила, я не знаю.
>>Какую конкретно проблему решит новая реализация libc?
> Как я понял из письма, они хотят разбиение libc на мелкие компоненты
> и статическую линковку. В последнем случае glibc отпадает, потому что статическая
> линковка там нормально не поддерживается. Чем им musl не угодила, я
> не знаю.Да, для меня это тоже выглядит острым приступом NiH синдрома.
>glibc отпадает, потому что статическая линковка там нормально не поддерживаетсяStop reopening
Есть 4 компонента кретичные для безопасности ОС:Ядро ОС Linux, компилятор С gcc, стандартная библиотека glibc и набор утилит binutils.
Власть Google, или другой монополии над любой из них допускать нельзя!
>Есть 4 компонента кретичные для безопасности ОСКретичные — это ведь от слова кретинизм, да?
Ну не надо по себе судить, я от слова креативность наверно "е" взял. ;)
это потому что кре... ативный ты )))
> Есть 4 компонента кретичные для безопасности ОС:
> Ядро ОС Linux, компилятор С gcc, стандартная библиотека glibc и набор утилит binutils.Всегда подозревал, что HardenedBSD на самом деле дырявое реш3то!
Имел в ввиду 4 компонента для *NIX. А для примера привёл назван е компонент с GNU/Linux.1. Ядро ОС
2. Компилятор
3. Системная библиотека
4. Базовые системные утылитыЕсли школу или кому другому в них удастся засунуть закладки - получит контроль над системой. И защититься не получится.
Благодарю за перевод и возможные дополнения
А потом они форкнут LLVM
Сначала напишут кучу кода, опубликуют его на весь мир под пермиссивной лицензией, а затем форкнут. Хитрый план, не так ли?
как вам /lib/libmsvcrt.so.1.0.0 от Microsoft?)
Полна фигня. Вот для винды бы лучше и сделали нормальную libc.
Очередной NIH от Google.
> Очередной NIH от Google.Гугль прижимающийся своими НИХом к эпплову НИХу.
К кому только не прижмутся -- лишь бы не GPLv3+.
пох-нах оценит!P-D
>> Очередной NIH от Google.
> Гугль прижимающийся своими НИХом к эпплову НИХу.
> К кому только не прижмутся -- лишь бы не GPLv3+.
> пох-нах оценит!P-DЯблочный NIH умеет шейдеры компилировать, от него есть реальная польза для Mesa!
>>> Очередной NIH от Google.
>> Гугль прижимающийся своими НИХом к эпплову НИХу.
>> К кому только не прижмутся -- лишь бы не GPLv3+.
>> пох-нах оценит!P-D
> Яблочный NIH умеет шейдерыСтолмановский тоже вродь научили. Почти.
Но это никому не интересно, согласен.
Противно даже! " Нормальному мужику такое впадлу предлагать. "
>компилировать, от него есть реальная польза для Mesa!
Я изучал стандартную библиотеку языка С:
glibс - это треш, в котором черт ногу сломит (макрос на макросе) - очень сложно разобраться и понять что там происходит. Видимо девиз тех, кто это писал такой: Смотрите как мы можем, смотрите какие мы умные, а вы нет!
musl - они думают, что они лучше glibc, но по факту не так уж и сильно. Более того, это ещё один пример того как НЕ надо писать на языке Си. Ребята очнитесь вы там, вы пишите код для людей, а не ебу** заклинания для компилятора.
bsd libc (в openbsd) - по сути такое же гавно (в плане стиля кода), как и
Продолжение:
остальные - не пишите так код!
Р/S IMHO Лично мне куда больше нравится стиль в книге The Standard C Library (реализация ANSI C library)
Вот вам пример из исходников:
https://git.musl-libc.org/cgit/musl/tree/src/string/strncat.c
А теперь, кто внимательный, видите здесь, что-то странное (лишнее)?
> Вот вам пример из исходников:
> https://git.musl-libc.org/cgit/musl/tree/src/string/strncat.c
> А теперь, кто внимательный, видите здесь, что-то странное (лишнее)?Из n надь вычесть strlen(s). И единицу. И проверить underflow при том.
Я выиграл? Не отвечайте. Я знаю, что проиграл -- "программирование" не моё.
Не вижу. Если Вы видите, сообщите, пожалуйста, что именно там "странное (лишнее)".
Нужно писать так:
*d = 0;
вместо этого:
*d++ = 0;
В данном случае, это никак не отражается на том, как ведёт себя данный код, однако согласитесь что это не есть хорошо!P\S
Опять же это лишний раз показывает то, что код должен быть написан в первую очередь для людей, так чтобы даже скажем условный студент 1-3 курса смог без труда разобраться.
Например, я бы написал это так:
char *strncat(char *to, const char *from, size_t n)
{
char *ret;
ret = to;for (; *to != '\0'; ++to)
/*nothing*/;for (; n != 0 && *from != '\0'; --n, ++from, ++to)
*to = *from;*to = '\0';
return ret;
}
Современные компиляторы (в большинстве случаев) прекрасно справляются с оптимизацией, так что не надо писать заумные вещи и показывать всем какой вы умный (В Си и без этого можно легко выстрелить себе в ногу)
Спасибо. Насчет лишнего "++" согласен что нагляднее без него, скажу Rich'у. В остальном по наглядности кода мне не очевидно чья версия лучше.
А вы попробуйте посмотреть на это с точки зрения неопытного Си программиста
А зачем неопытному Си программисту лезть в ДНК?
Наверное затем, чтобы понять как устроено ДНК и тем самым стать более опытным как можно раньше, а не смотреть на всё это сквозь призму черного ящика и делать глупые ошибки.
Чтобы стать более опытным, надо смотреть в реальный код, а не в адаптированный для неопытных. Это так же как с иностранными языками -- читать адаптированные тексты имеет смысл лишь в первые полгода обучения.
Никто и не отрицает важность умения читать и понимать то что написали другие люди, и в случае если потребуется, уметь писать в таком же стиле, в рамках проекта игнорируя свои личные предпочтения."Реальный код" - это код который написан реальными людьми, так что любой код это реальный код!
Что на счёт "Хорошего кода", то тут у каждого свое представление о том что это значит.
> "Реальный код" - это код который написан реальными людьми, так что любой
> код это реальный код!Как ты думаешь, если бы "реальный код" == "любой код", то зачем мне нужно было говорить прилагателное "реальный"? Явно ведь, что я хотел сказать что-то иное, а не то, что тебе хочется, так? Я верю в тебя, и тебе тоже следует поверить в себя: ты можешь понять, что именно я говорил, если подумаешь. Не сдавайся так быстро.
Я прекрасно вас понял!Просто, то что вы назвали адаптированным кодом, прозвучало так, как-будто в реальных проектах так никто не пишет!
> Я прекрасно вас понял!
> Просто, то что вы назвали адаптированным кодом, прозвучало так, как-будто в реальных
> проектах так никто не пишет!Пишут. Ещё и не так пишут. Бывает такой кошмар в коде, что сей пример на его фоне будет выглядеть совершенно безобидным.
>показывать всем какой вы умныйВот и не показывай.
strlen(d) из оригинала может быть заменен на специфический для платформы очень быстрый набор инструкций, а твой "for (; *to != '\0'; ++to)" (который на самом деле while(*to) to++;) - нет.
и откуда вы лезете с '\0' то? Впрочем, все эти размазывания присвоений на 3 строчки - явно карпарифный стандарт с галеры, где платят за количество строк кода. Можешь устариваться в гуголь, там такое любят.
А вы забавный:)))Я понял, Вы походу настолько суровы, что вместо NULL тоже везде пишете 0. Имена всех ваших переменных не длиннее одной буквы, а об оптимизации вы думаете ещё до того как получите хоть какой-то рабочий код.
Чтоже так тоже можно, но я предпочитаю думать о тех людях кто будет поддерживать код после меня, помня о том что возможно это буду я сам:))
ПС
А на счет '\0', и мой цикл for, ну что тут сказать, могу вам посоветовать почитать книгу:
The Practice of Programming (B.Kernighan and R.Pike)
И все претензии предъявлять этим уважаемым господам:))
>strlen(d) из оригинала может быть заменен на специфический для платформы очень быстрый набор инструкций, а твой "for (; *to != '\0'; ++to)" (который на самом деле while(*to) to++;) - нет.Дайте пример! Хочу увидеть где можно ускорить и без того простейший инкремент.
>>strlen(d) из оригинала может быть заменен на специфический для платформы очень быстрый набор инструкций, а твой "for (; *to != '\0'; ++to)" (который на самом деле while(*to) to++;) - нет.
> Дайте пример! Хочу увидеть где можно ускорить и без того простейший инкремент.Например, обрабатывать не байтик за байтиком:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/i38...
L(1): movl (%eax), %ecx /* get word (= 4 bytes) in question */
65 movl $0xfefefeff, %edx /* magic value */
66 addl %ecx, %edx /* add the magic value to the word. We get
67 carry bits reported for each byte which
68 is *not* 0 */
69 jnc L(3) /* highest byte is NUL => return pointer */
70 xorl %ecx, %edx /* (word+magic)^word */
Или вообще использовать SIMD:https://www.strchr.com/strcmp_and_strlen_using_sse_4.2
; ==== strlen ====
strlen_sse42:
; ecx = string
mov eax, -16
mov edx, ecx
pxor xmm0, xmm0STRLEN_LOOP:
add eax, 16
PcmpIstrI xmm0, dqword[edx + eax], EQUAL_EACH
jnz STRLEN_LOOPadd eax, ecx
retglibc
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86...
L(loop):
174
175 addq $64, %rax
176 cmpq %rax, %r10
177 je L(exit_end)
178
179 movdqa (%rax), %xmm0
180 PMINU 16(%rax), %xmm0
181 PMINU 32(%rax), %xmm0
182 PMINU 48(%rax), %xmm0
183 PCMPEQ %xmm3, %xmm0
184 pmovmskb %xmm0, %edx
185 testl %edx, %edx
186 jne L(exit)
187 jmp L(loop)
Так или иначе везде циклы, я-то думал, что будет что-то фантастическое в одну/две операции. Все равно за примеры спасибо.
Смешно.Ваш for (; *to != '\0'; ++to) это strlen в упрощенном виде:
https://git.musl-libc.org/cgit/musl/tree/src/string/strlen.cС точки зрения компилятора ваш код ничем не отличается от того, что в musl.
Итого, вы придрались к оформлению и к *d++ = 0, где инкремент может выпилить компилятор. Возникает вопрос зачем 100500 раз везде писать "for (; *to != '\0'; ++to)" вместо strlen? Вот это и есть дурной тон программирования. Другой вопрос почему strlen не сделан в виде макроса.
>>>Ваш for (; *to != '\0'; ++to) это strlen в упрощенном виде:В этом и весь смысл.
Вы всё равно должны учесть, что всё это рассчитано главный образом на компилятор gcc. (__GNUC__)>>> С точки зрения компилятора ваш код ничем не отличается от того, что в musl.
Так в том и суть, если нет разницы зачем писать такие "заклинания". Покажите мне хоть одну книгу по языку Си, где так учат писать код.
>>>Итого, вы придрались к оформлению и к *d++ = 0, где инкремент может выпилить компилятор.
Именно такие ситуации, в конечном итоге, и приводят к логическим ошибкам в коде программы.
Игнорировать такое просто недопустимо!!!>>>Возникает вопрос зачем 100500 раз везде писать "for (; *to != '\0'; ++to)" вместо strlen?
Потому что (в таких случаях):
если всё что вы делаете, так это двигаете указатель (чтобы затем использовать его) --> просто напишите цикл. В других случаях, при других обстоятельствах - я с вами полностью согласен!>>>Другой вопрос почему strlen не сделан в виде макроса.
Потому что лучше написать функцию вместо макроса. Все современные компиляторы прекрасно разберутся сами и смогут избежать вызова функции.
С помощью макроса лучше писать только то, на что функция в принципе не способна.
>По ряду причин Google не устраивают текущие libc (glibc, musl) и компания на пути к разработке новой реализацииNon copyleft licenses are considered as permissive licenses, mostly because they allow creating derivative works under other license terms.
It is important to make a difference between Free software and Open source software. All Free Software is Open source Software, but not all Open source Software is considered as Free software.
>All Free Software is Open source Software, but not all Open source Software is considered as Free software.ЛПП, см https://en.wikipedia.org/wiki/Comparison_of_free_and_open-so.... Есть экзотические лицензии, одобренные FSF и не одобренные OSI. При этом подавляющее большинство лицензий либо одобрены тем и другим, либо не одобрены тем и другим
Просто FSF различает open и free software, а OSI — нет.
> одобренные FSF и не одобренные OSIНе ожидал. Впрочем так же, как и то, что документация к gcc, флагманскому проекту FSF, является non-free в Debian.
>Опыт разработчика musl говорит о том, что с ним связывались в основном юристы для уточнения вопросов лицензирования, но никогда не обращались для уточнения технических деталей перед внесением в свои ответвления бесполезных и нарушающих работу изменений.Ну чё пацаны, похоже Гуглятина готовит фундамент для развития своей будущей проприетарной оси Chrome.
2024 год. В гугловской libc поломана getopt (которая в POSIX, не которая длинные опции читает).
В мэнпейджах и в POSIX, везде указывается что аргумент состоящий _полностью_ из строки "--" прерывает дальнейшее чтение опций. Так же аргументы опций могут следовать как в следующем аргументе командной строки, так и в одном и том же аргументе сразу после символа опции. Никаких ограничений на то какой символ модно использовать для опции нету.
Это позволяет реализовать длинные опции через символ '-', например "--help", просто добавив в optstring "-:". Поскольку getopt сначала проверяет равен ли аргумент командной строки строке "--" и только потом парсит его кау опцию если первый символ '-', мы может убить двух зайцев одним камнем и иметь сразу и прерыватель "--", и опцию '-', если будем скармливать ей её аргумент сразу после префикса "--".Гугловский getopt на адроиде выдаёт "Invalid option '-'". Почему? Потому что всё то, что перечислено в конце статьи.