Re: time_rz.c and Android NDK r27

Bruno Haible writes: > Hi Po Lu, > >> This new release of the Android NDK defines timezone_t in time.h whether >> or not it defines the related tzalloc and localtime_rz extensions, which >> being new APIs are controlled by __ANDROID_API__ as expected. >> Consequen

time_rz.c and Android NDK r27

This new release of the Android NDK defines timezone_t in time.h whether or not it defines the related tzalloc and localtime_rz extensions, which being new APIs are controlled by __ANDROID_API__ as expected. Consequently, when building for earlier Android releases with this NDK, Emacs compilation r

Re: Integer overflows in memchr

Paul Eggert writes: > On 6/30/24 13:14, Po Lu wrote: >> I think there should be a trivial test for a functional strnlen in >> strnlen.m4, since it would be terrible to duplicate what ought to be the >> responsibility of Gnulib in Emacs's configure.ac. > > Here&#

Re: Integer overflows in memchr

Paul Eggert writes: > Autoconf's existing AC_FUNC_STRNLEN uses AC_RUN_IFELSE so this > wouldn't work as-is. > > Perhaps you could write up a patch against Autoconf? That wouldn't > count against the Gnulib quota Sure, but Gnulib (and by extension Emacs) does not invoke the Autoconf test: A

Re: Integer overflows in memchr

