27661 2012-08-24 02:50:32 +0400 gcc warnings with reentrant parser 2012-09-05 19:31:19 +0400 1 1 4 Development Sisyphus flex unstable all Linux CLOSED FIXED P3 minor --- 1 legion placeholder glebfm ldv placeholder vt qa-sisyphus oldest_to_newest 132961 0 legion 2012-08-24 02:50:32 +0400 При сборке reentrant парсера получаю: loadkeys.analyze.c: In function ‘yy_fatal_error’: loadkeys.analyze.c:2532:58: warning: unused parameter ‘yyscanner’ [-Wunused-parameter] loadkeys.analyze.c: At top level: loadkeys.analyze.c:2582:5: warning: no previous prototype for ‘yyget_column’ [-Wmissing-prototypes] loadkeys.analyze.c:2658:6: warning: no previous prototype for ‘yyset_column’ [-Wmissing-prototypes] loadkeys.analyze.c: In function ‘yyalloc’: loadkeys.analyze.c:2864:43: warning: unused parameter ‘yyscanner’ [-Wunused-parameter] loadkeys.analyze.c: In function ‘yyrealloc’: loadkeys.analyze.c:2869:58: warning: unused parameter ‘yyscanner’ [-Wunused-parameter] loadkeys.analyze.c: In function ‘yyfree’: loadkeys.analyze.c:2881:36: warning: unused parameter ‘yyscanner’ [-Wunused-parameter] Проблемы известны давно: http://sourceforge.net/mailarchive/message.php?msg_id=23176513 http://sourceforge.net/mailarchive/message.php?msg_id=25967956 так что есть надежда на их исправление в апстриме. 133089 1 ldv 2012-09-01 20:47:54 +0400 Какой коммит из какого репозитория какой командой приводит к таким жалобам? 133091 2 legion 2012-09-01 22:52:27 +0400 Я получаю это на репозитории: http://git.altlinux.org/people/legion/packages/kbd.git?p=kbd.git;a=shortlog;h=refs/heads/loadkeys при сборке утилиты loadkeys. Сборка осуществляется autotools. 133092 3 ldv 2012-09-02 00:18:51 +0400 После обновления бизона до bison-2.6.2-alt1 бранч loadkeys не собирается с диагностикой: loadkeys.h:157:14: error: unknown type name 'yyscan_t' Пробовал как действующий flex-2.5.35-alt5, так и будущий flex-2.5.36-alt1. В код kbd не смотрел. 133093 4 legion 2012-09-02 02:14:19 +0400 (В ответ на комментарий №3) > После обновления бизона до bison-2.6.2-alt1 бранч loadkeys не собирается с > диагностикой: > loadkeys.h:157:14: error: unknown type name 'yyscan_t' Поставил bison-2.6.2-alt1, в kbd бранч loadkeys собрался. В системе flex-2.5.35-alt5. 133094 5 legion 2012-09-02 02:16:10 +0400 (В ответ на комментарий №4) > Поставил bison-2.6.2-alt1, в kbd бранч loadkeys собрался. В системе > flex-2.5.35-alt5. Я ошибся. loadkeys.c был от предыдущей версии. Да, не собирается. 133095 6 legion 2012-09-02 02:29:15 +0400 На первый взгляд ситуация смешная. В loadkeys.y есть include сгенерированных хэдеров: #include "loadkeys.h" #include "loadkeys.analyze.h" В loadkeys.h судя по git-diff появилось: +#ifdef YYPARSE_PARAM +#if defined __STDC__ || defined __cplusplus +int yyparse (void *YYPARSE_PARAM); +#else +int yyparse (); +#endif +#else /* ! YYPARSE_PARAM */ +#if defined __STDC__ || defined __cplusplus +int yyparse (yyscan_t scanner, struct keymap *kmap); +#else +int yyparse (); +#endif +#endif /* ! YYPARSE_PARAM */ Тип yyscan_t объявлен в loadkeys.analyze.h. Если в loadkeys.y поменять порядок хэдеров на: #include "loadkeys.analyze.h" #include "loadkeys.h" То получаем ошибку: loadkeys.analyze.h:271:1: error: unknown type name ‘YYSTYPE’ потому что YYSTYPE объявлен в loadkeys.h. 133096 7 legion 2012-09-02 02:54:19 +0400 У старого bison-2.4.3: $ fgrep -x -B1 -A3 'int yyparse (yyscan_t scanner, struct keymap *kmap);' loadkeys.{c,h} loadkeys.c-#if defined __STDC__ || defined __cplusplus loadkeys.c:int yyparse (yyscan_t scanner, struct keymap *kmap); loadkeys.c-#else loadkeys.c-int yyparse (); loadkeys.c-#endif У bison-2.6.2-alt1 получается вот что: $ fgrep -x -B1 -A3 'int yyparse (yyscan_t scanner, struct keymap *kmap);' loadkeys.{c,h} loadkeys.c-#if defined __STDC__ || defined __cplusplus loadkeys.c:int yyparse (yyscan_t scanner, struct keymap *kmap); loadkeys.c-#else loadkeys.c-int yyparse (); loadkeys.c-#endif -- loadkeys.h-#if defined __STDC__ || defined __cplusplus loadkeys.h:int yyparse (yyscan_t scanner, struct keymap *kmap); loadkeys.h-#else loadkeys.h-int yyparse (); loadkeys.h-#endif это и приводит к ошибке. 133109 8 legion 2012-09-03 14:57:12 +0400 Данную проблему нагуглить не смог. Не могу понять, как разорвать взаимную зависимость. Такая ситуация точно не бага в bison ? 133110 9 ldv 2012-09-03 15:02:13 +0400 (In reply to comment #8) > Данную проблему нагуглить не смог. Не могу понять, как разорвать взаимную > зависимость. Такая ситуация точно не бага в bison ? bison не подозревает об этой взаимной зависимости: когда он формирует прототип функции yyparse на основе %parse-param, ему все равно, как определены используемые в %parse-param конструкции. Из этих соображений получается, что bison не виноват. С другой стороны, раньше это работало. 133111 10 legion 2012-09-03 15:26:28 +0400 (В ответ на комментарий №9) > bison не подозревает об этой взаимной зависимости: когда он формирует прототип > функции yyparse на основе %parse-param, ему все равно, как определены > используемые в %parse-param конструкции. Дело не только в этом. Тут связка %parse-param и %union... а если быть совсем точным, то и %define api.pure. %union создаёт в хэдере YYSTYPE, которая используется в flex при указании %bison-bridge. > Из этих соображений получается, что > bison не виноват. С другой стороны, раньше это работало. Раньше он не выносил объявление yyparse в хэдер. Сейчас получается, что нельзя передавать через %parse-param ничего flex'ового. Как исправление можно только сделать структуру объединяющую все передаваемые yyparse параметры. 133112 11 legion 2012-09-03 15:57:40 +0400 (В ответ на комментарий №10) > Как исправление можно только сделать структуру объединяющую все передаваемые > yyparse параметры. Хе. Так сделать нельзя. Любое использование yyscan_t (хэдер flex) влечёт необходимость определения YYSTYPE (хэдер bison). 133127 12 legion 2012-09-04 18:16:38 +0400 Ок. Проблема с непересобираемостью с bison-2.6.2 устранена в том же бранче. 133134 13 repository-robot 2012-09-05 19:31:19 +0400 flex-2.5.37-alt1 -> sisyphus: * Wed Sep 05 2012 Dmitry V. Levin <ldv@altlinux> 2.5.37-alt1 - Updated to flex-2.5.37-17-gbac5b2b. - flex.skl: fixed warnings generated by gcc -Wunused-parameter (closes: #27661).