|
| |
| |
| 3.87, Анониматор (?), 20:02, 30/10/2024 [^] [^^] [^^^] [ответить]
| +2 +/– |
можно долго не перечислять софт по работе. На веланде не работает ни один удаленный дестктоп типа Anydesk и TeamViwer. Есть Rustdesk, но пока экспериментально и валится
| | |
| |
| 4.97, Аноним (97), 23:02, 30/10/2024 [^] [^^] [^^^] [ответить]
| –2 +/– |
> можно долго не перечислять софт по работе. На веланде не работает ни
> один удаленный дестктоп типа Anydesk и TeamViwer. Есть Rustdesk, но пока
> экспериментально и валится
Тем хуже для Anydesk или TeamViewer'а. Уж второй если помрет - мало кто из линуксоидов плакать будет.
| | |
|
|
| 2.39, Аноним (39), 09:30, 30/10/2024 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> И таких багов в том дидовом омнокоде не известно никому
Но в новлсти написано о баге в одной конкретной реализации исков.
А количество композиторов Вайленда перевалило за 20, и многие из них написаны на дидовой сишочке. Вот и подумай, где в итоге будет больше багов.
| | |
| |
| 3.44, Аноним (-), 10:38, 30/10/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Но в новлсти написано о баге в одной конкретной реализации исков.
Единственной распространенной. Считай монополия.
> А количество композиторов Вайленда перевалило за 20, и многие из них написаны на дидовой сишочке.
К сожалению пока нет закона, запрещающего использовать устаревшие инструменты.
Как и закона про ответственность программеров за свой код.
> Вот и подумай, где в итоге будет больше багов.
Багов которые влияют на практически все десктопные линуксы?
Или которые будут ограничены одним-двумя композиторами?
Вот и подумай что хуже, с учетом того, что этот баг тыщиглаз не замечали 18 лет.
| | |
| |
| 4.51, Аноним (50), 11:23, 30/10/2024 [^] [^^] [^^^] [ответить]
| +/– |
Забавно, почему айбиэм до сих пор пилит этот вяленый десять лет, и им невозможно пользоваться.
| | |
| |
| 5.55, Аноним (-), 11:47, 30/10/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
С чего это "не возможно"?
Использую вейланд последние года два и проблем только со старым хламом, которые ленивые опы не хотят обновлять до современных технологий.
И проблема такого луддизма заключается как в лени самих разрабов, так и в глупости шапки, которая тянула с дропом иксов настолько долго. Потому что всем известно, что разраб птица гордая, пока не пнешь - не полетит.
А вот как только объявили, что всё - иксы дропают - так сразу все зашевелились.
Даже всякие васяно-ДЕ вроде крысы и корицы начали двигаться в сторону поддержки вейланда. Хотя думаю они не смогут.
| | |
| |
| 6.76, randomize (?), 17:24, 30/10/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Использую вейланд последние года два и проблем только со старым хламом, которые
> ленивые опы не хотят обновлять
1) раз старым хламом пользуются, значит, он устраивает; 2) если есть пользователи, то должна оставаться поддержка; 3) все, что надо знать о вяленых фанатиках - культ потре&лятства и нового ради нового.
| | |
| |
| 7.78, Аноним (-), 17:38, 30/10/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> 1) раз старым хламом пользуются, значит, он устраивает
согласен
> 2) если есть пользователи, то должна оставаться поддержка;
Да неужели?) Кому должна? Разве хоть что-то кому-то что-то должен?))
Это же опенсорс - вот сами берете и поддерживаете.
> 3) все, что надо знать о вяленых фанатиках - культ потре&лятства и нового ради нового.
Все что нужно знать о фанатах иксов "диды в дерьме жили и мы будем! главное ничего не менять! а то вдруг у какого-то 6омжа с третим пнем работать перестанет!! дepьмо нужно тянуть вечно, вы абязаны!!1111"
| | |
| |
| |
| 9.98, Аноним (-), 23:04, 30/10/2024 [^] [^^] [^^^] [ответить] | +/– | Хахаха, нет дорогой, оно так не работает За поддержкой иди к корпам или плати д... большой текст свёрнут, показать | | |
| |
| |
| 11.124, Аноним (-), 16:28, 31/10/2024 [^] [^^] [^^^] [ответить] | +/– | Именно так Просто если ты придешь, например к красношапке и спросишь а кто ваш... большой текст свёрнут, показать | | |
|
|
|
|
| 7.99, Аноним (-), 23:07, 30/10/2024 [^] [^^] [^^^] [ответить] | +/– | В этом мире никто никому ничего не должен И если вам нужна поддержка, ОБАНА, в ... большой текст свёрнут, показать | | |
|
|
|
|
|
|
| 1.11, мяв (?), 02:07, 30/10/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 >Из-за ошибки при выставлении нового размера, изменение меняло только значение num_si, но оставляло неизменным значение size_si.
почему разаботчики брезгают макросами для такого вида приколов?
некоторые даже ''free(ptr); ptr=NULL;'' делают руками. а потом получают уязвимости вида "мы в Х строке забыли занулить и получили UB в другом конце программы".
изучила немного вопрос. вроде, ничего плохого в макросах нет.
даже сложные конструкции и ветвления туда без проблем запихиваются через
'''
#define Macro() \
do { \
<...> \
} while(0)
'''
do и while можно в доп. макросы завернуть, улучшив читаемость:
'''
#define Macro() \
MacroContextBegin() \
<...> \
MacroContextEnd()
'''
или функции инлайновые почему не использовать? зачем это руками делают, понять не могу?
| | |
| |
| 2.14, Аноним (14), 02:18, 30/10/2024 [^] [^^] [^^^] [ответить]
| +8 +/– |
Не понимаешь потому что видимо не пишешь ничего полезного. У тебя все указатели только в функции main(), что ты их можешь макросами занулять?
Ну сделаешь ты макрос, который вызывает free(), а затем присваивает NULL, только вот NULL присвоится локальному указателю внутри функции, а в вызывающе функции будет висячий указатель и никакой макрос тут не поможет
| | |
| |
| 3.16, мяв (?), 02:26, 30/10/2024 [^] [^^] [^^^] [ответить]
| –3 +/– |
"поможет ''free(ptr); ptr=NULL'', но не поможет ''#define Free(ptr) free(ptr);ptr=NULL''" ?
по-моему, Вы пишете, не думая.
| | |
| |
| 4.19, мяв (?), 02:37, 30/10/2024 [^] [^^] [^^^] [ответить]
| –3 +/– | |
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 то же самое говорят.
Вы - тролль.
| | |
| |
| 5.27, Аноним (27), 04:19, 30/10/2024 [^] [^^] [^^^] [ответить]
| +1 +/– | |
На stackoverflow много ерунды.
На самом деле, собирать с -fsanitize=address уже довольно неплохо, но, опять же, зачастую проблема в библиотеке, а не в собственном коде.
| | |
| |
| 6.101, Аноним (-), 23:10, 30/10/2024 [^] [^^] [^^^] [ответить]
| +/– |
> На stackoverflow много ерунды.
> На самом деле, собирать с -fsanitize=address уже довольно неплохо, но, опять же,
> зачастую проблема в библиотеке, а не в собственном коде.
sanitize=address довольно жестко тормозит - и RAM жрет на трекинг использования, так что вы получите нечто типа дотнета или явы из сишки. Ну и радости с него такого? Вот ubsan - довольно легкий бывает, но и ловит не все.
| | |
|
| 5.33, Аноним (33), 08:16, 30/10/2024 [^] [^^] [^^^] [ответить]
| +7 +/– | |
> Вы - тролль.
За словами следи, тролль. И прежде, чем лезть в 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;
}
| | |
|
| 4.23, Аноним (23), 03:06, 30/10/2024 [^] [^^] [^^^] [ответить]
| +3 +/– |
 > "поможет ''free(ptr); ptr=NULL'', но не поможет ''#define Free(ptr) free(ptr);ptr=NULL''"
