Здравствуйте, smeeld, Вы писали:

S>Здравствуйте, pagid, Вы писали:

S>fopen ничем не плох, но это одна из немногих POSIX функций, сотавленных MS без перекарёживания по-своему. Выше у меня иллюстрация того, как придётся в целом работать с POSIX в MS.

fopen же не только POSIX функция, но и С89 и C99 функция,
еще бы ее перекорежили.

Но с fopen конечно есть проблемы, как и любая функция принимающая "char *",
у нее проблемы с не ASCII именами файлов, а их удивительно много на машинах обычных пользователей.
MS недавно добавили: `fopen("newfile.txt", "rt+, ccs=UTF-8")`, но насколько новый C Runtime нужно
к своему приложению прилинковывать чтобы это работало и совместим ли такой способ с
Linux/glibc

Здравствуйте, pagid, Вы писали:

P>А это точно POSIX функция?

Это POSIX

Здравствуйте, smeeld, Вы писали:

S>Это POSIX
В том смысле, что она водит в POSIX как в стандарт, но она входит и в стандартную библиотеку Си, в стандарт языка входит, и до того как приняли первый стандарт в неформальные описания языка. Изначально fopen это была функция из стандартной библиотеки Си, а open() — системный вызов UNIX, задолго до того, как за разработку POSIX'а взялись.

Здравствуйте, smeeld, Вы писали:

S>Поэтому придётся делать так:

В обеих версиях open'а, если предполагается создание файла, нужен третий параметр — пермиссии нового файла.

Здравствуйте, Zhendos, Вы писали:

Z>Но с fopen конечно есть проблемы, как и любая функция принимающая "char *",
Z>у нее проблемы с не ASCII именами файлов, а их удивительно много на машинах обычных пользователей.

У _open() те же проблемы. В этом отношении оно ничем не лучше


Z>MS недавно добавили: `fopen("newfile.txt", "rt+, ccs=UTF-8")`, но насколько новый C Runtime нужно
Если не ошибаюсь это не о имени файла, а о его содержимом.

Z>овместим ли такой способ с Linux/glibc
Вроде как игнорироваться должно, если там нет аналогичного.

Здравствуйте, Pzz, Вы писали:

Pzz>В обеих версиях open'а, если предполагается создание файла, нужен третий параметр — пермиссии нового файла.

Это и ежу понятно. Выше псевдокод-иллюстрация про #define с _MSC_VER и _open c open. То, чем напичкан кроссплатформенный код на Сях. Там ещё куча всего, вроде возни c dllimport/dllexport, разницы в разрядности встроенных типов, чудесный MS-вский препроцессор, нарушающий стандарты, чем ТС набьёт немало шишек, расписывая кроссплатформ на Сях.

Здравствуйте, m11, Вы писали:

m11>

m11>#include <sys/types.h>
m11>#include <sys/stat.h>
m11>

m11>Debian, вроде как надо искать пакет этих заголовков

apt-get install libc6-dev

Здравствуйте, m11, Вы писали:

m11>Изначально я планировал писать на С. Ведь портируют же серьезные системы вроде apache mysql dig и тд
m11>а тут оказывается проще на С++ писать

И на C и на C++ для всего, что не входит в стандартную бибилиотеку и что является платформо-зависимым нужно писать

#ifdef <макрос, определяющий платформу>
// платформозависимый код
#else
// платформозависимый код
#endif

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


Например — заглянул я сейчас в исходники Апача. Увидел такой код (server/util_script.c):

#if defined(WIN32)
    env2env(e, r, "SystemRoot", NULL);
    env2env(e, r, "COMSPEC", NULL);
    env2env(e, r, "PATHEXT", NULL);
    env2env(e, r, "WINDIR", NULL);
#elif defined(OS2)
    env2env(e, r, "COMSPEC", NULL);
    env2env(e, r, "ETC", NULL);
    env2env(e, r, "DPATH", NULL);
    env2env(e, r, "PERLLIB_PREFIX", NULL);
#elif defined(BEOS)
    env2env(e, r, "LIBRARY_PATH", NULL);
#elif defined(DARWIN)
    env2env(e, r, "DYLD_LIBRARY_PATH", NULL);
#elif defined(_AIX)
    env2env(e, r, "LIBPATH", NULL);
#elif defined(__HPUX__)
    /* HPUX PARISC 2.0W knows both, otherwise redundancy is harmless */
    env2env(e, r, "SHLIB_PATH", NULL);
    env2env(e, r, "LD_LIBRARY_PATH", NULL);
#else /* Some Unix */
    env2env(e, r, "LD_LIBRARY_PATH", NULL);
#endif