>[оверквотинг удален]
>
>module_init(my_init);
>
>MODULE_LICENSE("GPL v2");
>
>
># insmod ./test.ko
># dmesg
>
>TEST: i = 0

соответсвенно из ниже следующих моих комментов - если вывести из блока переменную Ы
вот тогда будет

Jul 12 18:39:29 localhost kernel: init_module() called = 0

+ int i;
int my_init(void ) {

- int i;
printk(KERN_DEBUG " TEST: i = %d \n", i);
return 0;
}

>[оверквотинг удален]
>
>Jul 12 18:39:29 localhost kernel: init_module() called = 0
>
>+ int i;
>int my_init(void ) {
>
>- int i;
> printk(KERN_DEBUG " TEST: i = %d \n", i);
> return 0;
>}

Не хочет...  
INT: i = 0

/*
 *
 */
#include <linux/version.h>
#include <linux/module.h>
int i;
 
int my_init(void ) {
         printk(KERN_DEBUG "INT: i = %d\n", i);
 return 0;
}
module_init(my_init);
MODULE_LICENSE("GPL v2");

# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.5/lto-wrapper
Target: x86_64-suse-linux
Thread model: posix
gcc version 4.5.0 20100628 [gcc-4_5-branch revision 161494] (SUSE Linux)

# uname -a
Linux suse64 2.6.32.16 #6 SMP PREEMPT Tue Jul 6 21:09:44 MSD 2010 x86_64 x86_64 x86_64 GNU/Linux

что не хочет ???

тут будет 0 - правильно (int i - глобальная)

##########################
#include <linux/version.h>
#include <linux/module.h>

int i;

int my_init(void ) {

         printk(KERN_DEBUG "INT: i = %d\n", i);
return 0;

}

module_init(my_init);

MODULE_LICENSE("GPL v2");
###########################

>что не хочет ???
>тут будет 0 - правильно (int i - глобальная)

Я собственно о том, что не инициализирована переменная не обязана
принимать какие либо значения. Более того если от версии к версии
появляются какие-то постоянные значения это не есть хорошо.

Надеюсь, что нисколько.

Должно быть int i = 0;

Нет, не должно.

Таким образом вы экономите один store на каждый вызов функции. В случае, если это interrupt handler, экономия получается некислая. ;)

"Бездумная" инициализация автоматических переменных свидетельствует о непонимании того, как они обрабатываются.

>Нет, не должно.

Должно. Из-за этого столько багов, что лучше обнулять.

> свидетельствует о непонимании того

а, ну да, конечно. видимо, вы самый большой специалист.

вопрос: вот код
int i;
чему равна i в месте, где эта i используется в первый раз ?

ответ - неизвестно.

Простите, но у вас какие-то дилетантские познания программирования на С. Вы ещё думаю удивитесь когда узнаете сколько в ядре goto. В месте где используется i  первый раз может быть все равно какое у неё значение, потому что использовать i можно первый раз на запись.

простите, уж какие есть :-)
"может быть", "может" - это не те слова, которые следует использовать при разработке надёжного ПО.

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

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

насчёт того, в какой секции располагается такая переменная, действительно не уверен - как-то не было такой проблемы никогда, поэтому не изучал вопрос.

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

похоже что вы видимо никогда ничего на С и не писали, иначе почему вы ничего не знаете о варнингах компилятора?

>насчёт того, в какой секции располагается такая переменная, действительно не уверен -
>как-то не было такой проблемы никогда, поэтому не изучал вопрос.

это стековая переменная... ппц, какой нафиг раздел предварительно инициализированных переменных, люди??? Функция будет не реентерабельной. Не порите чушь.

>похоже что вы видимо никогда ничего на С и не писали, иначе
>почему вы ничего не знаете о варнингах компилятора?

Да с чего вы взяли, что я не знаю ???

>это стековая переменная... ппц, какой нафиг раздел предварительно инициализированных переменных, люди??? Функция
>будет не реентерабельной. Не порите чушь.

Уточнение: или стековая или регистровая. Остальное верно.

При разработке надежного ПО на C используют, как минимум, -Wall -pedantic, если на то пошло. И никаких лишних телодвижений делать не надо — проверить что может, а чего не может, способна и машина.

Ну а для реально надежного ПО - как обычно, доказательный подход, Карри-Говард, ATP и все такое.

Это с чего вы решили? В общем как код напишите так у вас и будет - известно или нет. Ну или приведите РЕАЛЬНЫЙ пример когда из ядра где есть этот недостаток, в противном случае это бездумное следование шаблону.

какой недостаток ? что непроинициализирована переменная ? так выше цифра приведена.

> какой недостаток ? что непроинициализирована переменная ?

нет, где это может привести к ошибке.

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

да, я предпочитаю бездумно следовать этому шаблону. более того, ругаюсь очень сильно, когда вижу непроинициализированные при объявлении переменные.

