bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
* fpending Android bug
       [not found] <87wn5pb3dv.fsf.ref@yahoo.com>
@ 2023-01-14 14:24 ` Po Lu
  2023-01-14 17:07   ` Bruno Haible
  0 siblings, 1 reply; 7+ messages in thread
From: Po Lu @ 2023-01-14 14:24 UTC (permalink / raw)
  To: bug-gnulib

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 afa840b8512..e57155e586e 100644
--- a/xcompile/lib/fpending.c
+++ b/xcompile/lib/fpending.c
@@ -41,7 +41,7 @@ __fpending (FILE *fp)
   return fp->_IO_write_ptr - fp->_IO_write_base;
 #elif defined __sferror || defined __DragonFly__ || defined __ANDROID__
   /* FreeBSD, NetBSD, OpenBSD, DragonFly, Mac OS X, Cygwin < 1.7.34, Minix 3, Android */
-  return fp->_p - fp->_bf._base;
+  return fp_->_p - fp_->_bf._base;
 #elif defined __EMX__                /* emx+gcc */
   return fp->_ptr - fp->_buffer;
 #elif defined __minix                /* Minix */


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: fpending Android bug
  2023-01-14 14:24 ` fpending Android bug Po Lu
@ 2023-01-14 17:07   ` Bruno Haible
  2023-01-14 17:12     ` Bruno Haible
  2023-01-15  0:28     ` Po Lu
  0 siblings, 2 replies; 7+ messages in thread
From: Bruno Haible @ 2023-01-14 17:07 UTC (permalink / raw)
  To: bug-gnulib; +Cc: Po Lu

Hi Po Lu,

> I think I now have the right fix for the fpending bug on Android.

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
 <https://lists.gnu.org/archive/html/bug-gnulib/2022-12/msg00087.html>

Please be specific: What do you mean by "not works"? Does not compile?
Does not return which value?

> diff --git a/xcompile/lib/fpending.c b/xcompile/lib/fpending.c
> index afa840b8512..e57155e586e 100644
> --- a/xcompile/lib/fpending.c
> +++ b/xcompile/lib/fpending.c
> @@ -41,7 +41,7 @@ __fpending (FILE *fp)
>    return fp->_IO_write_ptr - fp->_IO_write_base;
>  #elif defined __sferror || defined __DragonFly__ || defined __ANDROID__
>    /* FreeBSD, NetBSD, OpenBSD, DragonFly, Mac OS X, Cygwin < 1.7.34, Minix 3, Android */
> -  return fp->_p - fp->_bf._base;
> +  return fp_->_p - fp_->_bf._base;
>  #elif defined __EMX__                /* emx+gcc */
>    return fp->_ptr - fp->_buffer;
>  #elif defined __minix                /* Minix */

IMO, this patch is a no-op:

  - If you are using an Android NDK older than r14b, the definition of
    'struct __sFILE' is directly in <stdio.h> and thus visible.

  - If you are using an Android NDK r14b or newer, with __ANDROID_API__
    being < 24, the definition of 'struct __sFILE' has been moved out
    to <bits/struct_file.h> but is still included from <stdio.h> and is
    thus visible.

  - If you are using an Android NDK with __ANDROID_API__ being >= 23,
    the function __fpending exists and is declared, and therefore the
    Gnulib m4/fpending.m4 arranges to not compile fpending.c.

So, in order to investigate this, you need to
  - explain what you meant by "not works",
  - run your configure script with option -C,
  - report the results of
      grep -i fpending config.cache
    and
      grep -i fpending config.status
  - say which NDK version you're using,
  - say what is the __ANDROID_API__ value in your environment.

Bruno





