The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Результаты анализа системой Coverity безопасности и качества..., opennews (??), 25-Фев-12, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


9. "Результаты анализа системой Coverity безопасности и качества..."  +3 +/–
Сообщение от qux (ok), 25-Фев-12, 14:32 
Третье место — неинициализированные переменные. Как оно мимо gcc проходит? Или на выхлоп никто не смотрит, Werror не использует?
Ответить | Правка | Наверх | Cообщить модератору

38. "Результаты анализа системой Coverity безопасности и качества..."  +2 +/–
Сообщение от xxx (??), 25-Фев-12, 17:20 
Видел ли ты что мимо IAR проходит? Там вообще такое ощущение что разработчики компилятора наркоманы и стандарт Си на косяки перевели. У меня теперь в практику вошло, весь код пришедший с IAR прогонять через GCC и Clang'овский статический анализатор. Clang кстати тоже многие интересные моменты замечает, что GCC пропускает.
Ответить | Правка | Наверх | Cообщить модератору

52. "Результаты анализа системой Coverity безопасности и качества..."  +/–
Сообщение от Ytch (?), 25-Фев-12, 20:27 
> У меня теперь в практику вошло, весь код пришедший с IAR прогонять через
> GCC и Clang'овский статический анализатор. Clang кстати тоже многие интересные моменты
> замечает, что GCC пропускает.

А как вам это удается, если не секрет? Я давненько не имел дел с IAR'овскими компиляторами, но раньше, помню, натравить что-то, кроме IAR, на проект сделанный конкретно под IAR было весьма проблематично в силу огромного числа платформо-специфичных и сильно-iar-специфичных конструкций (а без них iar выдавал такое, что без слез не взглянешь). Любая утилита и/или компилятор спотыкались и отваливались на таких штуках и без суровой правки исходников их нельзя было использовать.

Ответить | Правка | Наверх | Cообщить модератору

93. "Результаты анализа системой Coverity безопасности и качества..."  +/–
Сообщение от xxx (??), 26-Фев-12, 01:39 
> А как вам это удается, если не секрет?

Сейчас там в IAR в основном все специфичные вещи запиханы в #pragma, которые GCC тупо игнорирует. Ну или мне пока очень везет=) Мне обычно и не надо, чтобы код с IAR собрался достаточно на warning и error поглядеть. А так да, приходится портировать. Просто весело когда кроме специфичных для компилятора #pragma или ещё чего вылезают вещи которые не совместимы с жизнью и IAR это лихо проглатывает.


Ответить | Правка | Наверх | Cообщить модератору

53. "Результаты анализа системой Coverity безопасности и качества..."  +/–
Сообщение от Ytch (?), 25-Фев-12, 20:44 
> Видел ли ты что мимо IAR проходит? Там вообще такое ощущение что
> разработчики компилятора наркоманы и стандарт Си на косяки перевели.

По моему скромному опыту, абсолютный рекордсмен и чемпион в этом сомнительном деле это TI CodeComposer Studio. Включить его в strict-режим невозможно - он прекращает компиляцию найдя более определенного количества ошибок (точно не помню сколько, но много). Ирония в том, что при этом он так и не доходит до ваших файлов - эта тьма ошибок (для strict-режима) уже в их собственных файлах.
Если не включать strict-режим, то он спокойно позволяет использовать, к примеру, функции без прототипа, а что он при этом реально вызывает и как передает параметры - загадка. Самое плохое, что он год будет все компилировать правильно, а потом, когда ты будешь править какие-нибудь незначащие строчки совершенно в другом месте в этой части получишь "биг-бада-бум" с вероятностью 50%. А хватило бы одного warning.

Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

96. "Результаты анализа системой Coverity безопасности и качества..."  +4 +/–
Сообщение от xxx (??), 26-Фев-12, 02:37 
> По моему скромному опыту, абсолютный рекордсмен и чемпион в этом сомнительном деле
> это TI CodeComposer Studio.

Я уже давно стал полным сторонником того, что проприетарные средства разработки зло полнейшее. Они вечно недопилены и кривы, особенно от производителей чипов. Тот же IAR, не считая компилятора (а он все-таки генерирует достаточно быстрый код, и библиотека Си компактна в отличии от того же newlib), но IDE, как с таким позором можно вообще в 21 веке появляться.

