[devel] Сообщения от компилятора

[devel] Сообщения от компилятора

[php-coder]

    Здравствуйте!

    Собираю маленький аплет wmnetload. В процессе сборки вываливается
    много предупреждений, хотя компиляция и заканчивается без ошибок.
    Хотелось бы узнать стОит ли добиваться того, чтобы этих предупреждений
    не было вообще?

    Есть много предупреждений следующих типов (что с ними делать?):

    - wmnetload.c:22: warning: ignoring #pragma ident
      
      В частности ему не нравится строчка:

      #pragma ident "@(#)wmnetload.c    1.15    03/02/23 meem"

      Что-то мне кажется, что эта директива используется лишь под Виндой.
      Нет?

    - wmnetload.c:887: warning: unused variable `ifcount'

      СтОит ли удалять такие переменные, которые не используются или нет?

    - wmnetload.c:1056: warning: passing arg 4 of `DAMakePixmapFromData'
      from incompatible pointer type

      Тут не знаю смогу ли я сам разобраться или лучше не трогать.

    - wmnetload.c:884: warning: 'loifrp' might be used uninitialized in
      this function

      Тут я так понимаю нужно находить где переменная определяется и
      инициализировать ее каким-нибудь дефолтным значением?


    Буду благодарен за вашу помощь!

-- 
+ php-coder
+ php-coder[at]altlinux[dot]ru

Re: [devel] Сообщения от компилятора

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]

* php-coder <php-coder@> [051008 10:23]:
>     Собираю маленький аплет wmnetload. В процессе сборки вываливается
>     много предупреждений, хотя компиляция и заканчивается без ошибок.
>     Хотелось бы узнать стОит ли добиваться того, чтобы этих предупреждений
>     не было вообще?
Да.  Надо быть готовым к тому, что в один светлый солнечный день
будет включен %def_enable Werror ;-)


>     - wmnetload.c:22: warning: ignoring #pragma ident
>       В частности ему не нравится строчка:
>       #pragma ident "@(#)wmnetload.c    1.15    03/02/23 meem"
Убить.

>     - wmnetload.c:887: warning: unused variable `ifcount'
>       СтОит ли удалять такие переменные, которые не используются или нет?
Да.

>     - wmnetload.c:1056: warning: passing arg 4 of `DAMakePixmapFromData'
>       from incompatible pointer type
>       Тут не знаю смогу ли я сам разобраться или лучше не трогать.
А вот тут надо разбираться в любом случае.

>     - wmnetload.c:884: warning: 'loifrp' might be used uninitialized in
>       this function
>       Тут я так понимаю нужно находить где переменная определяется и
>       инициализировать ее каким-нибудь дефолтным значением?
Да.

-- 
Regards, Sir Raorn.
-------------------
> В Сизифе не будет 2.4.23+, насколько я понял. 
То-то ed@ спрашивал, а не начать ли переход на 2.4.24.  Мож он не
в курсе просто? :-)
		-- mike in community@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: Сообщения от компилятора

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

On Mon, Oct 10, 2005 at 09:00:45AM +0400, Alexey I. Froloff wrote:
> > Собираю маленький аплет wmnetload. В процессе сборки
> > вываливается много предупреждений, хотя компиляция и
> > заканчивается без ошибок.  Хотелось бы узнать стОит ли
> > добиваться того, чтобы этих предупреждений не было вообще?
> Да.  Надо быть готовым к тому, что в один светлый солнечный
> день будет включен %def_enable Werror ;-)

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

Посему надеюсь, что эт ты про "быть готовым" (в принципе), а не
"будет включен" (конкретно) :]

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: Сообщения от компилятора

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 957 bytes --]

* Michael Shigorin <mike@> [051010 14:04]:
> > > Собираю маленький аплет wmnetload. В процессе сборки
> > > вываливается много предупреждений, хотя компиляция и
> > > заканчивается без ошибок.  Хотелось бы узнать стОит ли
> > > добиваться того, чтобы этих предупреждений не было вообще?
> > Да.  Надо быть готовым к тому, что в один светлый солнечный
> > день будет включен %def_enable Werror ;-)
> Люди, которые не отличают предупреждение и ошибку -- преступники.
> На примере нашего закона о государственной границе уже в этом
> летом убедился.
Некоторые предупреждения имеют тенденцию становиться ошибками.  А
некоторые ими на самом деле и являются.

> Посему надеюсь, что эт ты про "быть готовым" (в принципе), а не
> "будет включен" (конкретно) :]
Быть готовым и писать чистый код надо всегда...

