LINUX.ORG.RU

В стандарт C предложено внести лямбды и defer из golang

 , ,


5

6

Привет, ЛОР!

Я тут тебе немного покушать принёс. Как ты, наверное знаешь, не за горами выход нового стандарта языка C – C23. Среди прочих вкусностей, таких как лямбды в стиле C++, в этот стандарт предложено добавить механизм defer, аналогичный существующему в языке Go.

Ссылка на предложение: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2895.htm

В случае, если этот стандарт будет принят, будет возможно написание вот такого кода:

p = malloc(N);
defer { free(p); }

Где аргументом оператора defer является анонимная функция. Так же возможны более сложные варианты использования:

enum { initial = 16, };
double buffer[initial] = { 0 };
...
size_t elements = 0;
double* q = buffer;
defer [orig = q, &q]{ if (orig != q) { free(q); }};
...
// increase elements somehow
...
// adjust the buffer
if (elements > initial) {
    double* pp = (q == buffer) ? malloc(sizeof(double[elements])) : realloc(q, sizeof(double[elements]));
    if (!pp) return EXIT_FAILURE;
    q = pp;
}
...

Учитывая всё это, скоро в C больше не будет нужно использовать goto вообще нигде, даже для очистки ресурсов при ошибке. Так заживём, ЛОР!