Мне повезло, моя контора не ограничивает средства разработки, поэтому использую самосборный toolchain на GCC и радуюсь.

А вообще это просто беда разработки встраеваемых систем, с одной стороны кривые поделки от производителей чипов и т.д. с другой такие же криворукие разработчики. Приходится иметь дело с недавними выпускниками наших вузов, берут их разрабатывать встроенное ПО. И они могут разбираться во всем, в схемотехнике, физике, но только не в программировании и даже интереса к нему не испытывают. Или наоборот наберут бывших явистов для которых элементарные понятия цифровой схемотехнки и электроники или беззнаковые типы и ограничение в 1Кб памяти - rocket science. Зато все как один в резюме указывают, что знают Си в совершенстве. Они видимо забывают, что знание убогого синтаксиса (хотя в живую встречал только двух человек которые читали стандарт С99) это только 10%, остальное - это знания и умения на этом убожестве прменять современные методики, алгоритмы и сопутствующие инструменты.

Зато пионеры горлопанят: "На Си нельзя писать большие проекты!!!" Это оттого, что их знания Си == 0. А вот зная Си + алгоритмы + различные парадигмы и методики программирования + подходящие средства разработки и умея это все применять, оказывается, что можно запилить проекты масштаба Linux и *BSD.

Ответить | Правка | Наверх | Cообщить модератору

99. "Результаты анализа системой Coverity безопасности и качества..."  +/–
Сообщение от VoDA (ok), 26-Фев-12, 02:49 
> Или наоборот наберут бывших явистов для которых элементарные понятия
> цифровой схемотехнки и электроники или беззнаковые типы и ограничение в 1Кб
> памяти - rocket science.

Странные джависты, что джаву на С или С++ меняют. Возвожно как джависты не смогли адекватно работать, вот решили что С легче будет. Наивные =)))


PS хорошо отношусь к С и С++ разработчикам, но знаю что это другое множество задач ;)

Ответить | Правка | Наверх | Cообщить модератору

191. "Результаты анализа системой Coverity безопасности и качества..."  +/–
Сообщение от Ytch (?), 27-Фев-12, 01:24 
> Мне повезло, моя контора не ограничивает средства разработки, поэтому использую самосборный toolchain на GCC и радуюсь.

У меня, в этом смысле, аналогично. С некоторыми (а может и всеми) "сигнальниками" от Texas Instruments беда как раз в том, что альтернатив практически нет.
Analog Devices в этом смысле поступил гораздо лучше. Под многие семейства есть свободные toolchain и gcc, причем, судя по всему, исходно с некоторой поддержкой самих Analog Devices. Их собственные проприетарные компиляторы по опциям и "нестандартностям" более или менее похожи на gcc (даже в официальной документации к ним есть как минимум один раздел, посвященный сходствам и различиям с gcc).

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

Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

218. "Результаты анализа системой Coverity безопасности и..."  +/–
Сообщение от arisu (ok), 27-Фев-12, 14:00 
> По поводу «молодых» — ситуация полностью аналогичная. Либо «профильные» ребята, но с
> программированием туго, либо «программисты», но настолько «объектно-ориентированные»
> и/или далекие от «железа», что нужны годы, чтоб из оставшихся вышел
> толк в нашем деле.

если бы только у вас так… проблема с нормальными сотрудниками. «— Летать не умеют, стрелять — тоже пока не умеют. Но — орлы!» то есть, денег хотят как орлы, и чтобы при этом их отходы жизнедеятельности считались полезной работой.

Ответить | Правка | Наверх | Cообщить модератору

208. "Результаты анализа системой Coverity безопасности и качества..."  +/–
Сообщение от Аноним (-), 27-Фев-12, 10:45 
> это TI CodeComposer Studio. Включить его в strict-режим невозможно - он
> прекращает компиляцию найдя более определенного количества ошибок (точно не помню сколько,
> но много). Ирония в том, что при этом он так и
> не доходит до ваших файлов - эта тьма ошибок (для strict-режима)
> уже в их собственных файлах.