-- 
Regards, Sir Raorn.
-------------------
И что все так любят на каждый тред новую рассылку создавать?
		-- mithraen in community@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: Сообщения от компилятора

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

On Mon, Oct 10, 2005 at 01:01:22PM +0300, Michael Shigorin wrote:
> Люди, которые не отличают предупреждение и ошибку -- преступники.
Часто в новых версиях gcc за тот же код вместо варнинга начинают выдавать
ошибку, полагая, что можно было успеть исправить тогда, когда выдавалось
предупреждение.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

"Мне так удобно" -- самый слабый аргумент, который можно услышать от
maintainer'а. Удобно должно быть пользователю.
		-- mhz in #4796

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: Сообщения от компилятора

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 503 bytes --]

On Mon, Oct 10, 2005 at 08:36:41PM +0600, Andrey Rahmatullin wrote:
> > Люди, которые не отличают предупреждение и ошибку --
> > преступники.
> Часто в новых версиях gcc за тот же код вместо варнинга
> начинают выдавать ошибку, полагая, что можно было успеть
> исправить тогда, когда выдавалось предупреждение.

Я не считаю GCC Steering Committee образцом, достойным
подражания, если честно.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: Сообщения от компилятора

[Alexey Voinov]

[-- Attachment #1: Type: text/plain, Size: 628 bytes --]

Michael Shigorin wrote
> > Да.  Надо быть готовым к тому, что в один светлый солнечный
> > день будет включен %def_enable Werror ;-)
> Люди, которые не отличают предупреждение и ошибку -- преступники.
> На примере нашего закона о государственной границе уже в этом
> летом убедился.
Язык C обладает таким замечательным свойством, что если не считать все
варнинги за ошибки, можно налететь на большие проблемы даже при
тривиальном изменении уровня оптимизации. Не далее как в пятницу
пронаблюдал это на соседнем рабочем месте.


-- 
Best Regards!
Alexey Voinov
	     
voins@voins.program.ru
voins@altlinux.ru


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: Сообщения от компилятора

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 960 bytes --]

В Втр, 11/10/2005 в 08:36 +0400, Alexey Voinov пишет:
> Michael Shigorin wrote
> > > Да.  Надо быть готовым к тому, что в один светлый солнечный
> > > день будет включен %def_enable Werror ;-)
> > Люди, которые не отличают предупреждение и ошибку -- преступники.
> > На примере нашего закона о государственной границе уже в этом
> > летом убедился.
> Язык C обладает таким замечательным свойством, что если не считать все
> варнинги за ошибки, можно налететь на большие проблемы даже при
> тривиальном изменении уровня оптимизации. Не далее как в пятницу
> пронаблюдал это на соседнем рабочем месте.

Это не значит, что нужно делать Sisyphus еще более сизифовым трудом,
обрекая packager'ов на исправление политики толерантности к
предупреждениям, принятой upstream (разумеется, есть много пакетов,
которые регулярно собираются с -Werror, но это не повод). На самом деле
это просто нереально. Я не знаю, почему это здесь всерьез обсуждается.


[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: Сообщения от компилятора

[Денис Смирнов]

On Tue, Oct 11, 2005 at 11:00:27AM +0400, Mikhail Zabaluev wrote:

MZ> Это не значит, что нужно делать Sisyphus еще более сизифовым трудом,
MZ> обрекая packager'ов на исправление политики толерантности к
MZ> предупреждениям, принятой upstream (разумеется, есть много пакетов,
MZ> которые регулярно собираются с -Werror, но это не повод). На самом деле
MZ> это просто нереально. Я не знаю, почему это здесь всерьез обсуждается.

/me думает что в будущем (том, которое светлое) имеет смысл ставить
-Werror по-умолчанию, дав мантейнерам в руки средство легко это отключить.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

Re: [devel] Re: Сообщения от компилятора

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 811 bytes --]

On Tue, Oct 11, 2005 at 08:29:04PM +0400, Денис Смирнов wrote:
> On Tue, Oct 11, 2005 at 11:00:27AM +0400, Mikhail Zabaluev wrote:
> 
> MZ> Это не значит, что нужно делать Sisyphus еще более сизифовым трудом,
> MZ> обрекая packager'ов на исправление политики толерантности к
> MZ> предупреждениям, принятой upstream (разумеется, есть много пакетов,
> MZ> которые регулярно собираются с -Werror, но это не повод). На самом деле
> MZ> это просто нереально. Я не знаю, почему это здесь всерьез обсуждается.
> 
> /me думает что в будущем (том, которое светлое) имеет смысл ставить
> -Werror по-умолчанию, дав мантейнерам в руки средство легко это отключить.