> ?
Поможет от чего именно? "в другом конце программы" так и останется предыдущее значение ptr. Или вообще, указатель на кусок освобожденной памяти (*ptr+сдвиг)...
Все эти "новомодные" RAII, smart-pointers, владения и времена жизни в "молодежных" ЯП-ах (как кучи ЯП с автоматической сборкой мусора) не от переизбытка смузи или неосиляния free(ptr);ptr=NULL придумали.
> по-моему, Вы пишете, не думая.
По-моему, кто-то хелловордщик.
| | |
| |
| |
| |
| 7.52, Аноним (52), 11:29, 30/10/2024 [^] [^^] [^^^] [ответить]
| +/– |
это два разных указателя, первый со счетчиком ссылок и множественным владением, второй - допускает только одно владение
| | |
|
| 6.105, Аноним (23), 00:09, 31/10/2024 [^] [^^] [^^^] [ответить]
| +/– |
>> smart-pointers,
> std::shared_ptr не благодарите
Не благодарю (тем более за "сборщик мусора для бедных" из питоно-свифтов) 😉
| | |
| |
| 7.113, Аноним (113), 11:08, 31/10/2024 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> за "сборщик мусора для бедных" из питоно-свифтов
Умные указатели не имеют ничего общего со сборщиком мусора.
| | |
|
|
| 5.108, мяв (?), 04:54, 31/10/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
теперь дошло, что сказать хотели, спасибо.
но изначально вопрос был в принципе об использовании макросов для обобщения монотонный действий. а не об "офигенном способе зануленич указателей".
по-моему, это только ivan понял
| | |
|
| 4.35, Аноним (33), 08:48, 30/10/2024 [^] [^^] [^^^] [ответить]
| +4 +/– |
Объясняю для тупых: если ты объявил указатель, аллоцировал ему память, а потом очистил память и всё это в одной функции, то тогда всё ок. Но если программа сложнее хеллоуврота, то объявляется указатель, аллоцируется память, используется указатель и очищается память обычно в разных функциях. И с этим есть проблема, потому что указатель это самая обычная переменная, просто вместо значения он содержит адрес. Когда ты передаешь указатель в функцию, внутри функции создается КОПИЯ указателя, в которую копируется значение передаваемого указателя, всё как с обычными переменными. Меняя значение такого указателя внутри вызываемой не влияет на указатель в передаваемой функции. Всё как у обычных переменных, чем собственно указатель и является
| | |
| |
| 5.77, Ivan_83 (ok), 17:29, 30/10/2024 [^] [^^] [^^^] [ответить]
| +/– |
 Технически никто не мешает передавать указатель на указатель и тогда можно будет занулять и вызывающая функция не останется с невалидным указателем.