это тупо лучше при отладке, когда каждый раз значение переменной известно, а не случайно, и ломает всё в непредсказуемом порядке.

в общем, пишите софт, пробуйте сами как лучше, я тут высказал своё мнение, имею право. вы пишете софт по-своему - тоже имеете право.

>примера кода из ядра привести не могу, хотя вот посмотрите тут уже
>"модуль" набросали.
>
>да, я предпочитаю бездумно следовать этому шаблону. более того, ругаюсь очень сильно,
>когда вижу непроинициализированные при объявлении переменные.

Ну а кому-то удобнее наоборот, когда все переменные компактно объявляются в одном месте, а присваивания идут естественным образом по ходу дела. Это помогает следить за их количеством, что в случае с именно C порой весьма актуально, и отслеживать логику работы функции, не дёргаясь глазами по коду с мыслью "а во что эта хрень была выставлена-то?". И что удобнее читать, вот это:

/* Взято из src/lib/libc/stdio/mktemp.c в OpenBSD-CURRENT */
static int
mktemp_internal(char *path, int slen, int mode)
{
        char *start, *cp, *ep;
        const char *tempchars = TEMPCHARS;
        unsigned int r, tries;
        struct stat sb;
        size_t len;
        int fd;
        len = strlen(path);
        if (len == 0 || slen >= len) {
                errno = EINVAL;
                return(-1);
        }
        ep = path + len - slen;
        tries = 1;
        for (start = ep; start > path && start[-1] == 'X'; start--) {
                if (tries < INT_MAX / NUM_CHARS)
                        tries *= NUM_CHARS;
        }
        tries *= 2;

или вот это?

/* Модифицированная версия */
static int
mktemp_internal(char *path, int slen, int mode)
{
        char *start, *cp;
        size_t len = strlen(path);
        char *ep = path + len - slen;
        char *start = ep;
        const char *tempchars = TEMPCHARS;
        unsigned int r, tries = 1;
        struct stat sb;
        int fd;
        if (len == 0 || slen >= len) {
                errno = EINVAL;
                return(-1);
        }
        for (; start > path && start[-1] == 'X'; start--) {
                if (tries < INT_MAX / NUM_CHARS)
                        tries *= NUM_CHARS;
        }
        tries *= 2;

Про то, что хороший код - читаемый код, думаю, рассказывать не надо. :) Ну а современный компилятор, как уже говорилось, спасёт от глупых ошибок.

К слову, C99-компиляторы (а объявление переменных в середине кода - это есть C99) тоже не подо все ныне используемые платформы есть...

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

Да уж, а то некоторые приплюснутые сишнеги пишут типа такого кода

int func(void) {
 int i, j; 
 for (i = 0; i < LIMIT; i++ ) 
      j += 2*i; 
//  Далее строк 200 кода одной функции
//
...
// и вдруг резко
   int i = 5; 
   for ( int j = 10; j < i; j++) // ну не дибилы?!
      {
       //...
    }
//
} // EOF func()

разве gcc не заматерится по поводу двойного объявления переменной? такое возможно разве что при выделении блоков /*{..}*/

>разве gcc не заматерится по поводу двойного объявления переменной? такое возможно разве
>что при выделении блоков /*{..}*/

На i матернётся, на j - нет.

Более того, сработает вот такой маразм

#define LIMIT 25 
int main(void) {
        double i;
        long long j[25];
        for ( char i = 0; i < LIMIT; i++ )
                *j += 2*i;
        i = *j;
        for ( int j; j < i; j++);
 return *j;
}

обратил внимание только на i, поэнтому не уточнил. :) с j все понятно, ибо в теле цикла.
последний пример вообще стараюсь избегать, стыдно будет за такое перед коллегами.

>обратил внимание только на i, поэнтому не уточнил. :)
> с j все понятно, ибо в теле цикла.

Тело цикла это уже иная область видимости? Сублокальная?! :)

А чё ... я не против :) если итераторы будут умирать после окончания цикла.

типа
     for (int i = 0; i < X; i++) {
      Z *= i*i;
     }

     while (int j) {
      X = j+i;      // а тут i уже будет not declared
     }

>[оверквотинг удален]
>типа
>     for (int i = 0; i <
>X; i++) {
>      Z *= i*i;
>     }
>
>     while (int j) {
>      X = j+i;    
>  // а тут i уже будет not declared
>     }

Помнится, одно время в C++ так и сделали.

>Тело цикла это уже иная область видимости? Сублокальная?! :)

по крайней мере, компайлер должен проглотить j и даже не вякать. такое тоже встречал o_O еще хуже даже видел, когда j объявлена как глобальная O_O потом почему-то начинается неожиданная хрень. :)

