libc-config.h + cdefs.h

[Gisle Vanem]

The new files libc-config.h and cdefs.h, break MSVC in
several ways:
1) libc-config.h:
# undef __inline

'__inline' is a built-in reserved word used through-out the MS SDK.

2) MSVC doesn't accept this:
#define libc_hidden_proto(name, attrs...)

Why not simply?
#define libc_hidden_proto(name, ...)

[Paul Eggert]

Post by Gisle Vanem
The new files libc-config.h and cdefs.h, break MSVC in
# undef __inline
'__inline' is a built-in reserved word used through-out the MS SDK.

'#undef X' is merely a preprocessor directive; it doesn't affect whether X is
treated as a reserved word. So why is this a problem?

Hmm, is it because of the '#define __inline' to nothing later on? OK, I can see
where that might be an issue. Should be fixed in the attached patch, which I
installed into Gnulib.

Post by Gisle Vanem
#define libc_hidden_proto(name, attrs...)
Why not simply?
#define libc_hidden_proto(name, ...)

Thanks, that was merely a cut-and-paste from glibc, which can assume the GNU C
extension of a name for the "...", and where I didn't notice the assumption.
This also should be fixed in the attached patch.

I haven't tested this with MSVC since I don't use MSVC, so please give it a try.

PS. You write "several ways" but mention only 2 ways; are there other things
that need fixing?

[Gisle Vanem]

Hmm, is it because of the '#define __inline' to nothing later on? OK, I can see where that might be an issue.

Exactly, in glob.c which includes the Windows-SDK function:
__inline struct _TEB *NtCurrentTeb (void)
{
return (struct _TEB *) (ULONG_PTR) __readfsdword (0x18);
}

Prior to this change it caused multiple 'NtCurrentTeb()'.
But with your changes, no problem (tested with Wget).

PS. You write "several ways" but mention only 2 ways; are there other things that need fixing?

There are some other trivial stuff in:
./lib/count-leading-zeros.h
./lib/count-one-bits.h
./lib/iconv.in.h
./lib/inttypes.in.h
./lib/localtime-buffer.c

which I'll come back to.

[Bruno Haible]

Hi Gisle,

Post by Gisle Vanem
./lib/count-leading-zeros.h
./lib/count-one-bits.h
./lib/iconv.in.h
./lib/inttypes.in.h
./lib/localtime-buffer.c
which I'll come back to.

Huh? There were no issues with MSVC 14 in these places in my latest round
of testing [1]. Please give details.

Bruno

[1] https://lists.gnu.org/archive/html/bug-gnulib/2016-12/msg00112.html

[Gisle Vanem]

This post might be inappropriate. Click to display it.

[Bruno Haible]

Post by Gisle Vanem
localtime-buffer.c(46) : warning C4717: 'rpl_localtime': recursive on all control paths,
function will cause runtime stack overflow
localtime-buffer.c(56) : warning C4717: 'rpl_gmtime': recursive on all control paths,
function will cause runtime stack overflow
--- a/lib/localtime-buffer.c 2017-09-18 14:33:43
+++ b/lib/localtime-buffer.c 2017-09-18 17:29:38
@@ -32,6 +32,9 @@
On the first call, record the address of the static buffer that
localtime uses for its result. */
+#undef localtime
+#undef gmtime
+
struct tm *
rpl_localtime (time_t const *timep)
{
there's no warning.

What's the result of 'grep LOCALTIME config.status' in your case?

I got:
S["REPLACE_LOCALTIME"]="1"
S["REPLACE_LOCALTIME_R"]="GNULIB_PORTCHECK"
S["HAVE_DECL_LOCALTIME_R"]="0"
S["GNULIB_LOCALTIME"]="1"
D["GNULIB_TEST_LOCALTIME"]=" 1"
D["HAVE_DECL_LOCALTIME_R"]=" 0"

Bruno

[Bruno Haible]

Hi Gisle,

Post by Gisle Vanem
_GL_CXXALIAS_RPL (strtoimax, intmax_t, (const char *, char **, int));
# else
# undef strtoimax
_GL_FUNCDECL_SYS (strtoimax, intmax_t,
(const char *, char **, int) _GL_ARG_NONNULL ((1)));
# endif
Why is there a '#undef strtoimax' if there is *NO* declaration for
'strtoimax()'? Isn't 'HAVE_DECL_STRTOIMAX' supposed to be TRUE is so?
# undef strtoimax
_GL_FUNCDECL_SYS (strtoimax, intmax_t,
(const char *, char **, int) _GL_ARG_NONNULL ((1)));
# endif
I'd understand it better. Ditto for 'strtoumax()'.

The idioms that we use for function declarations in the *.in.h files are
designed to work
- regardless whether the system headers declare the function or not,
define the function as an inline function or not, or declare the symbol
as a macro or not,
- both in C and C++.

The situations where HAVE_DECL_XXX are set to 1 are described in [1].

If some header file does, say,
#define strtoimax(p,e,b) (long long) strtoll ((p),(char**)(e),(b))
then HAVE_DECL_STRTOIMAX will definitely be 0.

Instead of you wondering about these issues on your own, it is probably
better if you show
- the error that you observe,
- the relevant snippet from the gnulib-generated substitute .h file,
- the relevant definitions from config.status, config.h, in combination
with the config.log and the 'configure' output.
We can then analyze it together.

In a testdir from July 2017, with MSVC 14, I have these settings in
config.status:
S["REPLACE_STRTOIMAX"]="0"
S["HAVE_DECL_STRTOIMAX"]="1"
S["GNULIB_STRTOIMAX"]="1"
D["HAVE_STRTOIMAX"]=" 1"
D["HAVE_RAW_DECL_STRTOIMAX"]=" 1"
D["HAVE_DECL_STRTOIMAX"]=" 1"

Is it different for you?

Bruno

[1] https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Generic-Declarations.html