[/b/] [/d/] [/tu/] [/a/] [/ph/] [/wa/] [/cg/] [/t/] [/p/]

[Burichan] [Foliant] [Futaba] [Greenhell] [Gurochan] [Photon] - [Home] [Manage] [Archive]

[Return]
Posting mode: Reply
Leave these fields empty (spam trap):
Name
Link
Subject
Comment
File
Verification
Password (for post and file deletion)
  • Supported file types are: GIF, JPG, PDF, PNG
  • Maximum file size allowed is 20480 KB.
  • Images greater than 200x200 pixels will be thumbnailed.

File: 1607594481923.jpg -(78494 B, 341x500) Thumbnail displayed, click image for full size.
78494 No.183736  

Как быстро вкатиться в сишку до уровня модификации чужих кодов? Есть некоторые проекты на гитхабе, которые я хотел бы исправить как считаю нужным. Но я очень плохо знаю Си, в основном пишу на golang'е да питоне. Времени не очень много, хотелось бы чуть не завтра уже присылать пулреквесты.

>> No.183740  

>>183736
https://ru.wikibooks.org/wiki/Язык_Си_в_примерах
Си вообще простой для понимания язык, если умеешь программировать. Но программировать на нем сложно из-за того что можно ненароком отстрелить себе ногу указателем.

>> No.183834  

>>183736

>Как быстро вкатиться в сишку до уровня модификации чужих кодов?

K&R2

http://iso-9899.info/wiki/Books

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

Можешь устать потом свой форк поддерживать

>Времени не очень много, хотелось бы чуть не завтра уже присылать пулреквесты.

Об этом сложно говорить оптимистично

>>183740

http://iso-9899.info/wiki/Main_Page#Stuff_that_should_be_avoided
Wikibooks говно чаще всего

>> No.187689  
File: 1615484410504.pdf -(5648293 B, 0x0) Thumbnail displayed, click image for full size.
5648293

Автор книги Robert C. Seacord

>is on the Advisory Board for the Linux Foundation and an expert on the ISO/IEC JTC1/SC22/WG14 international standardization working group for the C programming language. http://robertseacord.com/wp/
>> No.187691  

Если кто-то найдёт шапку с арисучана то можно будет сделать полноценный Си тред.

>> No.187693  

https://www.youtube.com/watch?v=3JTwA5IOq7I

>> No.187701  
File: 1615487921991.jpg -(269629 B, 1191x670) Thumbnail displayed, click image for full size.
269629

>>187692
А что там с памятью такого сложного, что нельзя изучить за вечер? От регистров сишечка абстрагирует, понять, как работают указатели и в чём разница между memcpy и memmove много времени не надо. Сишечка как раз предельно проста в плане теории (в отличии плюсов) и основное время обучения занимают алгоритмы, структуры данных и общая культура написания кода.

>> No.187702  

>>187701
Покажи мне свой код на C /я смотрю мне тут не рады :)

>> No.187703  

>>187694
Я кажется знаю почему удалили. Я хотел на твой пост ответить, но не твой вопрос. Потому что вопрос идиотский. Нет, не потому что ответ очевиден, это как раз было бы простительно, проблема в том, что твой вопрос не снабжён никакими сведениями, которые помогли бы дать ответ. А ведь как известно половина ответа, это хорошо заданный вопрос.

>>187692

>Чтобы грамотно писать на C, нужно чоткое представление как работает память. Этому не учат в школе

Может, чтобы грамотно, однако для первых глав Кернигана и Ритчи хватит простого понимания отличия стека от кучи, точнее того как с ними работать. А дальше дело наживное. Справедливо было бы также добавить, что и на первых курсах университетов, такому также не учат. Зато есть охрененные таблицы на слайдах о том какой тип данных какое максимально большое число может себя вместить на конкретной, сцуко, архитектуре. Не то как это посчитать самому даже. Впрочем, говорю за свою шарагу^W университет.
Самообразование – это наш путь!

>> No.187704  
>Самообразование – это наш путь!

Вот поэтому я и говорю, если у тебя только теория из слайдов и не было толкового наставника, который лепил бы тебе "подзатыльники" ты будешь ловить *bufferoverflow всю оставшуюся жизнь. Те умные люди, кто это понял, перешли на python.

>> No.187705  
File: 1615489950701.pdf -(5708538 B, 0x0) Thumbnail displayed, click image for full size.
5708538

>>187704

> не было толкового наставника, который лепил бы тебе "подзатыльники" ты будешь ловить *bufferoverflow всю оставшуюся жизнь.

Думаю такого можно найти. Кто-то занимается этим платно, а кто-то из интереса. Ты считаешь что важны именно подзатыльники ? В случае ОПа это могут быть те люди, в чьи проекты он хотел бы добавить свой код.

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

>Те умные люди, кто это понял, перешли на python.

Хех, PEP7.

>> No.187706  

>>187703

>Самообразование – это наш путь!

Увы, да. Люто, бешено новерьчую о вузах. Касается всех предметов. Говорю за киевский вуз.

>> No.187707  
File: 1615490901642.jpg -(101178 B, 600x750) Thumbnail displayed, click image for full size.
101178

>>187704
Как показывает практика, каждый, кто пишет на сях будет ловить оверфлоу всю оставшуюся жизнь. Поэтому надо переходить на rust, а существующий код по крайней мере прогонять через статические анализаторы (не панацея, к сожалению).

