Re: 32 bit to 64 bit casting

[Petr Pisar]

V Thu, Jun 30, 2022 at 07:12:50PM +0200, Petr Pisar napsal(a):
> V Thu, Jun 30, 2022 at 07:04:43AM -0500, KeithG napsal(a):
> > On Wed, Jun 22, 2022 at 12:16 PM Petr Pisar <petr.pisar@atlas.cz> wrote:
> > >
> > > Can you post here a complete certificate chain the server presents to 
> > > wget?
> > > You can use "openssl s_client -connect THE_HOST:https -showcerts to 
> > > obtain it.
> > > If it so, than the only fix is to recompile your system with 
> > > "-D_TIME_BITS=64
> > > -D_FILE_OFFSET_BITS=64" CFLAGS. (Provided your platform supports it.)
> > >
> > > -- Petr
> > 
> > Petr,
> > 
> > I have done a bit more checking and it appears some configurational
> > issue with Arch on armv7 is the cause. I have not been able to pin it
> > down. I did verify that the binary is built with the 2 flags you
> > mention:
> > This is a snippet of the config.log for the binary that does not work:
> > 
> > | #define HAVE_FSEEKO 1
> > | #define _FILE_OFFSET_BITS 64
> > | #define _TIME_BITS 64
> > | #define _FILE_OFFSET_BITS 64
> > | /* end confdefs.h.  */
> > | #if defined __aarch64__ && !(defined __ILP32__ || defined _ILP32)
> > |                    int ok;
> > |                   #else
> > |                    error fail
> > |                   #endif
> > |
> 
> It's normal that some configure tests fail. This is how configure explores
> a system. Specifically this test checks whether the system is 64-bit. Because
> armv7 isn't, the compilation fails and configure sets
> gl_cv_host_cpu_c_abi_32bit=yes.
> 
> I recommed you reading sources in ./m4 directory instead of ./configure.
> 
> > configure:11550: result: yes
> > configure:11559: checking for ELF binary format
> > configure:11583: result: yes
> > configure:11635: checking for the common suffixes of directories in
> > the library search path
> > configure:11704: result: lib,lib,lib
> > configure:12229: checking for CFPreferencesCopyAppValue
> > configure:12248: gcc -o conftest -DNDEBUG -march=armv7-a
> > -mfloat-abi=hard -mfpu=vfpv3-d16 -O2 -pipe -fstack-protector-strong
> > -fno-plt -fexceptions         -Wp,-D_FORTIFY_SOURCE=2 -Wformat
> > -Werror=format-security         -fstack-clash-protection
> > -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now conftest.c
> > -Wl,-framework -Wl,CoreFoundation >&5
> > conftest.c:74:10: fatal error: CoreFoundation/CFPreferences.h: No such
> > file or directory
> >    74 | #include <CoreFoundation/CFPreferences.h>
> >       |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > compilation terminated.
> > distcc[3295] ERROR: compile conftest.c on localhost failed
> > configure:12248: $? = 1
> > configure: failed program was:
> > | /* confdefs.h */
> > 
> 
> > I tried it on RpiOS using the same architecture (armv7) which builds a
> > binary that passes all the tests and works properly and this part of
> > the config.log is dramatically different:
> > 
> > | #define HAVE_FSEEKO 1
> > | #define _FILE_OFFSET_BITS 64
> > | /* end confdefs.h.  */
> > |
> > |   #include <time.h>
> > |   /* Check that time_t can represent 2**32 - 1 correctly.  */
> > |   #define LARGE_TIME_T \
> > |     ((time_t) (((time_t) 1 << 30) - 1 + 3 * ((time_t) 1 << 30)))
> > |   int verify_time_t_range[(LARGE_TIME_T / 65537 == 65535
> > |                            && LARGE_TIME_T % 65537 == 0)
> > |                           ? 1 : -1];
> > |
> > configure:9815: result: no
> > configure:9818: checking for 64-bit time_t with _TIME_BITS=64
> > configure:9838: gcc -c -DNDEBUG -g -O2  conftest.c >&5
> > conftest.c:78:43: warning: integer overflow in expression of type
> > 'long int' results in '-1073741824' [-Woverflow]
> >    78 |     ((time_t) (((time_t) 1 << 30) - 1 + 3 * ((time_t) 1 << 30)))
> >       |                                           ^
> > conftest.c:79:28: note: in expansion of macro 'LARGE_TIME_T'
> >    79 |   int verify_time_t_range[(LARGE_TIME_T / 65537 == 65535
> >       |                            ^~~~~~~~~~~~
> > conftest.c:78:43: warning: integer overflow in expression of type
> > 'long int' results in '-1073741824' [-Woverflow]
> >    78 |     ((time_t) (((time_t) 1 << 30) - 1 + 3 * ((time_t) 1 << 30)))
> >       |                                           ^
> > conftest.c:80:31: note: in expansion of macro 'LARGE_TIME_T'
> >    80 |                            && LARGE_TIME_T % 65537 == 0)
> >       |                               ^~~~~~~~~~~~
> > conftest.c:79:7: error: variably modified 'verify_time_t_range' at file 
> > scope
> >    79 |   int verify_time_t_range[(LARGE_TIME_T / 65537 == 65535
> >       |       ^~~~~~~~~~~~~~~~~~~
> > configure:9838: $? = 1
> > configure: failed program was:
> > | /* confdefs.h */
> > 
> > I am not that well versed in what I should do at this point, but it
> > appears that the tests for 64 bit time are different and I wonder why
> > they are and what should be fixed.
> > 
> I think you compare apples and oranges. 32-bit time_t on Debian and 64-bit
> time_t on Arch. You should focus only on one time_t. I recommend following
> a 32-bit time_t. Especially because 64-bit time_t on 32-bit plaforms is not
> well-tested and there can be bugs anywhere.
> 
And another reason is that you cannot just enable 64-bit time_t for a program.
You need to build with 64-bit time_t all libreries the program uses. That
means e.g. gnutls, libidn2, libz and all libraries these libraries use, like
libtasn1. In other words it's distribution-wide change. If you only build wget
like that then it won't work. Maybe even in the configure phase.

-- Petr

signature.asc
Description: PGP signature