Pathoswithin
app_path много лет был 1024 байта. Это должно быть в глубинах форума. И буфер во всех приложениях для него 1024 байта. А теперь ядро туда может записать 4Кб, не проверяя, влезет или нет. Что в этом хорошего ? Если меняешь ABI, обеспечивай совместимость.
Путь приложения
А что в этом несовместимого? Что раньше ядро делало, если путь не влазил в argv[0]?
Объявлено в глубинах форума... надо запомнить эту фразу.
Объявлено в глубинах форума... надо запомнить эту фразу.
Pathoswithin wrote:А что в этом несовместимого?
Serge wrote:теперь ядро туда может записать 4Кб, не проверяя, влезет или нет.
Оно не писало больше 1024 байта, и поэтому он туда влазил. Приложениям достаточно было просто выделять буфер на 1024 байта.Pathoswithin wrote:Что раньше ядро делало, если путь не влазил в argv[0]?
Ну теоретически завтра можно вообще сделать эту константу на 10Kb. И сказать, что она теперь такая вот стала, вот и исправляйте свои приложения.Pathoswithin wrote:В коде было где как: и 1024, и 4096, и даже 260. Теперь везде одна константа. Где приложения работали, там по прежнему работают.
Вообще-то, если что-то ломаешь, то нужно тогда везде правки вносить. И не создавать проблемы другим участникам.
А или лучше сделай себе бранч и играйся в игрушки там.
Понятно, что не писало больше, я не об этом. Наводящий вопрос: как потом приложение работало с обрубком пути?
Pathoswithin
Да, работало с обрубком пути. Shit happens. Раньше ядро писало 1023 байта пути и завершающий ноль. А теперь затрёт память с непредсказуемыми последствиями.
Кстатиfilename_size может быть равно 4096 ?
Я не знаю нужен ли такой длинный путь. Когда diamond установил ограничение 1023 байта у него наверное были разумные причины.
Да, работало с обрубком пути. Shit happens. Раньше ядро писало 1023 байта пути и завершающий ноль. А теперь затрёт память с непредсказуемыми последствиями.
Кстати
Code: Select all
mov ecx, [ebp+APP_HDR.filename_size]
rep movsb
mov byte [edi], 0
Я не знаю нужен ли такой длинный путь. Когда diamond установил ограничение 1023 байта у него наверное были разумные причины.
Если знать где искать, можно найти много интересного. viewtopic.php?f=35&t=475&p=6218#p6218Pathoswithin wrote:Объявлено в глубинах форума... надо запомнить эту фразу.
diamond wrote:1. Путь (если он требуется) передаётся "как есть", т.е. как его передало 70-й функции запускающее приложение. При этом длина пути с учётом завершающего нуля не может превосходить 1024 символов (иначе вызов 70-й функции провалится).
*запускалось с обрубком пути. А как оно работало?
Это от приложения зависит. Главное, что не падало в ядре с утечкой памяти. Я напомню, что все программы на Си/Си++ обязательно получают путь к приложению. Независимо от того, нужен он им, или нет. Т.е. все эти программы в данный момент уязвимы.
Винда при пути больше 260 байт просто выкидывает ошибку на попытку открыть файл. То есть у программы не будет слишком длинного пути - она просто не запуститься. Вот и всё. Никто ничего не затрёт, если будет определённая константа и ядро с приложениями будут её учитывать.
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
GerdtR
Константа была, 1023 байта + завершающий ноль. А теперь её увеличили до 4Кб, даже не сообщив об этом.
Константа была, 1023 байта + завершающий ноль. А теперь её увеличили до 4Кб, даже не сообщив об этом.
И как обычно проблемы с сями... Тогда так: если на ограничение в 1023 байта были разумные причины, то путь никогда не будет длиннее и проблем не возникнет, а иначе значит, что 1023 байта мало, и я правильно сделал. Собственно, программам ничего не запрещает выделить буфер ещё меньше, и в большинстве случаев его тоже хватит. В идеале, надо было изначально делать так, чтоб ядро выделяло буфер, а не приложение (как со слишком длинной строкой параметров).
Pathoswithin
В идеале да. Но для командной строки почти десять лет потребовалось. Умная мысля иногда приходит с большой задержкой.
Я думаю 1023 байта для пути достаточно. Я хотел вообще убрать отдельный буфер для текущего каталога и хранить путь в структуре процесса. Тем более, что он общий для потоков в многопоточном приложении.
В идеале да. Но для командной строки почти десять лет потребовалось. Умная мысля иногда приходит с большой задержкой.
Я думаю 1023 байта для пути достаточно. Я хотел вообще убрать отдельный буфер для текущего каталога и хранить путь в структуре процесса. Тем более, что он общий для потоков в многопоточном приложении.
Serge wrote:Я думаю 1023 байта для пути достаточно.
Я тоже думаю, достаточно. Надо просто сделать maxPathLength = 1024, тем самым вернув всё на свои места.Serge wrote:Константа была, 1023 байта + завершающий ноль. А теперь её увеличили до 4Кб
По-моему, хорошая идея.Serge wrote:Я хотел вообще убрать отдельный буфер для текущего каталога и хранить путь в структуре процесса.
Верните кто-нибудь обратно. Pathoswithin никогда не будет признавать своих косяков, он всегда прав. Пора было уже понять это.
Куда вернуть? Я там половину переделал. И я действительно не признаю косяков, если их нет, тут обсуждается чисто теоретическая проблема.
Конечно, можно и ограничить длину argv[0] до 1024, это запросто, но длину пути для доступа к файлам лучше оставить 4096.
Конечно, можно и ограничить длину argv[0] до 1024, это запросто, но длину пути для доступа к файлам лучше оставить 4096.
Я же привел примеры, где используется.
Если ограничивать путь 256 символами, то при наихудшем раскладе х4, 1к достаточно.
Если ограничивать путь 256 символами, то при наихудшем раскладе х4, 1к достаточно.
Who is online
Users browsing this forum: No registered users and 4 guests