Re: format strings in libexpat

2023-02-20 Thread Joerg Sonnenberger
On Sat, Feb 18, 2023 at 08:22:56AM +, Miod Vallat wrote:
> libexpat assumes the compiler might not know of the C99 format
> specifiers for ptrdiff_t and size_t, and tries to guess alternative
> format strings.

The problem is the printf runtime. There is no good way to detect the
support without running a test program and for a library that is
explicitly used in many cross-compilation environments, that's a
problem.

> The following diff relieves it of this misery (but can't be sent
> upѕtream, as it is too aggressive).

I think it might be a good idea to try again. Since C++11 support made
much of the runtime parts of C99 mandatory, even Microsoft had to adopt
and they were the last big holdout. I don't know how ancient the systems
are that expat targets, but asking seems to be a reasonable idea
nowadays.

Joerg



Re: format strings in libexpat

2023-02-20 Thread Miod Vallat
> Does this actually change something on any of our architectures?

This gets rid of warnings such as:

/usr/src/lib/libexpat/lib/xmlparse.c: In function 'accountingReportDiff':
/usr/src/lib/libexpat/lib/xmlparse.c:7704: warning: format '%6d' expects
type 'int', but argument 3 has type 'ptrdiff_t'

but otherwise won't change anything.

> If not, I would prefer to stick to upstream #ifdef hell.  This
> avoids possible merge errors in every expat release.

Sure.



Re: format strings in libexpat

2023-02-20 Thread Alexander Bluhm
On Sat, Feb 18, 2023 at 08:22:56AM +, Miod Vallat wrote:
> libexpat assumes the compiler might not know of the C99 format
> specifiers for ptrdiff_t and size_t, and tries to guess alternative
> format strings.
> 
> The following diff relieves it of this misery (but can't be sent
> up??tream, as it is too aggressive).

This means a diff I have to merge with every libexpat update.  I
am quite happy that I got rid of them.

Does this actually change something on any of our architectures?

If not, I would prefer to stick to upstream #ifdef hell.  This
avoids possible merge errors in every expat release.

bluhm

> Index: lib/internal.h
> ===
> RCS file: /OpenBSD/src/lib/libexpat/lib/internal.h,v
> retrieving revision 1.10
> diff -u -p -r1.10 internal.h
> --- lib/internal.h20 Sep 2022 23:00:53 -  1.10
> +++ lib/internal.h18 Feb 2023 08:16:19 -
> @@ -105,31 +105,9 @@
>  #  endif
>  #endif
>  
> -#include  // ULONG_MAX
> -
> -#if defined(_WIN32)  
>   \
> -&& (! defined(__USE_MINGW_ANSI_STDIO)
>   \
> -|| (1 - __USE_MINGW_ANSI_STDIO - 1 == 0))
> -#  define EXPAT_FMT_ULL(midpart) "%" midpart "I64u"
> -#  if defined(_WIN64) // Note: modifiers "td" and "zu" do not work for MinGW
> -#define EXPAT_FMT_PTRDIFF_T(midpart) "%" midpart "I64d"
> -#define EXPAT_FMT_SIZE_T(midpart) "%" midpart "I64u"
> -#  else
> -#define EXPAT_FMT_PTRDIFF_T(midpart) "%" midpart "d"
> -#define EXPAT_FMT_SIZE_T(midpart) "%" midpart "u"
> -#  endif
> -#else
> -#  define EXPAT_FMT_ULL(midpart) "%" midpart "llu"
> -#  if ! defined(ULONG_MAX)
> -#error Compiler did not define ULONG_MAX for us
> -#  elif ULONG_MAX == 18446744073709551615u // 2^64-1
> -#define EXPAT_FMT_PTRDIFF_T(midpart) "%" midpart "ld"
> -#define EXPAT_FMT_SIZE_T(midpart) "%" midpart "lu"
> -#  else
> -#define EXPAT_FMT_PTRDIFF_T(midpart) "%" midpart "d"
> -#define EXPAT_FMT_SIZE_T(midpart) "%" midpart "u"
> -#  endif
> -#endif
> +#define EXPAT_FMT_ULL(midpart) "%" midpart "llu"
> +#define EXPAT_FMT_PTRDIFF_T(midpart) "%" midpart "td"
> +#define EXPAT_FMT_SIZE_T(midpart) "%" midpart "zu"
>  
>  #ifndef UNUSED_P
>  #  define UNUSED_P(p) (void)p
> 



format strings in libexpat

2023-02-18 Thread Miod Vallat
libexpat assumes the compiler might not know of the C99 format
specifiers for ptrdiff_t and size_t, and tries to guess alternative
format strings.

The following diff relieves it of this misery (but can't be sent
upѕtream, as it is too aggressive).

Index: lib/internal.h
===
RCS file: /OpenBSD/src/lib/libexpat/lib/internal.h,v
retrieving revision 1.10
diff -u -p -r1.10 internal.h
--- lib/internal.h  20 Sep 2022 23:00:53 -  1.10
+++ lib/internal.h  18 Feb 2023 08:16:19 -
@@ -105,31 +105,9 @@
 #  endif
 #endif
 
-#include  // ULONG_MAX
-
-#if defined(_WIN32)
\
-&& (! defined(__USE_MINGW_ANSI_STDIO)  
\
-|| (1 - __USE_MINGW_ANSI_STDIO - 1 == 0))
-#  define EXPAT_FMT_ULL(midpart) "%" midpart "I64u"
-#  if defined(_WIN64) // Note: modifiers "td" and "zu" do not work for MinGW
-#define EXPAT_FMT_PTRDIFF_T(midpart) "%" midpart "I64d"
-#define EXPAT_FMT_SIZE_T(midpart) "%" midpart "I64u"
-#  else
-#define EXPAT_FMT_PTRDIFF_T(midpart) "%" midpart "d"
-#define EXPAT_FMT_SIZE_T(midpart) "%" midpart "u"
-#  endif
-#else
-#  define EXPAT_FMT_ULL(midpart) "%" midpart "llu"
-#  if ! defined(ULONG_MAX)
-#error Compiler did not define ULONG_MAX for us
-#  elif ULONG_MAX == 18446744073709551615u // 2^64-1
-#define EXPAT_FMT_PTRDIFF_T(midpart) "%" midpart "ld"
-#define EXPAT_FMT_SIZE_T(midpart) "%" midpart "lu"
-#  else
-#define EXPAT_FMT_PTRDIFF_T(midpart) "%" midpart "d"
-#define EXPAT_FMT_SIZE_T(midpart) "%" midpart "u"
-#  endif
-#endif
+#define EXPAT_FMT_ULL(midpart) "%" midpart "llu"
+#define EXPAT_FMT_PTRDIFF_T(midpart) "%" midpart "td"
+#define EXPAT_FMT_SIZE_T(midpart) "%" midpart "zu"
 
 #ifndef UNUSED_P
 #  define UNUSED_P(p) (void)p