LINUX.ORG.RU

Релиз Glibc 2.22

 ,


2

1

Состоялся релиз Glibc 2.22.

Основные изменения:

  • Таблица символов и ctype обновлена до спецификации Unicode 7.0.0. За новый скрипт генератора скажем спасибо Pravin Satpute и Mike Fabian из Red Hat! Это изменение должно быть заметно пользователю, например исправление бага 17998.
  • Добавлена библиотека libmvec для работы с векторами. В ней есть следующие векторные x86_64-операции: cos, cosf, sin, sinf, sincos, sincosf, log, logf, exp, expf, pow, powf. Библиотека зависит от GCC ≥4.9, параметров сборки -fopenmp и -ffast-math, и оптимизации ≥-O1. Shared-библиотека libmvec.so линкуется с параметром -lm (нет необходимости указывать -lmvec).
  • Новая реализация fmemopen для совместимости с POSIX. Это нововведение исправляет множество многолетних багов: 6544, 11216, 12836, 13151, 13152 и 14292. Старая реализация не удалена для совместимости со старыми бинарными файлами.
  • Header-файл <regexp.h> объявлен устаревшим, и будет удалён в следующем релизе. При использовании теперь выдаётся Warning. Разработчикам программ необходимо обновить код приложений.

Малопопулярные архитектуры CPU

  • Для архитектуры s390 добавлен опрос информации о кэше с помощью функции sysconf(). Например с аргументом _SC_LEVEL1_ICACHE_SIZE.
  • Оптимизации TLS для архитектур powerpc и powerpc64. Это оптимизации дескрипторов LD и GD, ранее существовавшие для x86 и x86_64. Для задействования необходимы binutils ≥2.24
  • Для архитектуры SPARC 32-bit исправлен ABI sigaction, который был непреднамеренно сломан в Glibc 2.20. Теперь ABI работает как в Glibc 2.19. Бинарники, собранные с Glibc 2.20-2.21, необходимо пересобрать.
  • Native Client портирован на ARMv7-A (--host=arm-nacl). Скажем спасибо Roland McGrath (Google)!

Исправления ошибок

  • Исправлено переполнение буфера через gethostbyname_r, а также связанных с ней функций, осуществляющих запросы DNS. (CVE-2015-1781)
  • Исправлена ошибка, при которой NSS сообщает внутреннее состояние getXXent и getXXbyYY в одну и ту же базу данных, что может привести к состоянию denial-of-service в некоторых приложениях (CVE-2014-8121)
  • Улучшения "защиты от дурака" в парсер файлов timezone (на случай использования файлов, созданных кустарно). А именно исправлено возможное переполнение буфера при использовании переменных tzh_ttisstdcnt и tzh_ttisgmtcnt, а также переполнение стека при использовании огромного Data-файла Zone.
  • Исправлено множество других ошибок.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: CYB3R (всего исправлений: 2)

Header-файл <regexp.h> объявлен устаревшим, и будет удалён в следующем релизе.

И чо юзать?

anonymous
()
Ответ на: комментарий от Pinkbyte

Что там за реализация cat, если не вернула в stderr

cat: /sys/bus/pci/devices: Is a directory
?

Подсказка, если еще не понял: PCI-девайсов там НЕТ

Не надо такого тона. В современном промышленном невстраиваемом оборудовании это невозможно.

anonymous
()

Странно. execveat() не запилили, а в release notes упоминается fexecve(), который в glibc с дремучей версии 2.3

anonymous
()
Ответ на: комментарий от anonymous

я уже пояснил что ошибся - в /sys шина PCI присутствует и девайсы на ней есть

Pinkbyte ★★★★★
()
Ответ на: комментарий от anonymous

Раньше была проприетарная GX Bus, да.

anonymous
()
Ответ на: комментарий от Napilnik

виноват в никакой поддержке utf-32.

Уже появились символы с кодами >32 бит? Если нет, то не представляю, как можно «поддерживать» utf-32: это же юникод в чистом виде.

KennyMinigun ★★★★★
()
Ответ на: комментарий от KennyMinigun

Уже появились символы с кодами >32 бит?