>перешли на python

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

>> No.187710  

>>187707

>Поэтому надо переходить на rust

Не надо пожалуйста продолжать. У раст есть свои недостатки, а именно свой форк llvm и херовая поддержка большинства платформ, компилятор Си написать существенно проще. Кодовая база на раст с трудом может быть поддержана в том состоянии, чтобы всё было безопасно, о чём есть пост майнтейнера генты.
https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare/

>> No.187711  

>>187707

>он, скорее всего, ёбнутый

Скорее всего у него просто высокий уровень инженерного мастерства. У меня сейчас в доработке под руками борда на чистых сях. Без питонов, perl-ов и прочих php-bloat. Весом без капчи в 350кб. Видимо я ёбнутый.

>> No.187713  

>>187711
Если ты от этого ловишь кайф, то круто же.
Я вот как давно ёбнутый скажу, что если пить таблетки и не выёбываться, то все не так плохо будет.

Кстати, твоя борда никак вот с этим[0] стеком не связана ?
[0]: https://learnbchs.org/

>> No.187715  

>>187713
Нет. Я же сказал без BloatTM. А у тебя по ссылке микромускул )

>> No.187716  
File: 1615498395909.jpg -(42406 B, 736x414) Thumbnail displayed, click image for full size.
42406

>>187711

> У меня сейчас в доработке под руками борда на чистых сях.

Покажи исходники? Я тем же занимаюсь. Принимать GET/POST-запросы оказалось довольно просто, и делает всё это бинарий весом в 22 килобайта. Для компиляции достаточно tcc, который на дискетку умещается (код соответствует стандарту C89).

>> No.187740  

>>187716
Удваиваю. Было бы интересно поглядеть.

>> No.187746  
File: 1615542377964.png -(0 B, 226x256) Thumbnail displayed, click image for full size.

>>187716
>>187740
Я подумаю

>> No.187774  

>>187705

Забыл вот здесь написать, что это книга «C Traps and Pitfalls».
Немного старовата, но до сих пор применима. Она о том как делать НЕ НАДО. По этой теме ещё можно почитать здесь:
https://wiki.sei.cmu.edu/confluence/display/c

>> No.187785  

>>187711
Определённо. Я могу предположить только один смысл писать борду на си.

>> No.187787  

>>187774
Как НЕ НАДО делать. Говорит и показывает Брайан Кёрниган.
https://yewtu.be/8SUkrR7ZfTA
И заметки о книге, которую он упомянул.
https://wozniak.ca/blog/2018/06/25/1/index.html

>>183736
Си — не тот язык, в который можно «быстро вкатиться».

>> No.187821  
File: 1615588819360.jpg -(247845 B, 442x551) Thumbnail displayed, click image for full size.
247845

Нет ничего проще чем Си.
Чтобы понять основной синтаксис достаточно одной книги и никаких подвохов не будет. Я лично в свое время прочел "Программирование на языке Си Подбельский В.В., Фомин С.С.". Книга древняя, но и большинство компиляторов поддерживают по умолчанию древние стандарты. Даже не знаю чего там в новых стандартах добавили. Мне до сих пор компилятор ругается что я int i в for объявить не могу.
Да, нужно понимать распределение памяти, но что может быть проще чем понять линейное пространство памяти в байтах.
Если мне дать волю, то я бы всех учил Си как первому языку программирования.

>> No.187825  
File: 1615593102848.png -(1242462 B, 811x1155) Thumbnail displayed, click image for full size.
1242462

А есть что-то на русском и для тех у кого С это первый язык? Язык, в котором вообще непонятно что происходит?

>> No.187826  

>>187821
Столяров с тобой не согласен. Под статьёй длинное обсуждение подводных камней применения Сишки в учёбе.
http://www.stolyarov.info/pvt/anti_c

>> No.187828  

>>187825
на русском есть LuaRu и 1С

>> No.187838  
File: 1615628219007.pdf -(4617542 B, 0x0) Thumbnail displayed, click image for full size.
4617542

>>187825

>А есть что-то на русском и для тех у кого С это первый язык?

Переведённый на русский K&R2. А вообще дальше для чтения мануалов всё равно будет нужен английский, так что учи. Можешь уже сейчас их читать со словарём типа мультитрана, там часто есть графа о том, что слово значит в контесте математики или программирования.

>> No.187841  

>>187821

>Даже не знаю чего там в новых стандартах добавили

_Generic в C11
bool в С99

>Мне до сих пор компилятор ругается что я int i в for объявить не могу.

У меня такое было когда я в gcc указывал -std=c89 или оставлял дефолтные значения решается просто тем, что устанавливаешь другой стандарт, например c99
>>187826
В шапке Си треда на арисучане тоже было сказано, что этот язык не стоит изучать первым, ну наверное. У меня нет преподавательского опыта, чтобы об этом говорить. Потом постараюсь на твой пост более развёрнуто ответить.

>> No.187842  

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

>> No.187847  

>>187842

>А этот словарь есть на убунту и оффлайн?

Конкретно этот нет, но у тебя в зависимости от дистрибутива уже может быть клиент для словарей, который работает со словарями типа dict.org И естественно, если поднять у себя на компьютере такой же сервер как на dict.org, то оно будет и оффлайн работать. Но, мне кажется, что это уже сложно звучит, поэтому я на всякий случай ещё оповещу о возможности купить просто словарь в формате бумажной книги.
Словарный запас это вообще не так важно, если учишь язык, то тебе гораздо важнее понять как строятся предложения. Если переводить мануалы, то только научишься переводить мануалы. Тебе важно не найти аналог слова «из английского» на русском, а понять, что слово значит в нужном тебе контексте. Ну и не бойся ошибки делать.