^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: fpending Android bug
  2023-01-14 17:07   ` Bruno Haible
@ 2023-01-14 17:12     ` Bruno Haible
  2023-01-15  0:28     ` Po Lu
  1 sibling, 0 replies; 7+ messages in thread
From: Bruno Haible @ 2023-01-14 17:12 UTC (permalink / raw)
  To: bug-gnulib; +Cc: Po Lu

I wrote:
>   - If you are using an Android NDK with __ANDROID_API__ being >= 23,
>     the function __fpending exists and is declared, and therefore the
>     Gnulib m4/fpending.m4 arranges to not compile fpending.c.

More exactly:

  - If you are using an Android NDK r14b or newer, with __ANDROID_API__
    being >= 23, the function __fpending exists and is declared (in
    <stdio_ext.h>, that was added in NDK r14b), and therefore the Gnulib
    m4/fpending.m4 arranges to not compile fpending.c.

Bruno





^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: fpending Android bug
  2023-01-14 17:07   ` Bruno Haible
  2023-01-14 17:12     ` Bruno Haible
@ 2023-01-15  0:28     ` Po Lu
  2023-01-15 10:10       ` Bruno Haible
  1 sibling, 1 reply; 7+ messages in thread
From: Po Lu @ 2023-01-15  0:28 UTC (permalink / raw)
  To: Bruno Haible; +Cc: bug-gnulib

Bruno Haible <bruno@clisp.org> 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
>  <https://lists.gnu.org/archive/html/bug-gnulib/2022-12/msg00087.html>
>
> Please be specific: What do you mean by "not works"? Does not compile?
> Does not return which value?

Apologies for missing those details.

It doesn't compile because ->_p and ->_base are undefined in FILE *.

>> diff --git a/xcompile/lib/fpending.c b/xcompile/lib/fpending.c
>> index afa840b8512..e57155e586e 100644
>> --- a/xcompile/lib/fpending.c
>> +++ b/xcompile/lib/fpending.c
>> @@ -41,7 +41,7 @@ __fpending (FILE *fp)
>>    return fp->_IO_write_ptr - fp->_IO_write_base;
>>  #elif defined __sferror || defined __DragonFly__ || defined __ANDROID__
>>    /* FreeBSD, NetBSD, OpenBSD, DragonFly, Mac OS X, Cygwin < 1.7.34, Minix 3, Android */
>> -  return fp->_p - fp->_bf._base;
>> +  return fp_->_p - fp_->_bf._base;
>>  #elif defined __EMX__                /* emx+gcc */
>>    return fp->_ptr - fp->_buffer;
>>  #elif defined __minix                /* Minix */
>
> IMO, this patch is a no-op:
>
>   - If you are using an Android NDK older than r14b, the definition of
>     'struct __sFILE' is directly in <stdio.h> and thus visible.
>
>   - If you are using an Android NDK r14b or newer, with __ANDROID_API__
>     being < 24, the definition of 'struct __sFILE' has been moved out
>     to <bits/struct_file.h> but is still included from <stdio.h> and is
>     thus visible.

I'm using the NDK r25b; however, bits/struct_file.h in the NDK r25b only
includes:

__BEGIN_DECLS

/** The opaque structure implementing `FILE`. Do not make any assumptions about its content. */
struct __sFILE {
#if defined(__LP64__)
  char __private[152];
#else
  char __private[84];
#endif
} __attribute__((aligned(sizeof(void*))));

__END_DECLS

even when __ANDROID_API__ is 19.

> So, in order to investigate this, you need to
>   - explain what you meant by "not works",
>   - run your configure script with option -C,
>   - report the results of
>       grep -i fpending config.cache
>     and
>       grep -i fpending config.status
>   - say which NDK version you're using,
>   - say what is the __ANDROID_API__ value in your environment.

Thanks, I will do this later today.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: fpending Android bug
  2023-01-15  0:28     ` Po Lu