Paul Eggert writes: > Please feel free to write that. It's not something that would be easy > for me to do, as I don't know Android. Also, I don't know that it'd be > that trivial, as it might involve replacing the AC_FUNC_STRNLEN macro > of Autoconf (and we should propagate that fix into Autocon

Re: Integer overflows in memchr

Paul Eggert writes: > On 6/27/24 01:55, Po Lu wrote: >> Google continue to support SDKs from 19 onwards in the standard support >> library: >> >> https://android-developers.googleblog.com/2023/10/androidx-minsdkversion-19.html >> which is the real thresho

Re: Integer overflows in memchr

Paul Eggert writes: > On 6/27/24 02:37, Po Lu wrote: > >> Btw, doesn't this also mean that lib/strnlen.c (in Emacs, at least) is >> incorrect? > > Thanks for pointing that out. I installed the attached into Gnulib and > propagated it into Emacs master. Although

Re: Integer overflows in memchr

Po Lu writes: > Btw, doesn't this also mean that lib/strnlen.c (in Emacs, at least) is > incorrect? > > size_t > strnlen (const char *string, size_t maxlen) > { > const char *end = memchr (string, '\0', maxlen); > return end ? (size_t) (end - string) :

Re: Integer overflows in memchr

Paul Eggert writes: > On 6/26/24 12:33, Paul Eggert wrote: >> I installed the attached patch to document the Android 5.0 glitch > > Oops, attached the wrong patch. Here's the patch I meant to attach. Btw, doesn't this also mean that lib/strnlen.c (in Emacs, at least) is incorrect? size_t strnle

Re: Integer overflows in memchr

Paul Eggert writes: > Actually it's not incorrect because Android's memchr no longer has > undefined behavior with calls like memchr ("", 0, SIZE_MAX); it > reliably returns its first argument in that particular > example. Although this goes beyond what C and POSIX require for > memchr, it's OK f

Re: Integer overflows in memchr

Bruno Haible writes: > When the text says "the array S of size MAXLEN", it means that the bytes > S[0], S[1], ..., S[MAXLEN-1] must be accessible. Which is not the case if > you pass MAXLEN as > ~(uintptr_t)S. > > The implementation could, for example, examine > S[0], S[MAXLEN-1], S[1], S[MAXLE

Re: Integer overflows in memchr

Bruno Haible writes: > This memchr invocation is wrong. memchr is defined in ISO C23 § 7.26.5.2 > "The memchr generic function locates the first occurrence of c (...) >in the initial n characters (...) of the object pointed to by s." > The term "object" being defined in § 3.15: > "region

Re: Integer overflows in memchr

Po Lu writes: > disassembly of libc.so samples extracted from real Android devices > reveals that defective versions of memchr are present until Android 4.3, > API level 18. Correction, up to API level 22 on architectures without specific implementations of memrchr, as these issue

Integer overflows in memchr

It has been brought to my attention that a defective memchr is distributed with certain Android E-book readers with Android 2.3.5 that is liable to integer overflows with large values of N: memchr ("", 0, SIZE_MAX); returns NULL, since: Dump of assembler code for function memchr: 0xafd20644

Symbol list sources

Google severally provide lists of symbols exported by libc, libm, libdl, and related NDK libraries by older Android releases, at this URL, which might be a welcome resource for Gnulib developers: https://android.googlesource.com/platform/development/+/refs/heads/marshmallow-release/ndk/platform

Re: Warnings with Android NDK r26

Paul Eggert writes: > On 2024-06-04 02:10, Collin Funk wrote: >> Good point. Probably yes since they are public functions. '__gl' is used >> for private functions (see stdbit.in.h and binary-io.h). > > Yes, that makes sense. I installed the first attached patch into Gnulib. > > Po, could you plea

Re: Warnings with Android NDK r26

Collin Funk writes: > Can you test it for me? Let's hear from Paul first. > +/* Define our own. */ > +# define be16toh __gl_endian_be16toh > +# define be32toh __gl_endian_be32toh > +# define be64toh __gl_endian_be64toh > +# define htobe16 __gl_endian_htobe16 > +# define htobe32 __gl_endian_hto

Re: Warnings with Android NDK r26

Paul Eggert writes: > Thanks for reporting that. I installed this patch into Gnulib: > > https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=6457d2c190f47e2288c08f6a5e0dba412ff62855 > > and propagated it into Emacs master: > > https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=799f78a92c6

Re: Warnings with Android NDK r26

Paul Eggert writes: > Thanks for reporting that. I installed this patch into Gnulib: > > https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=6457d2c190f47e2288c08f6a5e0dba412ff62855 > > and propagated it into Emacs master: > > https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=799f78a92c6

Warnings with Android NDK r26

Gnulib's ieee754.h defines __LITTLE_ENDIAN and __BIG_ENDIAN, which are redundantly defined in another header in this release of the NDK, to wit, sys/endian.h, and conflicts with this definition when both are included by the same unit. Attached is one example of a warning message reporting such a c

Re: Resolve conflicts for functions introduced in Android API level 30

Thanks. I will merge this to Emacs in a while.

Re: Android NDK r26 and utmpx

Paul Eggert writes: > On 2024-01-20 19:38, Po Lu wrote: >> the problem affects the boot-time module rather than >> readutmp, which Emacs doesn't import. And in the words of Bruno, a >> functional utmp(x) might appear in Android someday, which binaries >> compile

Re: Android NDK r26 and utmpx

Paul Eggert writes: > Thanks for reporting that. Would something like the attached Gnulib > patch fix the Android issue? > > This patch assumes that readutmp-like functions have never worked on > Android (always report nothing); is that the case? That is true, but the problem affects the boot-ti

Android NDK r26 and utmpx

utmpx.h is provided by this new release of the Android NDK, defining functions as nonfunctional as utmp.h does. The more pressing problem is that its presence suppresses the definition of UTMP_NAME_FUNCTION when a program is built with an __ANDROID_API__ lower than 34, where the utmpx* series of f

Re: boot-time: straighten code

Bruno Haible writes: > Po Lu wrote: >> Both of your patches appear to work. > > Thanks for the confirmation. As you know, I'm using a Termux environment > for testing on Android. This has only approximately, not exactly, the same > include files and libc as what you

Re: boot-time: straighten code

Bruno Haible writes: > Po Lu wrote: >> During the automated build of the Android port, the following errors >> were encountered with the Android NDK r10b and __ANDROID_API__ set to 8 >> (which is the oldest configuration Emacs supports.) >> ... >> boot-time.c: In

Re: boot-time: straighten code

Paul Eggert writes: > On 2023-08-11 14:49, Bruno Haible wrote: >> Paul: With this simplification, you may consider using the 'boot-time' module >> in Emacs. I bet that it produces a better result than Emacs' src/filelock.c >> on many platforms. (I haven't tested it, but I could test it if you giv

Re: boot time on Linux

Bruno Haible writes: > Po Lu wrote: >> >> Both clock_gettime (CLOCK_BOOTIME, ... sysinfo fail with AVC denial >> >> errors and errno set to EACCESS. >> > >> > Was this inside Termux, or inside the Emacs app? >> >> Insid

Re: boot time on Linux

Bruno Haible writes: > Po Lu wrote: >> Both clock_gettime (CLOCK_BOOTIME, ... sysinfo fail with AVC denial >> errors and errno set to EACCESS. > > Was this inside Termux, or inside the Emacs app? Inside the Emacs app. I'll try Termux soon: maybe the target SDK version is the culprit.

Re: boot time on Linux

>> > from sysinfo: 1691616762.329261637 = 2023-08-09 21:32:42.329261637 >> > >> > Note that this uses the kernel's uptime counter, so it will not work well >> > when the user changes the current time manually. But this is rare on >> > Android. >

Re: boot time on Linux

Natanael Copa writes: > 2) Even if it does exist, there is no guarantee that the timestamp is > correct. There are machines without RTC (Raspberry PI for example), > and in this case the time stamp may end up to be the same every reboot > (if correctly set up it should save the shutdown time for

Re: boot time on Linux

Paul Eggert writes: > On 2023-08-09 19:14, Po Lu wrote: >> This uses the uptime counter (which also results in an SELinux denial >> for me, but different Android distributions have SELinux policies of >> varying strictness), which cannot establish the precise time the system

Re: boot time on Linux

Bruno Haible writes: > Po Lu wrote: >> > Also, I don't know how Android records boot time so I'll cc this to Po >> > Lu, the main developer for Emacs on Android. >> >> The boot time is off limits to user programs on Android, for security >> r

Re: boot time on Linux

who does the Alpine ports for Emacs, to see whether he > can give advice. > > Also, I don't know how Android records boot time so I'll cc this to Po > Lu, the main developer for Emacs on Android. The boot time is off limits to user programs on Android, for security reasons. It should suffice to undefine BOOT_TIME_FILE there.

Re: Android port

Bruno Haible writes: > 1) It's a security problem if a program's binary (+ associated shared > libraries) >somewhere implements a printf with %n, even without actively using it. >Because an attacker can piece together a format string in memory and call >that printf function; this the

gettime-res, gettime, and Android 14

Snapshots of the NDK r26 have `timespec_getres' in libc.so, which can only be used under API 35 (Android 14) and later. Does gettime-res require adjustments?

Re: Portability problem

Bruno Haible writes: > Hi Po Lu, > >> Gnulib generates non-portable shell constructs, which interferes with >> configuring Emacs on Solaris 10 using /bin/sh. >> >> See >> >> https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-04/msg01590.htm

Portability problem

Gnulib generates non-portable shell constructs, which interferes with configuring Emacs on Solaris 10 using /bin/sh. See https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-04/msg01590.html Would this be a sufficient solution? I've not had a chance to test it yet. 2023-04-26

Re: Sun C 5.14

Bruno Haible writes: > Po Lu wrote: >> Unfortunately, I've got the same Sun C that you do. > >> Could you show the preprocessed source for a call to `offsetof' on your >> system? I have a feeling stddef.h on this machine is somehow wrong. > > In yo

Re: Sun C 5.14

Bruno Haible writes: > I cannot reproduce it. > > On Solaris 10: > $ PATH=/opt/developerstudio12.5/bin:$PATH > $ cc -V > > cc: Studio 12.5 Sun C 5.14 SunO

Sun C 5.14

I can't build Emacs with Sun C 5.14, on x86_64-pc-solaris2.11: cc -m64 -c-g3 -O -I. -I../src -I. -I./../src -o time_rz.o time_rz.c "time_rz.c", line 45: non-constant enumerator value cc: acomp failed for time_rz.c gmake: *** [Makefile:84: time_rz.o] Error 2 Here is the preprocessed time_

Re: stpncpy

Bruno Haible writes: > Po Lu wrote: >> stpncpy is not replaced when building with the Android NDK r25b and >> __ANDROID_API__ 19, since it is __INTRODUCED_IN (21). >> >> I guess this should be fixed. Thanks. > > This ought to be done through commits from 2023-0

stpncpy

stpncpy is not replaced when building with the Android NDK r25b and __ANDROID_API__ 19, since it is __INTRODUCED_IN (21). I guess this should be fixed. Thanks.

Re: vasnprintf.c Android bug?

Bruno Haible writes: > Hi, > > Po Lu wrote: >> With the build API version set to 21 on the NDK r26b, vasnprintf.c needs >> to include: >> >> #include >> >> or else it cannot find mbstate_t. > > Thanks for the report. This

vasnprintf.c Android bug?

With the build API version set to 21 on the NDK r26b, vasnprintf.c needs to include: #include or else it cannot find mbstate_t. In addition, this warning is still emitted by Clang: ANDROID_CC vasnprintf.o vasnprintf.c:2416:21: warning: variable 'flags' set but not used [-Wunused-but-set-va

Re: Follow up to last post

Paul Eggert writes: > On 1/18/23 05:53, Po Lu wrote: >> + gl_CHECK_FUNCS_ANDROID([utimensat], [[#include ]]) >> if test $ac_cv_func_utimensat = no; then >> HAVE_UTIMENSAT=0 >> +REPLACE_UTIMENSAT=1 > > REPLACE_UTIMENSAT=1 means utimensat is pre

Follow up to last post

Okay, the problem seems to be a little more involved than I initially thought. Apparently, it is not ok to use gl_CHECK_FUNCS_ANDROID without removing utimensat from AC_CHECK_FUNCS_ONCE, because the latter will define HAVE_UTIMENSAT, leading to a build failure later (I only found this after runnin

More Android patches

quot; = no branch be enough to fix that? Thanks. 2023-01-18 Po Lu Fix uses of utimensat and ftruncate on Android API 8 or earlier. * m4/unistd_h.m4 (gl_UNISTD_H): Check that ftruncate is really there on Android. * m4/utimensat.m4: (gl_FUNC_UTIMENSAT):

Re: fpending Android bug

n NDK r13b the elements of a FILE were accessible, > - In NDK r14b the elements of a FILE were suddenly not accessible any more. > > I'm applying your patch: > > > 2023-01-15 Bruno Haible > > fpending: Fix compilation error with NDK ≥ r14b and Android AP

Re: fpending Android bug

Bruno Haible writes: > Before we make any change, we need to know what is wrong, i.e. what is > "the fpending bug on Android". You haven't said so, after I asked in > > > Please be specific: What do you mean by "not works"? Do

fpending Android bug

I think I now have the right fix for the fpending bug on Android. Google is very adamant that you should not do this, however, and they make no guarantee about the layout of the structure remaining as it is in the future. diff --git a/xcompile/lib/fpending.c b/xcompile/lib/fpending.c index afa840b

Re: Android environments

Bruno Haible writes: > I see. There are two ways to build C programs for Android: > > (A) The way it is designed by Google: With the Android NDK, > that includes a cross-compiler. For the runtime, use an emulator > (based on qemu) or a physical connection to a real device. > > (B)

Re: getrandom not replaced

Bruno Haible writes: > Why cross-compile? Both the Terminal-IDE and the Termux app support > native compilation. My port is "Emacs as an Android application package." The SDK build tools and Java compiler are only available on the host. > Again, what is the Android API level that you are using

Re: Android problem

Bruno Haible writes: > Po Lu wrote: >> Someone asked me to port Emacs to Android. > > Please be specific: Which Android API level are you using at compile-time? > And which Android version at run-time? > >> In doing so noticed that the >> fpending module no

Re: getrandom not replaced

Paul Eggert writes: > I meant to use the compiler that is actually used to compile > lib/getrandom.c. You can deduce this with something like this: > > rm lib/getrandom.o; cd lib; make V=1 getrandom.o > > and replace '-c -o getrandom.o' with '-E' in the resulting command. > > >> #if 1 >> /* Fill

Re: getrandom not replaced

Paul Eggert writes: > What's the output of gcc -E? Which of armv7a-unknown-linux-android19-clang -E or gcc -E on the host do you mean? > Also, it sounds like lib/sys/random.h wasn't generated correctly; > what's in that file? Here it is, thanks. /* DO NOT EDIT! GENERATED AUTOMATICALLY! */ /*

Android problem

Someone asked me to port Emacs to Android. In doing so noticed that the fpending module no longer works there, because struct FILE * is now: __BEGIN_DECLS /** The opaque structure implementing `FILE`. Do not make any assumptions about its content. */ struct __sFILE { #if defined(__LP64__) cha

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

Mattias Engdegård writes: > Thank you! This particular change should be back-ported to emacs-28 > once master has caught up with gnulib again. As long as someone backports the MS-DOS code at the same time. I don't want to update the code on the release branch for a gnulib update, especially sin