> Il giorno 26/mar/2015, alle ore 19:40, Bruce Evans <b...@optusnet.com.au> ha > scritto: > > On Thu, 26 Mar 2015, Pedro F. Giffuni wrote: > >> Log: >> Introduce some allocation function attributes. >> >> Bring support for two gcc function attributes that are likely to be used >> in our system headers: >> ... >> The __alloc_size attribute required some workarounds for lint(1). >> Both attributes are supported by clang. > > It is broken for all non-C99 compilers, the same as __nonull(). lint > may be one of these, depending on implementation details and on how > well it supports non-C99 mode (I think it knows almost nothing of > C99, but uses cpp and is not careful to kill C99 features). >
It is not a bug, it’s a feature. I did check and variadic macros were introduced in gcc 2.95. the __nonnull() stuff requires gcc 3.3. __alloc_size requires gcc 4.3. All compilers we use in base and support in FreeBSD have the feature. For the base system it doesn’t really make sense to hold new features to support inferior compilers. If you need an older compiler it may be perhaps to support a new platform and I recall gcc 2.95 doesn’t even support amd64. > FreeBSD even has a non-C90 compiler (modulo bugs). It is named c89. Even the > compilers that implement most of C99 have a C90 mode. This > is specifed by the compiler flag -std=c89 or -std=gnu89. > OK. you can cause breakage by using old modes.This may have to be evaluated running an exp run on the ports tree. > The follow breakage happens for ... and/or __VA_ARGS__: > > - c89 -E on ... alone > q.c:1:13: warning: variadic macros are a C99 feature [-Wvariadic-macros] > #define foo(...) > ^ > foo(1, 2, 3) then expands to nothing. > > - c89 -E on ... and __VA_ARGS__: > Same warning. __VA_ARGS__ then expands as in C99. > > - clang -E -std=c89: > Same as in C99. -std=c89 is not very std. > > - clang -E -std=c89 -pedantic > Same as for c89. c89 uses -pedantic so as to be more std. > > - gcc295 -E -std=c89: > z.c:1: warning: invalid character in macro parameter name > z.c:1: badly punctuated parameter list in `#define' > > foo(1, 2, 3) then expands to nothing for the empty macro > and __VA_ARGS__ expands as in C99. -std=c89 actually works > for gcc295 > > - gcc34 -E -std=c89 [-pedantic], > - gcc42 -E -std=c89 [-pedantic]: > Like clang, but with a better error message: > > q.c:1:13: warning: anonymous variadic macros were introduced in C99 > > - gcc48 -E -std=c89 [-pedantic]: > Like clang, except the error message has not regressed so far (it > is verbose as in clang, but missing colorization). > The above are all warnings. You can usually get around those by setting options and those won’t stop your code from building. > - TenDRA 5.0.0 (an actual C90 compiler. I sometimes use this for its > better diagnostics. Though very verbose, the references to C90 > section numbers are useful): > TenDRA is awesome. I recall it uses it’s own C headers with different compatibility modes so it won’t be affected by cdefs.h and the use of such macros in our headers. > "z4.c", line 1: Error: > [ISO C90 6.8.3]: Badly punctuated parameters for macro 'foo'. > > "z4.c", line 3: Error: > [ISO C90 6.8.3]: Macro 'foo' applied with 3 arguments, not 0. > > TenDRA has its own headers which are very clean, but to use it > even to do syntax checks, you have to use the system headers > (tcc -Ysystem). > >> Modified: head/sys/sys/cdefs.h >> ============================================================================== >> --- head/sys/sys/cdefs.h Thu Mar 26 15:54:54 2015 (r280699) >> +++ head/sys/sys/cdefs.h Thu Mar 26 16:00:35 2015 (r280700) >> @@ -209,6 +212,7 @@ >> #define __unused >> #define __packed >> #define __aligned(x) >> +#define __alloc_size(...) >> #define __section(x) >> #define __weak >> #else > > The first bug is here. This is for lint. This is supposed to give a > null macro, but actually gives a syntax error except for C99 compilers. > I tried to update lint and fix it. I did the former and I failed the later. Other BSDs (Dragonfly and OpenBSD) were less patient ;). Compilers without some level of C99 compliance are likely to have much bigger problems to compile FreeBSD. If someone with real need for such support submits s fix I’ll be glad to commit it, but at this time I would really like to use __alloc_size( 1, 2) for calloc(). >> @@ -233,6 +237,11 @@ >> #define __aligned(x) __attribute__((__aligned__(x))) >> #define __section(x) __attribute__((__section__(x))) >> #endif >> +#if __has_attribute(alloc_size) || __GNUC_PREREQ__(4, 3) >> +#define __alloc_size(...) __attribute__((alloc_size(__VA_ARGS__))) > > This is broken by namespace pollution. alloc_size is in the application > namespace. It must be spelled with underscores like all the other > attributes in the macros. > I overlooked that, thank you! > The "..." in this is broken in c89 mode. Passing the #if only guarantees > that the attribute is supported. It doesn't guarantee that "..." is > supported. The name of the attribute may be relevant here too. We want > most the special macros to work in c89 and other strict standard modes. > Their names are spelled with underscores to make this possible. Standard > modes turn off gcc features like asm() and even "inline". Perhaps they > do the same for alloc_size(). > >> +#else >> +#define __alloc_size(...) >> +#endif > > Similarly for all hard-coded uses of "...". This #else clause is supposed > to give compatibility for all compilers that don't support alloc_size(). > But most of these compilers also don't support "...", so this almost > never works. > >> @@ -363,8 +372,10 @@ >> >> #if __GNUC_PREREQ__(3, 4) >> #define __fastcall __attribute__((__fastcall__)) >> +#define __result_use_check __attribute__((__warn_unused_result__)) >> #else >> #define __fastcall >> +#define __result_use_check >> #endif > > Changes like this are correct since they don't depend on compiler-[option]- > dependent syntactic features. > Pedro. _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
