Вопрос к программистам на C , Исходники ядра Linux

Чего ж у тебя такая психика неустойчивая? ржешь и ржешь
Ну захотелось человеку использовать WinAPI. Неужели это запрещено?
Естественно, можно это же написать с помощью opendir/readdir/closedir/remove/rmdir

Добавлено 24.07.06, 06:11
А это чтобы ты просто уржался:

int __cdecl _trmdir (
        const _TSCHAR *path
        )
{
        ULONG dosretval;
 
        /* ask OS to remove directory */
 
        if (!RemoveDirectory((LPTSTR)path))
            dosretval = GetLastError();
        else
            dosretval = 0;
 
        if (dosretval) {
            /* error occured -- map error code and return */
            _dosmaperr(dosretval);
            return -1;
        }
 
        return 0;
}

Цитата

А вот здесь я РЖАЛ!!!

WinAPI + STL - крайне неудачная связка. В основном по причине очень странного интерфейса к std::string.

Сообщение отредактировано: BugHunter - 24.07.06, 06:19

Цитата the_Shadow @ 23.07.06, 12:34

С циндой несколько сложнее. С версии 2003 и XP, M$ божится, что версии функций, характерные для подсистемы POSIX изъяты (deprecated) и заменены на более безопасные эквиваленты, имена коих начинаются с символа "_". Это справедливо для M$ DevStudio 2005 и выше, насколько я понимаю. Более подробно -- в локальном M$DN или туттта -> http://msdn2.microsoft.com/ko-kr/library/ms235384.aspx, а так же -> http://msdn2.microsoft.com/ko-kr/library/wt8es881.aspx и http://msdn2.microsoft.com/ko-kr/library/ms235318.aspx. Но, самое важное на мой взгляд то, что поведение этих функций сходно. То, что M$ выкинула в чичтом виде ф-ии POSIX и OS/2 -- дело её. Думаю, скоро опять включит (выше объяснял почему им пришлось это включать, это же сработает и сейчас), но не столь суть.

Шадыч, вылезай из танка. Война уже давно закончилась... А ты все поезда под откос пускаешь. Я не видел ни одной студии (и ни одного MSDN начиная года с 1999-го), где POSIX-функции были без подчеркивания. Т. е. можешь считать, что ситуация обстоит таким образом изначально. Сейчас специально проверил - в MSDN 2001-го года нет функции rmdir. Есть _rmdir. В хидерах 6-ой студии (это 98-ой год) в хидере direct.h (замечу - отнюдь не unistd.h, как того требует POSIX) эти функции также начинаются с подчеркивания. Также замечу, что уже замусоленный тут ISO 9899:TC2 (Committee Draft 2005 - это то, чем я пользуюсь) вообще не содержит этих функций. А потому как, под каким видом и соусом их положит разработчик конкретного компилятора (и положет ли вообще) стандарт языка С абсолютно не колышет.

Цитата the_Shadow @ 23.07.06, 12:34

Таким образом, если мы возьмём сырец из Linux, то через #define для версии под цинду, эти функции мы можем использовать, выставив для них лидирующий символ "_".

А я тебе о чем писал?

Цитата Flex Ferrum @ 20.07.06, 22:11

Да не является он <компилятор MSVC - FF для сохранения контекста> POSIX-совместимым компилятором. В нем даже не весь набор CRTL-ных методов поддерживатся, и код, написанный чисто на MS C в общем не портабельный без #ifdef'ов и #define'ов.

А ты мне про какую-то совместимость втриал. Винда является POSIX-совместимой только с установленной поверх нее POSIX-подсистемы (то, что у них называется INTERIX). При это в качестве средства компиляции может быть использован как штатный (идущий в составе этой подсистемы) компилятор gcc, так и компилятор VC (но только в виде "голого" компилятора, т. е. без сопутствующих хидеров и библиотек), буде он установлен на машине и к нему прописаны пути. Об этом явно написано в одной из приведенных тобою ссылок:

Цитата

Interix provides a rich set of command-line and stand-alone tools for building, debugging, and testing applications. Tool categories delivered with the SDK are:

* Compiling (cc, c89, gcc, g++, and g77)
* Linking (ld)
* Debugging (gdb)
* File management
* Performance
* Testing

Interix integration with Visual C++