>>Тело цикла это уже иная область видимости? Сублокальная?! :)
>
>по крайней мере, компайлер должен проглотить j и даже не вякать. такое
>тоже встречал o_O еще хуже даже видел, когда j объявлена как
>глобальная O_O потом почему-то начинается неожиданная хрень. :)

Это называется С99

int i;

for (i = 0; i < 10; i++)
{
...
}

какой ужас, это не будет работать :D

нет! этот код может работать неверно в боевых условиях, когда синус 90 гр. достигает трех и более.

>Должно. Из-за этого столько багов, что лучше обнулять.

А не достаточно ли просто быть внимательней, а то напоминает: http://bash.org.ru/quote/396506

>>"Бездумная" инициализация автоматических переменных свидетельствует о непонимании того, как они обрабатываются.

с чего это вы решили что это автоматическая переменная ???

>>>"Бездумная" инициализация автоматических переменных свидетельствует о непонимании того, как они обрабатываются.
>
>с чего это вы решили что это автоматическая переменная ???

Хватит тролить. Курите маны на GCC.

.... спецификатор переменной всегда является auto, если не указано иного - static, extern или register.

>>>>"Бездумная" инициализация автоматических переменных свидетельствует о непонимании того, как они обрабатываются.
>>
>>с чего это вы решили что это автоматическая переменная ???
>
>Хватит тролить. Курите маны на GCC.
>
>

.... спецификатор переменной всегда является auto, если не указано иного - static, 
>extern или register. 
>

покурил (я тя уважаю)
читаем внимательно последний абзац

#########################

Спецификатор класса памяти в объявлении переменной может быть auto, register, static или extern. Если класс памяти не указан, то он определяется по умолчанию из контекста объявления.

Объекты классов auto и register имеют локальное время жизни. Спецификаторы static и extern определяют объекты с глобальным временем жизни.

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

Переменная с классом памяти auto имеет локальное время жизни и видна только в блоке, в котором объявлена. Память для такой переменной выделяется при входе в блок и освобождается при выходе из блока. При повторном входе в блок этой переменной может быть выделен другой участок памяти.

Переменная с классом памяти auto автоматически не инициализируется. Она должна быть проинициализирована явно при объявлении путем присвоения ей начального значения. Значение неинициализированной переменной с классом памяти auto считается неопределенным.

############################################################

ps:

Пример:
    int global_var;
    int func(void)
    { int local_var;                      /* по умолчанию auto  */
      static int *local_ptr=&local_var;   /*  так неправильно   */
      static int *global_ptr=&global_var; /*  а так правильно   */
      register int *reg_ptr=&local_var;   /*  и так правильно   */
    }

В приведенном примере глобальная переменная global_var имеет глобальное время жизни и постоянный адрес в памяти, и этот адрес можно использовать для инициализации статического указателя global_ptr. Локальная переменная local_var, имеющая класс памяти auto размещается в памяти только на время работы функции func, адрес этой переменной не является константой и не может быть использован для инициализации статической переменной local_ptr. Для инициализации локальной регистровой переменной reg_ptr можно использовать неконстантные выражения, и, в частности, адрес переменной local_ptr.

>>>>"Бездумная" инициализация автоматических переменных свидетельствует о непонимании того, как они обрабатываются.
>>
>>с чего это вы решили что это автоматическая переменная ???
>
>Хватит тролить. Курите маны на GCC.
>
>

.... спецификатор переменной всегда является auto, если не указано иного - static, 
>extern или register. 
>

в дополнении читаем внимательно 3 и 4 пункт

1.6.4. Инициализация глобальных и локальных переменных

При инициализации необходимо придерживаться следующих правил:

1. Объявления содержащие спецификатор класса памяти extern не могут содержать инициаторов.

2. Глобальные переменные всегда инициализируются, и если это не сделано явно, то они инициализируются нулевым значением.

3. Переменная с классом памяти static может быть инициализирована константным выражением. Инициализация для них выполняется один раз перед началом программы. Если явная инициализация отсутствует, то переменная инициализируется нулевым значением.

4. Инициализация переменных с классом памяти auto или register выполняется всякий раз при входе в блок, в котором они объявлены. Если инициализация переменных в объявлении отсутствует, то их начальное значение не определено.

5. Начальными значениями для глобальных переменных и для переменных с классом памяти static должны быть константные выражения. Адреса таких переменных являются константами и эти константы можно использовать для инициализации объявленных глобально указателей. Адреса переменных с классом памяти auto или register не являются константами и их нельзя использовать в инициаторах.

>[оверквотинг удален]
>
>4. Инициализация переменных с классом памяти auto или register выполняется всякий раз
>при входе в блок, в котором они объявлены. Если инициализация переменных
>в объявлении отсутствует, то их начальное значение не определено.
>
>5. Начальными значениями для глобальных переменных и для переменных с классом памяти
>static должны быть константные выражения. Адреса таких переменных являются константами и
>эти константы можно использовать для инициализации объявленных глобально указателей. Адреса переменных
>с классом памяти auto или register не являются константами и их
>нельзя использовать в инициаторах.