Что ж ты от проприетарщиков то хотел, дяденька?

Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

113. "Результаты анализа системой Coverity безопасности и качества..."  +/–
Сообщение от pavlinux (ok), 26-Фев-12, 05:45 
> Третье место — неинициализированные переменные. Как оно мимо gcc проходит? Или на
> выхлоп никто не смотрит, Werror не использует?


#include <stdio.h>
#include <string.h>
const char *TEXT = "123456789";
int main()
{
  char a;
        if (strlen(TEXT) > 20)
                a = 'A';
        if (strlen(TEXT) < 10)
                printf("%d\n", a);
  return 0;
}

$  gcc -W -Wall -Wextra -Werror -Wunused -Wuninitialized test.c

Молчит тварь :)

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

115. "Результаты анализа системой Coverity безопасности и..."  +1 +/–
Сообщение от arisu (ok), 26-Фев-12, 06:16 
а с чего бы ему вякать, если неинициализированные глобальные статики попадают в BSS, которая по-умолчанию инициализируется нулями? перемести 'a' в main() и убери static — сразу заорёт.

ты как первый раз замужем, честное слово.

p.s. опа, успел код поменять. забавно: a всегда инициализировано, причём значением из первого условия — если собирать с -O2. а если с -O0 — то там как и полагается бредятина. выверты gcc…

и да: молчит, зараза.

Ответить | Правка | Наверх | Cообщить модератору

118. "Результаты анализа системой Coverity безопасности и..."  +1 +/–
Сообщение от pavlinux (ok), 26-Фев-12, 06:24 
> перемести 'a' в main() и убери static — сразу заорёт.

А может сразу инициализировать, хрен ли мучатся?!
Есть пример. Рабочий! Глючный! Умнож такую багу
на десяки тыщь строк, и ищи её там...

Ответить | Правка | Наверх | Cообщить модератору

120. "Результаты анализа системой Coverity безопасности и..."  +1 +/–
Сообщение от arisu (ok), 26-Фев-12, 06:25 
а ты тоже сразу отвечать не спеши, у меня волшебная кнопка редактора работает.
Ответить | Правка | Наверх | Cообщить модератору

209. "Результаты анализа системой Coverity безопасности и..."  +/–
Сообщение от Аноним (-), 27-Фев-12, 10:47 
> а ты тоже сразу отвечать не спеши, у меня волшебная кнопка редактора
> работает.

Соревнуетесь кто кого техничнее поднае... редактированием? :)

Ответить | Правка | Наверх | Cообщить модератору

121. "Результаты анализа системой Coverity безопасности и..."  +/–
Сообщение от arisu (ok), 26-Фев-12, 06:26 
p.s. в любом случае за такой код надо тестикулы отрывать.
Ответить | Правка | К родителю #118 | Наверх | Cообщить модератору

123. "Результаты анализа системой Coverity безопасности и..."  +/–
Сообщение от pavlinux (ok), 26-Фев-12, 06:29 
> p.s. в любом случае за такой код надо тестикулы отрывать.

А в таком примере, переменная "a" может уползти далеко,
за 3-4 функции, через 5 файлов,... а если это библиотека,
которую использует другая библиотека, так ваще жо..а.

Ответить | Правка | Наверх | Cообщить модератору

125. "Результаты анализа системой Coverity безопасности и..."  +/–
Сообщение от arisu (ok), 26-Фев-12, 06:35 
just don't do that. есть же хорошая практика: изначально присваивать переменной чушь и assert'ить. ну, и assert'ить на предмет соблюдения контрактов, конечно. «и много-много макросов детишкам принесла…»
Ответить | Правка | Наверх | Cообщить модератору

126. "Результаты анализа системой Coverity безопасности и..."  +/–
Сообщение от pavlinux (ok), 26-Фев-12, 06:46 
> just don't do that. есть же хорошая практика: изначально присваивать переменной чушь
> и assert'ить. ну, и assert'ить на предмет соблюдения контрактов, конечно. «и
> много-много макросов детишкам принесла…»

В ядре почти все свободные переменные неинициализируются.
Свободные, в смысле те, которые могут не использоваться.
Там каждый грамм на счету.