If Visual C++ is installed, SFU Setup will configure the Interix SDK to work with Visual C++.

If Visual C++ is installed after the Interix SDK, the location of the Visual C++ compiler and linker is provided manually to the cc(1) and c89(1) utilities. The developer does this by using the Windows System Properties dialog box to create a Windows system variable named INTERIX_COMPILERDIR and setting its value to the path of the directory where Visual C++ is installed, in POSIX format. For example, if Visual C++ is installed in directory C:\MSDEV, the value of INTERIX_COMPILERDIR would be /dev/fs/C/MSDEV. If the path contains spaces, the MS-DOS version of the path should be used.

http://msdn.microsoft.com/library/default....ml/UCMGch02.asp

Цитата the_Shadow @ 22.07.06, 15:01

Flex, отдельно хочу заметить, что ни где на поставленные тобой вопросы (там, выше просто "очередь" из вопросов была) не отвечал, надеюсь, приписывать мне ответы на них ты не будешь. По отношению к первоначальным формулировкам (я их приводил и не раз), эти вопросы просто вторичны.

Не буду, ибо ответов этих от тебя не получил. А ответы мне хотелось услышать потому, что ты имел неосторожность обвинить меня в слабом знании предмета обсуждения. Вот я и допытывался от тебя - в чем же я его "слабо знаю".

Flex, на самом деле, меня просто неудовлетворяет формулировка, согласно которой "POSIX-совместимость -- пустой звук, а вот стандарты ISO/IEC -- это наше всё". Я, собственно, не вылазя из танка, для особоодарённых привёл уже ссылки про то, что речь идёт ни о какой-то там "совместимости ISO/IEC", а об именно POSIX-совместимости. Если ты так и непонялЪ, то... :D:D:D

Добавлено 24.07.06, 11:15

Цитата trainer @ 24.07.06, 05:59

Чего ж у тебя такая психика неустойчивая? ржешь и ржешь :D
Ну захотелось человеку использовать WinAPI. Неужели это запрещено? :D
Естественно, можно это же написать с помощью opendir/readdir/closedir/remove/rmdir

Не... Мне, если честно, то всё по-ровну в данном вопросе... Т.к. несмотря на то, что я являюсь апологетом "POSIX-совместимости", я давным-давно знаю о мифологичности самого понятия "кросс-платформенность". На самом деле, именно кросс-платформенность, совместимость на уровне исходного кода, как таковые достижимы на весьма огрниченном наборе ПО. В остальном, как правило, правки неизбежны. Если это касается цинда-линукс.

Flex, по непонятной для меня причине, даже рассказывая об INTERIX (ай, молодца! Нашёл название!) до сих пор отрицает то, что говорится о простой вещи -- о POSIX-совместимости. Поверь, если бы оно было, то было бы проще -- в системе, полностью удовлетворяющей требованиям POSIX 1003.1x, можно особо не тсрадать фантазмами.

Если это касается *NIX-мира, то там по-проще, ибо POSIX-compatible со всеми вытекающими.

Цитата the_Shadow @ 24.07.06, 11:00

Flex, на самом деле, меня просто неудовлетворяет формулировка, согласно которой "POSIX-совместимость -- пустой звук, а вот стандарты ISO/IEC -- это наше всё". Я, собственно, не вылазя из танка, для особоодарённых привёл уже ссылки про то, что речь идёт ни о какой-то там "совместимости ISO/IEC", а об именно POSIX-совместимости. Если ты так и непонялЪ, то... :D:D

Ну как тебе сказать, для меня (а за тебя я говорить не берусь) существует несколько уровней "совместимости" исходного текста. Есть уровень совместимости на уровне стандарта языка, есть - уровень совместимости на уровне требований системы. И это даже не уровни, это разные виды совместимости. Я, например, могу написать абсолютно переносимый текст на С/С++, но он будет компилироваться только под Windows, но разными компиляторами, т. е. быть переносимым с точки зрения стандарта языка. А могу абсолютно переносимый текст между разными системами, но он будет компилироваться только с помощью gcc. В этом случае мы можем говорить о совместимости только с точки зрения POSIX (правда в этом случае можно сказать - частичной). А могу - что он будет переносим и между компиляторами и между системами (это требование сложнее всего выполнить). Т. е. мы имеем два стандарта, и они предъявляют разные требования к исходному тексту. Только и всего. Или я опять в чем-то ошибаюсь?

