emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Android port


From: Eli Zaretskii
Subject: Re: Android port
Date: Sat, 05 Aug 2023 15:31:51 +0300

> From: Po Lu <luangruo@yahoo.com>
> Cc: Bruno Haible <bruno@clisp.org>,  angelo.g0@libero.it,
>   eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Sat, 05 Aug 2023 20:16:32 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Since the *printf family doesn't need to be replaced in the Emacs
> > build on MS-Windows, I'd rather we understood why the above causes
> > compilation errors.  Aren't Gnulib replacements for *printf functions
> > supposed to have prototypes compatible to the MinGW headers?
> 
> Judging from the headers Angelo provided, the issue lies in MinGW's
> headers defining (not merely declaring) asprintf:
> 
> #ifdef _GNU_SOURCE
> __mingw_ovr
> __attribute__ ((__format__ (gnu_printf, 2, 3))) __attribute__((nonnull (1,2)))
> int asprintf(char **__ret, const char *__format, ...)
> {
>   int __retval;
>   __builtin_va_list __local_argv; __builtin_va_start( __local_argv, __format 
> );
>   __retval = __mingw_vasprintf( __ret, __format, __local_argv );
>   __builtin_va_end( __local_argv );
>   return __retval;
> }
> 
> IMHO, the least risky solution remains disabling the vasprintf module
> entirely.

I agree.  We wanted to do that from the get-go, but you said it was
somehow impossible, or didn't work?

> We can revisit this problem when and if Emacs begins to rely on ISO
> C2X and C99 features supplied by Gnulib.

Right.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]