Посмотрите, с какими параметрами собирается hasher-priv, и скажите, в
каком светлом будущем это можно включить по умолчанию? :)


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[JT] Re: [devel] Re: Сообщения от компилятора

[Денис Смирнов]

On Tue, Oct 11, 2005 at 08:31:59PM +0400, Dmitry V. Levin wrote:

DVL> Посмотрите, с какими параметрами собирается hasher-priv, и скажите, в
DVL> каком светлом будущем это можно включить по умолчанию? :)

/me надеется до этого дожить :)

-- 
С уважением, Денис

http://freesource.info

Re: [devel] Re: Сообщения от компилятора

[Alexey Voinov]

[-- Attachment #1: Type: text/plain, Size: 743 bytes --]

Mikhail Zabaluev wrote
> Это не значит, что нужно делать Sisyphus еще более сизифовым трудом,
> обрекая packager'ов на исправление политики толерантности к
> предупреждениям, принятой upstream (разумеется, есть много пакетов,
> которые регулярно собираются с -Werror, но это не повод). На самом деле
> это просто нереально. Я не знаю, почему это здесь всерьез обсуждается.
Я на своей шкуре в довольно неприятной форме ощутил как upstream относится
к чистке кода. Тем не менее, лично я готов к исправлению варнингов в своих
пакетах и поддержке этих патчей. Все остальные могут отключить Werror в
своих пакетах или обратиться за помощью ко мне.

-- 
Best Regards!
Alexey Voinov
	     
voins@voins.program.ru
voins@altlinux.ru


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] standards.freedesktop.org icon paths

[Igor Vlasenko]

Уважаемые коллеги,
хочу обратить ваше внимание.
На http://wiki.sisyphus.ru/devel/IconPaths?v=11zi
написано:

> Кстати, а как насчет /usr/share/icons/*.{xpm,png} и
> /usr/share/icons/{large,mini} √ как они вписываются в эту схему?
> Надо ли класть значки туда?
нет

и по контексту рассылки можно понять, что имеется в виду 
бросать все в /usr/share/pixmaps.

Т. е. предлагается 
1) переделывать пакеты.

2) достругивать малые оконные менеджеры
(например, icewm в ALT Master 24:
icewm/preferences: (нет /usr/share/pixmaps)
IconPath="/usr/share/icons:/usr/share/icons/mini:\
/usr/share/icons/locolr/16x16/apps/:\
/usr/share/icons/hicolor/16x16/apps/:\
/usr/X11R6/lib/X11/icewm/icons"
)

3) Бороться с возникающими при этом проблемами несовместимости
и геморроем/граблями (hidden raker:)) с backport'ингом.

Насколько я понял. это предложение возникло из-за какой-то неудачной
сборки Гнома, при этом была ссылка на 
http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html

Однако в указанном месте говорится противное.
Единственное место с упоминанием /usr/share/pixmaps следующее:
<cite>
Directory Layout:
Icons and themes are looked for in a set of directories. By default,
apps should look in $HOME/.icons (for backwards compatibility), in
$XDG_DATA_DIRS/icons and in /usr/share/pixmaps (in that order). 
</cite>
В этом месте говорится только о том, что /usr/share/icons
имеет приоритет над /usr/share/pixmaps.

Более того, далее явно указывается /usr/share/icons как корень:
<cite>
Installing Application Icons:
So, you're an application author, and want to install application
icons so that they work in the KDE and Gnome menus. Minimally you
should install a 48x48 icon in the hicolor theme. This means
installing a PNG file in $prefix/share/icons/hicolor/48x48/apps. 
</cite>

Так что я думаю, убирать значки из
/usr/share/icons --- это вредный совет.

Кроме того, при этом остается затемненным вопрос с 16х16 
и 32х32 pixmaps. Их что, выбрасывать?
(Подсказка: icewm use 16x16 only)

Может лучше (дополнительно) 
ложить иконки(симлинки на них?) в /usr/share/icons/hicolor/(Size)x(Size) ?
Это будет в полном согласии с 
http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
и не будет ломать дров.

Ведь есть и другие оконные менеджеры.

Лучше допилить Гном, если возникнет необходимость?

-- 

Dr. Igor Vlasenko
--------------------
Topology Departament
Institute of Math
Kiev, Ukraine