Który dialekt c może pozwolić GCC na zabawę (...)?

Do kompilacji kodu starszego typu AC, która ma prototyp funkcjiKtóry dialekt c może pozwolić GCC na zabawę (...)?

void somefun(...)

gcc 4.1.2 zawsze sprawdzić błąd

error: ISO C requires a named argument before ...

Ale nie mogę zmodyfikować kod, więc opcja dialet co C powinna Używam, aby GCC skompilował ten kod?

gcc -c A.c ????

Źródło

2011-07-24 YourBestBet

Czy to ma jakiś sens? Jeśli nie masz nazwanego argumentu, prawdopodobnie nie masz dostępu do żadnego z argumentów. Powinno to być takie samo, jak 'void somefun()' (który nadal różni się od 'void somefun (void)' !!) – Szabolcs

Nie widzę żadnych opcji nowej wersji gcc, która może to zrobić. – Stan

możliwy duplikat [Czy możliwe jest posiadanie funkcji variadic w C bez żadnego parametru nie-variadycznego?] (Http://stackoverflow.com/questions/2622147/is-it-possible-to-have-a-variadic- parametr-w-c-z-nie-nie-wariackim) –

nie sądzę każdy dialektów C w GCC akceptuje to, ale G ++ to robi. Możesz więc umieścić definicję funkcji w bloku extern "C" {} i skompilować moduł zawierający ją pod numerem g++ (zakładając, że jest to również poprawna funkcja C++).

Należy następnie zadeklarować ją w języku C z kodem void somefun() (styl K &).

Będzie to wymagało również połączenia z g++.

Jeśli połączenie C++ nie jest tym, czego potrzebujesz, powinieneś zmienić funkcję, aby nie przyjmować żadnych argumentów i zadeklarować ją w stylu K & R.

Źródło

2011-07-24 14:05:17

Ten kod naprawdę kompiluje się na starym komputerze unixowym przy użyciu cc, a nawet bez żadnych konkretnych opcji. Wydaje mi się więc, że najpierw powinienem sprawdzić wersję CC tego komputera. Dzięki. – YourBestBet

nie sądzę już, że to możliwe. Zobacz komentarz w tej (3.4.0 - dość stary już) źródło GCC c-parse.in:

/* This is what appears inside the parens in a function declarator. 
    Is value is represented in the format that grokdeclarator expects. */ 
parmlist_2: /* empty */ 
     { $$ = get_parm_info (0); } 
    | ELLIPSIS 
     { $$ = get_parm_info (0); 
      /* Gcc used to allow this as an extension. However, it does 
      not work for all targets, and thus has been disabled. 
      Also, since func (...) and func() are indistinguishable, 
      it caused problems with the code in expand_builtin which 
      tries to verify that BUILT_IN_NEXT_ARG is being used 
      correctly. */ 
      error ("ISO C requires a named argument before `...'");

GCC 2.95.3 ma ten sam komentarz.

Nowsze wersje GCC (4.6.1) również nie widzę, aby mieć możliwość zaakceptowania tego kodu (z gcc/C-parse.c):

static struct c_arg_info * 
c_parser_parms_list_declarator (c_parser *parser, tree attrs) 
{ 
... 
    if (c_parser_next_token_is (parser, CPP_ELLIPSIS)) 
    { 
     struct c_arg_info *ret = build_arg_info(); 
     /* Suppress -Wold-style-definition for this case. */ 
     ret->types = error_mark_node; 
     error_at (c_parser_peek_token (parser)->location, 
     "ISO C requires a named argument before %<...%>"); 
     c_parser_consume_token (parser);

Źródło

2011-07-24 14:02:56 Mat

Który dialekt c może pozwolić GCC na zabawę (...)?

Odpowiedz

Powiązane problemy