И как это противоречит процитированному утверждению?
По поводу явной инициализации: не вижу ничего плохого в объявлении переменных без явной инициализации в случае, когда им присваивается значение далее по коду. Есть ли какая-нибудь разница при записи в памяти поверх нулей или поверх мусора? Если же программист попробует использовать не инициализированную переменную, то его об этом известит компилятор, о чем выше писалось неоднократно.

>И как это противоречит процитированному утверждению?
>По поводу явной инициализации: не вижу ничего плохого в объявлении переменных без
>явной инициализации в случае, когда им присваивается значение далее по коду.
>Есть ли какая-нибудь разница при записи в памяти поверх нулей или
>поверх мусора? Если же программист попробует использовать не инициализированную переменную, то
>его об этом известит компилятор, о чем выше писалось неоднократно.

int func(void)
{
    int local_var;                      /* по умолчанию auto  */
    static int *local_ptr=&local_var;   /*  так неправильно   */
.........

тады обьясните почему неправильно ??

>[оверквотинг удален]
>int func(void)
>{
>    int local_var;      
>          
>    /* по умолчанию auto  */
>    static int *local_ptr=&local_var;   /*  так
>неправильно   */
>.........
>
>тады объясните почему неправильно ??

Все правильно, только лишено какой-либо логики, кроме как для теста для компилятора и ОСи.

Глупо инициализировать переменные если они редко будут использоваться:

int func(int a, int b) {
  int i, j; 
   
  if ( a < b ) 
     return -1;
  i = a*b;
  if ( i % 5 ) 
     return -1;
  j = i % 5;
return i+j;
}

Как видите, при a < b значения i и j пофигу какие.

Все это можно даже упростить до:

int func(int a, int b) {
  if ( a < b ) 
     return -1;
  if ( (a*b) % 5 ) 
     return -1;
  return (a*b)+((a*b) % 5);
}

>[оверквотинг удален]
>

 
>int func(int a, int b) { 
>
>  if ( a < b ) 
>     return -1; 
>  if ( (a*b) % 5 ) 
>     return -1; 
>  return (a*b)+((a*b) % 5); 
>} 
>

нет не глупо особенно переменные которые попадают в локальную область видимости (без инициализации в них храниться мусор и порой это может стать причиной ошибки)

для глобальных - да типа "глупо"

>>[оверквотинг удален]
>нет не глупо особенно переменные которые попадают в локальную область видимости (без
>инициализации в них храниться мусор и порой это может стать причиной ошибки)

Какая может возникнуть ошибка, если эту переменную я не использую?
От инициализированной локальной переменной вообще никакого толка.

int func(void) {
 int i = 25; // шо такое 25 ?
 do {
     i--;
 } while ( i > 0 )
}

Заменяется на:

#define LIMIT 25
int func(void) {
 int i;
 for (i = LIMIT; i > 0; i--) {
 }
}

у вменяемых такого рода ошибок не будет

int func(void)
{
    int local_var;                      /* по умолчанию auto  */
    static int *local_ptr=&local_var;   /*  так неправильно   */

>[оверквотинг удален]
>

 
>int func(int a, int b) { 
>
>  if ( a < b ) 
>     return -1; 
>  if ( (a*b) % 5 ) 
>     return -1; 
>  return (a*b)+((a*b) % 5); 
>} 
>

 
inline int func(int a, int b) { 
 return (a < b) ? -1 : (((a*b) % 5) ? -1 : (a*b)+((a*b) % 5)); 
} 

Гы

 
inline int func(int a, int b) { 
 return (  ( (a < b) || ((a*b) % 5)) ) ? -1 : ( (a*b) + ((a*b) % 5) )  ); 
} 

гы-гы

>Еще бы за использование "int main()" роялити потребовали и "int i;" запатентовали.

Надо с ними на их же языке говорить, чтоб заткнулись. Взять код какой-то неюниксовой ОСи, ровестницы юникса, найти и предъявить те же конструкции, имена переменных и пр. И пусть потом доказывают, то сами не воры и что "int i;" не сплагиировали ;-))

А может быть вообще какой-то базовый учебник по основам С/unix... :-)

>Надо с ними на их же языке говорить, чтоб заткнулись. Взять код
>какой-то неюниксовой ОСи, ровестницы юникса, найти и предъявить те же конструкции,
>имена переменных и пр. И пусть потом доказывают, то сами не
>воры и что "int i;" не сплагиировали ;-))

