Pull to refresh
37
0
kmeaw @kmeaw

Пользователь

Send message

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

Например: 2+2=4, sha1=60cd39bda4.

Фраза 2+2=5, sha1=1bf278f022 будет грамматической ошибкой, а 2+2=5, sha1=60cd39bda4 будет сигнализировать о коммуникационном сбое.

Мало. Что, впрочем, справедливо и для многих других классов ошибок — ведь почти никто не считает свинством, что если программист забудет прибавить или отнять единичку, то компилятор сделает не то, чего на самом деле хотел человек.

Чем же тогда контракт "я не буду писать UB-код" хуже контракта "я не буду совершать off-by-one errors" или "я не буду допускать логических ошибок при инвалидации кэша"?

Современные процессоры при обработке данных делают не в точности то, что написано в исполняемом коде, а могут сделать что-нибудь другое, но так, чтобы результат был неотличим от непосредственного исполнения каждой инструкции наивным образом при условии, что программа не содержит data races — и большинство пользователей процессора довольны тем, ведь это позволяет ему работать быстрее, хотя очень мало людей могут никогда не допускать гонок в своих программах. Оптимизирующие компиляторы C делают нечто похожее — они генерируют из исходника такой код, результат работы которого неотличим от интерпретации исходника абстрактной C-машиной при условии, что программа не содержит UB.

Если gcc нетривиальным образом обновился, то он поменяет своё поведение. Иначе зачем его вообще обновлять?

Каким образом разработчики gcc должны отличать "хорошие" изменения поведения от "плохих"?

Для таких случаев используются термины unspecified behavior и implementation-specified behavior.

Это свинство.

Разрабатывая программу на стандартном C, разработчик принимает контракт, в рамках которого он не будет писать код, приводящий к неопределённому поведению, а компилятор не будет вести себя неопределённым образом. Эти правила известны разработчику заранее.

Но ведь такие обстоятельства существуют и для C, например UB. Почему вызов паники из C-кода ядра - хорошо, наличие UB в C разработчики ядра терпеть готовы, а панику рантайма Rust - нет?

В аналогичном опросе от Apple, если бы он существовал.

А что делать с идентификаторами, если из двух (частично неисправных, например) автомобилей путём трансплантации мозга делают один? Что лучше считать главным идентификатором?

А чем плоха ситуация, когда пользователя ограничивают в использовании компьютера, который ему не принадлежит? Чем блокировка view-source: принципиально отличается от любых других блокировок (например через групповые политики в Windows)?

Что значит "из глубоко вложенной структуры"?

Из глубоко вложенного цикла, например. В языке может не быть конструкции "break label".

Из любой функции, …, выйти можно через return.

Но в языках без RAII и сборки мусора нужно будет перед return освободить все ранее выделенные ресурсы. Если не использовать goto, то придётся копировать код освобождения перед каждым return и помнить исправлять все эти места, когда набор выделяемых ресурсов меняется.

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

А можно ограничить себя в "плохом" использовании goto: не покидать границы функции, прыгать только вперёд, делать это только в исключительных ситуациях.

Link register?

	mov ebp, RetFromCoolProc
	jmp MyCoolProc
RetFromCoolProc:
MyCoolProc:
  …
  jmp ebp

А для более сложных случаев есть romcc.

Есть RFC4941, реализованный во многих ОС. Сетевой интерфейс случайным образом выбирает себе адреса и ротирует их.

А если пользователь покупает VM с FreeBSD, не соглашается при покупке ни с какими офертами от Microsoft, оплачивает, а потом самостоятельно сносит ОС и заменяет её на пиратскую Windows?

Или у хостера есть соглашение с Microsoft, которое позволяет проверить любую VM, даже если хостер сам на неё продукты Microsoft не устанавливал?

Такой инструмент можно написать один раз, а потом использовать везде (ну или хотя бы только для Linux в QEMU на amd64, что уже очень неплохо, и покрывает 99% случаев). Сомневаюсь, что ни одна трёхбуквенная организация одновременно не имеет в своём штате человека, достаточно компетентного для написания такой утилиты и не смогла заказать её изготовление у сторонних специалистов.

Планируются ли модели с разблокированным Intel Boot Guard?

А что вы установили? Если в этой ОС есть браузер, то какой, и как ему живётся в современном вебе при таком объёме ОЗУ?

Чем обычное оффлайн-голосование более тайное? Я точно так же прихожу с паспортом, и ничего не мешает мотивированному сотруднику избирательного участка запомнить связку "номер паспорта"-"номер бюллетеня", нарушая таким образом тайну в момент извлечения бюллетеня из урны для подсчёта.

Так и в онлайн-голосовании - достаточно разнести на разные сервера процедуру аутентификации с авторизацией (выдаёт сертификат "предъявителю можно голосовать") с процедурой заполнения бюллетеня (проверяет сертификат, в котором гражданин анонимизирован).

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

В Prosody все эти проблемы так или иначе решаемы (плагинами, да).

Нет синхронизации истории на разные устройства

mam и carbons

Сообщения в оффлайн то доставляются, то теряются

smacks

Отправка файлов именно p2p, хотелось бы p2s2p

http_upload_external

На сервере не очень получается конфигурить имена сотрудников

lib_ldap с настроенным vcard_format

Pidgin в самом деле выглядит довольно скудно на фоне телеги

Pidgin (как и всё с libpurple) пытается поддерживать все протоколы сразу. Попробуйте современные XMPP-only мессенджеры, например Gajim и Convsersations.

Пользователю не важно

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

IPC у VLIW сильнее зависит от компилятора. На оптимизирующие компиляторы C для x86 было потрачено огромное количество ресурсов, чего нельзя сказать про Эльбрусы. Чтобы скомпенсировать это неравенство, имеет смысл приложить максимум усилий разработчика теста для увеличения IPC путём подсказок компилятору и переписыванию некоторых кусочков кода вручную.

Но при этом у нас остаётся потенциальная возможность перепаковать груз (новым lcc) таким образом, чтобы он размещался на креслах. И тогда его можно будет перевозить на уже купленном речном судне быстрее, чем на машине с прицепом.

Information

Rating
Does not participate
Registered
Activity