Now consider the code:

 int *p, *q;
    p = malloc (sizeof (int)); assert (p != NULL);
    (free)(p);
    q = malloc (sizeof (int)); assert (q != NULL);
    if (memcmp (&p, &q, sizeof p) == 0)
    {
        // Assume this point is reached     
        *p = 42;  // Line A 

Is the assignment valid (because an assignment using *q would have been, and the two variables hold identical values) ? Or is it invalid because the last-stored value of p is now indeterminate (because of the free) ?

The implementation is entitled to take account of the provenance of a pointer value when determining what actions are and are not defined. Thus the assignments on lines A and C involve undefined behaviour.

что они, женщина пониженной социальной ответственности, такое несут? кто им сказал что free - освобождает память. может быть я свой аллокатор написал. понабрали трангендеров по объявлениям в гейбарах и долбятся теперь.

неудивительно, что после этого компиляторы ересь несут.

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

ошибки в строках постоянно и у всех.

Это ложное утверждение. Бывают - возможно и у всех, но у кого-то действительно постоянно, а у кого-то очень редко. Да, баги случаются. Не надо делать из этого далеко идущие выводы. И это однозначно не повод урезать возможности языка.

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

а если я назову free furri например? а если у меня в ведре kfree какое-нибудь. а если я этот указатель использовал как ключ в какой нибудь мапе? с чего эти лоботрясы решили что функция с называнием из 4х букв начинающаяся на f и кончающаяся на ree делает мои указатели неправильными?

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

Там речь шла про выход за границы массива с обращением к памяти, куда нельзя было обращаться. В php такое невозможно. В целом проверки конечно нужны.

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

Ты меня с кем-то путаешь, я нигде не писал что проверки не нужны. Я отвечал тому, кто как раз не смог их осилить и предлагал ему в этой связи пользоваться нубоязыком.

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

Проблема C – это то, что этот язык стал популярным не потому что он в чём-то хорош. Совсем нет. C стал популярен, потому что его продвинул гугл того времени – AT&T – используя его в своей популярной ОС, на которую все подсели. Плюс, из-за того, что в начале 80х этот самый AT&T антимонопольщики люто долбили во все возможные и невозможные отверстия, у AT&T не было возможности и ресурсов закопирайтить C (и UNIX) по самые гланды, как это случилось с поцкалём, в результате чего расплодилось множество зачастую совсем несовместимых реализаций. Первый стандарт пытался это всё прибрать, но получилось так себе, потому что в него вошли по сути только общие вещи из разных реализаций.

А дальше UNIX просто сдох, кроме пары клонов (типа Linux и XNU) и форков (BSD), которые ныне к UNIX отношения практически не имеют, кроме разве что базовых функций.

Другая проблема C – это культ хацкерства вокруг него. Вместо того, чтобы развивать и улучшать инструмент, культисты C яростно наяривают на его топорность. Любой баг языка – это божественное откровение, записанное мудрецами на скрижалях. То, что все четыре популярных компилятора C (msvc, clang, gcc, icc) давно перевалили за миллион строк кода и написаны совсем не на C, вообще никак не мешает им кричать о простоте этого языка.

C – это такой АвтоВАЗ позднего совка от языков программирования, который лишний раз доказывает, что через силу чистого аутизма и яростное гнобление любой альтернативы что угодно можно заставить ехать. Но только ВНЕЗАПНО могут отвалиться колёса на трассе, но это вроде как документированная возможность, и вообще водитель сам виноват, надо было на автобусе ехать.

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

пардон, тред читал снизу вверх, не так распарсил

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

Си — говно. Но ничего лучше нету.

Для говноедства лучше говна ничего нет. Спорить не буду. А вот язык для системного программирования выбрать таки есть из чего. Одна только Ada уже 40 лет существует.

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

Ну да, поэтому если на верхнем уровне объявлен, то по выходу из функции. А если внутри if-а объявлен, то по выходу из if-а.

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

Я понял. Я и говорю что в C по-хорошему это тоже всё должно быть. Т.е. каждый указатель помимо адреса памяти ещё должен нести длину региона. И каждое обращение по этому указателю должно проверять, не выходит ли за пределы это обращение. Если, конечно, компилятор не может доказать, что проверка не нужна. То же с прочими ошибками вроде двойных delete и тд, везде можно найти способы убрать эти ошибки, пусть и за счёт небольшого проседания производительности. Сейчас компьютеры быстрые, пускай работают.

Ну хотя бы по умолчанию пускай так будет. Если в каком-то конкретном месте нужна экстра-скорость, пускай там объявляют unsafe или что-то подобное.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Ну у Си-шки ещё к плюсам можно отнести, что даже несмотря на усложнения новых стандартов, в сущности, он простой, как валенок. Расплачиваться за это, ест-но приходится тем, что все сложности приходится реализовывать самому, своими руками. Ну или искать кто это реализовал до тебя и не накрошил-ли там ошибок (вот с этим тоже проблема). Ada, в сравнении с Си-шкой, в этом плане - адский звиздец.

А про жирность, ну tcc тоже есть. Работает, вроде как, даже почти весь C99 (и даже екоторые GNU). Хотя оптимизаций и всех «крутых» фишек новых стандартов не предполагается.

SkyMaverick ★★★★★
()
Последнее исправление: SkyMaverick (всего исправлений: 1)
Ответ на: комментарий от SkyMaverick

Ну у Си-шки ещё к плюсам можно отнести, что даже несмотря на усложнения новых стандартов, в сущности, он простой, как валенок.

Тогда почему компиляторы такие жирные? Чтобы запилить простой язык, не нужен миллион строк кода. Даже полмиллиона не нужно.

Тут проблема в том, что C гораздо сложнее чем кажется. Дьявол, как всегда, кроется в мелочах. Там анон выше про «pointer provenance» написал. Что это такое? В стандарте не очень описано. Как эту проверку правильно реализовать? А хер знает. И такой лажи там очень много.

Запилить компилятор минимального подмножества C – задача, максимум, курсовой работы третьего курса для программистов. Особенно если это можно не на самом C делать. Запилить компилятор стандарта C18, даже без опциональных фич, да так чтобы он был совместим с GCC и шлангом – это как самому себе жопу на британский флаг порвать.

Если хочешь посмотреть на реально простые в реализации языки, смотри на Forth или Scheme. Вот они – действительно простые. Без шуток. Реализацию Forth, способную саму себя скомпилировать, можно за неделю-две написать.

hateyoufeel ★★★★★
() автор топика
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от Legioner

Эм, нет. Подменять смысл имеющегося синтаксиса - однозначно неприемлемо, так же как и пытаться навязать программисту какие-то проверки по дефолту. Если программист решит что нужна проверка - он её сделает. Можешь сделать для упрощения этого библиотеку или ввести в своём диалекте языка специальный тип указателя с размером (как раньше были разные NEAR/FAR указатели). Молча вставить его вместо обычных указателей однозначно нельзя, потому что есть штуки вида (void*)12345 (это самое простое, есть и намного сложнее), в которых никакие размеры не предусмотрены.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Тогда почему компиляторы такие жирные?

Потому что помимо, собственно, компилляции там ещё примерно 100500 задач, которые должен выполнить компилятор. Не даром они называются «оптимизирующие компилляторы». Там только НИОКР-ов не одна сотня, не говоря уже про реализации.

Плюсом, в новых стандартах, рантайм сильно вырос. В стадарт вошли треды/атомики/<куча остального>.

И самое главное - это давно уже компиляторы С++, а не С, со всеми вытекающими.

смотри на Forth или Scheme

Forth машину сделать проще некуда. Понять Forth и написать на нём что-то, что хотя-бы практически можно использовать - задача не для всякого выпускника техникума.

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

И да, в догонку к предыдущему сообщению. Я тут одно время с нтересом читал лог UniLink (линкер есть такой хороший от Юрия Харона).

Посколько Юрий пишет его очень тщательно, это такой шикарный лог ошибок компиляторов, что просто любо дорого читать (и офигевать, как ЭТО вообще работало). Особенно, кстати, насколько я помню, его убивала Борляндия/Эмбаркадеро, потому что судя по описаниям, компилятор там - полное говно (что Си, что Дельфий).

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

Не даром они называются «оптимизирующие компилляторы». Там только НИОКР-ов не одна сотня, не говоря уже про реализации.

В этом другая проблема C. Чтобы сделать его быстрым, требуется запилить немереное число мозгоразрывающих оптимизаций. Возьми классический пример с циклом:

int sum(int *arr, size_t n)
{
    int s = 0;
    for(size_t i = 0; i < n; i++)
      s += arr[i];
    return s;
}

Одна из классических оптимизаций – это loop unroll. А теперь вопрос: как ты докажешь, что операции внутри цикла не влияют друг на друга? Потому что это необходимое условие, и loop unroll, возможность применения которой в данном случае довольно очевидна, может сломать более сложный код. И вот такой эвристики в компиляторах до жопы. Но она была бы совсем не нужна, если бы в C, например, были полноценные массивы.

Т.е. получается такой парадокс, что оптимизирующий компилятор легче писать для более «сложного» языка и сложнее для более «топорного».

Понять Forth и написать на нём что-то, что хотя-бы практически можно использовать - задача не для всякого выпускника техникума.

Да не скажи. Я в универе на форте писал ради развлечения и вполне ок всё было. Мне даже 20 тогда не было ещё.

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

Всё так, и добавлю: если посмотреть историю развития си, то видно что направления развития у него нет.

K&R - портабельный макроассемблер.

C89 - Появилась абстрактная машина, UB, прикрученные к системе типов сбоку cv-квалификаторы, проверяемые сигнатуры функций (спасибо Страусу, а то сишники и сегодня бы доказывали что это для пхп-шников). Уже нифига не ассемлер, но 95% этого так и не заметили.

C99 - VLA (идет нафиг фиксированный стэкфрейм), strict aliasing (идет нафиг обратная совместимость, очевидность и любимые best practices).

C11 - многопоточная модель памяти (когда она уже давно никому не интересна), _Generic (от людей, всю жизнь ругавших перегрузку за неочевидность). VLA, оказывается, уже не очень нужны. Вау, gets тоже, не прошло и 20 лет.

… C23 - куча пропозалов на плюсовые фичи, из которых, вангую, не будет принято почти ничего (напомню, эти люди отбросили typeof по причине «ненужно»). Сишники продолжают восхищаться «портабельным ассемблером» и «очевидным поведением».

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

не прошло и 20 лет

Черт, а ведь прошло.

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

Ты C18 пропустил.

Моё любимое чтиво – это defect reports для стандартов C. Это почти что ЛОР, только без анонимусов.

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

Чтобы сделать его быстрым, требуется запилить немереное число мозгоразрывающих оптимизаций

Так, в общем-то, для всех справедливо. Просто все новые компиляторы пишуться поверх LLVM, который делает тотже , например, loop unroll только на уровне IR. Поэтому оно и получается внешне бесплатно.

Там же ещё куча всякого специфичного. Тоже PGO/LTO. Там вообще тема бездонная, но это все в компиляторах, что тоже, мягко говоря, не способствует их похудению.

Т.е. получается такой парадокс, что оптимизирующий компилятор легче писать для более «сложного» языка и сложнее для более «топорного».

Ну так и имеем классическую теорему «о двух стульях» для универсальных языков. Или простой язык, но сложный компиллятор, либо сложный и с кучей условностей язык, но более простой и резвый компилятор.

ЗЫ. К С++ это не относится, т.к. туда, видимо, решили впихнуть вообще всё и там и об язык мозг сломаешь, и то, что получается в его AST в результате всех этих перегрузок и Александреску-style извратов с шаблонами, никакой Ктулху не раберёт.

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

Ты C18 пропустил

Да, его уже не видел. Разупоролся и перешел на вменяемые языки.

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

Так, в общем-то, для всех справедливо.

Да вообще нет. Если у тебя есть массивы как тип, то независимость итераций доказывать не нужно. Можно просто сделать функцию sum(), которая будет экспортироваться и реализовываться как надо везде.

Просто C программисты из подкорки мозга копипастят этот цикл for() повсюду. Вон как выше наш товарищ оправдывал отсутствие строк тем, что дескать никому это не нужно. Так и выходит: куча кода и 95% из него – полный ад.

Или простой язык, но сложный компиллятор, либо сложный и с кучей условностей язык, но более простой и резвый компилятор.

Тут опять же штука в том, что C – это не простой язык. Все эти strict aliasing и прочие извращения добавляют довольно много сложности.

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

что они, женщина пониженной социальной ответственности, такое несут?

Идиоты какие-то, и правда. Придумывают какие-то абстракции, которые в твою микроцефальную голову не влезают. Почему им никто не объяснит про то, что указатели это информационные числа?

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

информационные числа

стало быть есть еще и дезинформационные числа, и даже числа, лишенные какой-либо информации.

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

Эм, нет. Подменять смысл имеющегося синтаксиса - однозначно неприемлемо, так же как и пытаться навязать программисту какие-то проверки по дефолту.

Не понимаю, о чём ты. Всё вышеперечисленное и так является неопределённым поведением. Я предлагаю его заменить на определённое - аварийное завершение программы.

Если программист решит что нужна проверка - он её сделает.

Программист тупой, ему доверия нет.

Молча вставить его вместо обычных указателей однозначно нельзя, потому что есть штуки вида (void*)12345 (это самое простое, есть и намного сложнее), в которых никакие размеры не предусмотрены.

И что по-твоему должен означать код (void*)12345? Не очень понимаю твоего аргумента. При попытке скастовать 12345 в (void*) можно сразу смело завершать программу.

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

И что по-твоему должен означать код (void*)12345? Не очень понимаю твоего аргумента. При попытке скастовать 12345 в (void*) можно сразу смело завершать программу.

ничего подобного. может это порт устройства, отображенный на память? для железа, фиксированные адреса, это вполне рядовое, и даже очень распространенное явление.

ps если ты не позволишь иметь фиксированные адреса в железе, тебя железячники задушат в темном углу.

pss. также, если тебе надо писать на железке тесты физических адресов памяти, тебе надо иметь возможность задавать их произвольно.

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 2)
Ответ на: комментарий от Legioner