Т. е. (все для тех же, кто в танке), если мы обсуждаем язык программирования, то POSIX тут совершенно ни при чем, ибо на язык есть соответствующий стандарт. А вот если мы будем обсуждать API систем - то POSIX тут будет упомянут в первую очередь. А если мы посмотрим на название темы, то увидим, что речь идет о языке программирования. А потому POSIX мы откладываем в сторонку, ибо для языка программирования существует вполне конкретный стандарт - ISO/IEC 9899:1999 (для С) и ISO/IEC 14882:2003 (для С++). Другого стандарта на язык С в природе не существует.

Цитата the_Shadow @ 24.07.06, 11:00

Flex, по непонятной для меня причине, даже рассказывая об INTERIX (ай, молодца! Нашёл название!) до сих пор отрицает то, что говорится о простой вещи -- о POSIX-совместимости. Поверь, если бы оно было, то было бы проще -- в системе, полностью удовлетворяющей требованиям POSIX 1003.1x, можно особо не тсрадать фантазмами.

Ничего не понял. "Папа, ты сейчас с кем разговаривал?"

Цитата

На самом деле, именно кросс-платформенность, совместимость на уровне исходного кода, как таковые достижимы на весьма огрниченном наборе ПО. В остальном, как правило, правки неизбежны. Если это касается цинда-линукс.

Согласен на все 100, попробуй написать, к примеру, кроссплатформенную cd писалку или там, сканирующую програмку, вот я посмотрю, как у тебя это получится

Цитата

А вот если мы будем обсуждать API систем - то POSIX тут будет упомянут в первую очередь. А если мы посмотрим на название темы, то увидим, что речь идет о языке программирования. А потому POSIX мы откладываем в сторонку, ибо для языка программирования существует вполне конкретный стандарт - ISO/IEC 9899:1999 (для С) и ISO/IEC 14882:2003 (для С++). Другого стандарта на язык С в природе не существует.

на мой ламерский взгляд спецификации на api системы (POSIX или WinAPI) и спецификация языка - штуки "слегка" в разных плоскостях находящиеся.

Кстати, Шад, вот тебе вопрос. Является ли исходный текст ядра Linux POSIX-совместимым? Т. е. соответствует ли текст ядра, например, такому требованию:

Цитата

For the C programming language, shall not exceed any minimum implementation limit defined in the ISO C standard, unless the System Interfaces volume of IEEE Std 1003.1-2001 specifies a higher minimum implementation limit

учитывая то, что ты не раз говорил, что в ядре используется код, специфичные именно для gcc расширения языка:

Цитата the_Shadow @ 21.05.06, 13:02

Народ, вообще говоря, я чётко и сразу сказал о том, что я использую расширения языка, доступные в gcc.

Могу ещё GCC'шный __extension__ поставить. Для ясности.

Вопрос был? Был. За расширенным описаловом сюда, pls -> http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html по поводу typedef и по поводу "compound expressions".

Возможно, что в следующей версии стандарта оно и будет... Равно как в С99 появилось многое из того, что было ранее "прерогативой" С++. Вот только работать оно будет по-проще. А, пока, у меня есть инструмент, который позволяет мне решать мои задачи. Вот и всё. Если кто-то по каким-то соображениям не желает их решать так же (с использованием возможностей инструмента), то я-то при чём? Или GCC?

Речь шла от typeof и специфичном использовании typedef. И то и другое активно используется в исходниках ядра.

Добавлено 24.07.06, 13:39

Цитата BugHunter @ 24.07.06, 13:28

на мой ламерский взгляд спецификации на api системы (POSIX или WinAPI) и спецификация языка - штуки "слегка" в разных плоскостях находящиеся.

Это я пытаюсь объяснить Шаду на протяжении последних 50-ти постов.

Добавлено 24.07.06, 13:47

Цитата BugHunter @ 24.07.06, 13:28

Согласен на все 100, попробуй написать, к примеру, кроссплатформенную cd писалку или там, сканирующую програмку

Если брать POSIX-совместимые платформы, то большой проблемы, я думаю, не будет. Проблема в другом: не все широкораспространенные платформы - POSIX-совместимые.

