- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
static int internal_CheckMac(char * inc_mac)
{
int return_value = 0x1;
if (strlen(inc_mac) != 17)
{
return return_value;
}
unsigned int i = 0x0;
for (i = 3; i <=17; i=i+2)
{
if (inc_mac[i-1] != 58)
{
return_value = 0x1;
break;
}
else
return_value = 0x0;
i++;
}
return return_value;
}
Функция проверяет содержимое строки. В строке должен быть мак адрес формата 00:01:02:03:04:05. 58 в строке 13 - это десятичное значение символа ":"
Авторство функции принадлежит Виталию Кострову, великому программисту из Рыбинска. После ревизии этого кода пришло понимание что надо избавляться от этого сотрудника.
Follow us!
код говно, но это меркнет на фоне вашего мужского поступка
> i++;
> 58
> 17
sscanf(addr, "%X:%X:%X:%X:%X:%X", &u8[0], &u8[1], &u8[2], &u8[3], &u8[4], &u8[5]);
Считаю что, ФИО гавнюков(написавших код) не подлежит огласке, в силу программистской этики.
P.S. "Мудрые обсуждают идеи. Умные — события. Глупые — других людей." (с)
Виталий Костров, человек и ASCII таблица.
Однако у вас вышло тоньше всех...
Fixed?
Тем временем уже есть C11 с генериками...
чтобы не ломать существующий десятилетиями код, добавили _Вот такое вот новое _Слово, потому что _Имели _Право
По-моему, требование совместимости с архаичными стандартами, что для C, что для C++, делает их с каждым новым обновлением всё менее элегантными. И скоро это превратится в жуткую кашу, если уже не превратилось.
на самом деле, реальная совместимость старого и нового синтаксиса должна быть разрулена ключами компиляции,
а раз ты ССЗБ, что скопипастил старый костыльный код именно в файл с новым синтаксисом - ну значит, не западло будет и исправить руками, никаких уже отмазок "но мы не можем ведь поменять старый код!" уже приниматься не должно
Поменять одно слово (внизапно ставшее ключевым) на другое во всех файлах проекта - говно вопрос, а уродство в языке - навсегда.
Да, scanf - не замена регэкспам.
Придётся ещё либо strlen, либо все шесть интов проверять на (i == i & 0xff). А это некузяво. :(
формат %02x подразумевает, что больше 1 байта не вычитается
sscanf вернет число успешно распарсенных значений - их должно быть ровно 6
можно, например, тупо "%02x:%02x:%02x:%02x:%02x:%02x%с", проследить, что либо результат == 6, тогда ок, либо == 7, тогда проверить последний char на isspace
во всех остальных случаях - не ок
по поводу регэкспа - если мне будет не лень, напишу тестик
в той же винде, например
мне сейчас лень искать официальные документы на MAC-48 на предмет регламента записи 6 октетов
под виндой, как обычно, сишные stdio работают супер-шустро, пока не выставишь локаль
код:
http://liveworkspace.org/code/b828b89821d56ecf74dd7219bdfe64fd
на винде результаты:
test_mac_sscanf : 93 milliseconds
test_mac_boost_regex : 244 milliseconds
test_mac_boost_xpressive : 608 milliseconds
after locale setup......
test_mac_sscanf : 292 milliseconds
test_mac_boost_regex : 235 milliseconds
test_mac_boost_xpressive : 611 milliseconds
на линухе x86 результаты:
test_mac_sscanf : 111 milliseconds
test_mac_boost_regex : 314 milliseconds
test_mac_boost_xpressive : 3315 milliseconds
after locale setup......
test_mac_sscanf : 134 milliseconds
test_mac_boost_regex : 317 milliseconds
test_mac_boost_xpressive : 3300 milliseconds
на линухе x86_64:
см ссылку на liveworkspace
выводы -
1) расхваленный boost::xpressive очень сильно отстает от boost::regex на 32-битном коде, отставание сокращается на х64, но всё равно сильно заметно
2) строгое ожидание 2 hex символов в октете заставило меня использовать уродское %1x%1x, может я подзабыл все нюансы формата, но я не смог заставить %02x парсить ровно 2 символа, а не не более 2 символов (т.е. он дозволял :a:b: и я это только так поборол)
3) для boost::regex есть мутные намеки в интернете, что если его перекомпилировать с некими доп. настройками, он будет работать в 2-3 раза быстрее (типа USE_CPP_LOCALE), но если честно, не сильно хочется пробовать
может я его не умею готовить...
http://bit.ly/NAX1aE - видать инфа о превосходстве борна несколько устарела (Boost.Regex Version: 1.33+, BOOST_REGEX_USE_CPP_LOCALE, BOOST_REGEX_RECURSIVE)
кстати еще всплывала мысль запилить тест на boost::spirit, вспомнить молодость так сказать, но на работе иногда и поработать надо
Ага. Но ведь "регулярка" - это тоже некоторая (выбранная ввиду частой встречаемости) грамматика.
> будет считать валидным "11-22:33-44:55-66"?
<|> пробует левый парсер, если он ничего не смог съесть - переключается правый (развилка без возврата).
А здесь по разделителю строится целиком парсер последних 15 символов, вроде все путем.
BTW: не подскажите как boost можно прилинковать для быстрой проверки из командной строки?
(*.pc нема, не make же файл писать, а то по ошибкам выбирать долго)
линукс для меня не родная система, поэтому если я что то компилю из командной строки, то указать вручную одну директорию поиска и несколько имен в -l не особо напрягает (-L/usr/lib/boost -lboost_system -lboost_regex -lboost_chrono ...)
а большие проекты под линухом - там список один раз задан и подставится автоматом
если честно, не знаю способа, чтобы код в gcc/ld самостоятельно искал, какие либы он хочет линковать (типа pragma comment lib в студийном тулчейне)
http://liveworkspace.org/
Даже компиляторы и бусты распаковывать себе не придется. Все уже готово онлайново и весьма удобно в онлайновой иде.
По теме - интересно, почему на линухе xpressive настолько медленный.
P.S. На liveworkspace только у меня глючит редактор (пишет символы 2-3 знакоместа правее курсора), когда включена подсветка синтаксиса?
Может за это минуснули, типа "непоказательно"?
Ага.
http://v6decode.com/
2001:0db8:0000:0000:0000:0000:1428:57ab
201:0db8:0000:0000:0000::1428:57ab
21:0db8:0:0:0:0:1428:57ab
1:0db8:0:0::1428:57ab
2001:0db8::1428:57ab
2001:db8::1428:57ab
http://download.dartware.com/thirdparty/test-ipv6-regex.pl
И мужик...
>какой-то фигни вместо ойпи адреса
fixed
Найн
Жаль...
Просто надо взять и осилить регэкспы, бле@ть!
Не нужны.
Не нужно.
Да скорее всего тупой конечный автомат. Не думаю, что там будут регулярки.
> владеть несколькими методами
Безусловно.
> А там уже по обстоятельствам.
Вот-вот. Написать тот же автомат или регулярку не сложно и не долго. Только вот тот же inet_pton уже отлажен и оттестирован. А с регуляркой все это проходить заново. Так что нужны очень веские обстоятельства, чтобы этим заниматься...
Например лаборатория одного очень не безызвестного дяди умеет определять,
что вызывают для своей работы программы безызвестных дядь...
1) считает подозрительным по умолчанию всё , если им же(продуктом) не доказано обратное;
2) тем более подозрительным всё то, что использует функции из множества «сетевые».
Если смотреть немного шире, то по существу, дублирование функционала
(естественно, там где это возможно/разумно/etc), несколько усложняет
анализ продуктов безызвестных дядь, а значит повышает их шансы на успеваемость.
Это всё к тому, что необходимость есть, может и не такая повседневная, но есть.
говнокод?
Как показало обсуждение strlen делать все равно надо.
А цикл проверки на валидность формата в котором
представлены данные самый быстрый.
Сразу возникает вопрос, а была ли поставлена задача
в данной функции проверять данные записанные в этом
формате.
Так намана, насяльника?
Не у всех есть компилятор C99
> ctype.h
> hex_digit_p
isxdigit
> validator validators[17]
Создание массива на стеке при каждом вызове функции
> for (i = 0; i < 17; ++i)
семнадцать вызовов функций для проверки одной маленькой строки как-то жирновато
А компилятор не догадается, что это константа и можно только 1 раз инициализировать?
Та ну, в массиве всего 17 элементов... можно и руками заполнить, подумаешь... тем более, что как выяснилось, нужно было бы еще добавить последним номером в этой программе проверку на то, что последний символ таки ноль. Можно было бы написать функцию, которая это делает, но она была бы совсем одноразовой.
Про компилятор С99... я последний раз писал на Си примерно в том же году... так что извиняйте... я не в курсе последних изменений.
По поводу проверки - если честно, то не понятно, что именно мы проверяем, т.как у МАК адресов нет задокументированой печатной формы, есть только общие какие-то "пожелания", где говорится что, например, можно использовать значек переноса вместо двоеточия, но я не видел ни одного примера где бы использовались одновременно и двоеточия и переносы. Изза чего не понятно можно ли допускать и то и другое одновременно.
Что до ipv6, то там вообще, как обычно, жопа полная в смысле написания и расшифровки. Там возможно 17 вызовами не обойтись. Как-то инженерная озадаченная сила любит озадачивать оставшуюся часть незадачливого человечества всякой херней в духе электорпочтовых адресов, универсальных идентификаторов в интернете и т.п. Этот совсем даже не исключение.
> (
> r=validators[0](x),
> rotate(begin(validators), end(validators)-1, end(validators)),
> r
> );
Хахах. Что только не сделают крестушки, чтобы использовать вывод типа результата лямбды и не указывать его вручную. Haskell чтоле возьми.
Можно было обойтись и без тежолой function<bool(char)>
P.S. Сорри, хотел плюсануть, а попал в минус.
я старался
> не претендует на обобщенность
хотел намекнуть, что микро-язык можно легко расширить и принимать шаблон как параметр, но делать этого не стал.
> Сорри, хотел плюсануть, а попал в минус
У меня, кстати, родилась вот какая идея для клона гк:
заменить плюсы и минусы битовыми сдвигами только не совсем понять, как быть с отрицательным рейтингом... или так
Двоичной дробью.
P.S. Сорри, хотел плюсануть, а попал в минус. Проклятье минуса. :\
fixed
"xx:xx:xx:xx:xx:xx"
В отличие от Хацкильного варианта и magic number проверок длины.
Тебя же процитировали.
Зачем вообще акцентировать на этом внимание?
Не примет. У тебя там лишний пробел. :D