И зачем тогда вообще нужны коды ошибок? Достаточно же при любой падать вообще ничего не возвращая. И сразу будет понятно - раз ничего не вернулось, значит кто-то где-то ошибся. А вам подойдёт, например, компилятор, который при ошибке в коде будет не выдавать сообщение об этой ошибке, а просто падать в SEGFAULT. Зачем лишние проверки в компиляторе писать? Раз он упал - значит у вас ошибка. Или в нём ошибка. Или с железом проблемы. Ищите.
Числа просто для примера. HTTP изначально не вводил никаких ограничений на длину URL, оставляя вопрос разработчикам серверов. Позднее добавилась рекомендация поддерживать не менее 8000 символов. Ну и первые браузеры обижались уже на 512 символов в адресной строке, а сейчас и 16К может прийти. Но в целом, увеличение размера входных данных это обычное дело. Те же имена файлов из 8.3 стали длиной 255/510 байт, в зависимости от ОС и ФС. В этом примере практически все проблемы решаются добавлением нескольких строк
Все ваши примеры содержат исходно неправильную строку. Тот самый "мусор на входе".
Ну да. И защиту от SQL-инъекций делать не надо. Ведь никто не может назвать ребёнка Robert'); drop table *;--.
Если система заведомо проектируется так, что "завтра размер входных данных увеличили" - норма жизни,
А если сегодня стандарт HTTP говорит, что лимит URL 1024 символа, то должно ли в ТЗ быть предположение, что завтра новая версия стандарта сделает его 16384 символа?
Да, он лёгкий, но габариты 53x34x6 см. В Аэрофлоте (55х40х25) он в ручную кладь впишется, а вот в Победе (36х30х15) уже нет. Ну и если рядом с вами окажется тот самый незакреплённый люк боинга, то вас может выбросить за борт и без ручной клади. Так что только на себе, чтобы быть полностью готовым к любой неожиданности.
Спасение утопающих - дело рук самих утопающих. Покупайте себе парашют и надевайте перед полётом. Заодно будете внукам рассказывать весёлые истории, как вы этот парашют проносили в самолёт.
Например размер буфера никак не мог превышать размер пакета.
Может быть. И как учебный пример сойдёт. Но в реальном продукте может оказаться, что завтра размер входных данных увеличили, а размер буферов забыли.
Неинициализируемый буфер "a="превратится в пару "a", ""
Да, тут я пример неправильный подобрал. Вот если на входе просто "a", то на выходе в value может быть произвольная строка, поскольку в конце цикла j = 1, value[1] = 0, а вот что записано в value[0] мы не знаем.
Как уже написали, нет защиты от переполнения буфера. А ещё там нет проверки корректности входной строки (пример: "a==c"), не инициализируется буфер (пример: "a="), используется постоянное разименование ссылки вместо отдельной переменной и if/else вместо switch/case.
решал задачу поиска самоповторов в массиве без дополнительной памяти
Имея при этом квадратичную сложность.
Вот пример кода на C под Linux, который демонстрирует ручное управление файловым вводом и выводом
Нет контроля успешности чтения и записи файлов.
IMHO, самый главный навык тех времён - это подзабытое сейчас умение отлаживать свой код. Не просто менять его, пока не заработает, а именно строка за строкой, шаг за шагом смотреть, что именно происходит в коде, как меняются переменные, как вычисляются условия, куда идут переходы.
Почему, почему. Да потому что сейчас аппаратных ресурсов до и больше. Посмотрел бы я на этих молодых разработчиков за компьютером с 640 килобайтами оперативки, 40 мегабайтами диска и одним медленным ядром без графического интерфейса. Ну и без интернета, вся документация только на бумаге. А то, что описано в статье - это не разработка, как таковая, а сборка из готовых модулей. Как только не будет модуля с нужным функционалом или в одном из этих модулей возникнет ошибка, вот тут то и начнётся собственно разработка.
вы помните, сколько времени у вас ушло, чтобы впервые поднять собственноручно собранный TCP-сервер
Да, собственно, немного. Простейший TCP-сервер на C под DOS выглядит так же, как пример на питоне в статье. Проблема начинается потом, когда надо перейти от цикла ожидания к асинхронной работе и параллельным процессам обработки запросов.
Так если мы за абсолютную безопасность, то именно любого человека. А если не любого, то почему именно 95 перцентиль, а не 90 или 98? Видимо, где-то есть экономические причины.
Но почему 95 перцентиль? Ведь безопаснее, если кресло будет выдерживать вес любого человека. А лучше двоих любых людей, так будет ещё безопаснее, а то вдруг кто-то проходя мимо сидящего пассажира не удержится на ногах и упадёт на него сверху.
А ещё там верхнее крыло и сильно поднятый вверх стабилизатор. Как раз, чтобы выпрыгнувший из двери десантник не ударился об них. Большинство современных лайнеров имеют нижнее крыло и стабилизатор близко к оси самолёта.
Статистика, правда несколько устаревшая, за 1952-1997 года, говорит, что при катапультировании с высоты менее 150 метров шансы на выживание чуть более 51%. На больше высоте немногим более 91%. Ещё одно исследование катапультирования при взлёте и посадке в США за 1973-1985 годы даёт на 22 катапультировавшихся трёх погибших и четырёх с компрессионным переломом позвоночника. И тоже даётся высота в 150 метров, выше которой катапультирование относительно безопасно. И учтите, что это среди пилотов, сознательно запустивших катапультирование, правильно пристёгнутых и зафиксировавших руки и ноги.
Отбор должен быть ради размножения. Выживание при этом необходимо, но не достаточно. Тот же красивый хвост у павлина - это гандикап. Он мешает выживанию, но способствует размножению, показывая, что даже с таким нерациональным украшением самец имеет достаточно сил и умений, чтобы выжить и может передать эти навыки потомству.
А потом наблюдать, как из-за нештатного срабатывания из взлетающего самолёта с высоты 50-100 метров сыплются кресла с пассажирами и падают, не успев раскрыть парашют.
Потому что на взлёте и посадке, где происходит большинство катастроф, такая система бесполезна - на раскрытие парашютов нужно время, то есть запас высоты. Но добавляется вероятность нештатного срабатывании такой системы в произвольный момент полёта.
И зачем тогда вообще нужны коды ошибок? Достаточно же при любой падать вообще ничего не возвращая. И сразу будет понятно - раз ничего не вернулось, значит кто-то где-то ошибся.
А вам подойдёт, например, компилятор, который при ошибке в коде будет не выдавать сообщение об этой ошибке, а просто падать в SEGFAULT. Зачем лишние проверки в компиляторе писать? Раз он упал - значит у вас ошибка. Или в нём ошибка. Или с железом проблемы. Ищите.
Числа просто для примера. HTTP изначально не вводил никаких ограничений на длину URL, оставляя вопрос разработчикам серверов. Позднее добавилась рекомендация поддерживать не менее 8000 символов. Ну и первые браузеры обижались уже на 512 символов в адресной строке, а сейчас и 16К может прийти.
Но в целом, увеличение размера входных данных это обычное дело. Те же имена файлов из 8.3 стали длиной 255/510 байт, в зависимости от ОС и ФС.
В этом примере практически все проблемы решаются добавлением нескольких строк
Hidden text
Ну да. И защиту от SQL-инъекций делать не надо. Ведь никто не может назвать ребёнка
Robert'); drop table *;--.А если сегодня стандарт HTTP говорит, что лимит URL 1024 символа, то должно ли в ТЗ быть предположение, что завтра новая версия стандарта сделает его 16384 символа?
Если это CGI, то сервер должен вернуть 400 Bad Request. 503 Service Unavailable тут никоим образом не подходит.
Да, он лёгкий, но габариты 53x34x6 см. В Аэрофлоте (55х40х25) он в ручную кладь впишется, а вот в Победе (36х30х15) уже нет.
Ну и если рядом с вами окажется тот самый незакреплённый люк боинга, то вас может выбросить за борт и без ручной клади. Так что только на себе, чтобы быть полностью готовым к любой неожиданности.
По габаритам может не пройти
Спасение утопающих - дело рук самих утопающих. Покупайте себе парашют и надевайте перед полётом. Заодно будете внукам рассказывать весёлые истории, как вы этот парашют проносили в самолёт.
Добавлю. Если на входе
"a", то ещё и нет гарантии, чтоkeyзавершается нулём.Может быть. И как учебный пример сойдёт. Но в реальном продукте может оказаться, что завтра размер входных данных увеличили, а размер буферов забыли.
Да, тут я пример неправильный подобрал. Вот если на входе просто
"a", то на выходе вvalueможет быть произвольная строка, поскольку в конце циклаj = 1,value[1] = 0, а вот что записано вvalue[0]мы не знаем.Как уже написали, нет защиты от переполнения буфера. А ещё там нет проверки корректности входной строки (пример:
"a==c"), не инициализируется буфер (пример:"a="), используется постоянное разименование ссылки вместо отдельной переменной и if/else вместо switch/case.Имея при этом квадратичную сложность.
Нет контроля успешности чтения и записи файлов.
IMHO, самый главный навык тех времён - это подзабытое сейчас умение отлаживать свой код. Не просто менять его, пока не заработает, а именно строка за строкой, шаг за шагом смотреть, что именно происходит в коде, как меняются переменные, как вычисляются условия, куда идут переходы.
Почему, почему. Да потому что сейчас аппаратных ресурсов до и больше.
Посмотрел бы я на этих молодых разработчиков за компьютером с 640 килобайтами оперативки, 40 мегабайтами диска и одним медленным ядром без графического интерфейса. Ну и без интернета, вся документация только на бумаге.
А то, что описано в статье - это не разработка, как таковая, а сборка из готовых модулей. Как только не будет модуля с нужным функционалом или в одном из этих модулей возникнет ошибка, вот тут то и начнётся собственно разработка.
Да, собственно, немного. Простейший TCP-сервер на C под DOS выглядит так же, как пример на питоне в статье. Проблема начинается потом, когда надо перейти от цикла ожидания к асинхронной работе и параллельным процессам обработки запросов.
Так если мы за абсолютную безопасность, то именно любого человека. А если не любого, то почему именно 95 перцентиль, а не 90 или 98? Видимо, где-то есть экономические причины.
Но почему 95 перцентиль? Ведь безопаснее, если кресло будет выдерживать вес любого человека. А лучше двоих любых людей, так будет ещё безопаснее, а то вдруг кто-то проходя мимо сидящего пассажира не удержится на ногах и упадёт на него сверху.
А ещё там верхнее крыло и сильно поднятый вверх стабилизатор. Как раз, чтобы выпрыгнувший из двери десантник не ударился об них. Большинство современных лайнеров имеют нижнее крыло и стабилизатор близко к оси самолёта.
Статистика, правда несколько устаревшая, за 1952-1997 года, говорит, что при катапультировании с высоты менее 150 метров шансы на выживание чуть более 51%. На больше высоте немногим более 91%.
Ещё одно исследование катапультирования при взлёте и посадке в США за 1973-1985 годы даёт на 22 катапультировавшихся трёх погибших и четырёх с компрессионным переломом позвоночника. И тоже даётся высота в 150 метров, выше которой катапультирование относительно безопасно.
И учтите, что это среди пилотов, сознательно запустивших катапультирование, правильно пристёгнутых и зафиксировавших руки и ноги.
Отбор должен быть ради размножения. Выживание при этом необходимо, но не достаточно.
Тот же красивый хвост у павлина - это гандикап. Он мешает выживанию, но способствует размножению, показывая, что даже с таким нерациональным украшением самец имеет достаточно сил и умений, чтобы выжить и может передать эти навыки потомству.
Особенно, если он перешёл в неуправляемое пикирование...
А потом наблюдать, как из-за нештатного срабатывания из взлетающего самолёта с высоты 50-100 метров сыплются кресла с пассажирами и падают, не успев раскрыть парашют.
Потому что на взлёте и посадке, где происходит большинство катастроф, такая система бесполезна - на раскрытие парашютов нужно время, то есть запас высоты. Но добавляется вероятность нештатного срабатывании такой системы в произвольный момент полёта.
Так кто же их лишает шансов то? Вроде не запрещено купить себе парашют и надевать его в полёт.