При попытке скастовать 12345 в (void*) можно сразу смело завершать программу.

А как тогда писать программы под железо, где по адресу 12345 находятся регистры MMIO какого-нибудь устройства?

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

не потому что он в чём-то хорош

Только с тех пор ничего лучшего для своей ниши для придумали, вот непотребство-то!

А дальше UNIX просто сдох, кроме пары клонов (типа Linux и XNU) и форков (BSD), которые ныне к UNIX отношения практически не имеют, кроме разве что базовых функций

У тебя извращенное понятие UNIX. Его реинкарнация в виде попыток стандартизации (POSIX) и есть продолжение жизни UNIX, но в современном мире.

Другая проблема C – это культ хацкерства вокруг него. Вместо того, чтобы развивать и улучшать инструмент, культисты C яростно наяривают на его топорность

«хацкеры» из 90-х действительно портят впечатление от сообщества, да и еще и пишут максимально криво. Однако современная хипстота ничем не лучше. У них почему-то в голове всегда что-то нужно улучшать и дорабатывать, в голове у них просто не может уложиться понятие, что что-то может быть просто _ГОТОВО_. Помню, даже на ЛОР-е возникают периодично треды типа «ой а есть что-то посвежее вот этого PROJECTNAME? А то там коммитов уже полгода нет!» от всяких хипстоклоунов, которым лишь бы раз в день коммит кидать в репу.

