После недели тестирования финальных сборок официально состоялся (https://sourceware.org/ml/libc-alpha/2015-08/msg00609.html) релиз системной библиотеки GNU C Library (http://ftp.gnu.org/gnu/glibc/) (glibc) 2.22 (http://sourceware.org/glibc/wiki/Release/2.22), которая полностью следует требованиям стандартов ISO C11 и POSIX.1-2008. В подготовке нового выпуска использованы патчи от 64 разработчиков.
Из добавленных в Glibc 2.22 улучшений (http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=NEWS;h... можно отметить:
- В состав включена библиотека векторных математических функций libmvec (https://sourceware.org/glibc/wiki/libmvec), позволяющая задействовать в приложениях векторизированные реализации типовых математических функций, в которых используются SIMD (https://ru.wikipedia.org/wiki/SIMD)-расширения. Для архитектуры x86_64 в библиотеке представлены следующие функции: cos, cosf, sin, sinf, sincos, sincosf, log, logf, exp, expf, pow и powf, оптимизированные при помощи инструкций SSE и AVX.Для использования векторизированных функций при обращении к GCC следует указать флаги "-fopenmp -ffast-math" (поддерживаются выпуски GCC, начиная с 4.9.0 в режимах оптимизации, начиная с "-O1"). Связывание исполняемого файла с libmvec.so производится автоматически при указании "-lm" (нет необходимости явно указывать "-lmvec"). При желании сборку libmvec в составе Glibc можно отключить при помощи опции "--disable-mathvec"
- Новая реализация функции fmemopen, отличающаяся более строгим следованием рекомендациям POSIX. В частности, в новой реализации fmemopen решены с давних пор остававшиеся неисправленными проблемы совместимости с POSIX (6544 (https://sourceware.org/bugzilla/show_bug.cgi?id=6544), 11216 (https://sourceware.org/bugzilla/show_bug.cgi?id=11216), 12836 (https://sourceware.org/bugzilla/show_bug.cgi?id=12836), 13151 (https://sourceware.org/bugzilla/show_bug.cgi?id=13151), 13152 (https://sourceware.org/bugzilla/show_bug.cgi?id=13152), 14292 (https://sourceware.org/bugzilla/show_bug.cgi?id=14292)). Код старой реализации fmemopen также оставлен в составе Glibc и продолжит использоваться в собранных ранее программах;
- Компоненты Glibc портированы для работы в браузерных окружениях Native Client на системах с архитектурой ARMv7-A ("--host=arm-nacl")
- Код разбора файлов с правилами перевода времени в часовых поясах переработан с целью повышения надёжности обработки некорректных данных, что увеличило стойкость к попыткам атак через подстановку модифицированных файлов часовых поясов, которые ранее могли вызвать переполнение буфера при некорректном заполнении полей tzh_ttisstdcnt и tzh_ttisgmtcnt или при обработке файлов очень большого размера. Также добавлена защита от манипуляций значениями переменной окружения TZ (установка слишком длинной строки приводила к переполнению стека и краху);
- В реализацию TLS (Thread-local storage) добавлены оптимизации, специфичные для архитектур
powerpc и powerpc64. Кроме того, по аналогии с кодом для x86 и x86-64, добавлены блоки описания для LD и GD. Для использования оптимизаций требуется установка binutils 2.24+;- Таблицы ctype и кодировки символов приведены в соответствие со спецификацией Unicode 7.0.0. Использованы новые скрипты генерации локали, которые позволили решить возникшие при переходе на Unicode 7.0.0 проблемы с локалью, такие как несрабатывание (https://sourceware.org/ml/libc-locales/2015-q1/msg00036.html) проверки islower для некоторых символов в нижнем регистре;
- Налажена работа sigaction ABI на 32-разрядных системах SPARC (в gibc 2.19 и 2.20 данный ABI был поломан);
- Для архитектуры s390 реализована возможность запроса информации из кэша через sysconf() с опцией _SC_LEVEL1_ICACHE_SIZE;- Заголовочный файл "regexp.h" помечен как устаревший (исключен из стандарта в 2001 году) и будет удалён в одном из ближайших выпусков. При обращении к "regexp.h" теперь выводится специальное предупреждение. Разработчикам следует перейти к использованию "regex.h" вместо "regex
p
.h";
- Устранены уязвимости:
- CVE-2015-1781 - переполнение буфера в gethostbyname_r и других функциях, отправляющих запросы к DNS, потенциально позволяющее организовать выполнение кода при возврате специально оформленных ответов от подконтрольного атакующему DNS-сервера. Проблема проявляется если функции NSS вызваны с использованием невыравненного буфера.- CVE-2014-8121 - возможность инициирования отказа в обслуживании приложения, из-за сохранения состояния NSS-вызовами getXXent и getXXbyYY в одной БД.
- Закрыт 101 отчёт об ошибках.
URL: https://sourceware.org/ml/libc-alpha/2015-08/msg00609.html
Новость: http://www.opennet.me/opennews/art.shtml?num=42797
> которая полностью следует требованиям стандартов ISO C11Неужели и потоки сделали?
Надо будет посмотреть.
Хрен там. threads.h в сорцах не ищется
полностью следует требованиям != реализовала все требованияМожете посмотреть новость к предыдущему релизу, там та же фраза.
Когда реализуют потоки, это точно будет указано в "основных улучшениях".
придет ии от ibm и закроет все уезвимости во всех либах за неделю
Но чтобы в IBM смогли написать ИИ, сначала следует вычистить все баги и уязвимости из glibc.
> Но чтобы в IBM смогли написать ИИ, сначала следует вычистить все баги
> и уязвимости из glibc.а может вычищены? это же ibm
не ради флуда, но нынешнии архитектуры вчерашний день, но они были дюже хороши, воистину.
> нынешнии архитектуры вчерашний деньИ завтрашнее завтра будет как вчерашнее вчера ... (с)
> И завтрашнее завтра будет как вчерашнее вчера ... (с)только совершеннее
> И завтрашнее завтра будет как вчерашнее вчера ... (с)А завтрашнее вчера будет очень здорово смахивать на вчерашнее завтра! [другой Аноним, где-то когда-то в тырьнете]
А вообще - я конечно не железячник, но вот всякие x86_(64) иначе чем кучей костылей и легаси (обратная совместимость с замшелым х86) не воспринимаются.
> А вообще - я конечно не железячник, ноНо это напоминает, что ты увидел и сюда скопипастил просто знакомые слова.
> Но это напоминает, что ты увидел и сюда скопипастил просто знакомые слова.А, ну да, real mode, 16 бит и сегменты, эмуляция этого самого real modа в protected - типа virtual 8086, в принципе и сам IA-32, как и куча всяких rep(nz) scas(w/l/b), stos(b/w) lods(/b/w/d) которые нормальными компиляторами давно игнорируются (http://gcc.gnu.org/ml/gcc/2008-07/msg00599.html), но которые все еще поддерживаются, это конечно не легаси -- ведь вдруг понадобиться запустить замшелую проприетарь из девяностых!1
Не вижу проблем, как вам это жить мешает? Денег меньше стало? С работы выгнали?Если новый лексус въедет в жопу 24 Волге, и у лексуса разворотит весь передок,
а на Волге не будет и царапины, то владелец Лексуса должен изойти на гной и сопли? :)Смысле басни: Есть в говно, то все сразу?!
Сегодня в завтрашний день не все могут смотреть. Вернее смотреть могут не только лишь все. Мало кто может это сделать.
Грешно смеяться над боксером, на ринг попробуй выйти с ним.
> Сегодня в завтрашний день не все могут смотреть. Вернее смотреть могут не
> только лишь все. Мало кто может это сделать.не знаю точных данных но всегда постя подобное расчитываю на тех кому думать о подобном не досуг например, а так хотьчто то да продвинется при всем уважении к опеннет аудитории само собой но кто его знает. а насчет того, что сделать или не сделать, а не сможем не сделать, вточности, что в той песне про счастье, которое не может не есть,вопрос только времени и само собой не сегодня ты прав, тоже так думаю.
Шизофазия.
> в библиотеке представлены следующие функции: cos, sin,
> ...оптимизированные при помощи инструкций SSE и AVX.Типа модно, молодежно? asm volatile ("fsin") уже не катит.
> Типа модно, молодежно? asm volatile ("fsin") уже не катит.Ну, к сожалению, не все такие профи и в курсе всяких мелких нюансов, типа
https://software.intel.com/blogs/2014/10/09/fsin-documentati...> As an example, let us consider a double precision argument x that is as close as possible to the
> mathematical value of ∏, i.e. x is the best 53-bit approximation of ∏. In FSIN, this argument is reduced by
> subtracting the 66-bit approximation PI of ∏ from it, which means that the reduced argument has only 13
> bits that are correct. The reduced argument is also very small, and sin(x-PI) ≈ FSIN(x-PI) ≈ x-PI has also only
> around 13 bits that are correct. This means that the ulp error can be of the order of 2^40 ≈ 10^12 ulps in this case.
> всяких мелких нюансов, типаА, ну это у интеля постоянно. Как-то было дело корень из 2PI == 0
> А, ну это у интеля постоянно. Как-то было дело корень из 2PI
> == 0Смею предположить, что далеко не всем это нужно - ни нюансики Ынтыльской реализации изучать, ни с урезанной точностью жонглировать.
Тайна модно-молодежности такого естественного желания все еще не раскрыта!
Не катит. FPU использоваться не должен.
> Не катит. FPU использоваться не должен.Вылазь из погреба и man "ABI x86_64"
Я-то давно вылез. Ты что сказать-то хотел?Использовать FPU сегодня - моветон.
новость опаздала на 11 дней
> новость опаздала на 11 днейОбед тогда, когда ты съел котлету, а не когда родилась корова. ©
> новость опаздала на 11 днейС учётом смещения часового пояса новость вышла в день релиза. 11 дней назад был тестовый выпуск, которые бегущие впереди паравоза посчитали за релиз.
http://www.gnu.org/software/libc/
2015-08-14: glibc 2.22 released.https://sourceware.org/ml/libc-alpha/2015-08/msg00609.html
The GNU C Library version 2.22 is now available
Date: Fri, 14 Aug 2015 16:14:02 -0400
> 11 дней назад был тестовый выпускХитро они придумали! Не Beta, не Release Candidate, а релиз! Но тестовый. Все радостно побежали обновляться, и если баги есть, о них массово же и сообщат. А не как с VuirtualBox-ом, о RC которого никто не слышал, а потом все ругались на релиз