Странно, что никого из комментаторов не смутило что результат strlen() сохраняется в переменной типа int, а не size_t

Думаю, что у меня самое лаконичное решение.

strtok(str,«\n»);

> Dimanc

На первом курсе профессор лекцию читал, вот и запомнилось.
В одном из оффтопиковых компиляторов напоролся на такую ситуацию. Видимо, был включен full-boolean evaluation флаг.
Если Вы гарантированно знаете, что будет short-circuit evaluation, то результат будет верным.
На мой же взгляд, такая запись делает код запутанным, а в общем случае, когда на месте len стоит сложное выражение, - результат трудно предсказуемым.

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

А вы часто видели «строки» длиной больше ~2млн. символов?

это Вы про меня? не думаю, что TC сохраняет строки размером в 4 гигабайта, чтобы затирать '\n' =)

int подсвечивается, size_t - нет
тока поэтому .)

s/млн/млрд

> А вы часто видели «строки» длиной больше ~2млн. символов?

а вы часто видели ворнинги от компилятора? :)

Постоянно. Стараюсь, чтобы их вообще не было, но некоторые можно и игнорировать.

зачем игнорировать, если можно сделать правильно.

Точно не припомню, но были у меня такие предупреждения, от которых избавиться нельзя было (при -Wall)...

Что характерно, самое умное замечание в топике о Си сделал юзер с ником php-coder. Отличный троллинг, и главное, по делу.

Не в тему.

> На мой же взгляд, такая запись делает код запутанным, а в общем случае, когда на месте len стоит сложное выражение

Запутанным она его не делает, а сложное выражение - это как раз не общий, а частный случай.

Но варинат с тремя if'ами просто красивее.

Не морочь людям голову.

str[pos-str]=0; ===> *(str+pos-str)=0; ===> *pos=0;

Обожаю ЛОР. Даже из простого вопроса можно сделать тему на 2 страницы со срачами.

> *(c+1)

Ну c[1] же

> разыменование len

Где ты его тут увидел.

Если же ты про проверку значений, то в Си гарантируется, что второй аргумент оператора && будет выислен только после того, как его первый аргумент будет вычислен в не нулевое значение

ISO/IEC 9899:1999 6.5.13 Logical AND operator:

4 Unlike the bitwise binary & operator, the && operator guarantees left-to-right evaluation; there is a sequence point after the evaluation of the first operand. If the first operand compares equal to 0, the second operand is not evaluated.

>> разыменование len

Где ты его тут увидел.

мысленно перевёл в машинный код

    len dd   1 dup(0)
    ...
    cmp   eax, len    ; здесь разыменование адреса len
    jnle  short_circuit_branch
    ... анализ правого выражения ...
    ...
    код if
    ...
short_circuit_branch:

> в Си гарантируется

блин, я же ответил уже, что на практике такие случаи возможны, как пример, full boolean evaluation.
Полагаю, что также могут быть проблемы с внеочередным исполнением.

Причём данный баг из разряда «хрен найдёшь», т.к. воспроизвести его в отладке просто не получится. Вероятность того, что адрес str-1 будет относится к другой странице, крайне мала.
Случилась травма на производстве, что делать будете? Весь код анализировать?

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

> Ну c[1] же
ну 2-ой час ночи был же =))
у некоторых даже тег [сode] из рук вываливается вон
> geekless Вот так и рождается код, который потом постят на code wtf и вспоминают индийских разработчиков.
ну табуляцию я пропустил, а проверка чтения из другой страницы - это, конечно, не так важно =)

ну всё же по теме =)

> Но варинат с тремя if'ами просто красивее.
хм... мне больше кажется красивым код в строку через &&, места меньше занимает, не жалко в конце блока оставить пустую строчку
но, если детерминированность результата выполнения критична, то не позволяю себе писать код, допускающий неоднозначности, наверное паранойа...

Вы откуда такой взялись, интересно.

разыменование

применимо только к указателям.

[code]
len dd 1 dup(0)
...
cmp eax, len
[/code]Боже, что это за брейнфак. Пишите на нормальном ассемблере, пожалуйста.

блин, я же ответил уже, что на практике такие случаи возможны, как пример, full boolean evaluation.

На практике в компиляторах ошибка может быть где угодно. Неупорядоченное вычисление операндов && эквивалентно вычислению тела условия кода под if раньше вычисления условия. Если у вас в компиляторе такая ошибка обнаружится, вы на форуме будете писать, что теперь и в if не гарантирован порядок вычислений? При чём тут язык?

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

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

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

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

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

А если кому-нибудь что-нибудь оторвёт из-за несбалансированных push-pop в коде, сгенерированном компилятором? Функции перестанете использовать? Пишите сразу на асме, чего уж там.

хорошо, я понял

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

хорошо, я понял

Ответьте на вопрос, уважаемый.

bcb2009

>bcb2009

Качаю. Будет время- проверю.