То, что все четыре популярных компилятора C (msvc, clang, gcc, icc) давно перевалили за миллион строк кода и написаны совсем не на C, вообще никак не мешает им кричать о простоте этого языка

То-то я гляжу плюсы простые как дерево - за полгода явно осилить реально! Да и аналог tcc с таким же количеством SLOC для плюсов написать вообще не проблема, да?

Но только ВНЕЗАПНО могут отвалиться колёса на трассе, но это вроде как документированная возможность, и вообще водитель сам виноват, надо было на автобусе ехать

Я понял. Ты просто не осилил и у тебя травма. Прости за это. Знаю что я не виноват в этом, но пусть хоть кто-то тебе скажет это. Мне очень жаль тебя.

reprimand ★★★★★
()

По теме:

Предложение как по мне хреноватенькое, его надо либо убрать либо доработать. Пока сам не знаю как, но выглядит это пока что странно.

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

А как тогда писать программы под железо, где по адресу 12345 находятся регистры MMIO какого-нибудь устройства?

Можно задекларировать extern переменную, которую задать с помощью линкера.

extern void* utxbuf0; 

https://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_chapter/ld_2.html

--defsym utxbuf0=12345
fsb4000 ★★★★★
()
Ответ на: комментарий от alysnix

ничего подобного. может это порт устройства, отображенный на память? для железа, фиксированные адреса, это вполне рядовое, и даже очень распространенное явление.