Ответить | Правка | Наверх | Cообщить модератору

122. "Результаты анализа системой Coverity безопасности и..."  +/–
Сообщение от pavlinux (ok), 26-Фев-12, 06:27 
> а с чего бы ему вякать, если неинициализированные глобальные статики попадают в
> BSS, которая по-умолчанию инициализируется нулями? перемести 'a' в main() и убери
> static — сразу заорёт.
> ты как первый раз замужем, честное слово.
> p.s. опа, успел код поменять. забавно: a всегда инициализировано, причём значением из
> первого условия — если собирать с -O2. а если с -O0
> — то там как и полагается бредятина. выверты gcc…
> и да: молчит, зараза.


char *a;
        if (strlen(TEXT) > 20)
                a = "A";
        if (strlen(TEXT) < 10)
                printf("%d\n", ++a);

А вот так SEGFALT словим

Ответить | Правка | К родителю #115 | Наверх | Cообщить модератору

141. "Результаты анализа системой Coverity безопасности и..."  +/–
Сообщение от qux (ok), 26-Фев-12, 13:24 
Тогда или ++(*a), или %p и отсутствие сегфолта, не?
Во втором случае оно еще и ругается уже.
Ответить | Правка | Наверх | Cообщить модератору

124. "Результаты анализа системой Coverity безопасности и..."  +/–
Сообщение от pavlinux (ok), 26-Фев-12, 06:33 
> забавно: a всегда инициализировано, причём значением из  первого условия

:)

Ответить | Правка | К родителю #115 | Наверх | Cообщить модератору

137. "Результаты анализа системой Coverity безопасности и качества..."  +/–
Сообщение от Df232z (ok), 26-Фев-12, 11:59 
> Третье место — неинициализированные переменные. Как оно мимо gcc проходит? Или на
> выхлоп никто не смотрит, Werror не использует?

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


#include <stdio.h>
void f1(){
  int a = 100;
  a++;
}
void f2(){
  int b; /*!*/
  printf("Sure 101 = %d",b);
}
int main(){
 f1();
 f2();
}

Очень активно используется в ядре линукс. Также почти все звуковые драйверы написаны подобным образом, но это скорее по историческим обстоятельствам.

Метод работать то работает, только надежности не прибавляет.

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

140. "Результаты анализа системой Coverity безопасности и качества..."  +/–
Сообщение от qux (ok), 26-Фев-12, 13:18 
Где оно в ядре, взглянуть можно для интереса? Пытался найти, не получилось, -Wno-uninitialized например только в одном месте, не звук.
Ответить | Правка | Наверх | Cообщить модератору

149. "Результаты анализа системой Coverity безопасности и качества..."  –1 +/–
Сообщение от Df232z (ok), 26-Фев-12, 14:23 
Кому нравятся ругань компилятора?
Правильно - никому.
Так что починим?
Правильно - нет.
Костылик вот наш ответ.
>>linux-3.3-rc5


/*
 * A trick to suppress uninitialized variable warning without generating any
 * code
 */
#define uninitialized_var(x) x = x

Ну ты понял.
Кстати ответ тем кто считает, что компилятор нам спасет от всех напастей.

Ответить | Правка | Наверх | Cообщить модератору

154. "Результаты анализа системой Coverity безопасности и..."  +1 +/–
Сообщение от arisu (ok), 26-Фев-12, 14:37 
и что это должно продемонстрировать? что компилятор неидеален, и иногда его ворнинги надо насильно затыкать? Кэп, мы в курсе. а просили мы продемонстрировать то, что ты назвал «тунелинг» и на голубом глазу утверждаешь, что в ядре оно «очень активно используется». поскольку ты так уверен — у тебя не должно быть затруднений с приведением хотя бы пары десятков мест, где это используется (хотя для «активно» надо бы сотни как минимум, да уж ладно…)
Ответить | Правка | Наверх | Cообщить модератору

161. "Результаты анализа системой Coverity безопасности и качества..."  +/–
Сообщение от qux (ok), 26-Фев-12, 15:01 
Прикольно. Но еще бы передачу между функциями увидеть.

