Это не срач, это оживленная дискуссия...
Лично я принимаю в ней участие, так как столкнулись с проблемой когда программа написанная профессионалами падала на разборке реестра запрещенных...из-за того, что не ожидала такие данные...
Пришлось нам не профессионалам писать самим на чистом PHP
нахрена??? поставить указатель на начало поиска зная указатель конца буфера можно простым вычитанием длины данных, здесь это значение равно 39, то-есть указатель начала блока данных равен указатель конца буфера минус 39
очень сомнительный подход. В нем вам понадобится буфер длиной, как минимум в размер блока данных. Здесь вам повезло и длина блока данных всего 39 байт. В реальном ответе сервера она легко может быть и 39 Кбайт и 39 Мбайт. Будете проматывать 39 Мбайт сначала вперед, чтоб найти конец, а потом обратно. чтобы отнять от конца 39Мбайт ? :) Интересно, в какой буфер вы поместите этот блок?
Правильно построенный парсер может найти нужные данные в блоке произвольной длины. обойдясь буфером в 32 или 64 символа :)
Обычно, гораздо меньшим. Правильному парсеру не требуется буфер длинее самой длинной лексемы разбираемого текста. Для лексического анализатора С - это обычно 32 байта, т.к. именно такой длины может быть имя переменной в большинстве компиляторов, но в большинстве случаев лексемы гораздо короче.
Правильно построенный парсер может найти нужные данные в блоке произвольной длины. обойдясь буфером в 32 или 64 символа :)
Эта, ты кому тут собрался читать теорию синтаксического и лексического анализа? Тут бы разобраться, какой тип данных подсовывать функции strstr, а ты тут со своими парсерами :) :) :)
Обычно, гораздо меньшим. Правильному парсеру не требуется буфер длинее самой длинной лексемы разбираемого текста. Для лексического анализатора С - это обычно 32 байта, т.к. именно такой длины может быть имя переменной в большинстве компиляторов, но в большинстве случаев лексемы гораздо короче.
Правильному парсеру вообще не нужен буфер, он это сделает на регистрах )))
Так это без разницы, речь то о размере буфера, а буфер - он и есть буфер, а уж на регистрах он или ещё на чём - хоть на бумажке записывается.
Не я не о том, что... "Си-программист стыдливо возится с буферами и указателями, иногда применяя Yacc и Lex"...
Речь о парсинге текста голым железом )))
Зря не читаете комментарии к статьям, на которые ссылаетесь. Там промежду прочим есть грамотное возражение про "пирсинг голым с железом". В общем, это не совсем то, что Вы подумали. :)
Зря не читаете комментарии к статьям, на которые ссылаетесь. Там промежду прочим есть грамотное возражение про "пирсинг голым с железом". В общем, это не совсем то, что Вы подумали. :)
Опять срач на ровном месте?
Это не срач, это оживленная дискуссия...
Лично я принимаю в ней участие, так как столкнулись с проблемой когда программа написанная профессионалами падала на разборке реестра запрещенных...из-за того, что не ожидала такие данные...
Пришлось нам не профессионалам писать самим на чистом PHP
Ну, профессионалы бывают разных специальностей...
Ну, профессионалы бывают разных специальностей...
мы говорим о программистах )))
Это не срач, это оживленная дискуссия...
Так и я ж про тоже.
нахрена??? поставить указатель на начало поиска зная указатель конца буфера можно простым вычитанием длины данных, здесь это значение равно 39, то-есть указатель начала блока данных равен указатель конца буфера минус 39
очень сомнительный подход. В нем вам понадобится буфер длиной, как минимум в размер блока данных. Здесь вам повезло и длина блока данных всего 39 байт. В реальном ответе сервера она легко может быть и 39 Кбайт и 39 Мбайт. Будете проматывать 39 Мбайт сначала вперед, чтоб найти конец, а потом обратно. чтобы отнять от конца 39Мбайт ? :) Интересно, в какой буфер вы поместите этот блок?
Правильно построенный парсер может найти нужные данные в блоке произвольной длины. обойдясь буфером в 32 или 64 символа :)
Обычно, гораздо меньшим. Правильному парсеру не требуется буфер длинее самой длинной лексемы разбираемого текста. Для лексического анализатора С - это обычно 32 байта, т.к. именно такой длины может быть имя переменной в большинстве компиляторов, но в большинстве случаев лексемы гораздо короче.
Правильно построенный парсер может найти нужные данные в блоке произвольной длины. обойдясь буфером в 32 или 64 символа :)
Эта, ты кому тут собрался читать теорию синтаксического и лексического анализа? Тут бы разобраться, какой тип данных подсовывать функции strstr, а ты тут со своими парсерами :) :) :)
Обычно, гораздо меньшим. Правильному парсеру не требуется буфер длинее самой длинной лексемы разбираемого текста. Для лексического анализатора С - это обычно 32 байта, т.к. именно такой длины может быть имя переменной в большинстве компиляторов, но в большинстве случаев лексемы гораздо короче.
Правильному парсеру вообще не нужен буфер, он это сделает на регистрах )))
Да, как Вам новость?
Так это без разницы, речь то о размере буфера, а буфер - он и есть буфер, а уж на регистрах он или ещё на чём - хоть на бумажке записывается.
Так это без разницы, речь то о размере буфера, а буфер - он и есть буфер, а уж на регистрах он или ещё на чём - хоть на бумажке записывается.
Не я не о том, что... "Си-программист стыдливо возится с буферами и указателями, иногда применяя Yacc и Lex"...
Речь о парсинге текста голым железом )))
"Си-программист стыдливо возится с буферами и указателями, иногда применяя Yacc и Lex"...
"стыдливо" - это про вас надо сказать, о том как вы съехали с темы :)
Зря не читаете комментарии к статьям, на которые ссылаетесь. Там промежду прочим есть грамотное возражение про "пирсинг голым с железом". В общем, это не совсем то, что Вы подумали. :)
Годная новость но .. блин страеют марвеловцы .. э-эх.
Так вот взяли бы да и выложили что используете, что изменили, глядишь и автор бы что-то перенял у Вас. Нет жеж .. :)
Зря не читаете комментарии к статьям, на которые ссылаетесь. Там промежду прочим есть грамотное возражение про "пирсинг голым с железом". В общем, это не совсем то, что Вы подумали. :)
читал, и даже что-то понял )))