>> No.187850  

>>187847

> поднять у себя на компьютере такой же сервер как на dict.org

В мое время не нужен был целый сервер для того чтобы пользоваться таблицой с двумя колонками - слово и определение.

>> No.187851  

>>187850

>В мое время не нужен был целый сервер для того чтобы пользоваться таблицой с двумя колонками - слово и определение.

Тоже подход, но это не такой же поисковик по толковым словарям как dict.org

Иногда я могу всё переусложнять, извините.

>> No.187852  

>>187826
Глянул бегло. Аргументы основываются на тотальном непонимании слушателями принципов работы ЭВМ и ОС. В таком случае, в начале стоит дать лекцию по архитектуре вычислительных систем, и уже потом перейти к. Ибо лучше не программировать то, не знаю что.

К лекции можно добавить ASM, нолики и единички, и пройтись с GDB по Hello World’у без libc на системных вызовах; и чем цветастей подсветка, тем, больше внимание неподготовленных слушателей из-за ассоциаций происходящего с образом кулхацкеров в media.

Короче, человек пытается начинать с абстрактных концептов, а уже потом говорит, как они map’ятся на реальность. А делать тут стоит либо наоборот, либо параллельно с, ящитаю. Тогда и проблем с понятием указателя не будет.

>> No.187854  

>>187852
дай-ка я тебя обниму

>> No.187868  
File: 1615675433802.jpg -(267165 B, 1920x1080) Thumbnail displayed, click image for full size.
267165

>>187852
Как бы такой курс Си выглядел, если приводить конкретные материалы?
Хотеть.

>> No.187874  

>>187852
Так можно научить только тех, кто уже имеет склонность к программированию, в то время как задача преподавателя дать общие представления о программировании каждому
>>187854
Отсосать не забудь

>> No.187875  

>>187874

>склонность к программированию

Это больше склонность к магии или склонность к технологии?

>> No.187884  

>>187875
Хуй знает, но одни стремятся к знаниям наперекор всему а других не может научить даже ментор.

>> No.187886  

>>187852

> Аргументы основываются на тотальном непонимании слушателями принципов работы ЭВМ и ОС.

Это косвенная причина.
Доводы о сложности понимания самого языка тоже есть — в сравнении с приветмиром на Паскале. Препроцессор и побочные эффекты, в частности. Амперсанд перед именами переменных — это зачем? И тут оказывается, что даже перед разъяснением таких простых программ придётся подать кучу вспомогательного материала.
А ещё такая мелочь, попробуй объяснить виндузятнику с первого раза, что такое '\n'. Перевод строки в ЦОММАНД.ЦОМ выводится сам перед промптом.
Остальное мне трудно оценивать просто потому, что я уже понимаю Сишку и обратно распонять её не смогу.
Автор не утверждает, что учить Си в целом трудно, только что как первый язык заходить будет тяжеловато. И только в том ВУЗе, в котором он тогда работал.

>> No.187889  

>>187886
Так говоришь, как будто виндузятники тупые по сравнению с кем?, а это далеко не так.

>>187868
Никак. Все курсы - это просто способ состричь бабла с хомяков.

>> No.187892  

Мне кажется в обсуждении преподавания в треде у нас кто-то ввёл за аксиому то, что учащемуся не должно быть хоть чуточку сложно и ему не нужно будет пытаться найти информацию самому.
А между тем мы живём в век всеобщей грамотности и доступности книг в университетской библиотеке.

>> No.187893  

>>187889

>Все курсы - это просто способ состричь бабла с хомяков.

Все ? Даже бесплатные с MIT OCW ? Курсы с coursera ?

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

>> No.187895  

>>187893
Ну а почему ты думаешь они бесплатные?

>> No.187899  
File: 1615729643299.jpg -(213652 B, 1920x1080) Thumbnail displayed, click image for full size.
213652

>>187895
Почему ? Скажи ты.

>> No.187904  
File: 1615731080330.jpg -(164124 B, 1134x872) Thumbnail displayed, click image for full size.
164124

>>187889

>Все курсы

перестал читать

>> No.187946  

>>187899
Я писал писал, а мой ответ потёр модератор.

>> No.187948  

>>187946

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

>> No.187953  
  1. FOSS *nix
  2. valgrind
  3. ???
  4. profit

Серьёзно, писать на C без valgrind'а или под проприетарной осью ни разу не весело

>> No.187954  

>>187948
Что-то там переписывать ради троллей... ну такое.

>> No.187955  

>>187821
Я не знаю что за компилятор тебе ругается на конструкцию из c99 в 2021. c17 уже на дворе, c2x скоро выходит, пора бы и обновить свою пятую фряху.

>> No.187957  

На самом деле писать на C просто, только немного муторно делать весь бойлерплейт с обработкой ошибок и буфферами руками.

Хорошей практикой будет реализация своих версий библиотек для

  • работы с индексированными (хранимыми вместе с длиной) строками, с методами как минимум для new/free, reverse, concat, substring.
  • для реаллоцируемых списков -- опять же, new/free, append, remove, sublist.
  • для linked-list'ов -- попробуй нивную реализацию, потом посмотри как linux linked lists концептуально реализованы и попробуй запилить свои макросы для того же.
  • для деревьев -- попробуй реализовать разные, начиная от просто binary tree до avl, red-black и прочих самобалансирующихся. потом можешь ещё и b-tree попробовать.
  • для хешмап -- с разными алгоритмами хеширования и кластеризации бакетов
  • для аллокации памяти -- бери sbrk и делай свой malloc
  • для парса аргументов -- попробуй сделать свой getopt с лягушками и ледяными феями вроде автохелпа

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

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

Читай так же сорцы реальных проектов, хорошими примерами будут ядро linux, nginx, сорцы всего openbsd, включая libre* -- запоминай техники, подходы. Избегай по-возможности стилей и подходов GNU-проектов, они так себе в большинстве своём.

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

Когда будет достаточно уверенности - попробуй взять какой-нибудь FOSS проект и запилить в него какую-нибудь фичу. Это на самом деле проще чем кажется и на MR/патче в мейллист тебе сделают ревью и скажут что поправить и что можно сделать лучше.

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

>> No.187958  

>>187957
Паста или сам писал?

>> No.187960  

>>187958
Сам же

>> No.187962  

>>187960
Ты классный, я бы хотел общаться с такими как ты, может быть даже дружить.

>> No.187965  

>>187962
Не уверен как реагировать. Думаю ты даёшь мне многовато кредита в силу каких-то заблуждений. Я на самом деле унылая колбаса, которая еле шевелится и ничего не соображает, но думает что всё может, если захочет.

В любом случае, треды тут сейчас интересные, мне нравится.

>> No.187966  

>>187965
Просто понравилась твоя паста, никакого кредита.

>> No.187983  

>>187965
"Во-вторых я ничего не знаю, просто очень хорошо умею притворяться что я всё знаю", хм.

>> No.188126  

Просто нужно понять что такое pointer - всё, ты выучил C.

>> No.188127  
File: 1616027049925.png -(9945 B, 340x109) Thumbnail displayed, click image for full size.
9945

>>188126

Хотелось бы чтобы это голословное утверждение было чем-нибудь подкреплено. Например было бы неплохо знать, что подразумевается под словом «понять». Знать определение указателя, пару раз применять их так как это написано в мануалах к стандартной библиотеке и использовать указатель на указатель, чтобы посередине связанного списка что-то вставить это разные вещи. Кстати о последнем два годных видео с участием профессора Брэйлсфорда на конструкторе лего показывающего некоторые нюансы использования указателей.

https://youtu.be/t5NszbIerYc
https://youtu.be/0ZEX_l0DFK0

>> No.188137  

Машинный код --> язык ассемблера --> язык C --> язык С++

Иначе до полного понимания не выучишь.

>> No.188138  

>>188137
Бред. Но написать свою VM для вымышленного байткода будет полезно с точки зрения понимания, как всё устроено

>> No.188140  

Думаю, ++ после C не обязательно, если нет целей туда идти. ООП паттерн можно и средствами C делать; более того, стоит понимать, как. После C лучше языки высокого уровня, на их примере рассмотрев отражения, метапрограммирование, атрибуты, компонентные модели и другие удобные и выразительные фичи.

>> No.188141  

>>188140
Рефлексию некорректно переводить как отражение.

>> No.188162  

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

>> No.188164  

>>188162
Нет.

>> No.188165  

>>188162

> Вас не бесят эти убогие хидеры на файлах с этой убогой капчей?

Нет.

>> No.188169  

>>188162
Искренне считаю вакабу самым оптимальным движком на данный момент.
Хорошо было бы внести пару изменений для условных noko, ютуб-embed и прочих мелочей, но оно уже прекрасно.
Капча даже лучше мятной.

>> No.188170  

>>188169

> ютуб-embed

Хотет. Надоели костыли с юзерскриптами

>> No.188172  

>>188162
Нормальные хидеры не видел? А pdf-preview вместо иконки убогой тоже? Мне тебя всех тут жаль.

>> No.188173  

>>188170
Что-то вроде: https://termbin.com/x5vu
Но это для 3.0.8 и слишком хлопотно будет внедрять в живой новерь, думаю.
К тому же голая вакаба больше соответствует минимализму - подобные фичи больше тянут как раз на юзерскрипты, да и реализуются проще.

>> No.188175  

>>188170
С другой стороны не все тут оценят слив данных гуглу. Так что опциональные юзерскрипты все-таки лучше.

>> No.188176  

>>188162
Потому что зачем? Движки для досок и так есть; почти на любой вкус.

>> No.188181  
File: 1616086033810.png -(50267 B, 278x284) Thumbnail displayed, click image for full size.
50267

>>188176
Чтобы выглядеть не как детский сад с мультиками и глаза не ломать.

>> No.188186  

>>188181

> как детский сад с мультиками и глаза не ломать

Eh? Досочки хорошо выглядят же.

>> No.188194  

>>188181
Имиджборда это не тот ресурс, который должен быть обвешан современным фронтендом и красивыми перделочками. Потому что есть старые браузеры, старые компьютеры. Потому что код должен быть максимально простым и удобным в понимании для того, чтобы проще было поддерживать. Потому что не надо нагромождать страницы чепухой, мешающей анализу написанного, вроде красивеньких кнопочек и эффектиков. Только сухой остаток, только нужные функции. Единственное, чего тут имхо не хватает, это ноко. Здесь даже саге не нужно, потому что сегать нечего, одна годнота и благодать.

