Date: Thu, 26 Mar 2015 20:28:54 -0500 From: Pedro Giffuni <pfg@FreeBSD.org> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r280700 - head/sys/sys Message-ID: <2EC15229-DE96-4200-A905-803028B22707@FreeBSD.org> In-Reply-To: <20150327104018.D994@besplex.bde.org> References: <201503261600.t2QG0as2045101@svn.freebsd.org> <20150327104018.D994@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Il giorno 26/mar/2015, alle ore 19:40, Bruce Evans = <brde@optusnet.com.au> ha scritto: >=20 > On Thu, 26 Mar 2015, Pedro F. Giffuni wrote: >=20 >> Log: >> Introduce some allocation function attributes. >>=20 >> 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. >=20 > 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). >=20 It is not a bug, it=E2=80=99s 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=E2=80=99t 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=E2=80=99t 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=3Dc89 or -std=3Dgnu89. >=20 OK. you can cause breakage by using old modes.This may have to be = evaluated running an exp run on the ports tree. =20 > The follow breakage happens for ... and/or __VA_ARGS__: >=20 > - 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. >=20 > - c89 -E on ... and __VA_ARGS__: > Same warning. __VA_ARGS__ then expands as in C99. >=20 > - clang -E -std=3Dc89: > Same as in C99. -std=3Dc89 is not very std. >=20 > - clang -E -std=3Dc89 -pedantic > Same as for c89. c89 uses -pedantic so as to be more std. >=20 > - gcc295 -E -std=3Dc89: > z.c:1: warning: invalid character in macro parameter name > z.c:1: badly punctuated parameter list in `#define' >=20 > foo(1, 2, 3) then expands to nothing for the empty macro > and __VA_ARGS__ expands as in C99. -std=3Dc89 actually works > for gcc295 >=20 > - gcc34 -E -std=3Dc89 [-pedantic], > - gcc42 -E -std=3Dc89 [-pedantic]: > Like clang, but with a better error message: >=20 > q.c:1:13: warning: anonymous variadic macros were introduced in C99 >=20 > - gcc48 -E -std=3Dc89 [-pedantic]: > Like clang, except the error message has not regressed so far (it > is verbose as in clang, but missing colorization). >=20 The above are all warnings. You can usually get around those by setting options and those won=E2=80=99t 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): >=20 TenDRA is awesome. I recall it uses it=E2=80=99s own C headers with = different compatibility modes so it won=E2=80=99t 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'. >=20 > "z4.c", line 3: Error: > [ISO C90 6.8.3]: Macro 'foo' applied with 3 arguments, not 0. >=20 > 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). >=20 >> Modified: head/sys/sys/cdefs.h >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> --- 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 >=20 > 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. >=20 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=E2=80=99ll 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__))) >=20 > 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. >=20 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(). >=20 >> +#else >> +#define __alloc_size(...) >> +#endif >=20 > 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. >=20 >> @@ -363,8 +372,10 @@ >>=20 >> #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 >=20 > Changes like this are correct since they don't depend on = compiler-[option]- > dependent syntactic features. >=20 Pedro.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2EC15229-DE96-4200-A905-803028B22707>