From owner-svn-src-all@FreeBSD.ORG Fri Mar 27 01:29:00 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D78815BC for ; Fri, 27 Mar 2015 01:29:00 +0000 (UTC) Received: from nm28.bullet.mail.bf1.yahoo.com (nm28.bullet.mail.bf1.yahoo.com [98.139.212.187]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8A15AA22 for ; Fri, 27 Mar 2015 01:29:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1427419738; bh=+Zm2L2dj4emWqg91Cd3XpzAheHaT742fFh4s8LVKSaE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=ewKDX3yzHNG1nwrvEbMm5mXZEFpQRDQrNOGEFEjVaGOkA3EWB97h2bFJFqK/i6cpqqHei/lWd69nsouGUSFLPeN4hr13cCV3wfIwUWt3h7Po2V/nDi8tUGnaQcCqRjK/Ppp6ZdtbV3nr+Oc7UzH72p4FlRnbQysRHZ1RiqoNy6mjiNzCeMFGFpe58UHuDVhxotZDD5bYrDuqyeqVrApgk8Z0+ceuDT9xud/KqRUxzb0gHuFrBEDvOXaCJah5tabnbAFsMbRk1GWNI528KqAxoDqxEDck5U7XuLpcy6zlQl1fMRssgO3uk1sGOb8wLa+ph2zKmTajEsD5YVjFtfmB7g== Received: from [98.139.170.178] by nm28.bullet.mail.bf1.yahoo.com with NNFMP; 27 Mar 2015 01:28:58 -0000 Received: from [98.139.213.14] by tm21.bullet.mail.bf1.yahoo.com with NNFMP; 27 Mar 2015 01:28:58 -0000 Received: from [127.0.0.1] by smtp114.mail.bf1.yahoo.com with NNFMP; 27 Mar 2015 01:28:58 -0000 X-Yahoo-Newman-Id: 747230.74692.bm@smtp114.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Eao.k9MVM1m2rNkeaBcUeXHZQYiAK1WOMtwOC0uz2RhBYfI kHCOCae29ytWqvt7.FxPOhdX8Jxg04Zj7F9rvu4WWxJ6w6FtF4DWS9FRucHl kZ9BfoXrCE_LV_HPmoyJKIULEmlK8lvt0iFCOc8WqsCXaDj_lFDiqRWmuiyz lp_zwvL3BXgVxaki92rNta9kfUILBRFiZGSmGb5prKFKTl6HhAH7XZd1jBGX 9fb2ntdlHA6vb6CJQ2qvV1iwq7u4VviRKoM4EBvKtPQN4CPhT6fswh22p.Cx xR4sv6Sc5DROWrR1657fKbPAx0g_63cNeBmrriTYlu2CAntfCv3QU0x96l6. xAznR1TOkFnIt6fRIHjw4yu.bZpgS5fa2wQSQJwht8gO1IXikH8NOBrccQCE 1xWu4BsVOmrpKh5HIQY72_tRhNEHHY4z6UTyvsgUtDBhG_xGVf3_srnlLQQl wMGCKLKSz6GRbNtGVFwxtRaa2jAU8g9bkAcujsrY8b766MOCb.o76gQAx0rG OLqWedtEaAkwrbfUYY5V3APJV_Q4lLOkd X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: svn commit: r280700 - head/sys/sys From: Pedro Giffuni In-Reply-To: <20150327104018.D994@besplex.bde.org> Date: Thu, 26 Mar 2015 20:28:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2EC15229-DE96-4200-A905-803028B22707@FreeBSD.org> References: <201503261600.t2QG0as2045101@svn.freebsd.org> <20150327104018.D994@besplex.bde.org> To: Bruce Evans X-Mailer: Apple Mail (2.2070.6) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 01:29:00 -0000 > Il giorno 26/mar/2015, alle ore 19:40, Bruce Evans = 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.