>> No.188200  
File: 1616133091255.gif -(2035 B, 76x21) Thumbnail displayed, click image for full size.
2035

>>188175
Поэтому решение на юзерскриптах и сосёт. А вот если бы картинка-превью с ютьюба копировалась на сервер новеря, проблем бы не было.

>> No.188203  

>>188200
Хм, интересное. Через условный yt-dl брать превью и тайтл. Всё равно для удобства обычно только эти вещи и нужны, ведь сами видео смотрятся в других окнах.

>> No.188204  

>>188203

>в других окнах

*в других программах

>> No.188206  

>>188200
Но при просмотре данные все равно утекут, нужно копировать весь ролик целиком. Осталось только понять чем это отличается от постга сразу скачанного ролика.

>> No.188207  

>>188206
Смотреть необязательно.

>чем это отличается от постга сразу скачанного ролика.

Ну, если бы все постили скачанные ролики или новерь делал бы это автоматически было бы гораздо удобнее, согласен. Однако ни первое, ни второе не произойдёт.

>> No.188216  

>>188194

>Имиджборда это не тот ресурс, который должен быть обвешан современным фронтендом и красивыми перделочками.

Ты потерял нить диалога полностью. Чем читаешь не понятно. Речь была о наползающих хидерах во все поля.

>> No.188222  

>>188162
Движок на С не пишут, умник.

>> No.188223  

>>188222
Почему азиат на перле написать борду может, а белый человек на С - нет?

>> No.188225  

>>188223
Та я не об этом.

>> No.188227  
File: 1616166083415.gif -(1108 B, 34x20) Thumbnail displayed, click image for full size.
1108

>>188225
Так в чём проблема тогда? Почему на C нельзя написать такое же убожество, как вакаба?

>> No.188228  

>>188227
Не положено.

>> No.188229  
File: 1616167109606.jpg -(257316 B, 850x1204) Thumbnail displayed, click image for full size.
257316

>>188227
Нецелесообразно потраченные усилия с сомнительным трудноподдерживаемым результатом. Зачем тратить массу усилий на то, что на том же Питоне сделать на два порядка проще проще, причём результат будет заведомо безопаснее и компактнее? Причём это даже не задача ради какого-то там перформанса, у вас никогда не будет столько пользователей, чтобы питон на малинке захлебнулся. Под каждую задачу свой инструмент, при массе свободного времени можно и линейкой померить диаметр садового кольца, но ни один вменяемый инженер этого делать не станет.

>> No.188231  

>>188229

> причём результат будет заведомо безопаснее и компактнее

АХАХАХАХАХАХАХА

>> No.188233  

>>188231
Чё ржёшь, даун? У тебя 90% кода на сишечке будет бойлерплейт, который в Пайтоне идёт искаропке. Про безопасность даже комментировать не хочется, там, где питон просто бросит эксепшн, сишечка проедет по памяти мимо буфера до самого ядра

>> No.188234  

>>188223

>сишечка проедет по памяти мимо буфера до самого ядра

(сквозь от смеха слёзы) или просто сгенерит html-страничку и скормит серверу

>> No.188235  

>>188234
В которую попадут пароли от админки, лол.

>> No.188236  

>>188235
Не попадут. Сначала подумай, потом пиши.

>> No.188237  

>>188236
АХАХАХАХАХАХАХА

>> No.188238  

>>188236

>Не попадут

Потому что на си вакабу никогда не допишут?

>> No.188240  

>>188237
sha256, дурашка. Пукни что-нибудь посмешнее.

>> No.188241  

>>188240
С хорошей видеокартой хеши можно накрякать, если кушать без соли.

>> No.188242  

>>188238
Она готова уже. Осталось капчу причесать, чтобы такого говна, как в вакабе не было.

>> No.188243  

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

>> No.188244  

>>188241
Крякай, кукарекай... Это твоё право.

>> No.188245  

>>188243
ну это уже совсем глупости говоришь.

>> No.188246  

Преимущество Си в относительном удобстве написания программ без динамического выделения памяти.
Когда это необходимо возможна прямая работа с указателями.
block_copy(block_in, &(message->data[n * BLOCK_LEN]));
Большую часть фич языка на мой взгляд нет смысла использовать: динамическое выделение/освобождение памяти, знаковые числа и числа с плавающей запятой, стандартная библиотека (строки не юникод + те самые сишные дыры).
Если нужно чтобы просто работало лучше взять джаву или питон. Когда нужна предсказуемость и гибкость оптимизации, и при этом модуль не слишком большой (библиотека, утилита, драйвер), то можно использовать Си.

>> No.188249  

>>188245
https://rules.sonarsource.com/c/type/Vulnerability/RSPEC-5798

>> No.188250  

>>188244
Ну просто сам факт хеширования ещё не значит что пароли в безопасности. Хеши надо ещё и солить. А ещё лучше цепочку ключей использовать, чтобы ротировать последний в ней регулярно. Но к аргументам того баки который думает что C автоматически равен дырам в безопасности это не относится.

Баке который думает что C автоматически равен дырам в безопасности: есть инструменты для статического и рантаймового анализа, valgrind упомянутый в треде - один из них. Есть так же сканнеры самого кода, десятки их. В плане лаконичности - на самом деле сильно зависит от используемых библиотек и апишек. На C можно тоже писать без особого бойлерплейта, не сильно больше чем на go например.

>> No.188253  

>>188249
Ты прав, не подумал о выходе из скоупа.

>> No.188254  

>>188250
Несмотря на все ваши валграйнды и гковы в опенсурсе всё ещё регулярно находят банальные уязвимости.

>C автоматически равен дырам в безопасности

Не равен, но повышает их вероятность до близкого к еденице по мере расширения кодбазы.

>На C можно тоже писать без особого бойлерплейта,

Лаконичным и читабельным код от этого точно не станет.

>> No.188259  

>>188250

>не хочу нормальный язык, хочу си и миллион левых инструментов

ок

>> No.188260  

>>188240

Я призвываю в тред Уцуху, потому что во первых вы тут всё засрали, во вторых SHA256 уже никто не использует для хэширования паролей , для хэширования паролей есть bcrypt(3) и bcrypt_pbkdf(3) они так или иначе будут поставляться вместе с SSL библиотекой в операционной системе, например с LibreSSL, про которую тут писали.

>> No.188262  
File: 1616177896839.jpg -(109783 B, 724x1024) Thumbnail displayed, click image for full size.
109783

>>188260
Как бы не был хорош алгоритм хеширования пароля, от перехвата в момент ввода через RCE он не спасет. В то же время в C способов допустить RCE по неосторожности более чем достаточно. Впрочем технологий по минимизации ущерба от успешного RCE сейчас тоже появилось немало.

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

>> No.188263  

>>188227
Потому что большинство программистов хотят денег за "сложный" код на си.

>> No.188280  

>>188259

Ну для тебя это «левые инструменты», а у некоторых ctags часть базовой системы, у многих bison часть пакета posix-c-development

>> No.188283  

>>188246

> Большую часть фич языка на мой взгляд нет смысла использовать: динамическое выделение/освобождение памяти

Как работать с вводом, длина которого не известна заранее?

>> No.188285  

>>188283
Обычно длина ввода не выходит за пределы фиксированного размера, пусть даже большого. Иногда можно обрабатывать ввод частями. Но это не универсальный принцип, а только мое видение места Си среди других языков.
На полную катушку его в 2021 использовать не имеет смысла. Однако есть множество задач, где требуется предсказумость и возможность ручной оптимизации.
Предсказуемость это адекватная компиляция в машинный код. Когда исполняемая программа делает именно то, что от неё ожидается. С java возникают проблемы, так как невозможно контролировать код виртуальной машины. Сборка мусора, jit-компиляция и тонны кода, которые еще и разнятся версия от версии.
Если этого не требуется, тогда зачем заморачиваться? С Java + Maven работать в разы проще. Многие библиотеки ставятся одной строчкой в конфиге.

>> No.188319  

>>188259
Почти любая *nix-система - IDE сама по себе. Это же причина по которой попытки сделать IDE для C без использования стандартных инструментов обычно выходят так себе. И как правило тот же vim с тайловым wm со всеми инструментами в соседних терминалах оказывается удобней.

>>188285
В наши дни уже go скорее новая java, но в целом с условным разделением на прикладкой код бизнес-логики под меняющиеся требования, где важна скорость разработки и на код под критичные участки, где ресурсы (включая латенси и фактическое время исполнения, помимо очевидных циклов и памяти) так или иначе ограничены спорить глупо.

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

>> No.188324  
File: 1616252847291.jpg -(256727 B, 1200x900) Thumbnail displayed, click image for full size.
256727

Да, есть области где писать на Си это явно усложнить задачу. Но при этом стоит упомянуть области где у Си практически нет конкурентов. Это Embedded (встраиваемые системы). Там правят Си, ассемблер, ну и местами Си++. Причем из этой тройки Си для этой задачи подходит лучше всего. Во-первых прямо в Си можно делать ассемблерные вставки где это необходимо. Во-вторых код на Си в отличие от Си++ легко читаем и не нужно догадываться какие перегрузки операторов использует неизвестная тебе библиотека или особо одарённый программист до тебя.

Да, писать борду на Си это немного извращение, но написать веб-морду для прибора - это то с чем Си справится на ура.

Да, иногда есть возможности поставить операционку, те же unix-ы. Тогда есть возможность использовать почти любую технологию: виртуальную машину Java, скрипты Питона. Поднять сервер к примеру. Но низкоуровневую часть все равно удобнее будет написать на Си.

>> No.188327  

>>188285
Зачем ты перечисляешь другие языки, если авторам их компиляторов/интерпретаторов приходилось решать те же низкоуровневые проблемы.
Речь идёт о Це, а не о чём-нибудь другом.

> Иногда можно обрабатывать ввод частями.