@ 2023-01-15 10:10       ` Bruno Haible
  2023-01-15 11:11         ` Po Lu
  2023-01-17 16:10         ` Bruno Haible
  0 siblings, 2 replies; 7+ messages in thread
From: Bruno Haible @ 2023-01-15 10:10 UTC (permalink / raw)
  To: Po Lu; +Cc: bug-gnulib

Po Lu wrote:
> It doesn't compile because ->_p and ->_base are undefined in FILE *.
> ...
> I'm using the NDK r25b; however, bits/struct_file.h in the NDK r25b only
> includes:
> 
> __BEGIN_DECLS
> 
> /** The opaque structure implementing `FILE`. Do not make any assumptions about its content. */
> struct __sFILE {
> #if defined(__LP64__)
>   char __private[152];
> #else
>   char __private[84];
> #endif
> } __attribute__((aligned(sizeof(void*))));
> 
> __END_DECLS
> 
> even when __ANDROID_API__ is 19.

Ah, now that makes sense: When they moved 'struct __sFILE' out of <stdio.h>
into <bits/struct_file.h>, they also removed its named fields.

In other words, looking at the timeline of the Android API level 19 support:
  - They added this support in NDK r10e,
  - In 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  <bruno@clisp.org>

	fpending: Fix compilation error with NDK ≥ r14b and Android API < 23.
	Report and patch by Po Lu <luangruo@yahoo.com>.
	* lib/fpending.c (__fpending) [__ANDROID__]: Use the fp_ macro.

diff --git a/lib/fpending.c b/lib/fpending.c
index afa840b851..e57155e586 100644
--- a/lib/fpending.c
+++ b/lib/fpending.c
@@ -41,7 +41,7 @@ __fpending (FILE *fp)
   return fp->_IO_write_ptr - fp->_IO_write_base;
 #elif defined __sferror || defined __DragonFly__ || defined __ANDROID__
   /* FreeBSD, NetBSD, OpenBSD, DragonFly, Mac OS X, Cygwin < 1.7.34, Minix 3, Android */
-  return fp->_p - fp->_bf._base;
+  return fp_->_p - fp_->_bf._base;
 #elif defined __EMX__                /* emx+gcc */
   return fp->_ptr - fp->_buffer;
 #elif defined __minix                /* Minix */





^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: fpending Android bug
  2023-01-15 10:10       ` Bruno Haible
@ 2023-01-15 11:11         ` Po Lu
  2023-01-17 16:10         ` Bruno Haible
  1 sibling, 0 replies; 7+ messages in thread
From: Po Lu @ 2023-01-15 11:11 UTC (permalink / raw)
  To: Bruno Haible; +Cc: bug-gnulib

Bruno Haible <bruno@clisp.org> writes:

> Ah, now that makes sense: When they moved 'struct __sFILE' out of <stdio.h>
> into <bits/struct_file.h>, they also removed its named fields.
>
> In other words, looking at the timeline of the Android API level 19 support:
>   - They added this support in NDK r10e,
>   - In 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  <bruno@clisp.org>
>
> 	fpending: Fix compilation error with NDK ≥ r14b and Android API < 23.
> 	Report and patch by Po Lu <luangruo@yahoo.com>.
> 	* lib/fpending.c (__fpending) [__ANDROID__]: Use the fp_ macro.
>
> diff --git a/lib/fpending.c b/lib/fpending.c
> index afa840b851..e57155e586 100644
> --- a/lib/fpending.c
> +++ b/lib/fpending.c
> @@ -41,7 +41,7 @@ __fpending (FILE *fp)
>    return fp->_IO_write_ptr - fp->_IO_write_base;
>  #elif defined __sferror || defined __DragonFly__ || defined __ANDROID__
>    /* FreeBSD, NetBSD, OpenBSD, DragonFly, Mac OS X, Cygwin < 1.7.34, Minix 3, Android */
> -  return fp->_p - fp->_bf._base;
> +  return fp_->_p - fp_->_bf._base;
>  #elif defined __EMX__                /* emx+gcc */
>    return fp->_ptr - fp->_buffer;
>  #elif defined __minix                /* Minix */

Thanks, Bruno.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: fpending Android bug
  2023-01-15 10:10       ` Bruno Haible
  2023-01-15 11:11         ` Po Lu
@ 2023-01-17 16:10         ` Bruno Haible
  1 sibling, 0 replies; 7+ messages in thread
From: Bruno Haible @ 2023-01-17 16:10 UTC (permalink / raw)
  To: Po Lu; +Cc: bug-gnulib

I wrote:
> When they moved 'struct __sFILE' out of <stdio.h>
> into <bits/struct_file.h>, they also removed its named fields.

And the Termux environment, that I'm using for testing, contains a
<bits/struct_file.h> that contains all the 20 real fields. This file
does not come from any Android NDK. This explains why I was confused
about this 'struct __sFILE'...

Bruno





^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2023-01-17 16:10 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <87wn5pb3dv.fsf.ref@yahoo.com>
2023-01-14 14:24 ` fpending Android bug Po Lu
2023-01-14 17:07   ` Bruno Haible
2023-01-14 17:12     ` Bruno Haible
2023-01-15  0:28     ` Po Lu
2023-01-15 10:10       ` Bruno Haible
2023-01-15 11:11         ` Po Lu
2023-01-17 16:10         ` Bruno Haible

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).