On Friday 29 November 2024 00:18:38 Martin Storsjö wrote:
> On Tue, 19 Nov 2024, Pali Rohár wrote:
>
> > Currently mingw_vfwscanf.c files provides 3 functions:
> > mingw_swformat(), mingw_vfwscanf() and mingw_vswscanf().
> >
> > Split this file into 3 files, one for each function.
> >
> > Diff for this change from git is more human readable when showed by
> > git options -B and -D.
> > ---
> > mingw-w64-crt/Makefile.am | 4 +-
> > .../{mingw_vfwscanf.c => mingw_swformat.c} | 46 +-
> > mingw-w64-crt/stdio/mingw_swformat.h | 63 +
> > mingw-w64-crt/stdio/mingw_vfwscanf.c | 1645 +----------------
> > mingw-w64-crt/stdio/mingw_vswscanf.c | 15 +
> > 5 files changed, 102 insertions(+), 1671 deletions(-)
> > copy mingw-w64-crt/stdio/{mingw_vfwscanf.c => mingw_swformat.c} (97%)
> > create mode 100644 mingw-w64-crt/stdio/mingw_swformat.h
> > rewrite mingw-w64-crt/stdio/mingw_vfwscanf.c (99%)
> > create mode 100644 mingw-w64-crt/stdio/mingw_vswscanf.c
>
> > index 81cb46b661e9..5f4b2c08f395 100644
> > --- a/mingw-w64-crt/stdio/mingw_vfwscanf.c
> > +++ b/mingw-w64-crt/stdio/mingw_swformat.c
> > @@ -57,6 +57,8 @@
> > #include <locale.h>
> > #include <errno.h>
> >
> > +#include "mingw_swformat.h"
> > +
> > #ifndef CP_UTF8
> > #define CP_UTF8 65001
> > #endif
> > @@ -80,19 +82,6 @@
> >
> > #define IS_ALLOC_USED (USE_GNU_ALLOC | USE_POSIX_ALLOC)
> >
> > -/* internal stream structure with back-buffer. */
> > -typedef struct _IFP
> > -{
> > - __extension__ union {
> > - void *fp;
> > - const wchar_t *str;
> > - };
> > - int bch[1024];
> > - unsigned int is_string : 1;
> > - int back_top;
> > - unsigned int seen_eof : 1;
> > -} _IFP;
> > -
> > static void *
> > get_va_nth (va_list argp, unsigned int n)
> > {
> > @@ -123,7 +112,7 @@ optimize_alloc (char **p, char *end, size_t alloc_sz)
> > }
> >
> > static void
> > -back_ch (int c, _IFP *s, size_t *rin, int not_eof)
> > +back_ch (int c, _IFPW *s, size_t *rin, int not_eof)
> > {
> > if (!not_eof && c == WEOF)
> > return;
>
> So here we're renaming the structure _IFP into _IFPW - is this a required
> step? I guess this may have been the case if you initially considered using
> one shared header for both narrow and wide versions of it, but as this
> currently has two separate headers, I guess the struct renaming strictly
> isn't necessary?
>
> // Martin
Yea, maybe the renaming is not necessary. But I think it is better if we
do not have two different structures with same names in header files.
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