При чтении файлов — да.
А если, например, программа читает файл argv[1], сохраняет результат в файл "argv[2]".ext, добавляя новое расширение — как заранее предугадать размер (strlen(argv[2]) + 5? Только не предлагай выискивать в мануалах максимальную длину имени файла и выделять столько же на стеке.
Мне интересно, я без каверзы спрашиваю.

>> No.188328  

>>188327
Большинство программ ограничивают размер имени файла, даже если в файловой системе такого ограничения нет. Другой вопрос, что чтение/запись выходит за рамки моей концепции. Появляются непредсказуемые побочные эффекты. А значит, тесты могут показывать разные результаты в зависимости от фазы луны.
Идея в том, чтобы отделить максимум логики в либу без побочных эффектов. В результате получается .so бинарник и .h со структурой и функциями. Если правильно протестировать, то можно быть уверенным, что в этом модуле нет ошибок/уязвимостей. При этом в отличие от функциональщины все работает настолько быстро, насколько возможно.

>> No.188329  

>>188328

>можно быть уверенным, что в этом модуле нет ошибок/уязвимостей.

Нельзя. Вне зависимости от языка, инструментов и степени покрытия тестами.

>> No.188330  

>>188327
>>188328
Приготовьтесь заебаться-с

https://man7.org/linux/man-pages/man3/realpath.3.html

>The POSIX.1-2001 standard version of this function is broken by design, since it is impossible to determine a suitable size for the output buffer, resolved_path. According to POSIX.1-2001 a buffer of size PATH_MAX suffices, but PATH_MAX need not be a defined constant, and may have to be obtained using pathconf(3). And asking pathconf(3) does not really help, since, on the one hand POSIX warns that the result of pathconf(3) may be huge and unsuitable for mallocing memory, and on the other hand pathconf(3) may return -1 to signify that PATH_MAXis not bounded.
>> No.188331  

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

Пример:
uint64_t add(const uint64_t a, const uint64_t b)
{

return a + b;

}

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

>> No.188332  

>>188331
Ещё нужно понимать, что тесты верифицируют не исходный код, а частный случай скомпилированной на этой машине программы. Я сейчас не об экзотике вроде
https://bugs.launchpad.net/gcc-arm-embedded/+bug/1633882
а о банальном UB, который каким-то чудом совпадает с правильным результатом на твоей машине и твоей версии конпелятора

>> No.188335  

>>188324
На Си сложно обращаться к базе с постами и генерировать статический html? Или при POST-запросе от http-сервера добавлять запись в базу, а после этого пересоздавать тред?

>>188227
Программисты на Си не умеют писать веб-приложения и обычно их работа с этим не связана.
Программисты на других языках дешевле.
Здесь программисты на Си пишут свои оправдания. Почему они не смогут написать борду на Си.
У меня времени нет.

>> No.188336  
File: 1616277324132.jpg -(59305 B, 1024x1024) Thumbnail displayed, click image for full size.
59305

>>188335

>На Си сложно обращаться к базе с постами и генерировать статический html? Или при POST-запросе от http-сервера добавлять запись в базу, а после этого пересоздавать тред?

Давно пробовал, чтобы понять на сколько это сложно.

Первое это пример bare metal для embedded (голая железка без операционки). Никакой файловой системы и баз данных, всё что есть пишешь в Си коде. Использовал библиотеку lightweight IP https://en.wikipedia.org/wiki/LwIP#:~:text=lwIP%20(lightweight%20IP)%20is%20a,many%20manufacturers%20of%20embedded%20systems. Борду на этом врядли напишешь, но пару дасятков интерактивных HTML страничек для управления устройством вполне можно.

Второе под операционкой (урезанный Linux) использовал Си CGI скрипты (но это для тех кто не знает путей проще) http://jkorpela.fi/forms/cgic.html
Выдержка из ссылки:

>This document was written to illustrate the idea of CGI scripting to C pro­gram­mers. In practice, CGI programs are usually written in other lan­guages, such as Perl, and for good reasons: except for very simple cases, CGI programming in C is clumsy and error-prone.

Если хочешь использовать чистый Си для борды то тебе придется по сути написать свой Web server, думаю объем работ понятен.

>> No.188337  

>>188336

>Если хочешь использовать чистый Си для борды то тебе придется по сути написать свой Web server, думаю объем работ понятен.

Не обязательно. Можно использовать уже готовый httpd или NGINX, об этом есть ссылка выше по треду. Там же ссылка на библиотеку для работы с common gateway interface.

>>188335
Борда на Си не то чтобы очень нужна. А если у тебя так мало времени, то тебе и борда на пёрле не особо нужна, да и вообще хоть какая-то аиб.

>> No.188339  

>>188337

> Там же ссылка на библиотеку для работы с common gateway interface.

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

>> No.188352  

>>188227
>>188335
Да можно. Но, опять же, зачем? Борд и так полно.

>> No.188356  

>>188337

>Можно использовать уже готовый httpd или NGINX

Ага.
>>188337
>>188352

>Борда на Си не то чтобы очень нужна.

Нужна. Отсутствие зависимости от динамических языков.
Я не нашел имиджборд в репозитории debian. Нужен apt-get install imageboard с зависимостью от httpd

>Но, опять же, зачем? Борд и так полно.

Полно, они кривые. Это улучшит конкуренцию.

>> No.188357  

>>188356
С не единственный не-динамический язык. Есть и более подходящие для вебовой разработки альтернативы. Те же go и rust имеют достаточно широкий набор билиотек как раз для этих целей. В том числе есть компиляция в wasm через llvm -- можно целиком всё взаимодействие из браузера на языке бека описать. Готовые либы и фреймворки заточенные под как раз такое взаимодействие тоже уже есть и постепенно матереют.

>> No.188386  

>>188356

>Полно, они кривые. Это улучшит конкуренцию.

Не особо хочется дерейлить тред, но почему вы решили, что конкуренция между бордами это хорошо ?

>>188356
Может просто тебе сделать ебилд для вакабы или порт во фряхе? Это гораздо проще потому что сможешь через saved config или flavors соответсвенно выбирать какой-то альтернативный вебсервер, чтобы сервить cgi тебе не обязательно нужен httpd. А во вторых часть админов привыкла самостоятельно куда-то рядом с /var/www эти веб приложения кидать. Ещё могу предложить найти или сделать самому докер имейдж или в случае с OpenBSD запилисть архив site.tgz, который можно разворачивать сразу в момент установки этой ОС.
Но всё это не к вопросам использования Си, это к вопросам использования пакетных менеджеров. Хотя если кто-то захочет сделать ультимативную утилиту, которая позволит майнтейнерам разных ОС опакечивать один архив таким образом, чтобы можно было его добавить в репозитории разных ос, то было бы интересно.
Я не про flatpak, идея в другом.
Идея в том чтобы я прописывал ссылку на архив tar.gz, а мне в ответ утилита писала список других архивов от которых архив с исходниками зависел, в том числе с опциональными зависимостями, неплохо бы было добавить поиск по уязвимостям, как в pkg_audit во фряхе, можно ещё сделать какие-то отзывы от других авторизованных майнтейнеров, которые бы писали, какие трудности есть с тем или иным пакетом, ну и конечно, чтобы можно было посмотреть какие патчи есть в каких в дистрибутивах. Главное не выполнять уже сделанную работу, не делать пакетный менеджер, который ещё будет собирать этот пакет, это уже можно отдать на откуп майнтейнерам дистрибутивов. Мда что-то я разговорился.

>> No.188397  

>>188386
Чтобы анону было куда уйти, когда очередной модератор скатится в мочу

>> No.188400  
>В linux-next добавлена возможность писать драйверы на Rust

https://www.linux.org.ru/news/kernel/16217268

Дни C сочтены

>> No.188401  

Fortran до сих пор жив, а вы.

>> No.188402  

>>188401
Разве это жизнь? Ты бы ещё Делфи вспомнил

>> No.188403  

>>188402
А что не так с Delphi?
Тот же C++, только без встроенной обфускации исходного кода.

>> No.188404  

На паскаледельфях написаны лучшие оконные файловые мэнэджэры.
https://www.ghisler.com/
https://doublecmd.sourceforge.io/
Компилировать это дело, правда, боль.

>> No.188411  
> Дни C сочтены

0xFFFF
0xFFFE
0xFFFD

>> No.188440  
File: 1616452792356.jpg -(38527 B, 626x351) Thumbnail displayed, click image for full size.
38527

>>188400

>LOR
>Дни C сочтены
>> No.188458  

>>188400

>LOR

Просили же не приносить на него ссылки, про раст в ядре давно и без тебя знаем

>> No.188460  

Нихерово у вас от безобидных шуток пригорает.

>> No.188462  

https://linuxplumbersconf.org/event/7/contributions/804/attachments/641/1168/barriers-to-in-tree-rust.pdf

>> No.188470  
File: 1616596668698.gif -(96889 B, 800x720) Thumbnail displayed, click image for full size.
96889

>>188462
Бла-бла-бла... Маркетинг буллшит.
Все ошибки, которые у меня возникали с Адой, были или от непонимания алгоритма, который кодировала, или тупо проебом части условия или путанием символов. На задачах, приближенных к реальности, где надо использовать сторонние библиотеки на C, однако, там везде use Uncheked_Reference и Unchecked_Access пополам с Unsigned_Integer, которое is mod 2**32, т.е. является массивом битов, и Unchecked_Conversion. Хуле толку-то.

>> No.188472  

>>188470
Таблетки прими. Нативные интерфейсы для ядра как раз и означают, что весь теребящий си ансейф будет заботливо завёрнут во влажный раст.

>Маркетинг буллшит.

Чего бля?

>> No.188492  

Хороший тред. Как использовать httpd или NGINX на чистом C?

>> No.188493  

>>188492
cgi/fcgi/http

>> No.189137  

Новерь у меня OpenBSD 6.8 с компилятором Clang 10.0.1. Есть программа на Си, которая успешно на сабже собирается, но мне хотелось бы перед тем как окончательно оформлять порты добавить патчи подключающие pledge(2). Мне нужно в аргументах plegde(2) написать группы сисколлов, которые программа будет использовать. Вопрос такой: Как не компилируя программу узнать к каким сисколам она обращается ?
Вопрос точно так же актуален и для фряхи с линуксом, потому там тоже есть механизмы ограничивающие доступ к системным вызовам.
Если есть какой-то способ узнать по объектному файлу например использую что-то типа readelf -s, то тоже напишите пожалуйста.

>> No.189138  
File: 1617979907839.jpg -(765874 B, 830x1000) Thumbnail displayed, click image for full size.
765874

>>189137

> Как не компилируя программу узнать к каким сисколам она обращается ?

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

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

>> No.189141  

>>189137
Перекомпилируй ядро, внедрив на обработку сисколлов логгирование. Затем читай логи. )))))000)))0)

>> No.189142  

>>189141

Идея чем-то напоминает ktrace
https://man.openbsd.org/man1/ktrace.1

>> No.190569  

https://youtu.be/QpAhX-gsHMs



Delete Post []
Password

[/b/] [/d/] [/tu/] [/a/] [/ph/] [/wa/] [/cg/] [/t/] [/p/]