Тогда пиши через всякие компиляторо-специфичные словечки.

ps если ты не позволишь иметь фиксированные адреса в железе, тебя железячники задушат в темном углу.

Можешь идти и душить разработчиков стандарта прямо сейчас, т.к. обращение по памяти какого-то захардкоденного адреса это implementation defined behaviour уже очень много лет.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от anonymous

Всё так, и добавлю: если посмотреть историю развития си, то видно что направления развития у него нет

Все потому что комитет стандартизации вообще не интересуется у тех кто реально пишет софт

Появилась абстрактная машина

Объясни

UB

Он и до этого был

прикрученные к системе типов сбоку cv-квалификаторы

А какие есть альтернативы?
Вообще, лучше бы они сразу убрали стандартную систему типов и использовали ту, которая оглашена в stdint.h

VLA

Просто попытка стандартизировать alloca. Не скажу что удачная, лучше бы они просто молча стандартизировали alloca, либо хотя-бы убрали требование что sizeof должен возвращать правильный размер на такие объекты

strict aliasing

А вот тут согласен, могли бы совсем иначе его запилить

многопоточная модель памяти

Объясни детальнее что ты имеешь ввиду

VLA, оказывается, уже не очень нужны

Ну да, потому что они его неудачно реализовали

Вау, gets тоже, не прошло и 20 лет

А есть кто-то кто реально будет использовать gets?

портабельным ассемблером

А есть что-то лучше? Только не надо про Rust плз

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

А как тогда писать программы под железо, где по адресу 12345 находятся регистры MMIO какого-нибудь устройства?

Через какой-нибудь #define WRITE_BYTE(addr, value) __gcc_builtin_write_byte(addr, value)

А ещё лучше так:

uint8_t *device = __gcc_builtin_get_pointer(0x12345, 0x10)

