
Представляем вам реализацию игры в крестики-нолики на С с помощью одного вызова printf. Написана для участия в IOCCC в 2020 году.
Программист
Представляем вам реализацию игры в крестики-нолики на С с помощью одного вызова printf. Написана для участия в IOCCC в 2020 году.
Поздравляю всех с днем числа Пи! (день числа Пи отмечается 14 марта, поскольку эта дата в американском формате записывается в как 3.14 - прим. перев.) Чтобы отметить его как следует, я хочу ненадолго отвлечься от программного обеспечения и поговорить о чем-то особом. Возможно, вы слышали байку о том, как в штате Индиана пытались законодательно приравнять число Пи к чем-то типа 3, или 4, или 3.15. Обычно ее рассказывают в качестве доказательства того, что жители Индианы - бестолковая деревенщина, но это далеко не вся история. Зачем они пытались поменять значение π и на что они рассчитывали?
Я занялся исследованием, и теперь могу рассказать историю целиком. Чтобы вы поняли контекст, мне придется объяснить кое-какие математические концепции.
Мне придется объяснить немало математических концепций.
Уже давно считается, что многие (если не все) игры или приложения можно улучшить, добавив в них поддержку скриптов.
Для этого есть несколько разных способов. Наиболее распространенный подход - встроить Lua (или другой язык, который вам больше нравится). Если это по каким-то причинам не вариант, отважный программист может замахнуться на реализацию собственного интерпретатора, или хотя бы сделанного на коленке парсера для усовершенствованного файла с настройками.
Нет, честное слово, это нормально. Просто подумайте заранее о том, как ваш конфигурационный файл позволит влиять на игру - ведь вне зависимости от выбранного вами способа, вся суть скриптинга в том, чтобы дать возможность сделать то, о чем вы изначально даже не подозревали, не меняя при этом исходный код программы.
У невероятного роста Youtube есть одно последствие, радостное и грустное одновременно - множество историй потеряются под слоями новой краски. Именно поэтому я хочу рассказать одну из них - историю того, как 10 лет назад маленькая команда веб-разработчиков задумала убить IE6 с помощью Youtube и даже не получила за это по шапке.
Я не могу вспомнить то конкретное событие, из-за которого наша команда разработки начала строить планы убийства браузера за обедом в столовой Youtube. Возможно, в тот раз я случайно отправил в релиз CSS-стиль, где был указан селектор атрибута на нестандартном HTML-элементе. Любой здравомыслящий веб-разработчик предположил бы, что если браузер не может распознать элемент - он молча пропустит данное описание. Но со старыми версиями IE дело обстояло не так. В определенных условиях это приводило либо к внутренней рекурсии и падению браузера (если повезет), или даже к синему экрану смерти (если не повезет).
А может быть, в сотый раз кто-то из наших разработчиков использовал тег <img>
без указания атрибута src
. От новичков никто не требовал быть в курсе, что в старых версиях IE вместо пустого аттрибута src подставляется корневой путь ("/"). Это внезапно превращает тег <img>
в <iframe>
, загружая главную страницу и все связанные с ней ресурсы, что может привести к бесконечной рекурсии. Когда пустой тег <img>
случайно просачивался на главную страницу - вся команда в экстренном режиме искала его, пока сервера не расплавились под нагрузкой.
В общем, не вдаваясь в подробности - это была настоящая жесть, и она была связана с IE6. Этот браузер сильно отравлял жизнь всей нашей команде разработки. По меньшей мере 1-2 недели из каждого мажорного релиза отводились на то, чтобы заставить новый UI работать под IE6. Несмотря на всю эту боль, нас заставляли поддерживать его ради пользователей, которые не могут обновиться или работают в компаниях, где обновление запрещено политиками безопасности. Пользователи IE6 на тот момент составляли примерно 18% от общего числа. Все понимали, что просто так прекратить его поддержку нельзя, но когда мы сидели в той столовой после нескольких бессонных ночей, на сопереживание тем несчастным пользователям просто не оставалось сил. Мы начали коллективно фантазировать о том, как отомстить IE6. Одна идея сразу привлекла всеобщее внимание: а что, если мы просто пригрозим прекратить поддержку? Как отреагируют пользователи? Они поднимут бунт против Youtube, начнут присылать нам письма с угрозами расправы (как это уже случалось раньше)? Или вдруг станут апологетами новых браузеров? Мы мечтали о том, как офисные работники по всему миру внезапно начнут придумывать причины, по которым обновление браузеров жизненно необходимо для бизнеса, а бабушки и дедушки возьмут своих технически прошаренных внуков в заложники, чтобы те "починили им ютубы". То, что началось как сеанс групповой психотерапии, стало превращаться в конкретный план действий, для реализации которого у нас были уникальные условия.
SIGSEGV
. Исследование проблемы позволило мне провести отличное сравнение между musl libc
и glibc
. Для начала посмотрим на стектрейс:==26267==ERROR: AddressSanitizer: SEGV on unknown address 0x7f9925764184
(pc 0x0000004c5d4d bp 0x000000000002 sp 0x7ffe7f8574d0 T0)
==26267==The signal is caused by a READ memory access.
0 0x4c5d4d in parse_text /scdoc/src/main.c:223:61
1 0x4c476c in parse_document /scdoc/src/main.c
2 0x4c3544 in main /scdoc/src/main.c:763:2
3 0x7f99252ab0b2 in __libc_start_main
/build/glibc-YYA7BZ/glibc-2.31/csu/../csu/libc-start.c:308:16
4 0x41b3fd in _start (/scdoc/scdoc+0x41b3fd)
if (!isalnum(last) || ((p->flags & FORMAT_UNDERLINE) && !isalnum(next))) {
p
— это корректный, ненулевой указатель. Переменные last
и next
имеют тип uint32_t
. Сегфолт случается на втором вызове функции isalnum
. И, самое важное: воспроизводится только при использовании glibc, но не musl libc. Если вам пришлось перечитать код несколько раз, вы не одиноки: тут попросту нечему вызывать сегфолт.55074-c2e83c69
Примечание переводчика: в перерывах между холиварами про JS предлагаю обсудить несерьёзную, пятничную тему:
Кто не любит эмодзи? Активно используя их в мессенджерах и почтовых приложениях, я решил проэкспериментировать с тем, как можно применить их с умом в повседневной разработке приложений. Хотя поначалу это была просто шутка, эмодзи действительно оказались полезными в ряде случаев. Как так?
Мы, программисты, читаем много текста — будь то код, логи, комментарии к коммитам, документация или что-либо еще. Эмодзи бросаются в глаза, и их гораздо легче найти на простыне текста, чем обычную строку. Быстрее поиск — выше продуктивность. Хотя даже если на вашей продуктивности это никак не скажется, пользоваться эмодзи — весело! Вот некоторые вещи, которые я опробовал на практике:
document.write
— один из самых странных методов. Он вставляет HTML-код на страницу сразу после себя. Точнее говоря, сразу после тега <script>
, внутри которого он расположен. И только в том случае, если документ еще не был загружен полностью. А если был? Тогда страница очищается и заменяется на, что было указано.document.write('<plaintext>')
if (Math.random() > 0.9)
document.write('<!--')
JSHint
, в основном с целью изучить ES6 (я особенно горжусь тем, как переделано обнаружение областей видимости для переменных). Во время этого процесса я наткнулся на несколько вещей, которые меня удивили — в основном, в ES6, однако есть и кое-что про ES3, что я до этого никогда не использовал.break
и continue
— это стандартная возможность в современных языках программирования. Однако не все знают, что циклам можно давать метки и с их помощью прерывать любой конкретный цикл:outer: for(var i = 0; i < 4; i++) {
while(true) {
continue outer;
}
}