Daiki Ueno wrote:
> Thanks for the update. I'm attaching a slightly modified version of the
> patch, with typo and style fixes (e.g. adding two spaces after a period,
> according to GCS, etc).
>
Thanks. ^^ And fixed typo, cp1361 to cp1381.
> KO Myung-Hun writes:
>
>> I used CODEPAGE and COU
Pádraig Brady wrote on 2014-12-14:
> Thanks for the extra info. I pushed this:
> http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=1fafbb30
Note, to clarify the expectations: The 'parse-datetime' module still requires
bison to generate the parse-datetime.c file. The comment in m4/bison.m4
Paul Eggert wrote:
> I thought about that, but my kneejerk reaction was that the likelihood that a
> new architecture would come in without C11 support was low enough (and
> declining) that it didn't seem worth the trouble of adding a dependency on
> the
> longlong module.
OK.
> But perhaps I
Hi Joel,
You wrote on 2014-12-13:
> Both BFD and GDB use a number of procfs routines, and those routines
> are apparently incompatible with largefile support on 32bit solaris
> (sparc32, x86).
Thanks for the notice, but gnulib deals with portability pitfalls
of ISO C / POSIX / GNU APIs. Portabili
Bruno Haible wrote:
How about adding a member
#if @HAVE_LONG_LONG_INT@
long long int __li;
#endif
to this union? Not that it would make a difference on the existing
architectures, but it may be more future-proof.
I thought about that, but my kneejerk reaction was that the likelihood th
Hi Paul,
On 2014-12-12 you wrote:
> +/* Some platforms lack max_align_t. */
> +#if !@HAVE_MAX_ALIGN_T@
> +typedef union
> +{
> + char *__p;
> + double __d;
> + long double __ld;
> + long int __i;
> +} max_align_t;
> +#endif
How about adding a member
#if @HAVE_LONG_LONG_INT@
long long in