Ну зачем же так сложно?
Они сами на себя компромат выкатили - пример 251, syslog.h.
Имена констант и комментарии к ним совпадают.
В glibc-2.2.5/misc/sys/syslog.h:
* Copyright (c) 1982, 1986, 1988, 1993
*      The Regents of the University of California.  All rights reserved.
как того и требует лицензия Беркли.
Проследить историю этого файла вплоть до 82-83 годов можно благодаря коллекции МакКузика.

Отсюда следуют ровно две возможности:
- либо в SCO отрезали шапку Беркли (нарушили лицензию)
- либо они сознательно пытались ввести суд в заблуждение, утаивая информацию о происхождении кода

>Они сами на себя компромат выкатили - пример 251, syslog.h.

поправка - пример 247

>[оверквотинг удален]
> *      The Regents of the University
>of California.  All rights reserved.
>как того и требует лицензия Беркли.
>Проследить историю этого файла вплоть до 82-83 годов можно благодаря коллекции МакКузика.
>
>
>Отсюда следуют ровно две возможности:
> - либо в SCO отрезали шапку Беркли (нарушили лицензию)
> - либо они сознательно пытались ввести суд в заблуждение, утаивая информацию
>о происхождении кода

А вариант, что это в BSD остался огрызок чужого кода, вы не рассматриваете? Я серьёзно.

>А вариант, что это в BSD остался огрызок чужого кода, вы не
>рассматриваете? Я серьёзно.

Нет. syslog.h из glibc-2.2.5 основан на дистрибутиве 4.4BSD-Lite2, который является лицензионно чистым (не содержит проприетарных файлов от AT&T) и был выпущен после судебного разбирательства BSD vs. USL.

>>А вариант, что это в BSD остался огрызок чужого кода, вы не
>>рассматриваете? Я серьёзно.
>
>Нет. syslog.h из glibc-2.2.5 основан на дистрибутиве 4.4BSD-Lite2, который является лицензионно чистым
>(не содержит проприетарных файлов от AT&T) и был выпущен после судебного
>разбирательства BSD vs. USL.

То есть он появился _после_ того судебного разбирательства? Тогда это радует. :)

>>Нет. syslog.h из glibc-2.2.5 основан на дистрибутиве 4.4BSD-Lite2, который является лицензионно чистым
>>(не содержит проприетарных файлов от AT&T) и был выпущен после судебного
>>разбирательства BSD vs. USL.
>
>То есть он появился _после_ того судебного разбирательства? Тогда это радует. :)
>

Если быть совсем точным, то копирайт _сохранился_ (1982, 1986, 1988, 1993), т.е. USL никогда не претендовала на то, что syslog - это их разработка.
А вообще, насколько я сумел понять, ноги syslog растут из sendmail (тоже берклиевская разработка).

>Еще бы за использование "int main()" роялити потребовали и "int i;" запатентовали.

Так вот какой код скопировали из Unix в линух?! Блин, этак меня SCO тоже засудит за копипасту :(.

Посмотрел первые два документа.
Да. Некоторые идентификаторы совпадают или похожи.
А вот стилистика совсем другая. Чувствуется, что писали разные люди.
Я считаю, что документы готовились, чтобы поразить воображение судей, которые не сильны в программировании, в текстуальном сходстве.
А сходство не удивительно. Т.к. предметная область совпадает.

Так как имена преременных прописаны в спецификациях ELF.

  Интересно, а могут ли разработчики кода винды что либо заимствовать с кода линукс. А если бы код винды был бы открыт, то для кого и для чего он был бы тогда интересен?

Для злоумышленников код венды интересен.

поскольку закрыт. А против открытого кода - скучно.

Но так проще. А раз все сидят на венде, то и эффективней выходит.

>поскольку закрыт. А против открытого кода - скучно.

Что мешает стянуть код части винды из сети ? (nt4 и sp3 win 2000)
смотрел когда-то на него, код как код на первый взгляд все самопальное, явных коментов типа GPL или Linux не увидел.

> Что мешает стянуть код части винды из сети ? (nt4 и sp3 win 2000)

Ну так ими никто не пользуется почти. Сейчас всем перделки, то есть висту и виндоуз 7 подавай.

По сути да, но тогда придется эти продукты делать свободными. А вот с БСД уже много чего нагло забрали.

Почему нагло? Лицензия такая, супер-пупер свободная.

Вы бы еще Public Domain наглостью назвали... Нагло было бы забрать из GPL что-нить, а из BSD это не наглость

Нагло я имею ввиду, что хотя бы в эбауте написали чтото типа "...и проект ВSD..."

Наивно было бы ждать такого от MS :)

"Такое" они как раз местами пишут.  Подозреваю, что даже везде или почти везде, где нужно.

Только почему-то это всегда окаызывается местом где не светит солнце и куда редкий юзер забредает. Поэтому почти все юзеры уверены что все это - Copyright (с) Microsoft Corporation, XXXX-YYYY. All rights reserved.

