Bruno Haible wrote:
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.
Huh? There were no issues with MSVC 14 in these places in my latest round
of
Hi Gisle,
> 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.
Huh? There were no issues with MSVC 14 in these places in my latest round
of t
Paul Eggert wrote:
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 (0x
Gisle Vanem wrote:
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.
'#undef X' is merely a preprocessor directive; it doesn't affect whether X is
treated as a rese
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_pr