Кажется ты не понимаешь о чём говоришь. В утф-8, во многобайтовых символах, большинство байтов не использует 4 бита - такая вот экономия битов из-за которой максимальное число байтов для кодирования буквы может достигать шести, а в будущем и семи. А в утф-32 все буквы кодируются строго четырьмя байтами и кругом порядок и предсказуемость.

Если нет, то не представляю, как можно «поддерживать» utf-32: это же юникод в чистом виде.

Создаёшь файл, открываешь его линуксовыми текстовыми редакторами, пытаешься найти в настройках кодировку utf-32 и жестоко обламываешься.

Napilnik ★★★★★
()
Ответ на: комментарий от Napilnik

Кажется ты не понимаешь о чём говоришь.

Кажется ты не понял, что я сказал.

А в утф-32 все буквы кодируются строго четырьмя байтами и кругом порядок и предсказуемость.

Вот это же я и написал, только другими словами. За исключением слова "кодируются": символы не кодируются, а записываются ровно так, как определены их code point'ы в юникоде (единственное, что может отличатся — порядок байтов).

Создаёшь файл, открываешь его линуксовыми текстовыми редакторами, пытаешься найти в настройках кодировку utf-32 и жестоко обламываешься.

Да, почему-то пункт в меню отсутствует. Тем не менее, заранее созданные файлы вполне себе открываются, редактируются и сохраняются: http://i.imgur.com/npSOMsq.png

KennyMinigun ★★★★★
()
Ответ на: комментарий от KennyMinigun

Да, почему-то пункт в меню отсутствует.

UTF-8 здоровая конкуренция не нужна...

Тем не менее, заранее созданные файлы вполне себе открываются, редактируются и сохраняются: http://i.imgur.com/npSOMsq.png

а записываются ровно так, как определены их code point'ы в юникоде (единственное, что может отличатся — порядок байтов).

Ну и как их создавать если порядок байтов различается.

Napilnik ★★★★★
()
Ответ на: комментарий от Napilnik

UTF-8 здоровая конкуренция не нужна...

Какая конкуренция? UTF-8 деньни чтоли зарабатывает? Если кому-то нужна скорость UTF-32, то он будет использовать UTF-32 (например декодировав в uint32_t)

Ну и как их создавать если порядок байтов различается.

  1. Скачать в UTF-32 (если тебе нужно редактировать такие файлы)
  2. Использовать редактор, который умеет
  3. ... тысячи их ...
  4. Оформить баг-репорт (фич-реквест) в ${your_favorite_editor}
  5. iconf -f ... -t utf-32 ${existing_file}
  6. Ну, или на худой конец:
    printf '\x00\x00\xFE\xFF' >file.txt # UTF-32BE
    printf '\xFF\xFE\x00\x00' >file.txt # UTF-32LE
    
KennyMinigun ★★★★★
()
Последнее исправление: KennyMinigun (всего исправлений: 1)
Ответ на: комментарий от KennyMinigun

Какая конкуренция?

Удобства англоязычных.

UTF-8 деньни чтоли зарабатывает?

А ты попробуй внедри в дистр то, что неудобно англоязычным:)

Скачать в UTF-32 (если тебе нужно редактировать такие файлы)

Чтобы скачивать, сначала нужно такое туда положить.

Использовать редактор, который умеет

Да что-то нет таких в дистре.

Оформить баг-репорт (фич-реквест) в ${your_favorite_editor}

А кому кроме нескольких фанатов нужен свободный код на плюсах? Это же мёртвый груз.

Napilnik ★★★★★
()
Ответ на: комментарий от Napilnik

А в утф-32 все буквы кодируются строго четырьмя байтами и кругом порядок и предсказуемость.

Так же как и в utf-8 старший бит зарезервирован, и если число «символов» привысит 2^31 то мы получим многодвухсловные символы. Но, надеюсь, двух миллиардов символов землянам хватит.

German_1984 ★★
()
Ответ на: комментарий от German_1984

двух миллиардов символов

Когда я последний раз просматривал стандарт, там из-за особенностей формата символов было то ли 16 млн., то ли вообще чуть больше 1 млн. О миллиардах речи даже не идёт.

anonymous
()

позор!

Unicode 7.0.0

уже 8й на дворе а вы только 7,0 осилили

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.