Техника безопасности при работе с памятью в Си
ฝัง
- เผยแพร่เมื่อ 5 ก.ย. 2024
- Ошибки работы с памятью в Си: Segmentation fault, Memory leak.
Инициализация указателей: NULL.
Проверка корректности адреса.
Ответственность за освобождение памяти.
Курс молодого бойца по информатике (Язык Си).
cs.mipt.ru/c_intro
![[กูเพิ่งซื้อมึงปิดหนี] 20 นาที ผมรีวิวเกมที่แย่ที่สุดในโลก CONCORD](http://i.ytimg.com/vi/XhC-3q3Ii7I/mqdefault.jpg)
Благодарю за лекцию + с уважением!
Спасибо! за столь огромный труд!
После использования функций gets() или указателя без инициализации или массива на стеке, или гарантия доступа за границы массива (*(name - 1) и *(name+sizeof(name)+1). ) программирование на языки Си это нервный тик при объявлении объектов памяти.
шаг -> расстрел.
спасибо за курс!
Большое спасибо за ваши лекции!
Это дар, рассказать интересно и понятно, профессионально и запоминаемо.
Полезная и довольно редкая информация! Спасибо!
Мне 12 лет, я хочу научится работать с памятью в Си, вот, ищу Инфу. Наткнулся на этот канал, надо учитывать что здесь я и научился языку Си
Тоже самое!!!
@@StepanChuevYT а тебе сколько лет?
@@_klim4204 13
Огромное спасибо, Тимофей Федорович! Я прошел этот курс.
Я люблю Си. В том числе, за большие проблемы при работе с памятью. Потому что -- кому проблемы, а кому -- фишечки.
Фишечки тому, для кого проггерство - игрушечки. Для тех же, кто пишет оборонное, медицинское и космическое ПО - это ПРОБЛЕМЫ.
@@garrygaller2853 какие далеко идущие выводы из ни}{✓я, однако! Больше 50 процентов действующего медицинского и, особенно, военного ПО, написано во времена, когда и Си считался слишком высокоуровневым для таких задач. И люди, пишущие подобное ПО, скорей всего пошлют вас лесом, если вы начнёте втирать им эту дичь про проблемы языка. Это все равно, что столяру вы начнёте рассказывать, какие ужасные проблемы у вот этого молотка или вот этой циркулярной пилы! Она ведь очень опасна -- можно и руку себе отрезать! Все эти современные тенденции создания языков, которые пытаются обезопасить идиота от его собственного мозга, родились из-за бума электронной и IT индустрии, в результате которого программистом быть стало тупо модно, и в программисты повалили все, кому не лень. Люди на своем-то родном языке, зачастую, мысли выражать не умеют, а лезут на ЯП выражаться и ещё других потом учить начинают.
Особенно интересно хакерам, когда происходит переполнение буфера или проблемы с памятью)))
@@user-cu9wl3dn5j Выделил память -- отдай обратно. Следи за границами. Я понимаю, что сейчас уже в микроконтроллеры джава-машину суют, но тогда, может, будем на велосипед ставить турбовентиляторный двигатель, полный комплект средств безопасности, двух пилотов (ну ладно, одного)... А потом получаем программистов, которые за деньги пишут код, но не могут даже в битовые операции -- тупо не знают, как это. (Это вот прям совсем не шутка и не преувеличение) Потому что низззяяяя! Вдруг чего-нибудь не так там сделаешь! Когда я учился, так же пугали ассемблером. Мол, там же можно прям в регистры процессора писать и память портить, как вздумается. А еще, о УЖАС!, там нужно руками контекст в стеке сохранять -- это ж сколько напартачить можно!
@@Ma_X64" И люди, пишущие подобное ПО, скорей всего пошлют вас лесом" Далеко идущее заявление. Потому что среди специалистов как раз таки есть понимание всех проблем языка и необходимости их исправлять. Так что скорей пошлют тебя, горе-оптимиста. Все остальное в твоем посте - бессмысленная дичь. Новые языки создаются потому что таково требование времени и этого нельзя избежать.
В плейлисте курса не хватает видео Переменные в языке С
спасибо большое за ваши видео
Тимофей Федорович наше все!
Garbage collector жрет много ресурсов и эффективность у него не стопроцентная, всегда будет утечка, лучше один раз написать правильно на С, чем всё время коллектору анализировать код и память. Поэтому С форевер.
Воистину!
@@Ma_X64 C will never die
Лучше совмещать приятное с полезным и писать только некоторые части программ на языках типа C, а остальные - хоть на python.
Спасибо!
Вот как раз думал повторить СИ. Как раз с памятью что там. Начал с этого вопроса. И как то идея повторить СИ.
Раньше мне как-то ума не хватало на программирование. То есть прошел курс, понял. Но как то сверхсложным все казалось. Так что вот теперь надо еще раз. Кстати может повторить прямо. По урокам, думаю. Это СИ. Раньше, я его 1 раз быстро минимум какой то прошел и сразу на СИ++. Трудно, страшно. Поэтому и рад был что с СИ там за уроков 7 что ли... Быстро разделался то же по видел тогда учил. Но тогда - это первый раз. Без всякой специальной подготовки. Поэтому конечно, это был АД для меня. Мой МОЗГ не был готов к такому. Но усвоить и пройти удалось.
Думаю теперь еще раз! Повторить все.
Для начала следует повторить русский язык
здравствуйте Тимофей! Благодарю вас за чудесный курс (стдент МГТУ). Появился вопрос про ситуацию на 12ой минуте видео. Если в цикле перевыделять память одной и той же переменной, то как ее потом освободить?
Я считал, что в таком случае результат будет такой же, как у функции реаллок и у указателя будет меняться размер принадлежащего ему пространства памяти, и использование одного free будет достаточно.
Дело в том, что неважно, в какую переменную кладется результат malloc() - каждый раз выделяется новый блок памяти, и переменная "p" перезаписывается, чтобы указывать на этот новый блок. Таким образом, по завершении цикла "p" указывает на последний выделенный блок, а все блоки, выделенные до этого - потеряны - указателей на них нет.
А какие варианты есть у strdup кроме как сделать аллокацию?
Использовать alloca? В общем не понял проблему
У первой лекции в 11 раз больше просмотров )
Хороший пример ТЕЛЕГРАММ. течет на всех системах )))))
100мб в ОЗУ - не утечка, поставьте пожалуйста хотя бы 4гб озу
может он течёт из-за QT ?
Очень странно... числа Вы сравниваете с 0, хотя с ними разночтений не бывает. А вот указатели лучше таки сравнивать с константой NULL - может быть в некоторых компиляторах не совсем ожидаемая реакция на попытку неявного преобразования...
Александр, не понял вашего замечания. Уточните, пожалуйста, с меткой времени.
6:54 - Вы убиваете сравнение с NULL. При этом в других роликах сравниваете числа с нулем.
Это не замечание, а скорее удивление. Поведение преобразование чисел к булевым однозначно: не ноль = тру, ноль = фолс
Кажется, Страуструп писал о том, что поведение неявного преобразования указателей к булевому не столь однозначно... но может это на каком-нить семинаре мейл.ру или яндекса звучало... точно не скажу.
ЗЫ я сам тоже в учебных примерах не сравниваю с NULL... исключительно из соображений "красоты" :))
@@tkhirianov у вас нет ли дальнейших курсов? может платных, чтоб получить знания, достаточные для работы программистом без официального диплома?
@@istra3265 NULL это макрос #define NULL ((void*)0), вобщем всегда 0
@@shurakm Замечание вполне дельное, поскольку нужно изначально формировать правильный подход, код должен быть осмысленным и единообразным, а не просто работать, тогда это не только облегчит его чтение, понимание и отладку, но и не приведёт к непредсказуемым ошибкам при переносе на другую платформу или другой язык, где NULL вполне может быть, скажем, -1.
То есть нужно "NULL" воспринимать не как "0", а как значение переменной по умолчанию, иначе вообще забыть про "NULL" и везде писать "0", но большое количество "магических чисел" в коде может угнетать и резко снизить его понятность спустя годы.
😍
А stack overflow, buffer overflow Вы не относите к проблемам работы с памятью? Ведь большинство уязвимостей строится именно на этих ошибках. Странно, что тут ничего об этом не сказано
как бы это очевидные вещи и можно сравнить с ситуацией записи лонгового числа в интовую переменную
ваши примеры были рассмотрены в видео "переполнение и ошибки при работе с целыми типами"
так, ачто дальше, я могу работать?
и где следующее видео? 🧐
1000й )))