На практике я пробовал так делать, код получается громздким.
| | |
| |
| 6.84, Аноним (84), 18:55, 30/10/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Технически никто не мешает передавать указатель на указатель и тогда можно будет занулять и вызывающая функция не останется с невалидным указателем.
Технически мешает тот факт, что объект уже освобожден из памяти. Ты же не будешь после free(ptr) держать эту самую переменную ptr, чтобы указатель-на-ptr все еще мог на нее указывать?
| | |
| |
| 7.93, Ivan_83 (ok), 22:22, 30/10/2024 [^] [^^] [^^^] [ответить]
| +/– |
То что я описал это способ в С коде без лишних языковых конструкций и отдельных языков получить аналог std::*_ptr от крестов.
Да, не идеальный, тк теперь у нас не сама память от объекта может быть внезаптно освобождена а может быть освобождена память где хранится указатель на объект.
В целом это иногда удобно когда вызывающая функция может освободить память, но того же самого можно добится проверяя код возврата или договорившись что вызывающая функция дальше владеет объектом и отвечает за его освобождение.
Бывают и сложные ситуации когда реально нужен подсчёт рефов и только при нуле удаление, но я лично стараюсь такого избегать архитектурно.
| | |
| |
| 8.109, мяв (?), 05:16, 31/10/2024 [^] [^^] [^^^] [ответить] | –2 +/– | а не проще, кстати, заменить стандартные функции на свои с механихмом подсчета р... текст свёрнут, показать | | |
|
|
|
|
| 4.49, n00by (ok), 11:08, 30/10/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > "поможет ''free(ptr); ptr=NULL'', но не поможет ''#define Free(ptr) free(ptr);ptr=NULL''"
> ?
> по-моему, Вы пишете, не думая.
В данном частном случае, может быть, поможет.
В общем случае придётся делать что-то вроде
#define Free_S(pptr) free(*pptr);*pptr=NULL
и соответственно в остальных местах работать с лишней косвенностью, что убьёт смысл использовать Си.
| | |
| |
| 5.107, мяв (?), 04:49, 31/10/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
смысл не убьет - компилятор с99 в каждой микроволновке, ибo POSIX.
по-моему, его в основном используют там, где нужна порьабельность.
но вообще, я немного о другом говорила.
вопрос был о том, зачем писать дважды, если можно один раз, в общем случае, не о конкретике.
| | |
| |
| 6.116, n00by (ok), 12:44, 31/10/2024 [^] [^^] [^^^] [ответить]
| +/– |
> смысл не убьет - компилятор с99 в каждой микроволновке, ибo POSIX.
> по-моему, его в основном используют там, где нужна порьабельность.
Например, Vala транслируется в Си. Оно прикручено болтами к GLib (не путать с glibc), но можно открутить, автоматическое управление памятью на подсчёте ссылок останется. Можно ещё что-то транслировать, вплоть до Рефала. Если производительность не играет роли.
> но вообще, я немного о другом говорила.
> вопрос был о том, зачем писать дважды, если можно один раз, в
> общем случае, не о конкретике.
Макросы не очень любят, поскольку подчас всплывают неожиданности. Вот классический пример ошибки из букваря (описано в книге Алена Голуба "Верёвка достаточной длины..."), с которым ничего не могут поделать https://bugzilla.altlinux.org/show_bug.cgi?id=38212#c2 потому что придётся всю GNU C Library выкидывать.
Страуструп даже отдельный препроцессор придумал вместо макросов - CFront.
| | |
| |
| 7.132, мяв (?), 23:53, 31/10/2024 [^] [^^] [^^^] [ответить]
| +/– |
не знаю, что за Рефал, а Vala, во-первых, не ясно, на кукую версию стандарта метит, во-вторых, gnu-расширения использует.
изначально на ней писать хотела
| | |
|
|
| 5.134, мяв (?), 00:11, 01/11/2024 [^] [^^] [^^^] [ответить]
| +/– |
почему, кстати, с лишней косвенностью?
сейчас посмотрела - у меня так и происходило.
'''
void mmeFree(void **point){
if(point==NULL||*point=NULL){...}
free(*point);
*point=NULL;
}
'''
'''
<...>
memFree(&point);
<...>
'''
потом просто на NULL значения проверяете и все
| | |
|
|
|
| 2.75, Ivan_83 (ok), 17:21, 30/10/2024 [^] [^^] [^^^] [ответить]
| –3 +/– | |
Потому что синтаксический сахар вызывает передоз.
Посмотрите на gobject для примера или ещё какой проект где активно юзаеются макросы.
Да даже без макросов многие либы навязывают архитектуру и дизайн приложения.
Когда пишешь на С есть желание оставатся в рамках общепринятого и понятного синтаксиса, а так то конечно легко обернуть каждую функцию в свои функции или макросы а потом получившийся код будет как лапшка на крестах - сплошной местячковый диалект на полтора анонима, притом автор и сам через год не вспомнит что у него была какаянить safe_free() и напишет ещё одну free_safe() в другом файле.
По крайней мере я через это проходил в оба конца, и видел как целые компании пошли по пути написания обёрток и абстракций для всего подряд, получив в итоге вместо кода полное сектанство.
Да, они даже malloc(), free(), str*() и прочее обернули или сами реализовали, и учитывая что я эту шизу проходил это был NIH синдром под лозунгом "зато наш код на любой платформе одинаково плох" :)
| | |
| |
| 3.83, Аноним (84), 18:47, 30/10/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> как лапшка на крестах - сплошной местячковый диалект на полтора анонима
Лол. В крестах с его RAII таких глупых проблем в принципе нет.
| | |
| |
| 4.106, Аноним (-), 00:58, 31/10/2024 [^] [^^] [^^^] [ответить]
| +/– |
>> как лапшка на крестах - сплошной местячковый диалект на полтора анонима
> Лол. В крестах с его RAII таких глупых проблем в принципе нет.
Да уж. Там другие проблемы. В частности - что каждый плюсер хреначит на своем собственном субдиалекте C++. На фоне вон этого, вон то - такие мелочи, право.
| | |
| 4.118, n00by (ok), 13:08, 31/10/2024 [^] [^^] [^^^] [ответить]
| +/– |
Да. Решить все остальные проблемы плюсов можно как Линус Торвальдс: назвать всех плюсовиков нехорошим словом. После дружеского мордобоя работать с теми, кто останется.
| | |
|
| 3.110, мяв (?), 05:24, 31/10/2024 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>Да даже без макросов многие либы навязывают архитектуру и дизайн приложения.
хм.. ну, может это не нравится кому-то, действительно.
хотя, мне кажется, это наоборот хорошо.
>притом автор и сам через год не вспомнит
вот локальность - да, может быть проблемой. но можно ж кратко все функции в .md файлах документировать. тем более, есть удобные инструменты для генерации манов.
через год просто
man MyAPI (видишь раздел "Mem")
man MyAPI.Mem, где для каждой функции расписано, какие коды отлавливать надо, когда паника и т.п.
>они даже malloc(), free(), str*() и прочее обернули
так же сделала. а чем плохо это?
штатные реализации можно отключить:
'''
#define malloc myAPIPanic("malloc() is blocked, use MemAlloc instend!""
'''
,так что ебезопасный вариант не влепишь.
> | | |
| |
| 4.111, мяв (?), 05:27, 31/10/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
случайно "отправить" нажала.
>это был NIH синдром под лозунгом "зато наш код на любой платформе одинаково плох" :)
почему плох обязательно? и почему nih-синдром?
можно ж обернуть некоторые функции и полностью забыть об определенном классе проблем.
заодно и решить проблемы с поддержкой тех же Окон, перенеся все #define'ы в либу и получив на выходе простой, читаемый код.
это ж хорошо наоборот
| | |
| |
| 5.117, n00by (ok), 13:01, 31/10/2024 [^] [^^] [^^^] [ответить]
| +/– |
nih-синдром -- это такая мантра, что бы люди разучились кодить. Этим синдромом "больны" все влиятельные корпорации: Микрософт, Гугл, даже GNU и то -- is Not UNIX. :)
| | |
|
| 4.127, Аноним (33), 17:10, 31/10/2024 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Блин, скажи честно - ты дура?
> #define malloc myAPIPanic("malloc() is blocked, use MemAlloc instend!""
Во-первых, тут закрывающейся скобки нет. Во-вторых непарное количество кавычек.
В-третьих, ты хоть посмотри через gcc -E во что это твоё чудо сгенерируется, если использовать нормальный вызов malloc вместо твоих корявых костылей.
В четвертых, man LD_PRELOAD
| | |
| |
| 5.131, мяв (?), 23:47, 31/10/2024 [^] [^^] [^^^] [ответить]
| +/– | |
скажу честно - разоблачитель опечаток правила формуа нарушает.
>LD_PRELOAD
сейчас бы конструкции препроцессора загружать.
>посмотри
ни во что.
потому что макрос паники использует fprintf, возвращающий int.
а malloc - void*, о чем будет написано во время компиляции.
| | |
| |
| 6.135, Аноним (33), 01:13, 01/11/2024 [^] [^^] [^^^] [ответить]
| +/– |
> ни во что.
> потому что макрос паники использует 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);
Это блин ваще чё такое?
| | |
|
|
|
|
| 2.100, Аноним (-), 23:08, 30/10/2024 [^] [^^] [^^^] [ответить] | +/– | gt оверквотинг удален Фига у некоторых понятия о улучшении читаемости Теперь ... большой текст свёрнут, показать | | |
| |
| 3.112, мяв (?), 05:34, 31/10/2024 [^] [^^] [^^^] [ответить]
| +/– | |
>Ибо изначально имплементация не очевидна
так это ж плюс, нет?
вместо того, что б голову себе морочить реализаций - понятный
ContextBegin().
или MacroSaveContext() и MacroEndSaveContext(), условно.
>Что для системного яп - такая себе радость.
почему? вон, в C#, java и тд построение абстракций и скрытие реализации - это вообще поощряемое дело. что и правильно, как мне кажется. зачем это в голове держать, опять же? тем более, что многие редакторы позволяют по 1й кнопке прыгнуть к реализации.
| | |
| |
| 4.129, Аноним (129), 17:32, 31/10/2024 [^] [^^] [^^^] [ответить] | +1 +/– | Вон то это стандартный паттерн для сишников В отличие от делающего фиг зн... большой текст свёрнут, показать | | |
|
|
|
| 1.30, Аноним (29), 07:52, 30/10/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
"системах, в которых X-сервер выполняется с правами root, а также для удалённого выполнения кода в конфигурациях, в которых для доступа используется перенаправление сеанса X11 при помощи SSH. "
иными словами ни в одном адекватно настроенном дистрибутиве проблемы нет.
| | |
| |
| 2.32, Аноним (31), 08:15, 30/10/2024 [^] [^^] [^^^] [ответить]
| +/– |
Прокинуть X11 через SSH - это, всего-лишь, пожелание пользователя, независимо от дистрибутива.
| | |
|
|
