Существует ли эквивалент MAX_PATH WinAPI в соответствии с linux/unix?
Вы просто копируете начальный адрес str в temp. Это означает, что любые изменения в temp будут отражены и в str, поскольку они указывают на одну и ту же память. Он по-настоящему не эмулирует strcpy(dest, src), что создает отдельную копию строки с нулевым символом в конце, на которую указывает src, начиная с ячейки памяти, на которую указывает dest.
Итак, чтобы ответить на ваш вопрос как на вопрос: нет.
Если ваше намерение состоит в том, чтобы избежать времени выполнения O (n) strcpy, это также то, что вы не можете сделать на самом деле.
Если для программирования или выполнения упражнения вам потребуется создать код, функционально эквивалентный strcpy, вот высокоуровневое описание алгоритма, который он использует:
- Скопируйте символ в
*source-*destination - Если только что скопированный символ был нулевым терминатором, выйдите.
- В противном случае увеличьте указатель до
sourceи увеличьте указатель доdestination. - Перейти к шагу 1.
4 ответа
There is a PATH_MAX, but it is a bit problematic. From the bugs section of the realpath(3) man page:
The POSIX.1-2001 standard version of this function is broken by design, since it is impossible to determine a suitable size for the output buffer, resolved_path. According to POSIX.1-2001 a buffer of size PATH_MAX suffices, but PATH_MAX need not be a defined constant, and may have to be obtained using pathconf(3). And asking pathconf(3) does not really help, since, on the one hand POSIX warns that the result of pathconf(3) may be huge and unsuitable for mallocing memory, and on the other hand pathconf(3) may return -1 to signify that PATH_MAXis not bounded.
Остальные ответы до сих пор кажутся правильными в отношении * nix-аспектов, но я добавлю предупреждение об этом в Windows.
Вам лгали ( бездействием) по документации.
MAX_PATH действительно определен и, вероятно, даже применяется к файлам, хранящимся в FAT или FAT32. Однако любое имя пути может иметь префикс \\? \ , чтобы указать Windows API игнорировать MAX_PATH и позволить драйверу файловой системы принять собственное решение. После этого определения становятся нечеткими.
Добавьте к смеси тот факт, что имена путей на самом деле являются Unicode (ну, UTS-16) и что при использовании API «ANSI» преобразование во внутреннее имя Unicode и обратно зависит от множества факторов, включая текущую кодовую страницу, и у вас есть рецепт для путаницы.
Хорошее описание правил для Windows можно найти по адресу MSDN . Правила намного сложнее, чем я здесь изложил.
Редактировать: Я изменил \\. \ на \\? \ в вышеупомянутом благодаря комментарий от KitsuneYMG.
Пути и пространства имен Windows сложны. Некоторые могут даже утверждать, что они слишком сложны. Одним из источников сложности является то, что Win32 (а теперь и Win64) API - это подсистема, расположенная поверх собственной системы Windows NT.
Путь без префикса совместим с самыми разными платформами Windows. Если он ограничен 7-битными символами ASCII, то он совместим с 16-битной DOS начиная с версии 2.0 или около того (всякий раз, когда были введены подкаталоги, которые могли фактически быть в DOS 3; но DOS 1. 0 имел только корневые каталоги, а символ \ не имел особого значения).
Префикс \\? \ приводит к тому, что баланс имени пути передается дословно в соответствующий драйвер файловой системы, который создает эффект удаления ограничения до MAX_PATH символов. Если длинный путь также есть в общем сетевом ресурсе, вы можете использовать для него расширенное имя UNC с префиксом \\? \ UNC \ server \ share \ вместо обычного имени UNC \\ сервер \ папка \ . Использование этого префикса ограничивает переносимость для Win32 и более поздних платформ Windows, но если вам не требуется поддержка 16-битной Windows на устаревшем оборудовании, это не является большой проблемой.
Префикс \\. \ другое животное. Это позволяет получить доступ к объектам устройств за пределами набора устройств с особыми именами, которые автоматически сопоставляются Windows как специальные имена файлов в каждой файловой папке. К этим специальным именам относятся CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8 и LPT9. Обратите внимание, что все эти имена являются особыми, независимо от того, используется ли расширение или в любом сочетании верхнего или нижнего регистра. Но возможно, что у вас установлено 10 или более COM-портов. Это происходит быстро, если вы играете с USB-модемами или адаптерами последовательного порта USB, поскольку каждому уникальному последовательному порту на основе USB будет назначено отдельное имя COMn. Если вам нужен доступ к 50-му последовательному порту, вы можете сделать это только с именем \\. \ COM50 , поскольку COM50 - это , а не , а специальное имя, такое как COM1.
Well, on Linux at least, there is:
PATH_MAX(defined inlimits.h)FILENAME_MAX(defined instdio.h)
both of these are set to 4096 on my system (x86 Linux).
Update: : Some info from the glibc manual on this
Each of the following macros is defined in limits.h only if the system has a fixed, uniform limit for the parameter in question. If the system allows different file systems or files to have different limits, then the macro is undefined; use pathconf or fpathconf to find out the limit that applies to a particular file
You can use pathconf() to figure out at run-time, but there's also a PATH_MAX preprocessor define in