Date: Sun, 24 Nov 2013 08:11:13 -0700 From: Warner Losh <imp@bsdimp.com> To: David Chisnall <theraven@FreeBSD.org> Cc: toolchain@FreeBSD.org, Pedro Giffuni <pfg@FreeBSD.org> Subject: Re: Apple's GCC 42 enhancements (was Re: [CFT] Experimental gcc update). Message-ID: <573FEF92-255E-4C71-B5A3-496A0C504925@bsdimp.com> In-Reply-To: <3826345B-E783-43C7-B4AB-A05C95C1A8A2@FreeBSD.org> References: <528A924A.8050904@FreeBSD.org> <529127F8.5080606@FreeBSD.org> <3826345B-E783-43C7-B4AB-A05C95C1A8A2@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 24, 2013, at 5:54 AM, David Chisnall wrote: > On 23 Nov 2013, at 22:11, Pedro Giffuni <pfg@freebsd.org> wrote: >=20 >> I have particular interest in -fwritable-strings >> and the block support, mostly with the idea of making our gcc >> somewhat more compatible to clang. >=20 > I would absolutely love to see our GCC have blocks support. It would = be very nice to be able to use blocks in libc. =20 >=20 > I have some macros that allow code to call blocks even when compiled = with a compiler that doesn't support them, but having native blocks = support would be fantastic. It's worth noting that Apple's libc = includes a few _b variants of standard library functions: >=20 > scandir_b > err_set_exit_b > fts_open_b > glob_b > atexit_b > bsearch_b > heapsort_b > mergesort_b > psort_b > qsort_b >=20 > These all do the same as their non-_b-suffixed equivalents, but take a = block as an argument instead of a function pointer. Adding them has = been on my todo list for a while, and this would give me a strong = incentive to do so... Cool! Any chance clang supports this Apple extension? :) Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?573FEF92-255E-4C71-B5A3-496A0C504925>