Adamos

Понемногу накапливается мануал на Debian.pro - то, что уже есть, написано очень живо и по делу.

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

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

Вообще-то, если у вас по серверу приходится поискать "все avi более 3 гигабайт", то вы угрепаетесь проверять их все постоянно. Во всяком случае, на следующем этапе, когда вам захочется еще и содержимое как-то контролировать. А вам захочется, когда те же файлы будут лежать просто многотомным архивом, несмотря на ваши ухищрения.

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

Чтобы создать на движке Unreal, например, крестики-нолики - арифметики будет достаточно.

Завести применение нового шаблона на условие (какой-нибудь ключ в GET).
В Битриксе по умолчанию так сделан шаблон "для печати", например.
Отладить. Оттестировать.
Применить ко всему сайту.

Любая современная платежная система работает так:
- клиент на сайте хочет за что-то заплатить
- сайт формирует заказ под уникальным номером, сохраняя, кто, что и за какую сумму оплачивает
- клиент отправляется на сайт платежной системы с номером заказа и его ценой
- если клиент оплатил этот заказ, платежная система возвращает его на сайт, но это НЕВАЖНО
- потому что некоторые платежи могут час идти от клиента до платежной системы (хотя к PP это, может быть, и не относится)
- когда ПС удостоверится, что клиент оплатил заказ, она дергает скрипт на нашем сайте, сообщая ему, что заказ номер такой-то проплачен такой-то суммой. Тут может быть предварительное подтверждение, что этот заказ стоит именно столько - только при этом условии с клиента вообще что-либо снимется. Но в любом случае информацию о том, что заказ проплачен, на сайт приносит не браузер пользователя (это дырища), а сервер ПС
- когда клиент заходит после этого на сайт, сайт уже в курсе, что этот клиент проплатил этот заказ, и действует соответственно

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

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

Вообще-то в инструкции /configure --with-cards=hda-intel - но дело, конечно, не в этом.
Не знаю, какими ключами ему объяснить, что предупреждения не нужно трактовать, как ошибки.
Но вам же даны файл и строчка, в которой проблема. Замените текст на "Compiled today for kernel %s" например - предупреждение и исчезнет...

В адресе, скорее всего, все-таки указана область (в первую очередь нужно искать ее) или хотя бы город (во вторую очередь). Когда они будут определены - количество вариантов улиц будет уже не таким страшным.
Ключевые слова "ул.", "р-н" и пр. могут помочь отличить ул. Большую Московскую от области.

Вычисляем расстояния Левенштейна для имеющихся правильных вариантов и фрагментов введенной строки. Наименьшее считаем правильным...

Вам же не надо засекретить ссылки, вам всего лишь нужно подсчитать переходы.
99% пользователей не будет заморачиваться с вытягиванием настоящей ссылки из вашей даже после простого urlencode... Ну, в крайнем случае, замените перед кодированием точку на запятую, а на сервере поменяйте обратно.

Может, проще настроить этот самый выход на физическую кнопку выключения?
А пользователям объяснить, что теперь наконец можно выключать именно так, как они обычно поначалу пытаются ;)

SELECT `id`, `num` FROM `table` HAVING `active`=1 AND `num`=MAX(`num`)

И хоть бы один рассуждалец предупредил человека о главной опасности, которая подстерегает его при переходе с Виндов на Линукс.
Срываем покровы! Наш герой - Wine!
Потому что пользователь его все равно поставит. При этом Wine по умолчанию будет запускать по тычку все виндово-исполняемое. Например, .scr-файл с трояном-шифровальщиком, которому через Z:-диск доступно на запись все, что доступно пользователю. В том числе сетевые шары, например. И Wine, если что, прекрасно исполняет эти самые шифровальщики. Которые, невзирая на громкие вбросы о взломах Линуксов, по-прежнему пишут исключительно под Винды...

Кусок рабочего кода для медитации:

var data = new FormData();
data.append('file', this.files[count]);
$(form).find('input[type!=file]').each(function () {
  data.append(this.name, this.value);
});
$.ajax({
  'url': ajax_path,
  'type': 'POST',
  'data': data,
  'contentType': false,
  'processData': false,
  'dataType': 'json',

Первое - ищете файлы с самыми свежими датами. Когда вы последний раз что-то меняли на сайте - вам виднее.
Ищутся такие файлы в Linux простейшим find.
По ним уже разбираете - заражены они или вовсе не ваши и подлежат удалению.
Главная задача у вас - не удалить то, что вам навалили через бэкдор (все эти скрипты и баннеры), а найти сам бэкдор и обезвредить. Иначе завтра же вся эта хрень снова будет на сайте. В идеале - найти, как этот бэкдор появился на сайте вообще. И устранить эту возможность.

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

Ну, а фреймворк (любой) тут даст три плюса:
1. меньше дыр из-за навязанных фреймворком правильных подходов к архитектуре и данным;
2. более вменяемый код, по той же причине - легче будет его переделывать и поддерживать;
3. хотя бы в самых базовых вещах типа авторизации и ACL можно взять готовое, а не велосипедить.

Простейшие шаги примерно такие:
1. Ставится винда на двухтерабайтник, для чего создается системный раздел.
2. На остальной части двухтерабайтника создается раздел под NTFS - для Линукс это, конечно, не оптимально, но зато обе системы будут нормально его видеть. И это всяко лучше, чем рубить его пополам.
3. Ставится Линукс на твердотельник. И все работает.