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>
index | next in thread | previous in thread | raw e-mail
On Nov 24, 2013, at 5:54 AM, David Chisnall wrote: > On 23 Nov 2013, at 22:11, Pedro Giffuni <pfg@freebsd.org> wrote: > >> I have particular interest in -fwritable-strings >> and the block support, mostly with the idea of making our gcc >> somewhat more compatible to clang. > > I would absolutely love to see our GCC have blocks support. It would be very nice to be able to use blocks in libc. > > 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: > > scandir_b > err_set_exit_b > fts_open_b > glob_b > atexit_b > bsearch_b > heapsort_b > mergesort_b > psort_b > qsort_b > > 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? :) Warnerhelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?573FEF92-255E-4C71-B5A3-496A0C504925>