Хотя не понял, как это работает. Если использовать для глобальной переменной, то gcc выдает ошибку "initializer element is not constant". А для автоматической переменной почему не так? Компилит молча с "gcc -O0 -g -Wall -Wextra -pedantic --std=c90".

clang тоже молча собирает (с дефолтными опциями). С --analyze отлавливает.

Ответить | Правка | К родителю #149 | Наверх | Cообщить модератору

193. "Результаты анализа системой Coverity безопасности и качества..."  +/–
Сообщение от pavlinux (ok), 27-Фев-12, 03:41 
> Где оно в ядре, взглянуть можно для интереса? Пытался найти, не получилось,

Ну вот напрямер http://lxr.linux.no/#linux+v3.2.7/drivers/xen/xen-selfballoo...

На 151-ой строке объявляют и не инициализируют cur_frontswap_pages,
на 155-ой это неясное значение присваивают другой переменной.
на 158-ой идёт сравнение, уже инициализированной, cur_frontswap_pages с
неясным значением у last_frontswap_pages.

Тут и ёжику понятно, что эти две переменные используются
как проверка работы функции frontswap_curr_pages().
То есть, это присваивание однозначно определяет то,
что эти две переменные меж собой равны, даже не инициализируемые вручную.

Но факт присваивания неинициализированной переменно налицо.

Вот Coverity, за подобный такому, шухер, и получает бабло от АНБ,
заказы от корпоративщиков, и орёт на каждом заборе, что они находят баги. :)


static void frontswap_selfshrink(void)
{
        static unsigned long cur_frontswap_pages;
        static unsigned long last_frontswap_pages;
        static unsigned long tgt_frontswap_pages;
        last_frontswap_pages = cur_frontswap_pages;
        cur_frontswap_pages = frontswap_curr_pages();
 
        if (!cur_frontswap_pages ||
                        (cur_frontswap_pages > last_frontswap_pages)) {
                frontswap_inertia_counter = frontswap_inertia;
                return;
        }
...

Ответить | Правка | К родителю #140 | Наверх | Cообщить модератору

200. "Результаты анализа системой Coverity безопасности и качества..."  +/–
Сообщение от Alex_S (??), 27-Фев-12, 09:58 
>> Где оно в ядре, взглянуть можно для интереса? Пытался найти, не получилось,
> Ну вот напрямер http://lxr.linux.no/#linux+v3.2.7/drivers/xen/xen-selfballoo...
> На 151-ой строке объявляют и не инициализируют cur_frontswap_pages,
>         static unsigned long cur_frontswap_pages;

  эй, а разве static переменные внутри функции не в ноль инициализируютя по умолчанию ?

Ответить | Правка | Наверх | Cообщить модератору

221. "Результаты анализа системой Coverity безопасности и..."  +/–
Сообщение от arisu (ok), 27-Фев-12, 14:06 
>   эй, а разве static переменные внутри функции не в ноль
> инициализируютя по умолчанию ?

а вот кстати не помню. ау, у кого там стандарт под рукой?

Ответить | Правка | Наверх | Cообщить модератору

228. "Результаты анализа системой Coverity безопасности и..."  +/–
Сообщение от qux (ok), 27-Фев-12, 16:03 
А кстати да. То есть работать должно нормально, хоть стиль и.. хромает.

If an object that has static storage duration is not initialized explicitly, it is initialized implicitly as if every member that has arithmetic type were assigned 0 and every member that has pointer type were assigned a null pointer constant.

Ответить | Правка | Наверх | Cообщить модератору

229. "Результаты анализа системой Coverity безопасности и качества..."  +/–
Сообщение от Noname (??), 27-Фев-12, 17:36 
>>> Где оно в ядре, взглянуть можно для интереса? Пытался найти, не получилось,
>> Ну вот напрямер http://lxr.linux.no/#linux+v3.2.7/drivers/xen/xen-selfballoo...
>> На 151-ой строке объявляют и не инициализируют cur_frontswap_pages,
>>         static unsigned long cur_frontswap_pages;
>   эй, а разве static переменные внутри функции не в ноль
> инициализируютя по умолчанию ?

Практически везде в 0, но это скорее костыль чем фича. :)