>А если бы код винды был бы открыт, то для кого и для чего он был бы тогда интересен?

Код винды уперли еще несколько лет назад. Как минимум винтукея. Большой кус ядра и ряда программ. Учтя что остальные ядра от него ничем принципиально не отличаются - в общем то сорс винды в природе есть. Только юзать его - проблематично. В итоге он вызвал интерес только у тех кто анализирует код. Можно даже найти разбор кода ноутпада где-то в ЖЖ.

SCO унылы, как протухший помидор - тоже ради интереса глянул код. Названия а-ля "buf", "len", "maxlen" можно использовать чуть ли не для половины строковых алгоритмов, делать на этой основе какие-то выводы - это позориться собственной некомпетентностью. Хотя я тоже склоняюсь к мысли, что не ради правды этот процесс.

Посмотрел первые 7 ссылок. Жестко. Надеюсь, хотя бы пару программистов привлекут в качестве экспертов в суд. Если логика функции подразумевает: проверить правильность указателя и вернуть данные согласно коду функции либо код ошибки, то трудно извернуться и написать ее как-то иначе чем тут написано. Блин, у меня половина программ получается попадает под лицензии типа SCO :(.

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

Ну так Микрософт же платила Эпплу за прямоугольные окна.

открыл 4 случайных примера. дальше даже смотреть не стал.

Однозначно все это происки Империи зла.
нет там никакого соответствия. и копипасты там нет.
возможно имел место рерайтинг;)

Помнится сне, толи даймлер толи еще кто-то отстегнул очень крупную сумму SCO, чтобы застраховаться от претензий... там нулей было гораздо больше чем три.

Один ученик сказал Мастеру Фу: "Нам говорят, что фирма SCO удерживает реальную власть над Unix".
Мастер Фу кивнул в знак согласия.
Ученик продолжал: "Однако нам также говорят, что другая фирма, OpenGroup, также удерживает реальную власть над Unix".
Мастер Фу кивнул в знак согласия.
"Как такое возможно?" — спросил ученик.
Мастер Фу ответил: "SCO действительно владеет кодом Unix, но код Unix — это не сама Unix. OpenGroup действительно владеет маркой Unix, но название Unix — это не сама Unix".
"В чем же тогда сущность Unix?" — спросил студент.

Мастер Фу ответил: "Не в коде. Не в имени. Не в мышлении. Вообще ничего материального.
Вечное изменение без перемен".
"Сущность Unix проста и пуста. Поскольку она проста и пуста, она сильнее тайфуна".
"Повинуясь естественным законам, она непреклонно расцветает в умах программистов,
ассимилируя конструкции в свою собственную природу. Всякое программное обеспечение, которое хотело бы конкурировать с Unix, должно стать таким, как Unix: пустым, пустым, глубоко пустым, абсолютно лишенным содержания потоком!"
Услышав это, ученик достиг просветления.

// Искусство программирования Unix, Эрик С. Реймонд

> // Искусство программирования Unix, Эрик С. Реймонд

Ага, щаз, у него столько мозга нет.
Он тоже скопипастил у Конфуция из "Книги Перемен"

>> // Искусство программирования Unix, Эрик С. Реймонд
>Ага, щаз, у него столько мозга нет.
>Он тоже скопипастил у Конфуция из "Книги Перемен"

Нет. Он применил универсальный закон, который понял Конфуций, к конкретной ситуации.
Никто не может быть выше Истины. Выше Истины, только Истина.

>[оверквотинг удален]
>Вечное изменение без перемен".
>"Сущность Unix проста и пуста. Поскольку она проста и пуста, она сильнее
>тайфуна".
>"Повинуясь естественным законам, она непреклонно расцветает в умах программистов,
>ассимилируя конструкции в свою собственную природу. Всякое программное обеспечение, которое хотело бы
>конкурировать с Unix, должно стать таким, как Unix: пустым, пустым, глубоко
>пустым, абсолютно лишенным содержания потоком!"
>Услышав это, ученик достиг просветления.
>
>// Искусство программирования Unix, Эрик С. Реймонд

класс! Я только что достиг просветления!!!

Я правильно понял, что достаточно переименовать переменные, и SCO уже не при делах? ;) Курам^W программерам на смех!

#include <sys/types.h> (Tab331) - это по-любому спертый у SCO участок кода ;)

string.h (Tab 242) o_O

Ну и где там сходство? В именах переменных и функций? Но хотелось бы заметить, что реализованны там одни и те же функции по- разному, ибо даж ёжикам понятно. что elf и *elf- совсем не одно и то же, а значит и функции, с ними оперирующие должны работать не совсем одинаково. А сходство названий проистекает из того, что это софт, используемый в одних и тех же целях. Они бы ещё на мелкомягких в суд подали. ЛОЛ, а не доказательство вины Novell и IBM.