Цитата BugHunter @ 24.07.06, 13:28

Согласен на все 100, попробуй написать, к примеру, кроссплатформенную cd писалку или там, сканирующую програмку, вот я посмотрю, как у тебя это получится

cdrecord?
sane?

Цитата e-yes @ 24.07.06, 14:01

cdrecord?
sane?

Че, они же в виндах заработали? Они портируемые внутри семейства ОС и на довольно широкий круг железа, что, в принципе, можно считать кроссплатформенностью, но GTK/Qt тут гораздо кроссплатформенней.

Цитата linuxfan @ 24.07.06, 15:29

Че, они же в виндах заработали?

Ну порты есть. Я уж не знаю, насколько там изменено всё, но всё Ж...

Цитата Flex Ferrum @ 24.07.06, 13:37

Это я пытаюсь объяснить Шаду на протяжении последних 50-ти постов.

А я, в свою очередь, пытаюсь (примерно столько же) объяснить вполне простую и очевидную вещь, хорошо заметную из *NIX-мира:

Цитата Flex Ferrum @ 20.07.06, 20:49

Не дурно было бы заметить, что POSIX и C это, гм, примерно то же самое, как компьютер целиком и клавиатура к нему. Т. е. не сравниваемые вещи.

Высказывание -- бред.

Добавлено 24.07.06, 16:11
Особенно, по-листавши POSIX 1003.1 (ссылка и сам список функций -- выше). Ссылки на то, что в "других языках"... То же выше -- в части Fortran и Ada (они -- bindings to POSIX 1003.1 -- не более), на уровне System определён только один язык. С.

Всё. Из спора вышел. Надоело, чесслово.

Цитата the_Shadow @ 24.07.06, 16:09

Высказывание -- бред.

Ну, Шадыч, значит аргументация у тебя как-то хромает... Ибо никто акромя тебя это бредом не назвал. Ну нельзя сравнивать теплое с мягким, дрель со сверлом, молоток с гвоздем, автомобиль с бензином или дорогой, желтое со сладким, и т. д. и т. п. Нельзя. Это разные вещи, разные плоскости, разные стандарты. То, что ты считаешь, что С и POSIX - это одно (или, как миниму, сравнимые вещи) и тоже, говорит лишь о том, что ты невнимательно читаешь те самые стандарты, на которые сам же и указываешь. А также высказывания своих оппонентов. А ведь я специально привел здесь нужные цитаты. И даже любезно подсветил нужные их фрагменты болдом.

P.S. Покамест, об ISO/IEC-compatible системах слышать не доводилось. А вот о POSIX-comatible -- сколько угодно (кстати, их и предпочитаю -- бреда в них по-мене будет).

Шадыч, извини. Больше не могу читать этот бред. Читай стандарты. Читай приводимые мною цитаты из них. А потом будем разговаривать. Тебе уже три человека сказало то же самое, что и я (linuxfan, trainer, BugHunter). Впрочем, ты сам выше признал, что знаешь этот предмет лучше всех... Куда уж нам до тебя...

Добавлено 24.07.06, 16:17
Если ты не понимаешь смысл слова POSIX - это только твои проблемы. Если бы внимательно читал - то понял, почему говорят POSIX-compatible, но не ISO/IEC-compatible.

Цитата Flex Ferrum @ 24.07.06, 16:13

То, что ты считаешь, что С и POSIX - это одно (или, как миниму, сравнимые вещи) и тоже, говорит лишь о том, что ты невнимательно читаешь те самые стандарты, на которые сам же и указываешь.

Не-а...

Цитата Flex Ferrum @ 20.07.06, 20:49

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

Не сможешь, т.к. вызовы уже описаны. Ясно и чётко сказано как они (вызовы) определены, с какими параметрами используются. Если ты не заметил, то это -- С-функции. Для уровня СИСТЕМЫ (POSIX-совместимой) такое решение не канает. Уж звиняйте, кто бы чего не говорил, но "системный интерфейс" описан явно и чётко. А всё остальное -- "свадьба". Желаемое за действительное выдаём.

Цитата Flex Ferrum @ 24.07.06, 16:15

Шадыч, извини. Больше не могу читать этот бред.

Ага... Аналогично...

Сообщение отредактировано: the_Shadow - 24.07.06, 16:33