Ответить | Правка | К родителю #200 | Наверх | Cообщить модератору

219. "Результаты анализа системой Coverity безопасности и..."  +/–
Сообщение от arisu (ok), 27-Фев-12, 14:03 
человек имел в виду совсем другое. он утверждает, что в ядре активно используется хак с неявной передачей локальных переменных через стек. вот мы хотим видеть доказательства сего утверждения. твой пример — он совсем из другой оперы, тут и стек-то не задействован.
Ответить | Правка | К родителю #193 | Наверх | Cообщить модератору

147. "Результаты анализа системой Coverity безопасности и..."  +/–
Сообщение от arisu (ok), 26-Фев-12, 14:09 
на самом деле даже средней тупости оптимизатор понаделает тут мегапроблем. что, кстати, было известно давно, чуть ли не с момента появления оптимизирующих компиляторов.

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

Ответить | Правка | К родителю #137 | Наверх | Cообщить модератору

177. "Результаты анализа системой Coverity безопасности и качества..."  +/–
Сообщение от Xasd (ok), 26-Фев-12, 18:07 
> Позволяет передавать значения переменных в функцию без дополнительных затрат времени.
> ...
> Очень активно используется в ядре линукс. ...

если это используется хотябы гдето [я имею ввиду серъёзные проекты, а не на домашней странице Васи Пупкина] -- то я очередной раз очень разочаруюсь в жизни :-(

Ответить | Правка | К родителю #137 | Наверх | Cообщить модератору

179. "Результаты анализа системой Coverity безопасности и..."  +/–
Сообщение от arisu (ok), 26-Фев-12, 18:12 
> если это используется хотябы гдето

раньше использовалось. тю, сам использовал ещё во времена DOS — даже с разрешёнными прерываниями.

Ответить | Правка | Наверх | Cообщить модератору

195. "Результаты анализа системой Coverity безопасности и качества..."  +/–
Сообщение от pavlinux (ok), 27-Фев-12, 05:45 
> Очень активно используется в ядре линукс.

Ага, щаз, сто тыщь раз...

gcc -fipa-pure-const test.c
./a.out
101=0

-fipa-pure-const входит во флаг -O, а линуховый дефолтный -02

Так что, слово "активно" совсем не уместно.

Ответить | Правка | К родителю #137 | Наверх | Cообщить модератору

220. "Результаты анализа системой Coverity безопасности и..."  +/–
Сообщение от arisu (ok), 27-Фев-12, 14:05 
т-с-с-с. ну что ты всё ломаешь? щаз обидишь его, и он не скажет, какие именно участки ядра надо переделать. а я хотел потом втихаря патчей заслать и выпендриться, сколько багов починил!
Ответить | Правка | Наверх | Cообщить модератору

234. "Результаты анализа системой Coverity безопасности и качества..."  +/–
Сообщение от netch (ok), 28-Фев-12, 16:53 
> Все просто - не инициализированные переменные активно используются.
> Есть специальная техника - туннелирование.
> Позволяет передавать значения переменных в функцию без дополнительных затрат времени.

Это должно работать очень ненадёжно.
Gcc любит оптимизацию работы со стеком следующим образом: возврат позиции SP (ESP, RSP - неважно) после каждой функции не делается, а делается только в конце. При нескольких последовательных вызовах позиция SP будет постепенно уползать влево. Это частично отключается в случае вызовов внутри цикла (SP на входе в цикл должен иметь всегда одно и то же значение), но при линейных вызовах позволяет экономить операции.
При такой оптимизации адреса для f1.a и f2.h будут разными, и передача данных не случится.

> Очень активно используется в ядре линукс. Также почти все звуковые драйверы написаны
> подобным образом, но это скорее по историческим обстоятельствам.
> Метод работать то работает, только надежности не прибавляет.

Ну теперь я не удивляюсь тому, как в Linux относятся к звуку.

Ответить | Правка | К родителю #137 | Наверх | Cообщить модератору

235. "Результаты анализа системой Coverity безопасности и..."  +/–
Сообщение от arisu (ok), 28-Фев-12, 17:05 
> Ну теперь я не удивляюсь тому, как в Linux относятся к звуку.

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

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру