On Fri, Oct 02, 2026 at 08:33:46AM +0300, Eli Zaretskii wrote:
> > Date: Thu, 1 Oct 2026 22:54:19 +0200
> > From: Patrice Dumas <[email protected]>
> >
> > Hello,
> >
> > In the new mingw based on MSYS2 CI platform setup by Bruno, the C build
> > is stopped by TEXT being a macro, with an error that is explicit with
> > clang,
> > ../../../tta/C/convert/converter.h:189:9: error: type specifier missing,
> > defaults to 'int'; ISO C99 and later do not support implicit int
> > [-Wimplicit-int]
> > 189 | TEXT (*convert_tree)(CONVERTER *self, const ELEMENT *tree),
> > |
> > | int
> > D:/a/_temp/msys64/clang64/include/winnt.h:415:28: note: expanded from
> > macro 'TEXT'
> > 415 | #define TEXT(quote) __TEXT(quote)
> > | ^
> > D:/a/_temp/msys64/clang64/include/winnt.h:412:23: note: expanded from
> > macro '__TEXT'
> > 412 | #define __TEXT(quote) quote
> > | ^
> >
> > the macro being documented here:
> > https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-text
> >
> > In texi2any TEXT is "typedef struct TEXT" for the accumulated text with
> > length used everywhere (from tta/C/main/text.{c,h}).
> >
> >
> > Any idea how to handle such a case? Decide that TEXT is too generic?
> > define the macro to something else of undef the macro?
>
> The best alternative is to use a different name for the texi2any
> macro, not TEXT but something less common, like TEXT_AND_LENGTH or
> somesuch. Undefining a macro defined by a system header runs the risk
> of causing trouble, and should only be done if there are no better
> alternatives (like when you really want to change what that macro
> does).
>
I would rather undef the macro as Windows is not a primary platform for
Texinfo or GNU software in general. I completely object to changing the
name of the TEXT type throughout the texi2any code. TEXT is not a reserved
name in C or POSIX standards as far as I am aware and so we are entitled to
use it.
I would simply add something like the following to text.h:
/* TEXT defined as macro in winnt.h on MSYS2. */
#ifdef TEXT
#undef TEXT
#endif
If that works, we can move on from the issue.
This would only fail, as far as I understand, if TEXT is referred to
somewhere in the system headers, and that such are included after the
undefinition.
If this is the case, we have a couple of possibilities:
* We could attempt to reorder the inclusion of the problematic header
(that depends on the Windows-NT TEXT macro from winnt.h) to be before
the inclusion of text.h.
For example, converter.h where the error occurs has:
#include <stddef.h>
/* for FILE */
#include <stdio.h>
#include "text.h"
#include "command_ids.h"
#include "option_types.h"
#include "tree_types.h"
#include "document_types.h"
#include "converter_types.h"
One of the included files, "document_types.h", includes <iconv.h> (for
the iconv_t type). Hypothetically, if <iconv.h> produced an error if
TEXT was undefined, then we could try to include <iconv.h> earlier -
possibly in a header file included by the other source files. (This is
assuming the contents of the header file is not elided by an include
guard due to earlier inclusion of the file.)
* Another workaround could be to provide our own header file "iconv.h" (for
example), with contents little more than the following:
#define TEXT(a) a
#include_next "iconv.h"
#undef TEXT
This would include the next include file by this name in the search path.
I believe Gnulib uses this technique. (This depends on the C compiler
in use recognising this directive, of course.)