И дальше компилятор будет вставлять проверки, что ты обращаешься по адресам от 0x12345 до 0x12355, и не дальше. А при попытке записать device[0x10] = 0 программа упадёт а не пойдёт писать куда не положено.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от reprimand

Только с тех пор ничего лучшего для своей ниши для придумали, вот непотребство-то!

Для ниши наполнения CVE дырами действительно лучше ничего не придумали.

У тебя извращенное понятие UNIX. Его реинкарнация в виде попыток стандартизации (POSIX) и есть продолжение жизни UNIX, но в современном мире.

Учитывая, какой жирный болт на POSIX кладут все заинтересованные (привет, Поттеринг!), ты внезапно прямо в точку попал.

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

Программист тупой, ему доверия нет

Согласен, я бы вообще этот тред начинал с этих слов.

И что по-твоему должен означать код (void*)12345?

Что нам нужен указатель, который указывает на неизвестный тип, и у этого указателя адрес 12345

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

Можно задекларировать extern переменную, которую задать с помощью линкера.

то есть просто записать адрес ручками в поинтер - это некруто, а через линкер - круто.. это вообще будет одна и та же физически команда проца. положить число в регистр.

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

Для ниши наполнения CVE дырами действительно лучше ничего не придумали

Проблемы людей. Что-то жабка не очень помогла от log4j.

Учитывая, какой жирный болт на POSIX кладут все заинтересованные (привет, Поттеринг!), ты внезапно прямо в точку попал

Снова проблемы людей. Поцтеринг просто пытается занять ту нишу, которая не была описана в POSIX. А не была она описана, потому что не было требования решать несуществующие проблемы.

На самом деле, если бы Линус на заре Линукса созвал бы заинтересованных лиц и предложил бы разработать нормальный способ описать то, как должна быть устроена ОС в той её части, которая уже не ядро, то поцтеринг так бы и остался королём пшш-пшш звука в мире Линукс.

По аналогии - запилил бы Дуров в своё время СРАЗУ аудиозвонки в телеге - вайбер бы не взлетел

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

Rust изобрели без меня. Мне хочется, чтобы в программах на С не было глупых уязвимостей, которые делаются во имя того, чтобы код работал на 1% быстрей, причём в тех местах, где этот 1% быстрей на конечный результат чаще всего никакого влияния не оказывает. И в целом, имхо, это вполне возможно - сделать safe C в рамках текущего C. Вот если бы это сделали 30 лет назад, сегодня все эти затраты на проверки границ просто не ощущались бы, т.к. всё было бы оптимизировано на уровне процессоров. Существующие программы на C переписывать на Rust будут очень долго, а многие вряд ли вообще перепишут.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от Legioner

Диванные железячники подтянулись.

Программа упадет

Программе может быть некуда падать.

а не пойдёт писать куда не положено.

А если писать можно (и нужно) по любому адресу?

компилятор будет вставлять проверки

Может программист все-таки сам решит, где ему надо вставлять проверки, а где не надо?

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

Что нам нужен указатель, который указывает на неизвестный тип, и у этого указателя адрес 12345

А по стандарту C этот код значит «хз че это такое читай мануал к своему компилятору, а если хочешь переносимый код, то вообще не пиши так».

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

Через какой-нибудь #define WRITE_BYTE(addr, value) __gcc_builtin_write_byte(addr, value)

Ну то есть если у меня по тому адресу структура данных а не просто байт, то «привет» велосипеды с for, о которых писал уважаемый hateyoufeel

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

Проблемы людей. Что-то жабка не очень помогла от log4j.

Тем не менее, 70% CVE – это ошибки работы с памятью. Такие дела.

Снова проблемы людей.

Так других программистов у нас, к сожалению, нет. А вот нормальные языки без таких тупых проблем сделать – это вполне реально.

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

Да пофиг, это уже всё на уровне компиляторо-специфичных конструкций разруливается, хоть байты, хоть структуры. Суть в том, что в C такой конструкции нет и быть не может, пиши компиляторо-зависимый код. И твой (void)12345 ничем не отличается от __gcc_builtin_blabla, такой же компиляторо-зависимый код, только внешне выглядит безобидно.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.