kika

Порядок местами не перепутан, 200 и 177 не поменялись, поменялись 81 и 31. Что-то я не уверен, что здесь есть хоть что-ниудь классическое.

From:

krotoff.livejournal.com

На хорошие грабли, на проверенные :)

From:

Не удалось мне запутать :-)

По историческим причинам маленькие целые в ерланге представлены как char, но в документации к ei_encode/decode написано что их надо воспринимать как unsigned 0-255. Разработчик это не прочитал, взял charы и не думая соорудил из них IP адрес сдвигами :-)

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

From:

Классичнее не бывает. signed/unsigned char в Сях - это грабли, ручка которых никогда не тускнеет.

From:

Попытался себе представить как числа 81 и 31 (меньшие 128) оказались под этими граблями и не смог.

From:

Соседние оказались больше 128 :-)
Адреса типа 10.10.27.34 - проходили отлично :-)

From:

все равно не понятно

From:

yuridichesky.livejournal.com

Что-то я не понял: в клубе наступальщиков на эти грабли сплошь и рядом приличные люди или наоборот? Волнуюсь.

From:

Саша вычислил эту ошибку по-моему за единицы минут. Что какбе говорит нам что наверное не в первый раз :-)
Я, вопмщем, думаю что в клубе наступальщиков на эти грабли вообще просто все. Очень демократичный клуб.

From:

struct in_addr
ertpinet(char a, char b, char c, char d)
{
 struct in_addr in;
 in_addr_t ip;
 in.sin_addr.s_addr = ((((d<<8) | c) << 8) | b)<<8) | a);
 return in;
}

ну и где тут такой фифиект будет?
требую показа кода.

From:

krotoff.livejournal.com

нет, ну я вас умолеяю!!
с | все будет даже смешнее, чем с +.

From:

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

From:

    char               k[ 4 ];

    blah_blah_blah(k);

    sin.sin_addr.s_addr = endian_to_be32(   k[ 3 ] +
                                          ( k[ 2 ] << 8 ) +
                                          ( k[ 1 ] << 16 ) +
                                          ( k[ 0 ] << 24 ) );

From:

а почему не написали просто

sin.sin_addr.s_addr = hostendian_to_be32( *(int32 *)k );

From:

Понятия не имею.

From:

И правильно что не написали. У меня на машине такой код крэшится.

From:

у тебя не выравнивают массивы на границу 4-х байтного целого?

From:

Кто бы ещё k выровнял, если это приходит из сети в составе буфера какого-то.

From:

pzz.livejournal.com

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

From:

Блин, я, пока это не увидел, тоже не понял. Это, кстати, не одни классические грабли, а несколько! Нафига было это, вообще, складывать. Нежто, это нельзя было в массив запихать? Сразу в Big-Endian порядке. ОООО, безумный мир.

From:

Да нет, там же массив на стеке определяется. Но ты прав, это не на любой архитектуре сработает. Но можно union использовать. Он-то должен будет выровнен.
PS: На интеле всегда будет нормально работать. На сане, я помню, невыровненные числа заваливали программу, если ее не скомпилировать со специальным флагом (будет работать, но медленее). А у тебя оно падает, поди, на старом, не интеловском, маке.

Edited Date: 2009-11-13 05:45 pm (UTC)

From:

На интеле невыровненные числа чуть замедляют работу программы. Особенно, если они на границах cache lines.

А здесь, если мы не можем предсказать, какие данные и какого размера были в буфере до k, мы не можем гарантировать выровненность k.

char buf[] = { ..., 1, 2, 3, 4, ... }; // ← пришло по сети.
k = &buf[N]; // ← N ← начало айпи адреса в буфере

From:

Там в примере было char k[4] :-)

From: