Опубликованы корректирующие выпуски X.Org Server 21.1.14 и DDX-компонента (Device-Dependent X) xwayland 24.1.4, обеспечивающего запуск X.Org Server для организации выполнения X11-приложений в окружениях на базе Wayland. В новых версиях устранена уязвимость (CVE-2024-9632), которая может быть эксплуатирована для повышения привилегий в системах, в которых X-сервер выполняется с правами root, а также для удалённого выполнения кода в конфигурациях, в которых для доступа используется перенаправление сеанса X11 при помощи SSH...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62136
Тун-тун-тун... а что это тут у нас?
А! Это классическая сишная дырень с переполнением буфера почти 20ти летней давности!
Ничего нового)))
Мда, конечно хорошо что иксы закапывают.
Но весь иксовый мусор сейчас затянули в xwayland.
И таких багов в том дидовом омнокоде не известно никому.Нет бы выкинуть сразу, а кто хочет - пусть сидит на иксих до скончание времен.
Людям работать надо, а не пердолингом заниматься. У меня была попытка перейти на "чистый" Wayland:* Emacs (emacs-pgtk): [OK]
* Mattermost: [OK]
* Firefox: [OK]
* Яндекс.Браузер: [FAIL]
* Telegram: [FAIL]Ну и ещё по мелочи, что пока не оптимизировано под Wayland, тоже плохо работает даже через XWayland. Поэтому сижу пока на иксах.
Вообще, проблема с Яндекс / Telegram имеют общий корень - Chromium.
И Google заявили, что в процессе переноса Chromium на Wayland (в первую очередь делается для ChromeOS.)
А при чем там телеграм и хромиум?
Electron работает на базе Chromium
P.S. Пересмотрел, на базе Qt5/6. Значит накасячили разработчики Telegram
Mattermost -> Electron -> Chromium
Яндекс - кривое и зло.
Когда даже не пользовался такие мысли могут посещать, особенно осенью.
Любитель отдавать "обезличенные RLZ-параметры"?
В бете ЯБ можно отключить или вовсе удалить дополнение которое отправляет отчеты об ошибках. Достаточно перейти в дополнения и норм.
Яндекс - самый удобный браузер. Из всех. Все эти Vivaldi, Opera - все не то
А зачем сидеть на иксах, если xwayland работает seemless? Я просто включил вейланд и... всё. Никаких попыток не было.
Да, видно такой же seamless, как твоя орфография. А я вот ставил новую убунту на виртуалку. Казалось бы, что могло пойти не так? Какая-то прямоугольная хрень вместо курсора и мигающая полоска внизу экрана. Зато не луддиты, поставили вяленд по умолчанию. Модно-молодежно.
А, xwayland, а не Wayland. Впрочем, глючность вяленда это не отменяет.
> А я вот ставил новую убунту на виртуалку. Казалось бы, что могло пойти не так?
> на виртуалкуУ тебя в первом предложении все пошло не так. Да ещё скорее всего кривейший virtualbox.
> А зачем сидеть на иксах, если xwayland работает seemless?Зачем обмазываться грудой костылей, если можно просто поставить иксы и всё будет работать так же, как и со связкой вейланд+хвейланд?
> можно просто поставить иксы и всё будет работать так же,В том то и дело что не будет.
Я свалил с иксов как только вейланд смог ставить разное дробное маштабирование для каждого монитора.
А до этого это как раз были костыли и страдания.
У wayland клиенты изолированы и толку от XWayland маловато. Иконка из трея будет одиноко висеть посреди рабочего стола. А состояние клавиатуры не обновится, пока курсор мыши не "пролетит" над иксовым окном. Ну и глобальные хоткеи на самом-то деле и не такие уж и глобальные.Как бы толку маловато от XWayland. Баги будут одинаковы у старого qt5 в wayland и у qt5 в XWayland... А у qt5 в X11 этих багов не будет ;)
>Яндекс.Браузер: [FAIL]Уже не фейл. Починили.
>Telegram: [FAIL]
Подтверждаю. Сейчас запускаю его под xwayland, потому что под вейландом он падает и контекстные меню обрезает. Но там дело в пашкиных быдлокодерах, которые используют свой патченный Qt. Телега у меня ещё во времена иксов глючила и грузила проц.
У меня была попытка перейти на "чистый" Wayland:* Mattermost: [OK]
* Telegram: [FAIL]Странно, у меня наоборот.
C Telegram нормльно (из коробки раз-два), а вот Mattermost - сплошной Fail, вот неадвно пробовал с эксперементальными флагами, но проще использовать его через XWayland, может черег год попробовать снова.
И какой смысл страдать с вяленым? Там же десятки отдельных реализаций, и написаны они в основном на сишке. То есть и в вяленом будут уязвимости.
> И какой смысл страдать с вяленым?А почему с вяленым вообще нужно страдать?
> и написаны они в основном на сишке
Но есть и на плюсах, и на расте, и на всякой экзотике. И ЕСТЬ ВЫБОР.
А не как с иксами - вот копролит, юзай его.> То есть и в вяленом будут уязвимости.
Везде будет. Вопрос к количестве и поверхности атаки.
Когда у тебя уязвимость в иксах - у тебя дырень в 99% линукс-десктопов, потому что даже вейланды тянут xwayland.
Так я и не страдаю.
У меня есть небольшой список приложений работающих под Xwayland.Пытался их запустить под чистым Wayland ради спортивного интереса. В иксах тоже глюков хватает.
> Поэтому сижу пока на иксах.Ну так об этом и речь!
* Яндекс.Браузер: [ФСБ]
* Telegram: [ФСБ]
можно долго не перечислять софт по работе. На веланде не работает ни один удаленный дестктоп типа Anydesk и TeamViwer. Есть Rustdesk, но пока экспериментально и валится
> можно долго не перечислять софт по работе. На веланде не работает ни
> один удаленный дестктоп типа Anydesk и TeamViwer. Есть Rustdesk, но пока
> экспериментально и валитсяТем хуже для Anydesk или TeamViewer'а. Уж второй если помрет - мало кто из линуксоидов плакать будет.
> И таких багов в том дидовом омнокоде не известно никомуНо в новлсти написано о баге в одной конкретной реализации исков.
А количество композиторов Вайленда перевалило за 20, и многие из них написаны на дидовой сишочке. Вот и подумай, где в итоге будет больше багов.
> Но в новлсти написано о баге в одной конкретной реализации исков.Единственной распространенной. Считай монополия.
> А количество композиторов Вайленда перевалило за 20, и многие из них написаны на дидовой сишочке.
К сожалению пока нет закона, запрещающего использовать устаревшие инструменты.
Как и закона про ответственность программеров за свой код.> Вот и подумай, где в итоге будет больше багов.
Багов которые влияют на практически все десктопные линуксы?
Или которые будут ограничены одним-двумя композиторами?
Вот и подумай что хуже, с учетом того, что этот баг тыщиглаз не замечали 18 лет.
Забавно, почему айбиэм до сих пор пилит этот вяленый десять лет, и им невозможно пользоваться.
С чего это "не возможно"?
Использую вейланд последние года два и проблем только со старым хламом, которые ленивые опы не хотят обновлять до современных технологий.
И проблема такого луддизма заключается как в лени самих разрабов, так и в глупости шапки, которая тянула с дропом иксов настолько долго. Потому что всем известно, что разраб птица гордая, пока не пнешь - не полетит.А вот как только объявили, что всё - иксы дропают - так сразу все зашевелились.
Даже всякие васяно-ДЕ вроде крысы и корицы начали двигаться в сторону поддержки вейланда. Хотя думаю они не смогут.
> Использую вейланд последние года два и проблем только со старым хламом, которые
> ленивые опы не хотят обновлять1) раз старым хламом пользуются, значит, он устраивает; 2) если есть пользователи, то должна оставаться поддержка; 3) все, что надо знать о вяленых фанатиках - культ потре&лятства и нового ради нового.
> 1) раз старым хламом пользуются, значит, он устраиваетсогласен
> 2) если есть пользователи, то должна оставаться поддержка;
Да неужели?) Кому должна? Разве хоть что-то кому-то что-то должен?))
Это же опенсорс - вот сами берете и поддерживаете.> 3) все, что надо знать о вяленых фанатиках - культ потре&лятства и нового ради нового.
Все что нужно знать о фанатах иксов "диды в дерьме жили и мы будем! главное ничего не менять! а то вдруг у какого-то 6омжа с третим пнем работать перестанет!! дepьмо нужно тянуть вечно, вы абязаны!!1111"
> Да неужели?) Кому должна? Разве хоть что-то кому-то что-то должен?))
> Это же опенсорс - вот самиЕще раз. Раз пока есть пользователи, то пока есть и поддержка. Мало кто будет собирать кастомное ядро или патчи специально для себя писать. Достаточно не ломать просто. Да, я знаю, иногда просто "оставить как есть" не получится, но ломание гнома и вяленых композиторов иногда происходит по принципу "когда коту нечего делать".
> Все что нужно знать о фанатах иксов "диды в дерьме жили и
> мы будем!Ага, ща впихнем всем в глотку вяленд и как заживем. А то диды жить мешают.
> 6омжа с третим пнем работать перестанет!!Сегрегация пользователей, насильное пропихивание своих технологий. Что еще можно ожидать от фанатиков. А в ответ на сообщения о багах - УМВР, не нужно, вы неправильно этим пользуетесь.
> Еще раз. Раз пока есть пользователи, то пока есть и поддержка.Хахаха, нет дорогой, оно так не работает.
За поддержкой иди к корпам или плати денежку.
А опенсорс это "я написал код, я им поделился"
Но у меня нет никаких обязанностей: ни принимать pull request'ы, ни реализовывать фичи, ни осуществлять вообще какую-то поддержку.> Мало кто будет собирать кастомное ядро или патчи специально для себя писать.
Очень жаль)
> Достаточно не ломать просто.
Угу, "не ломать" это значит проводить тестирование на регрессии, проверять багрепорты и тд.
Это куча работы, которую такие как вы сами делать не хотите.> Да, я знаю, иногда просто "оставить как есть" не получится,
Именно поэтому начали выкидывать ХОрг - тк никто не хотел в нем ковыряться.
> но ломание гнома и вяленых композиторов иногда происходит по принципу "когда коту нечего делать".
И это их полное право.
> Ага, ща впихнем всем в глотку вяленд и как заживем. А то диды жить мешают.
Так сиди на ХОрге - сам фикси баги, сам осуществляй поддержку.
Ты на меня наезжаешь, а сам, по сути, та самая потербялдь, которая делать ничего не хочет, а только вопит что все ему должны.> Сегрегация пользователей, насильное пропихивание своих технологий.
Хахахахахаха! Давай поплачь, что 16 битные процы дропнули.
А по поводу насильного пропихивания - patches are welcome.
Вам нужны иксы? Поддерживайте сами!> А в ответ на сообщения о багах - УМВР, не нужно, вы неправильно этим пользуетесь.
Да, вы пользуетесь не так как решили создатели софта.
Т.к они делают для себя, а вам просто дали возможность попользоваться.
> За поддержкой иди к корпам или плати денежку.
> Т.к они делают для себя, а вам просто дали возможность попользоваться.Интересная логика. Гном делается за бабки, большинство коммитов Linux - от корпов, но при этом "просто дали попользоваться".
Что касается твоих личных нападок, то где я писал, что мне кто-то что-то должен? То, что старое оборудование должно поддерживаться, это не значит, что разработчик лично мне обязан. Просто без поддержки нужных вещей программа лишится части пользователей. Так что давай, вперед, выпиливай "ненужные" иксы и особенно XWayland. Я только за 😊
> Да, вы пользуетесь не так
Когда прога получает бОльшую часть рынка, то либо она прогибается под хотелки пользователей, либо пользователи под нее. Второй вариант обычно распространяется на закрытый софт.
> Интересная логика. Гном делается за бабки, большинство коммитов Linux - от корпов,
> но при этом "просто дали попользоваться".Именно так.
Просто если ты придешь, например к красношапке и спросишь "а кто ваши пользователи", то они расскажут тебе про крупные компании которые перешли на линукс, а именно на "Red Hat Enterprise Linux for Workstations".Можешь сам убедиться
redhat.com/en/technologies/linux-platforms/enterprise-linux/workstations
Volkswagen migrated from UNIX to Red Hat Enterprise Linux for Workstations to simplify its operating system (OS) management for its research and development (R&D) engineers.Так что для своих пользователей они делают фичи, а остальным позволяют пользоваться.
> Что касается твоих личных нападок, то где я писал, что мне кто-то что-то должен?
Хм.. если ты это так воспринял - то извини.
Мои рассуждения были скорее риторические.> То, что старое оборудование должно поддерживаться, это не значит, что разработчик лично мне обязан.
Так оно и не должно)
Ну нет у разработчика обязанности поддерживать старье (если это отдельно не предусмотрено контрактом)> Просто без поддержки нужных вещей программа лишится части пользователей.
И если создателя программы это устраивает - то все хорошо.
>Так что давай, вперед, выпиливай "ненужные" иксы и особенно XWayland. Я только за 😊
Из новости про релиз Федоры
"Пакеты, относящиеся к xorg-server, стали опциональными, по умолчанию не ставятся. Это можно считать признаком движения к полному отказу от X11 вообще."> Когда прога получает бОльшую часть рынка, то либо она прогибается под хотелки пользователей, либо пользователи под нее. Второй вариант обычно распространяется на закрытый софт.
Андроид и Хром показывает, что на открытый тоже.
Особенно если это опенсорс, который ментенить и развивать очень сложно.
> И если создателя программы это устраивает - то все хорошо.Опять же, если у проги большой рынок, то, скорее всего, разрабы сидят на зарплате. А в таком случае им вообще может быть фиолетово.
> Из новости про релиз Федоры
> "Пакеты, относящиеся к xorg-server, стали опциональными, по умолчанию не ставятся.Я в курсе. Проблема в том, что реализации Wayland кажутся еще сырыми, и не мне одному. Если бы переход с иксов был максимально бесшовным и безболезненным, а разработчиком пришлось бы перерисывать минимум кода (а не как сейчас), то вообще никакого флейма не было бы, и про иксы уже давно забыли. Ну а Федора - это известный глюкодром (ну или тестовый полигон, если такое обидно) для обкатки разработок Red Hat/IBM, лучше не использовать ее в реальной жизни.
> Андроид и Хром показывает, что на открытый тоже.
Эм, если не считать очевидных зондов для продажи рекламы, то какие свистелки, которые хотят пользователи, остались без внимания? А что касается сложности продукта - ну да, веб разжирел, а браузер стал заменять собой остальные проги в системе.
> Опять же, если у проги большой рынок, то, скорее всего, разрабы сидят на зарплате. А в таком случае им вообще может быть фиолетово.Так почти все успешные программы - это разрабы на зарплате.
Что ядро линукс, что блендер и тд.
Есть пару исключений типа vim, на то они и исключения (и при этом сливает по аудитории VS-коду).> Я в курсе. Проблема в том, что реализации Wayland кажутся еще сырыми, и не мне одному.
Если оно не соответствует твоим ожиданиям, то можешь продолжать сидеть на ХОрге и поддерживать его сам.
> Если бы переход с иксов был максимально бесшовным и безболезненным,
Не будет) Это невозможно просто архитектурно.
> а разработчиком пришлось бы перерисывать минимум кода (а не как сейчас),
Ты сам знаешь что это не возможно.
Слишком много изменилось, ИМХО это даже круче чем смена 16 на 32 бита.> то вообще никакого флейма не было бы, и про иксы уже давно забыли.
Тут просто классическая ситуация "ну раз еще все не перешли, то зачем тратить время? будем просто игнорировать проблему"...
а потом "аааа! все горит! наше чудесное приложение на костылях 20летней давности не работает! а там же переписывать кучу всего нужно!!"
Отсюда истеричные вопли "я просто хочу чтобы работало как раньше1!1!!"> лучше не использовать ее в реальной жизни.
Или наоборот - удачное место, где можно посмотреть чего будет в след. версиях красношапки.
> то какие свистелки, которые хотят пользователи, остались без внимания?
Дублирование приложений, Secure Folder, хаптик, мне был бы интересен аналог Samsung Dex.
Они реализованы в версиях вендоров (типа хаоми или самсунг), но в ванильном нету.> А что касается сложности продукта - ну да, веб разжирел, а браузер стал заменять собой остальные проги в системе.
Это значит что веб-аппа будет запускаться на любой архитектуре, на любой конфигурации где есть свежий браузер.
Почти как java 20+ лет назад)В теме про webassembly много спорили на эту тему.
> 1) раз старым хламом пользуются, значит, он устраивает; 2) если есть пользователи,
> то должна оставаться поддержка;В этом мире никто никому ничего не должен. И если вам нужна поддержка, ОБАНА, в опенсорсе в моде - self service. Значит вы идете и - поддерживаете то что ВАМ нужно САМИ. Как тебе такое Элон Маск?!
> 3) все, что надо знать о вяленых фанатиках - культ потре&лятства и нового ради нового.
Не, это - желание нормальной графической системы. Которая не ловит якорь от открытия менюшки или одной runaway задачи, не падает всей толпой оптом от GPU recovery, не тормозит и тирингует на отображении видео и анимаций, и не таскает 100500 легаси кода всякой отрисовки контролов и фонтов, которые страшны как смерть - так что это уже никто не использует, но код в результате такой - что посетивших его мучают ночные кошмары.
>Из-за ошибки при выставлении нового размера, изменение меняло только значение num_si, но оставляло неизменным значение size_si.почему разаботчики брезгают макросами для такого вида приколов?
некоторые даже ``free(ptr); ptr=NULL;`` делают руками. а потом получают уязвимости вида "мы в Х строке забыли занулить и получили UB в другом конце программы".
изучила немного вопрос. вроде, ничего плохого в макросах нет.
даже сложные конструкции и ветвления туда без проблем запихиваются через
```
#define Macro() \
do { \
<...> \
} while(0)
```
do и while можно в доп. макросы завернуть, улучшив читаемость:
```
#define Macro() \
MacroContextBegin() \
<...> \
MacroContextEnd()
```
или функции инлайновые почему не использовать? зачем это руками делают, понять не могу?
вот фикс даже: https://gitlab.freedesktop.org/xorg/xserver/-/commit/85b7765...тут ж можно было макрос сделать и избежать подобных проблем в любой части кода раз и навсегда.
Не понимаешь потому что видимо не пишешь ничего полезного. У тебя все указатели только в функции main(), что ты их можешь макросами занулять?
Ну сделаешь ты макрос, который вызывает free(), а затем присваивает NULL, только вот NULL присвоится локальному указателю внутри функции, а в вызывающе функции будет висячий указатель и никакой макрос тут не поможет
"поможет ``free(ptr); ptr=NULL``, но не поможет ``#define Free(ptr) free(ptr);ptr=NULL``" ?
по-моему, Вы пишете, не думая.
Using macros for auto-assigning NULL after freeing a pointer is a common practice in C and C++ programming to help prevent dangling pointer issues.на stackoverflow то же самое говорят.
Вы - тролль.
На stackoverflow много ерунды.На самом деле, собирать с -fsanitize=address уже довольно неплохо, но, опять же, зачастую проблема в библиотеке, а не в собственном коде.
> На stackoverflow много ерунды.
> На самом деле, собирать с -fsanitize=address уже довольно неплохо, но, опять же,
> зачастую проблема в библиотеке, а не в собственном коде.sanitize=address довольно жестко тормозит - и RAM жрет на трекинг использования, так что вы получите нечто типа дотнета или явы из сишки. Ну и радости с него такого? Вот ubsan - довольно легкий бывает, но и ловит не все.
> Вы - тролль.За словами следи, тролль. И прежде, чем лезть в stackoverflow и что-то тут комментировать, следует сначала разобраться в предметной области.
#include <stdio.h>
#include <stdlib.h>#define FREE(ptr) do { \
free(ptr); ptr = NULL; } while(0)void f(int *ptr)
{
FREE(ptr);
}int main(void)
{
int *p = malloc(sizeof(int));f(p);
printf("%p\n", p);
return 0;
}
> "поможет ``free(ptr); ptr=NULL``, но не поможет ``#define Free(ptr) free(ptr);ptr=NULL``"
> ?Поможет от чего именно? "в другом конце программы" так и останется предыдущее значение ptr. Или вообще, указатель на кусок освобожденной памяти (*ptr+сдвиг)...
Все эти "новомодные" RAII, smart-pointers, владения и времена жизни в "молодежных" ЯП-ах (как кучи ЯП с автоматической сборкой мусора) не от переизбытка смузи или неосиляния free(ptr);ptr=NULL придумали.
> по-моему, Вы пишете, не думая.
По-моему, кто-то хелловордщик.
std::shared_ptr не благодарите
std::unique_ptr сейчас
это два разных указателя, первый со счетчиком ссылок и множественным владением, второй - допускает только одно владение
> это два разных указателя, первый со счетчиком ссылок и множественным владением, второй
> - допускает только одно владениеОтсутствие этого знания в сях порой вообще несколько портит некоторые аспекты. Скажем, некоторые оптимизации не знают - как доступаются к объекту. Скажем можно было бы сфолдить несколько констант в одну при идентичности. Но если к ним доступаются по указателям... все становится намного интереснее, и в экзотичных случаях сие будет работать не идентично честному хранению констант по отдельности.
> Отсутствие этого знания в сях порой вообще несколько портит некоторые аспекты. Скажем,
> некоторые оптимизации не знают - как доступаются к объекту. Скажем можно
> было бы сфолдить несколько констант в одну при идентичности.Ну, как бы, есть restrict, да. Но ... все "гарантии" и проверки тут опять таки - на самом п(о)громмисте.
> Ну, как бы, есть restrict, да. Но ... все "гарантии" и проверки
> тут опять таки - на самом п(о)громмисте.Есть и более радикальные ключи компилера позволяющие мерж констант - с пониманием что это noncompliant формально. Так rodata - меньше, но какой-то экзотичный код уповавший на вон то имеет право отъехать.
>> smart-pointers,
> std::shared_ptr не благодаритеНе благодарю (тем более за "сборщик мусора для бедных" из питоно-свифтов) 😉
> за "сборщик мусора для бедных" из питоно-свифтовУмные указатели не имеют ничего общего со сборщиком мусора.
>> за "сборщик мусора для бедных" из питоно-свифтов
> Умные указатели не имеют ничего общего со сборщиком мусора.Но только после пиар-компании маркетолугов и фанбоев ябла, с их "инновационным" ARC в свифте, который "не GC!!1"
А до этого, подсчет ссылок считался одной из разновидностей GC.
Но ты всегда можешь ткнуть в реализацию:https://github.com/gcc-mirror/gcc/blob/1f7b1c555c66cf55f9032...
и "опровергнуть" (ну, попытаться).
> А до этого, подсчет ссылок считался одной из разновидностей GC.Нет, никогда не считался. А в unique_ptr счетчика ссылок и вовсе нет.
>> А до этого, подсчет ссылок считался одной из разновидностей GC.
> Нет, никогда не считался.У "альтернативных", в их альтернативной вселенной с альтернативно-маркетолухоичной.
терминологией - все может быть.https://www.cl.cam.ac.uk/~nk480/C1819/lecture7.pdf
https://cplusplus.com/reference/memory/shared_ptr/
> Manages the storage of a pointer, providing a limited garbage-collection facility,---
>>> smart-pointers,
>> std::shared_ptr не благодарите
> А в unique_ptr счетчика ссылок и вовсе нет.Начались виляния. Уныло.
> в unique_ptr счетчика ссылок и вовсе нет.0 или 1 -- вполне счётчик.
теперь дошло, что сказать хотели, спасибо.
но изначально вопрос был в принципе об использовании макросов для обобщения монотонный действий. а не об "офигенном способе зануленич указателей".
по-моему, это только ivan понял
Объясняю для тупых: если ты объявил указатель, аллоцировал ему память, а потом очистил память и всё это в одной функции, то тогда всё ок. Но если программа сложнее хеллоуврота, то объявляется указатель, аллоцируется память, используется указатель и очищается память обычно в разных функциях. И с этим есть проблема, потому что указатель это самая обычная переменная, просто вместо значения он содержит адрес. Когда ты передаешь указатель в функцию, внутри функции создается КОПИЯ указателя, в которую копируется значение передаваемого указателя, всё как с обычными переменными. Меняя значение такого указателя внутри вызываемой не влияет на указатель в передаваемой функции. Всё как у обычных переменных, чем собственно указатель и является
Технически никто не мешает передавать указатель на указатель и тогда можно будет занулять и вызывающая функция не останется с невалидным указателем.На практике я пробовал так делать, код получается громздким.
> Технически никто не мешает передавать указатель на указатель и тогда можно будет занулять и вызывающая функция не останется с невалидным указателем.Технически мешает тот факт, что объект уже освобожден из памяти. Ты же не будешь после free(ptr) держать эту самую переменную ptr, чтобы указатель-на-ptr все еще мог на нее указывать?
То что я описал это способ в С коде без лишних языковых конструкций и отдельных языков получить аналог std::*_ptr от крестов.
Да, не идеальный, тк теперь у нас не сама память от объекта может быть внезаптно освобождена а может быть освобождена память где хранится указатель на объект.В целом это иногда удобно когда вызывающая функция может освободить память, но того же самого можно добится проверяя код возврата или договорившись что вызывающая функция дальше владеет объектом и отвечает за его освобождение.
Бывают и сложные ситуации когда реально нужен подсчёт рефов и только при нуле удаление, но я лично стараюсь такого избегать архитектурно.
> То что я описал это способ в С коде без лишних языковых конструкций и отдельных языков получить аналог std::*_ptr от крестов.То, что вы описали, даже приблизительно не является аналогом std::*_ptr из C++. А получите вы от этого решения только еще больше геморроя на пустом месте, ибо изначальную проблему оно вообще не решает, но еще и добавляет новую.
а не проще, кстати, заменить стандартные функции на свои с механихмом подсчета референсов?
```
void fn1(char *point){
free(point); // понизит до 1, не очистит
}
#define fn1(point) fn1(ref(point))int main(){
char *str = malloc(sizeof(char*)); # создаст мутекс, счетчик и вернет аллоцированную память
str = "hi";
fn1(point); // повысит уровень ссылки до 2printf("%s\n", str) // все ок
free(str) // очистит
}
```
это так, концепция, вчера буквально написала.
осталось поудобнее все это сделать проблема сгинет, вроде.
Хоспади, да хватит уже позориться.P.S.
> char *str = malloc(sizeof(char*)); # создаст мутекс, счетчик и вернет аллоцированную память
> str = "hi";У тебя утечка памяти, инноваторша
в коде ошиблась - ну все, позор на всю жизнь, лол.
```
TableNewExten(h);int main(){
str1="123";
str2="456";char *out;
void *outCtlstrUnite(out, str1, str2) // memAlloc
TableInitExtern(h);
TableAdd(h, "key", refLend(outCtl, out))printf("%s:%s", out, TableGet(h, char*, "key"));
memFree(out); // уровень 1
TableFree(h);refBorrow(outCtl) { // уровкнь 0
memFree(outCtl) // free()
}
}
> "поможет ``free(ptr); ptr=NULL``, но не поможет ``#define Free(ptr) free(ptr);ptr=NULL``"
> ?
> по-моему, Вы пишете, не думая.В данном частном случае, может быть, поможет.
В общем случае придётся делать что-то вроде
#define Free_S(pptr) free(*pptr);*pptr=NULL
и соответственно в остальных местах работать с лишней косвенностью, что убьёт смысл использовать Си.
смысл не убьет - компилятор с99 в каждой микроволновке, ибo POSIX.
по-моему, его в основном используют там, где нужна порьабельность.
но вообще, я немного о другом говорила.
вопрос был о том, зачем писать дважды, если можно один раз, в общем случае, не о конкретике.
> смысл не убьет - компилятор с99 в каждой микроволновке, ибo POSIX.
> по-моему, его в основном используют там, где нужна порьабельность.Например, Vala транслируется в Си. Оно прикручено болтами к GLib (не путать с glibc), но можно открутить, автоматическое управление памятью на подсчёте ссылок останется. Можно ещё что-то транслировать, вплоть до Рефала. Если производительность не играет роли.
> но вообще, я немного о другом говорила.
> вопрос был о том, зачем писать дважды, если можно один раз, в
> общем случае, не о конкретике.Макросы не очень любят, поскольку подчас всплывают неожиданности. Вот классический пример ошибки из букваря (описано в книге Алена Голуба "Верёвка достаточной длины..."), с которым ничего не могут поделать https://bugzilla.altlinux.org/show_bug.cgi?id=38212#c2 потому что придётся всю GNU C Library выкидывать.
Страуструп даже отдельный препроцессор придумал вместо макросов - CFront.
не знаю, что за Рефал, а Vala, во-первых, не ясно, на кукую версию стандарта метит, во-вторых, gnu-расширения использует.
изначально на ней писать хотела
> gnu-расширения используетУж лучше GNU-расширения, чем твои уродские костыли
Рефал это просто пример, что транслировать в Си можно почти что угодно. Изначально препроцессор Си был отдельной программой -- намёк, что если не хватает макросов, то можно написать свой препроцессор. Что сделали в Vala и прочих ЯП.
почему, кстати, с лишней косвенностью?
сейчас посмотрела - у меня так и происходило.
```
void mmeFree(void **point){
if(point==NULL||*point=NULL){...}
free(*point);
*point=NULL;
}
```
```
<...>
memFree(&point);
<...>
```
потом просто на NULL значения проверяете и все
>[оверквотинг удален]
> free(*point);
> *point=NULL;
> }
> ```
> ```
> <...>
> memFree(&point);
> <...>
> ```
> потом просто на NULL значения проверяете и всеВ #11 не вижу этой лишней косвенности, только ``free(ptr); ptr=NULL;``
Лишняя - потому что лишние операции, лишние инструкции в машинном коде. Если такая цена устраивает, то вопросов нет. Часть лишнего оптимизатор может быть даже выкинет, если не передавать такие указатели между модулями (so, dll).
вот при таком раскладе проявляются проблемы:
```
int main(){
TableInitExtern(htb);char *str1 = "123";
char *str2 = "456";
char *str3 = "789";char *out;
eAPIStrUnite(out, str1, str2, str3);
TableAdd(htb, "Key", out);
printf("%s\n", out);
eAPIMemPointFree(out);char *Data = TableGet(htb, char*, "Key");
printf("%s\n", Data); // обращение к NULLTableFree(htb);
}
```
сделала вот так в конечном итоге:
```
int main(){TableInitExtern(htb);
char *str1 = "123";
char *str2 = "456";
char *str3 = "789";char *out;
refctl outCtl;
eAPIStrUnite(out, str1, str2, str3);
TableAdd(htb, "Key", refLend(outCtl, out));
printf("%s\n", out);
memFree(out); // не очищает: 0 юзеров, 1 арендаchar *Data = ref(TableGet(htb, char*, "Key"));
printf("%s\n", Data);
memFree(Data); // не очищает: 0 юзеров, 1 арендаTableFree(htb);
refBorrow(outCtl); // очищает
}
```
> char *str1 = "123";
> char *str2 = "456";
> char *str3 = "789";
> char *out;А зачем вообще нужны голые указатели?
Вот эти массивы char -- в примере появились для наглядности -- в рабочей программе они откуда-то взялись? И при этом была подсчитана их длина, наверняка и память под них выделена?
> eAPIStrUnite(out, str1, str2, str3);
Например, если "строки" хранить в странном на первый взгляд формате - в двусвязном списке char - может оказаться, что слияние выполняется без лишних копирований и вопрос с управлением памятью отпадает сам собой.
> TableAdd(htb, "Key", out);
Шаблонная функция в Си++ потребовала бы вместо указателя итератора (а по списку он или по массиву - зависит от специализации). В Си для списка придётся написать отдельную, но вряд ли в ней итерация по списку это основная сложность.
Список - просто как пример неочевидного решения, в каких-то частных случаях оправданного. Здесь может быть проще инкапсулировать указатель и счётчик в struct string?
>> char *str1 = "123";
>> char *str2 = "456";
>> char *str3 = "789";
>> char *out;
> А зачем вообще нужны голые указатели?Я таки нашел 1 применение похожей конструкции. Можно написать например
...
return "OK";...и номер в принципе катит. Актуально для всяких "err2str" самопальных. Конечно оно return по факту - указатель на строку "OK", си ж не умеет строку by value возвращать вот так в лобову. Да и не в лобовую - лучше не надо.
>[оверквотинг удален]
>>> char *str3 = "789";
>>> char *out;
>> А зачем вообще нужны голые указатели?
> Я таки нашел 1 применение похожей конструкции. Можно написать например
> ...
> return "OK";
> ...и номер в принципе катит. Актуально для всяких "err2str" самопальных. Конечно оно
> return по факту - указатель на строку "OK", си ж не
> умеет строку by value возвращать вот так в лобову. Да и
> не в лобовую - лучше не надо.В каких-то частных случаях без голых указателей на массивы символов не обойтись, но в общем случае от них больше проблем, чем пользы.
> eAPIStrUnite(out, str1, str2, str3);
> TableAdd(htb, "Key", out);
> printf("%s\n", out);
> eAPIMemPointFree(out);
> char *Data = TableGet(htb, char*, "Key");
> printf("%s\n", Data); // обращение к NULLВ догонку к "двусвязному списку для хранения"... Если TableAdd() и TableGet() внутри содержат некий перфект хеш, то замена хештаблицы на префиксное дерево позволит убрать операцию слияния подстрок для формирования ключа, вместо этого искать-добавлять непосредственно по подстрокам ключа. Сами строки-подстроки при этом хранятся в дереве. Для передачи в printf придётся их скопировать в массив char, но в простейшем случае хватит локальной копии (в стеке). Почему "значение" следует объединять из подстрок перед добавлением в таблицу - тоже неочевидно. Может быть, проще его менять?
Потому что синтаксический сахар вызывает передоз.Посмотрите на gobject для примера или ещё какой проект где активно юзаеются макросы.
Да даже без макросов многие либы навязывают архитектуру и дизайн приложения.Когда пишешь на С есть желание оставатся в рамках общепринятого и понятного синтаксиса, а так то конечно легко обернуть каждую функцию в свои функции или макросы а потом получившийся код будет как лапшка на крестах - сплошной местячковый диалект на полтора анонима, притом автор и сам через год не вспомнит что у него была какаянить safe_free() и напишет ещё одну free_safe() в другом файле.
По крайней мере я через это проходил в оба конца, и видел как целые компании пошли по пути написания обёрток и абстракций для всего подряд, получив в итоге вместо кода полное сектанство.
Да, они даже malloc(), free(), str*() и прочее обернули или сами реализовали, и учитывая что я эту шизу проходил это был NIH синдром под лозунгом "зато наш код на любой платформе одинаково плох" :)
> как лапшка на крестах - сплошной местячковый диалект на полтора анонимаЛол. В крестах с его RAII таких глупых проблем в принципе нет.
>> как лапшка на крестах - сплошной местячковый диалект на полтора анонима
> Лол. В крестах с его RAII таких глупых проблем в принципе нет.Да уж. Там другие проблемы. В частности - что каждый плюсер хреначит на своем собственном субдиалекте C++. На фоне вон этого, вон то - такие мелочи, право.
Да. Решить все остальные проблемы плюсов можно как Линус Торвальдс: назвать всех плюсовиков нехорошим словом. После дружеского мордобоя работать с теми, кто останется.
>Да даже без макросов многие либы навязывают архитектуру и дизайн приложения.хм.. ну, может это не нравится кому-то, действительно.
хотя, мне кажется, это наоборот хорошо.>притом автор и сам через год не вспомнит
вот локальность - да, может быть проблемой. но можно ж кратко все функции в .md файлах документировать. тем более, есть удобные инструменты для генерации манов.
через год просто
man MyAPI (видишь раздел "Mem")
man MyAPI.Mem, где для каждой функции расписано, какие коды отлавливать надо, когда паника и т.п.>они даже malloc(), free(), str*() и прочее обернули
так же сделала. а чем плохо это?
штатные реализации можно отключить:
```
#define malloc myAPIPanic("malloc() is blocked, use MemAlloc instend!""
```
,так что ебезопасный вариант не влепишь.>
случайно "отправить" нажала.
>это был NIH синдром под лозунгом "зато наш код на любой платформе одинаково плох" :)почему плох обязательно? и почему nih-синдром?
можно ж обернуть некоторые функции и полностью забыть об определенном классе проблем.
заодно и решить проблемы с поддержкой тех же Окон, перенеся все #define'ы в либу и получив на выходе простой, читаемый код.
это ж хорошо наоборот
nih-синдром -- это такая мантра, что бы люди разучились кодить. Этим синдромом "больны" все влиятельные корпорации: Микрософт, Гугл, даже GNU и то -- is Not UNIX. :)
Блин, скажи честно - ты дура?> #define malloc myAPIPanic("malloc() is blocked, use MemAlloc instend!""
Во-первых, тут закрывающейся скобки нет. Во-вторых непарное количество кавычек.
В-третьих, ты хоть посмотри через gcc -E во что это твоё чудо сгенерируется, если использовать нормальный вызов malloc вместо твоих корявых костылей.
В четвертых, man LD_PRELOAD
*вместе с твоими корявыми костылями
скажу честно - разоблачитель опечаток правила формуа нарушает.>LD_PRELOAD
сейчас бы конструкции препроцессора загружать.
>посмотри
ни во что.
потому что макрос паники использует fprintf, возвращающий int.
а malloc - void*, о чем будет написано во время компиляции.
> ни во что.
> потому что макрос паники использует fprintf, возвращающий int.
> а malloc - void*, о чем будет написано во время компиляции.вот это твоё безобразие
#define malloc myAPIPanic("malloc() is blocked, use MemAlloc instend!")при таком использовании
int *p = malloc(4);сгенерируется в:
int *p = myAPIPanic("malloc() is blocked, use MemAlloc instead!")(4);Это блин ваще чё такое?
Ого, это похоже на переполнение входного буфера при попытке множественного инстанциирования.
>>Да даже без макросов многие либы навязывают архитектуру и дизайн приложения.
> хм.. ну, может это не нравится кому-то, действительно.
> хотя, мне кажется, это наоборот хорошо.А вот это - зависит от. Может, по изначальной задумке было бы удобно совсем другую архитектуру. Но нет, придется делать самолет из бамбука и лиан. Потому что автор либы так хотел. И запускать его - с обрыва, чтобы хоть как-то летал.
>[оверквотинг удален]
> <...> \
> } while(0)
> ```
> do и while можно в доп. макросы завернуть, улучшив читаемость:
> ```
> #define Macro() \
> MacroContextBegin() \
> <...> \
> MacroContextEnd()
> ```Фига у некоторых понятия о улучшении читаемости. Теперь всем кто видит это впервые неплохо бы RTFMнуть что есть MacroContextBegin/End и к каким особенностям сие ведет. Ибо изначально имплементация не очевидна. Что для системного яп - такая себе радость. Одно из требований в случае например safety critical типа MISRA это использование стандартного синтаксиса, без хаков. Чтобы другие програмеры не трактовали энный код неверно и не вкатили багов на этой почве.
А если этот аспект пофиг - так никто и не будет читать Macro(). На самом деле это все далеко не главная трабла севых макросов.
> или функции инлайновые почему не использовать? зачем это руками делают, понять не могу?
Инлайновые функции хороши до известного предела.
>Ибо изначально имплементация не очевиднатак это ж плюс, нет?
вместо того, что б голову себе морочить реализаций - понятный
ContextBegin().
или MacroSaveContext() и MacroEndSaveContext(), условно.>Что для системного яп - такая себе радость.
почему? вон, в C#, java и тд построение абстракций и скрытие реализации - это вообще поощряемое дело. что и правильно, как мне кажется. зачем это в голове держать, опять же? тем более, что многие редакторы позволяют по 1й кнопке прыгнуть к реализации.
> вместо того, что б голову себе морочить реализаций -Вон то это стандартный паттерн для сишников. В отличие от...
> понятный ContextBegin().
...делающего фиг знает что и почему, отдельно смотреть еще надо что сие. Или при случае налететь, неверно поняв свойства конструкции. Если это было не важно - програмер вообще не будет смотреть тот макрос.
> или MacroSaveContext() и MacroEndSaveContext(), условно.
Это вообще вопиющая дезинформация. Потому что никаких контекстов оно никуда не сэйвит. А облом ожиданий прогармера и дезинформация - чреваты совершенно дурными багами на ровном месте.
Это не значит что совсем не надо юзать макросы, в мане gcc, по моему, пример как достаточно прикольно и красиво инициализировать что-нибудь этакое, типа array struct'ов, в элегантном виде. Для себя я даже его расширил подобными вещами дабы точно не забыть терминатор (struct с специальными значениями) в хвосте по которому парсеры определяют (при заранее неизвестном размере) что все, пора угомониться. Но это task specific штука, под заведение нескольких однотипных "объектов" которые всяко были довольно кастомными штуками, и парсер свой.
>>Что для системного яп - такая себе радость.
> почему? вон, в C#, java и тд построение абстракций и скрытие реализации
> - это вообще поощряемое дело. что и правильно, как мне кажется.Теперь попробуйте на этом системный софт, бутлоадеры, фирмвари, ядра и все такое писать. Поймете в чем прикол. Когда от системы надо предсказуемость поведения - а вы понятия не имеете как компонент себя ведет, какие особенности и проч - это не фича.
> зачем это в голове держать, опять же? тем более, что многие
> редакторы позволяют по 1й кнопке прыгнуть к реализации.Вон то стандартный прием в си. Если специальных соображени нет - вам реализация пофиг. А если реализация не пофиг то нестандартные плюхи в ней заставят читать еще и реализацию этих плюх, и вместо 1 штуки - теперь читаем 3! Т.е. провалившись в реализацию, еще обклацываем 2 под-реализации воооон того. И это типа улучшение? :)
"системах, в которых X-сервер выполняется с правами root, а также для удалённого выполнения кода в конфигурациях, в которых для доступа используется перенаправление сеанса X11 при помощи SSH. "
иными словами ни в одном адекватно настроенном дистрибутиве проблемы нет.
Прокинуть X11 через SSH - это, всего-лишь, пожелание пользователя, независимо от дистрибутива.
И снова сишка ни при чём...
Разумеется! Это фсе погромисты виноваты!
Вот настоящий сишник™ никогда бы такую ошибку не допустил.
А если допустил, то он просто бракодел и не настоящий сишник™
Ты патч смотрел?Там логическая ошибка в работе с макроданными.
То есть или язык будет ущербным без возможности использовать макроданные для описания данных. Или в нем будут допустимы аналогичные ошибки.
Для реализации протоколов макроданные необходимы.
Но безопастном Расте тоже есть макросы, получается...
Кажется теперь новости про иксы все будут выглядеть примерно так...