О, супер! Код показали. А то надоели уже абстрактно обвинять в том, что "у вас где-то что-то нарушено, а ну платите деньги". Потому что когда изместно, где и что может хотя бы в теории вызвать вопросы - например, в функции обработки 16-ричных контрольных сумм в памяти, сразу же можно проблемный код заменить. Вариантов написано много

А еще запретим всем писать int i в своих программах. Это ж копирайченый код SCO, правда? :)

дела тут не в переменных а в реализацих

допустим смотрите про poll - что в юниксах и линуксе разная реализация ???? (не путать с epoll в линухе)

пс: отсюда выходит что если одинаковый принцип реализации то ссответсвенно программист будет придумывать более вменяемые имена переменным и функциям/ (ну и ещё один фактор - у кого в первые была реализация - что луноходы код юниксов не глазели ????)

Это чё, типа ВНЕЗАПНО стандарт POSIX стал закрытым, что они такую хрень предъявляют?

Да уж... а если в слове "хлеб" сделать 4 правки, то получится "пиво".

с примера tab-330.pdf я ржал аки конь и катался по полу...
там, среди прочего, был отмечен следующий плагиат:

#ifndef _LIBELF_H
#define _LIBELF_H

#include <sys/types.h>

Лучшая реклама Linux за последние годы!

в Tab247 уже поинтереснее =)

>в Tab247 уже поинтереснее =)

ага. :)
код, написанный в Беркли и распространявшийся под Berkley лицензией...
Что и было написано в отрезанном лоерами из SCO заголовке файла. В glibc-2.2.5 копирайт Беркли сохранен без изменений.

*
*      @(#)syslog.h    8.1 (Berkeley) 6/2/93
*/

#define _PATH_LOG       "/dev/log"

/*
* priorities/facilities are encoded into a single 32-bit quantity, where the
* bottom 3 bits are the priority (0-7) and the top 28 bits are the facility
* (0-big number).  Both the priorities and the facilities map roughly
* one-to-one to strings in the syslogd(8) source code.  This mapping is
* included in this file.
*
* priorities (these are ordered)
*/
#define LOG_EMERG       0       /* system is unusable */
#define LOG_ALERT       1       /* action must be taken immediately */
#define LOG_CRIT        2       /* critical conditions */
#define LOG_ERR         3       /* error conditions */
#define LOG_WARNING     4       /* warning conditions */
#define LOG_NOTICE      5       /* normal but significant condition */
#define LOG_INFO        6       /* informational */
#define LOG_DEBUG       7       /* debug-level messages */

tab251

12: /* Copyright (c) 1987, 1988 Microsoft Corporation */
13: /* All Rights Reserved */
14:
15: /* This Module contains Proprietary Information of Microsoft */
16: /* Corporation and should be treated as Confidential. */

И, главное, какой код то сперли! Аж 2 определения констант, и те - для совместимости. Все, ворье однозначно! (интересно, а авторов wine тогда надо как минимум расстрелять?)

38: /*
39: * The following are symbolic constants required for
40: * X/Open Conformance. They are the equivalents of
41: * the constants above.
42: */
43:
44: #define UL_GETFSIZE 1 /* get file limit */
45: #define UL_SETFSIZE 2 /* set file limit */

> (интересно, а авторов wine тогда
>надо как минимум расстрелять?)

Живьем!! И на смерть!!
А стремление к совместимости объявить преступной наклонностью!!

ага.
открываю исходники OSF/1, нахожу там /usr/opt/OSC200/src/usr/include:

/*
* COMPONENT_NAME: (LIBCSYS) Standard C Library System Functions
*
* FUNCTIONS:
*
* ORIGINS: 27
*
* (C) COPYRIGHT International Business Machines Corp. 1985, 1989
* All Rights Reserved
* Licensed Materials - Property of IBM
*
* US Government Users Restricted Rights - Use, duplication or
* disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
*/

#ifndef _ULIMIT_H_
#define _ULIMIT_H_

#include <standards.h>

#ifdef _XOPEN_SOURCE

#ifdef _NO_PROTO
extern long ulimit();
#else
#if defined(__STDC__) || defined(__cplusplus)
#if defined(__cplusplus)
extern "C"
{
#endif
extern long ulimit(int, ...);
#if defined(__cplusplus)
}
#endif
#endif
#endif

#define UL_GETFSIZE     1       /* get max file size limit */
#define UL_SETFSIZE     2       /* set max file size limit */

#endif /* _XOPEN_SOURCE */

#ifdef _OSF_SOURCE
#define UL_GETBREAK     3       /* get max break (data space) limit */
#endif /* _OSF_SOURCE */

#endif /* _ULIMIT_H_ */

а у IBM копирайт-то пораньше будет!

http://www.mcbride-law.com/wp-content/uploads/2010/07/Tab-24...
Эм strcasecmp() и strncasecmp() это вообще POSIX.
http://www.opengroup.org/onlinepubs/009695399/basedefs/strin...

!!!"Бездумная" инициализация автоматических переменных свидетельствует о непонимании того, как они обрабатываются.!!!

Господа, а в новости речь ведь не об этом)))

