Многие пользователи Mac могли заметить, что X11 больше не поставляется вместе с OS X, и он также не доступен для отдельной установки через Developer Tools. Для того, чтобы работать с X11 на OS X Mountain Lion (и выше), вы можете загрузить и установить бесплатную программу XQuartz, которая включает в себя все библиотеки и приложения, необходимые для запуска и полноценной работы оконной системы X11 в OS X.
XQuartz является проектом с открытым исходным кодом, и на самом деле был создан Apple, которая и сейчас продолжает вносить свой вклад в проект, чтобы убедиться, что он имеет полную совместимость с каждым новым выпуском и обновлением OS X. Хотя большая часть разработок находиться в руках X.org и XFree86.
Получить XQuartz и запустить X11 в Mac OS X очень легко. Все, что вам нужно сделать:
Бесплатно скачать XQuartz от MacOSForge.org, размер программы 70Мб, для установки
Запустить установщик PKG и пройти стандартную процедуру установки
XQuartz будет установлена в качестве приложения в папку «Утилиты», также появиться иконка программы в Launchpad
После запуска XQuartz, вы получаете несколько основных приложений X11, в том числе: Xterm для доступа к командной строке за пределами стандартного приложения Terminal, Xman — окошко со справочной информацией и xlogo — просто рисует на экране классический логотип X. Сторонние приложения, которые нуждаются в X11, должны быть установлены отдельно, но запускаться они будут через XQuartz.
Рядовому пользователю Mac, вероятно, не будет особого смысла в установке X11, многие популярные приложения, такие как Gimp уже адаптированы для OS X, но это может быть интересно для изучения приложений из мира UNIX.
Я лично, использую Х11 для запуска программы Inkscape, которая отлично подходит для работы с векторной графикой. Она поддерживает огромное количество форматов, к тому же, как и Gimp — бесплатная.
Источник
X11.app
The X Window System (X11)
Окно «О программе» X11
Тип
Apple Public Source License, Лицензия MIT
The X Window System (X11) — реализация X11 от Apple для Mac OS.
XQuartz (более известен как X11.app) для Mac OS X представляет собой полноценное программное средство системы X Window System, которое базируется на программном обеспечении с открытым исходным кодом и содержит полный набор стандартных программ сервера X11, клиентских библиотек и инструментов разработчиков, а также ряд служебных программ, таких как xterm. Поддерживает аппаратное ускорение 2D и OpenGL. Имеет интеграцию с интерфейсом Aqua. Первая бета-версия была доступна для Mac OS X 10.2, а вот для Mac OS X 10.3 уже была доступна для скачивания с официального сайта Apple как стандартный пакет.
Был переписан в Mac OS X 10.5 для использования более популярного X.Org Server (X11R7.2), вместо XFree86
О программе
Т.к. Mac OS X базируется на UNIX, то пользователь может работать со многими инструментами и средами UNIX. Имея X11 для Mac OS X, пользователь может использовать программы, базирующиеся на графическом интерфейсе пользователя системы X Window System.
Программы X11 работают по тому же принципу, что и программы Mac OS X. Например, при работе с ними можно пользоваться стандартными функциями Mac OS X, такими как сворачивание окна в Dock, копирование или вставка объектов между программами X11 и Mac OS X. Также возможно использование любой трехкнопочной USB-мыши для работы с X11 для Mac OS X.
Установить X11 можно при установке Mac OS X. Если X11 не установлена, необходимо вставить установочный диск Mac OS X Install и дважды нажать на пакете «Дополнительно».
X11 для Mac OS X позволяет без труда переносить программы X Window System на компьютер Macintosh. X11 SDK устанавливается как часть пакета Xcode Tools.
Местонахождение
X11 располагается в папке «Программы», точнее: /Applications/Utilities/X11.app. Вы можете открыть программы X Window System, находясь в программе «X11» или «Finder».
Хронология версий
Wikimedia Foundation . 2010 .
Полезное
Смотреть что такое «X11.app» в других словарях:
X11.app — Entwickler Apple Aktuelle Version X11.app 2.3.2.1 X.Org 7.3 (3. Januar 2009) Betriebssystem Mac OS X Lizenz Apple Public Source License MIT License … Deutsch Wikipedia
X11.app — Infobox Software name = X11 caption = developer = Apple Computer latest release version = X11 2.3.0 X.Org 7.3 latest release date = July 19, 2008 latest preview version = latest preview date = operating system = Mac OS X genre = X11 Window… … Wikipedia
X11 (disambiguation) — X11 may refer to : * X11 or X Window System , a system which implements the X display protocol * X11 (New York City bus) * X11.app, a Mac OS X application * a Samsung Sens laptop computer modelX 11 may refer to : * Convair X 11, the first testbed … Wikipedia
X11 color names — WhiteSmoke redirects here. For the computer virus connected with Norton AntiVirus, see WhiteSmoke (Virus). In computing, on the X Window System, X11 color names are represented in a simple text file, which maps certain strings to RGB color values … Wikipedia
X11 Xedit — Note: This page is about the X Window System xedit editor. For the VM/CMS visual editor, see XEDIT. xedit is a text editor for the X Window System. It uses the Athena (Xaw) widget set.Originally written during the days of the MIT X Consortium… … Wikipedia
Список цветов в X11 — В оконной системе X Window System определена цветовая схема, которая определяет соответствие имени цвета к его цветовым значения RGB. Цветовая схема X11 указана в текстовом файле, хранящем строки в виде имя цвета значение цвета в RGB.… … Википедия
X Window System — X11 redirects here. For other uses, see X11 (disambiguation). A historical example of graphical user interface and applications common to the MIT X Consortium s distribution running under the twm window manager: X Terminal, Xbiff, xload and a… … Wikipedia
Mac OS X — OSX redirects here. For other uses, see OSX (disambiguation). Mac OS X … Wikipedia
X Window System — Тип оконная система Разработчик X.Org Foundation Операционная с … Википедия
Mac OS X — Эту страницу предлагается переименовать в OS X. Пояснение причин и обсуждение на странице Википедия:К переименованию/11 мая 2012. Возможно, её текущее название не соответствует нормам современного русского языка и/или правилам… … Википедия
Источник
Ядро macOS, есть ли червячки в этом яблоке?
В самом начале этого года Apple выложили в открытый доступ исходный код системных компонентов macOS 11.0 – Big Sur, включая XNU – ядро операционной системы macOS. Пару лет назад исходный код ядра уже проверялся PVS-Studio в связи с выходом анализатора для macOS. Прошло достаточно много времени, и вышел новый релиз исходного кода ядра. Почему бы и не провести повторную проверку.
Что это за проект, Apple и open-source?
XNU – X is Not Unix – используется и разрабатывается Apple в качестве ядра операционных систем OS X. Исходные коды этого ядра 20 лет назад были опубликованы под лицензией APSL (Apple Public Source License) вместе с OC Darwin. Раньше Darwin можно было даже установить в качестве полноценной операционной системы, однако теперь это стало невозможно. Причиной публикации исходного кода является тот факт, что он во многом основан на других open-source проектах.
Исходные коды компонентов можно найти тут. Для проверки я использовала зеркало проекта на GitHub.
Предыдущая проверка
Как я уже упомянула, этот проект ранее проверялся нами с помощью PVS-Studio. С предыдущими результатами можно познакомиться в статье: «Релиз PVS-Studio для macOS: 64 weaknesses в Apple XNU Kernel». После публикации мой коллега Святослав также отправил статью разработчикам на почту, но ответа не получил. Так что я предполагаю, что наша проверка никак не связана с исправлениями, которые мы дальше рассмотрим. Разработчикам пришлось искать их другим путём. А могли бы просто взять и запустить PVS-Studio :). Сейчас, после публикации статей, мы в основном пишем об этом в GitHub репозиторий проекта.
Мне стало интересно, были ли исправлены ошибки, описанные в предыдущей статье, или всё так и осталось. Большинство из найденных ошибок действительно были исправлены. Это показывает, что отобранные предупреждения анализатора оказались верными. Хотя для написания статьи с отчётом работал человек, не участвующий в разработке XNU, то есть близко не знакомый с этим исходным кодом.
Я приведу здесь несколько примеров исправлений. Но, чтобы не раздувать объём статьи, не буду полностью приводить объяснение ошибок. Если из исправления будет неясно, в чём была проблема, то вы всегда можете обратиться к первой статье по проверке этого проекта. Я не буду разбирать все исправленные фрагменты, большинство из фрагментов всё-таки было поправлено. А фрагментов в предыдущей статье было ни много ни мало 64!
Перейдём к рассмотрению исправлений примеров из прошлой статьи.
Фрагмент N1, в котором член класса сравнивался сам с собой:
Был исправлен следующим образом:
Где макрос, из которого получена переменная orglen, выглядит следующим образом:
Выходит, что анализатор оказался прав: сравнение было некорректным и должно было проводиться с переменной orglen, которая даже присутствовала в коде до исправления.
Еще один пример исправления, который я хочу привести здесь, – фрагмент N5, где знак равно всё-таки был исправлен на проверку на равенство.
Накосячить в условии assertf – одно, но ещё и перезаписать переменную для отладочной версии – такое точно стоит поправить.
Фрагменты 6 и 7 были исправлены одинаково. Оказалось, что во вложенной проверке перепутали значение перечислителя для сравнения. Вместо PBUF_TYPE_MBUF во внутренней проверке должен быть элемент PBUF_TYPE_MEMORY в обоих случаях.
В случае фрагментов N8, 9, 10 исправление было таким:
На это исправление я обратила внимание, так как серьёзная часть коммита в целом (обновление репозитория до xnu-4903.270.47 от 11 января) содержит помимо прочего много правок код-стайла. Это может указывать на то, что для данной версии кодовая база была подчищена с помощью разных инструментов качества кода. Что сделает эту проверку PVS-Studio более интересной. Ведь видно, что качество кодовой базы уже было улучшено другими инструментами.
Что касается фрагментов 11, 12, 13, 14 – был исправлен только фрагмент 11:
Остальные остались прежними. Похоже, кто-то невнимательно прочитал наш отчёт 😉 (или отчёт анализатора, использованный для улучшения качества кода в этом коммите). Приведу здесь код, на который было выдано одно из предупреждений, чтобы не было сомнений в аналогичности ошибки:
Предупреждение PVS-Studio: V612 An unconditional ‘return’ within a loop. kern_credential.c 951
Я привела код почти целиком, чтобы можно было сформировать общее представление о том, что происходит в этой функции. В случае отмеченного цикла при выполнении условия входа в него будет совершён один проход по телу цикла, завершающийся возвращением error. Видимо, подразумевалось, что если выполняется условие (workp = TAILQ_FIRST(. )) == NULL, то нужно найти причину ошибки и завершить функцию возвращением информации об ошибке. Однако по какой-то причине вместо if был написан while, как и во фрагменте из предыдущей статьи. Строчка error = msleep0(. ) выглядит в коде таким образом:
Здесь последним аргументом передаётся указатель на функцию kauth_resolver_getwork_continue. В теле этой функции есть условие, аналогичное условию цикла, на который нам указал анализатор. Но в нём уже корректно используется if, а не while.
В принципе этот код работает немного сложнее, чем я описала. В нём присутствует рекурсия (в методе kauth_resolver_getwork_continue), и, как я поняла, он нацелен на нахождение потоков, которые можно перезагрузить. Но я не стала вдаваться в подробности, так как while всё равно лишний. Возможно, он остался здесь с того времени, когда исходный код выполнял ту же задачу, но без использования рекурсии.
Это примеры из начала статьи. Проскочим в середину и возьмём фрагмент N40. В нём одному и тому же элементу дважды присваивается одно значение:
Предупреждение PVS-Studio: V519 CWE-563 The ‘wrap.Seal_Alg[0]’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 2070, 2071. gss_krb5_mech.c 2071
Эта ошибка, конечно же, тоже была поправлена:
Ну и ближе к концу статьи, фрагмент 62 был исправлен так, как и было предложено в предыдущей статье. Причём это было единственной правкой в том файле.
Фрагменты 63 и 64 также были исправлены, но там код был изменён капитально. Поэтому понять, какое исправление было именно для рассмотренного предупреждения, сложно.
Новые находки
После этого долгого вступления перейду к ошибкам, которые привлекли моё внимание при последней проверке исходного кода XNU статическим анализатором PVS-Studio. Скажу честно, мне тяжело далась работа с отчётом, так как проект имеет сложный код и у меня нет опыта работы с подобной кодовой базой. Но предупреждения PVS-Studio достаточно подробны и имеют ссылку на документацию с примерами правильного и неправильного кода и описанием возможной проблемы, что очень меня выручило.
К этой проверке cloc насчитал в проекте 1346 *.c файлов, 1822 С/C++ хэдера и 225 *.cpp файлов.
Ну и перейдём к разбору интересных находок.
Фрагмент N1
Предупреждение PVS-Studio: V1064 The ‘gPEClockFrequencyInfo.bus_clock_rate_hz’ operand of integer division is less than the ‘gPEClockFrequencyInfo.dec_clock_rate_hz’ one. The result will always be zero. pe_identify_machine.c 72
Все используемые здесь поля имеют целочисленный тип:
Через промежуточные присвоения полю gPEClockFrequencyInfo.bus_clock_rate_hz, являющемуся делимым, присваивается значение 100000000, а полю-делителю gPEClockFrequencyInfo.dec_clock_rate_hz присваивается значение 1000000000. Делитель в этом случае в десять раз больше делимого. Так как все поля здесь являются целочисленными, поле gPEClockFrequencyInfo.bus_to_dec_rate_den окажется равным 0.
Судя по наименованию результирующего поля bus_to_dec_rate_den, делитель и делимое были перепутаны местами. Я допускаю возможность, что код был написан с расчётом на то, что исходные значения изменятся и результат уже не будет равен 0. Но этот код всё равно кажется мне очень подозрительным.
Насколько я поняла, этот метод ищет название некоей функции. В алгоритме используется переменная best, возможно, это положение наилучшего кандидата на результат. Однако изначально эта переменная только объявляется без инициализации. Следующее же использование сверяет значение некоего элемента с переменной best, которая будет неинициализированной на тот момент. Еще страннее, что она инициализируется только внутри условия, в котором используется её же значение.
Неинициализированные переменные могут приводить к непредсказуемым результатам. И, хотя эта ошибка может показаться достаточно банальной, она всё ещё часто встречается при проверках разных проектов с помощью PVS-Studio. Например, совсем недавно мой коллега Андрей описывал интересный случай такой ошибки.
Фрагмент N3
Предупреждение PVS-Studio: V560 A part of conditional expression is always false: index nb_dirtyoff >= bp->nb_dirtyend’ is always false. nfs_bio.c 3858 V560 A part of conditional expression is always true: (bp->nb_dirtyoff nb_dirtyend > 0) && (bp->nb_dirtyoff nb_dirtyend > end. А также осуществляется присвоение bp->nb_dirtyend = end.
Почему же третья проверка bp->nb_dirtyoff >= bp->nb_dirtyend будет всегда false?
Всё просто. Из условий выходит, что nb_dirtyoff меньше, чем end, а nb_dirtyend равно end. В итоге nb_dirtyend точно больше, чем nb_dirtyoff. Присвоение bp->nb_dirtyoff = bp->nb_dirtyend = 0 никогда не будет выполнено.
В итоге вот такой участок кода:
Можно упростить хотя бы до такого:
Но только если в настоящий момент этот алгоритм работает корректно.
Второе предупреждение указывает на четвёртый if, вложенный в первый.
Здесь анализатор выдаёт предупреждение на основании того, что присвоение нуля никогда не будет выполнено. В итоге во внешнем условии уже была проверка bp->nb_dirtyoff t_rawq.c_cc + tp->t_canq.c_cc’ statement is a part of the condition. Perhaps, this statement should have been compared with something else. tty.c 568
Аналогичный случай. Тут повыше в коде снова есть проверка, которая не просто использует сумму, а сравнивает результат с другой переменной:
В упрощённом коде условие, на которое указал анализатор, выглядит заметно. Но в оригинале оно было вложено в несколько if. Так что при код-ревью такое можно и пропустить, а анализатор не пропустит 😉
Фрагмент N7
Предупреждение PVS-Studio: V1028 Possible overflow. Consider casting operands of the ‘amount + used’ operator to the ‘size_t’ type, not the result. kpi_mbuf.c
Снова ошибка в условии, но уже совсем другого рода. Вместо приведения к size_t операндов сложения, чтобы результат точно поместился в числовой тип, к size_t приводится результат сложения. Если в итоге сложения возникнет переполнение, то с результатом mbuf_maxlen(m) будет сравниваться бессмысленное значение, приведённое к size_t. Раз программист всё-таки хотел защититься от переполнения, то стоит его сделать правильно:
Таких срабатываний было несколько, стоит обратить на этот момент внимание.
V1028 Possible overflow. Consider casting operands, not the result. vm_compressor_pager.c 1165
V1028 Possible overflow. Consider casting operands, not the result. vm_compressor_pager.c 1131
V1028 Possible overflow. Consider casting operands, not the result. audit_worker.c 241
V1028 Possible overflow. Consider casting operands of the ‘((u_int32_t) slp * hz) + 999999’ operator to the ‘long’ type, not the result. tty.c 2199
Фрагмент N8
Предупреждение PVS-Studio: V1019 Compound assignment expression ‘n -= i’ is used inside condition. kern_descrip.c_99 3916
Этот код, на мой взгляд, является крайне сложночитаемым. Возможно, условие, на которое указал анализатор, стоит переписать в более простом виде:
Этот код выглядит менее эффективным, но точно является более понятным. Для быстрой проверки равнозначности эффективности этого кода можно зайти на Godbolt (Compiler Explorer), где, кстати, можно тестировать работу диагностик PVS-Studio. Анализатор легко найти среди инструментов этого сервиса.
Если не включать оптимизации, то ассемблерный код получится на пару строк больше. А вот с оптимизациями разницы уже нет никакой. Так что писать тут хитрый код нет смысла, компилятор всё сам сделает, как надо.
Но, если обратить внимание на тело этого if, новое значение n в нём не используется. То есть вполне возможно, что никакое присвоение здесь и не нужно. Тогда можно обойтись таким кодом:
И, более того, исходный код может приводить к ошибке при дальнейшем использовании переменной n. Если выражение (n -= i) tbr_last’ should be checked here. classq_subr.c 685
В проекте эта диагностика работала не лучшим образом, так как в коде постоянно над телом условия или цикла инициализировались сторонние переменные с именами, похожими на используемые в условии. Поэтому на этот раз диагностика выдала несколько явно ложных предупреждений. Но рассматриваемое нами срабатывание всё же показалось мне подозрительным, так как проверяемое поле tbr_rate не использовалось в теле условия и было инициализировано на 35 строк выше этой проверки. А вот поле tbr_last, инициализированное прямо перед этой проверкой, больше нигде не используется. Можно предположить, что проверить нужно было его вместо tbr_rate.
Фрагмент N11
Предупреждение PVS-Studio: V571 Recurring check. The ‘if (ar->k_ar.ar_arg_mac_string == NULL)’ condition was already verified in line 245. audit_mac.c 246
На этот код анализатор выдал сразу два предупреждения.
Сначала взгляд может зацепиться за то, что проверка в самом первом if и во втором совпадает. Но тут всё правильно: внутри тела первой проверки аллоцируется память, а для второй проверки есть пояснение:
Судя по этому комментарию, во второй проверке не должно быть никакой внутренней проверки. Нужно просто выйти из метода. Так что, скорее всего, внутренняя проверка была продублирована случайно и не имеет никакого смысла.
Хотя возможен и тот вариант, что во внутренней проверке нужно было проверить какое-то другое поле. Но сюда закралась ошибка копипасты, и разработчик забыл поправить имя поля.
Фрагмент N12
Предупреждение PVS-Studio: V567 Undefined behavior. The ‘ucsp’ variable is modified while being used twice between sequence points. vfs_utfconv.c 298
Макросы – очень коварная штука. Возможно, вы даже уже встречались с нашей статьей «Вред макросов для C++ кода». Я обычно при написании статей избегаю срабатываний на макросы. С ними всегда всё оказывается сложно без знакомства с кодовой базой проекта.
Но в случае этой ошибки всё оказалось чуть проще. Хотя, чтобы дойти до причины и развернуть цепочку макросов, пришлось прыгнуть в ту ещё кроличью нору. Собственно, цепочка эта начинается с выражения OSSwapInt16(*ucsp++).
Потом я поняла, что есть способ попроще, и просто обратилась к .i файлу, который остался после проверки проекта. По нему строка с этим макросом развернулась следующим образом:
Больше всего здесь нас интересует вот этот участок выражения:
Никакой из операторов в выражении не является точкой следования. Так как точно неизвестно, какой из аргументов оператора | будет вычисляться первым, значение *uscp оказывается неопределённым.
Для диагностики V567 PVS-Studio предоставляет крайне подробную документацию. Если вам интересно, почему такой код может приводить к неопределённому поведению, документация может стать хорошим началом изучения этой проблемы.
Однако это ещё не всё! Есть очень интересный и важный момент. Готова поспорить, что человек, писавший этот код, планировал увеличить значение *ucsp только один раз. Но, на самом деле, значение увеличится дважды. Это не видно и непонятно. Макросы очень и очень опасны из-за вот таких случаев. Во многих ситуациях лучше написать обыкновенную функцию. Скорее всего, компилятор автоматически выполнит подстановку и никакого ухудшения производительности не произойдёт.
Фрагмент N13
Предупреждение PVS-Studio: V567 Undefined behavior. The ‘pf_status.stateid’ variable is modified while being used twice between sequence points. pf.c 1440
И снова коварные макросы смешали все карты для инкремента. Рассмотрим строку с вызовом htobe64, которая оказалась подозрительной для анализатора после препроцессинга:
Проблема собственно та же, что и в предыдущем примере. Во внутренней цепочке с операндами | и & нет точек следования. Поэтому неизвестно, какое значение примет pf_status.stateid на моменте выполнения каждой операции. Результат также неопределён.
И, опять-таки, переменная увеличивается несколько раз подряд, что является неприятным сюрпризом от макроса :).
Вот остальные срабатывания этой диагностики на этом проекте:
V567 Undefined behavior. The ‘ip_id’ variable is modified while being used twice between sequence points. ip_id.c 186
V567 Undefined behavior. The ‘lp’ variable is modified while being used twice between sequence points. nfs_boot.c 505
V567 Undefined behavior. The ‘lp’ variable is modified while being used twice between sequence points. nfs_boot.c 497
V567 Undefined behavior. The ‘ip_id’ variable is modified while being used twice between sequence points. kdp_udp.c 588
V567 Undefined behavior. The ‘ip_id’ variable is modified while being used twice between sequence points. kdp_udp.c 665
V567 Undefined behavior. The ‘ip_id’ variable is modified while being used twice between sequence points. kdp_udp.c 1543
Фрагмент N14
Предупреждение PVS-Studio: V519 The ‘uh->uh_sport’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 4866, 4870. ipsec.c 4870
В этом фрагменте возникла подозрительная ситуация: полю uh_sport в зависимости от определённого условия присваиваются разные значения. Однако сразу после if-else этому же полю снова присваивается значение, такое же как в ветке else. В итоге этот if-else блок теряет смысл, так как значение поля всё равно будет перезаписано.
Многие пользователи Mac могли заметить, что X11 больше не поставляется вместе с OS X, и он также не доступен для отдельной установки через Developer Tools. Для того, чтобы работать с X11 на OS X Mountain Lion (и выше), вы можете загрузить и установить бесплатную программу XQuartz, которая включает в себя все библиотеки и приложения, необходимые для запуска и полноценной работы оконной системы X11 в OS X.