а о копирастии, вернемся к теме)

Я немного не в теме, поясните за что это за файл

/home/nutt/Consulting/Boies/204/S-ulimit-2.h

где стоят копирайты мелкософта и для чего он нужен?
и как там этот копирайт оказался?

Это кусок xenix.

почитал про Xenix-- связи SCO с Империей зла наметились давным давно))

Ну вот если из всех команд командной строки Винды убрать названия Юник-совых команд, то на самом деел останется всего три-пять команд, и внутренних и внешних. Что же тогда было раньше - M$ или Unix? С еще более интетесной стороны - если перменные называются одинаково как в закрытой так и в открытой ОС, то имеют место два случая. Первый - профуканны исходники закрытой ОС. Второй - притянуты за уши исходники открытой ОС. Теперь просьба к SCO - скомпилировать свою закрытую ОС с вставками из открытой ОС и получить идентичный код своей закрытой ОС. А вот воздух потить только потом.

Кодирующим "своё" сейчас должно быть вообще неуютно. Нужно перечитать тонны кода, чтобы случайно не сплагиатить очевидный алгоритм или имена переменных/констант/функций/классов и т.п. Мало того, нужно изловчиться и написать код так, что бы не был похож не на что существующее и в то же время алгоритм соответсвовал поставленной задаче. За примерами ходить далеко не нужно, мало ли нас, начинающих кодеров не писали "своих" алгоритмов сортировки? Мы все сидели в разное время в разных местах и не знали друг о друге, но парадигма заставляла нас писать не просто похожий код, но в большинстве своём, совпадающий символ в символ...
От капиталлизма до маразма, видимо, меньше одного шага.

"За примерами ходить далеко не нужно"

Из личной жизни: мы с коллегой 10 лет сидели за соседними столами, потом жизнь развела. Через 5 лет встретились и в шутку нас попросили написать одну и туже простенькую программу. Так не только алгоритм, но и имена процедур, функций и переменных совпали на 99% не только по именам, но и по верхнему/нижнему регистрам

До него, например, именем Kevin звали одного ирландского священника в 7м веке.
http://en.wikipedia.org/wiki/Kevin_of_Glendalough
Сплагиатил юрист себе имечко. Надо бы заплатить.

Да, их аргументы неубедительны, но если они уже выиграют когда-нибудь, то пересмотров после этого никаких не будет. Потом SCO купит балмер. После этого предлагаю шарахнуть по ним из тополя, чтоб не наглели :)

имхо, это большое заблуждение макбрайта, видимо он не понимает в программировании ничего иначе понял бы, что над пошутили показывая наиболее частые и общие приёмы кода, это всё равно, что показывать английский и русский тексты (даже ближе), есть и буквы одинаковые по виду и слова похожие и там всякие точки, тире и зпт., к тому же авторы текстов имели одного преподавателя и читали одинаковые книжки с примерами и вообще

кто то ради шутки показал ему это, а он уверовал и носился с этими жалкими кусками заголовков по судам, скрывал от посторонних глаз и надеялся, что напал на золотую жилу, а сейчас выложил в качестве последнего доказательства

мда уж, лоханулся

у него никаких заблуждений, заработал кучу денег слив компанию SCO.
Лоханулись те кто его слушали и акции SCO в 2003-2004 году покупали.

>Юрист Кевин МакБрайд (Kevin McBride), брат бывшего главы компании SCO Group, раскрыл завесу тайны над участками кода, скопированными из UNIX в Linux.

Молодец юрист! Осталось спросить исходники ядра у джобса. С него-то можно поболее бабла вытянуть. Он вроде бы не нищщий красноглазик, скелет имеет титановый, пластмассовые органы, компьютеры, телевоны и ось для богатых гомосексуалистов производит :)

А переменные-то у него ворованные! Вот сволочь проприетарная, совсем обнаглел :D

а дарвин и так открыт)))
ttp://darwinbuild.macosforge.org/

А вот "int i;" --- это цветочки)))

"return 0;" vs "return NULL;" в tab-333

За свою жизнь я не написал ни одной програмы на С/С++ сложнее хелоувовда, которая бы выдержала такой контроль плагиата)))

Да совпадение названий функций strcasecmp и strncasecmp это жестко (документ 241). Чистый троллинг причем толстый троллинг, даже ананимы с лора на него не повелись бы.

Ещё припомните кто мышку у ксерокса скомуниздил

ога....
и про Next еще вспомните.. и про то кто, что у них комуниздил...