msvcrt vs std incl

[Dimitrie O. Paun]

Hi guys,

Here's a small test program:

#include <windows.h>
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>

int main()
{
    printf("sizeof(wchar_t)=%d\n", sizeof(wchar_t));

return 0;
}

And I want to compile this with our msvcrt headers. 
Look what happens:

[dimi@dimi wine]$ gcc -nostdinc -fshort-wchar -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include test.c
In file included from /home/dimi/dev/wine/wine.src/include/windows.h:38,
                 from test.c:1:
/home/dimi/dev/wine/wine.src/include/winbase.h:23:20: stdarg.h: No such file or directory
In file included from /home/dimi/dev/wine/wine.src/include/windows.h:38,
                 from test.c:1:
/home/dimi/dev/wine/wine.src/include/winbase.h:1257: parse error before "va_list"
/home/dimi/dev/wine/wine.src/include/winbase.h:1258: parse error before "va_list"
In file included from /home/dimi/dev/wine/wine.src/include/windows.h:40,
                 from test.c:1:
/home/dimi/dev/wine/wine.src/include/winuser.h:23:20: stdarg.h: No such file or directory
In file included from /home/dimi/dev/wine/wine.src/include/windows.h:40,
                 from test.c:1:
/home/dimi/dev/wine/wine.src/include/winuser.h:4459: parse error before "va_list"
/home/dimi/dev/wine/wine.src/include/winuser.h:4460: parse error before "va_list"
In file included from test.c:2:
/home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:13:20: stdarg.h: No such file or directory
In file included from test.c:2:
/home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:135: parse error before "va_list"
/home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:175: parse error before "va_list"
/home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:176: parse error before "va_list"
/home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:177: parse error before "va_list"
/home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:184: parse error before "va_list"
/home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:211: parse error before "va_list"
/home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:212: parse error before "va_list"
/home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:213: parse error before "va_list"
test.c:4:20: assert.h: No such file or directory
test.c: In function `main':
test.c:8: `wchar_t' undeclared (first use in this function)
test.c:8: (Each undeclared identifier is reported only once
test.c:8: for each function it appears in.)
[dimi@dimi wine]$

First off, are we supposed to die on the va_list stuff?
Second, why is wchar_t undeclared?

[Dimitrie O. Paun]

On November 19, 2002 09:46 am, Dimitrie O. Paun wrote:
> [dimi@dimi wine]$ gcc -nostdinc -fshort-wchar -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include test.c

Hm, maybe we need the standard headers after all.
Even though this might create confusion.

Nevertheless, they solve only part of the problem:

[dimi@dimi wine]$ gcc -fshort-wchar -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include test.c
test.c: In function `main':
test.c:8: `wchar_t' undeclared (first use in this function)
test.c:8: (Each undeclared identifier is reported only once
test.c:8: for each function it appears in.)

This shouldn't have, should it?

[David Fraser]

Dimitrie O. Paun wrote:
> On November 19, 2002 09:46 am, Dimitrie O. Paun wrote:
> > [dimi@dimi wine]$ gcc -nostdinc -fshort-wchar -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include test.c
>
> Hm, maybe we need the standard headers after all.
> Even though this might create confusion.
>
> Nevertheless, they solve only part of the problem:
>
> [dimi@dimi wine]$ gcc -fshort-wchar -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include test.c
> test.c: In function `main':
> test.c:8: `wchar_t' undeclared (first use in this function)
> test.c:8: (Each undeclared identifier is reported only once
> test.c:8: for each function it appears in.)
>
> This shouldn't have, should it?

This actually happens whether you do -fshort-wchar or not.
The question is, where is wchar_t defined?
The answer seems to be, in stddef.h
However, the Wine stddef.h has this:
/* Best to leave this one alone: wchar_t */
and doesn't define it.
So if you include the normal stddef.h, we have a definition. This can be 
done with a -I- to indicate that only "" style headers should be included
from the given directories:

gcc -fshort-wchar -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include -I- test.c

The problem is, there is a conflict between linux stddef.h and wine stdlib.h. There is also a 
redifinition of size_t in stdio.h, but that's not a problem.

So the following C program compiles fine with the above command, -fshort-wchar or not, and making
stdio.h angle-bracketed will take away the size_t warning:

#include <stddef.h>
#include "windows.h"
#include "stdio.h"
#include <stdlib.h>
#include "assert.h"

int main()
{
            printf("sizeof(wchar_t)=%d\n", sizeof(wchar_t));

return 0;
}

Obviously something could be done about the conflicts and or lack of wchar_t in wine stdlib.h,
but I'll leave that up to someone else...

David

[Dimitrie O. Paun]

On November 19, 2002 10:26 am, David Fraser wrote:
> So the following C program compiles fine with the above command,
> -fshort-wchar or not, and making stdio.h angle-bracketed will take away the
> size_t warning:

What I'm waiting for is a solution that does not touch the program 
I've posted. My gut feeling is that our headers are busticated.

[Vincent Béron]

Dimitrie O. Paun a écrit:
> On November 19, 2002 10:26 am, David Fraser wrote:
> > So the following C program compiles fine with the above command,
> > -fshort-wchar or not, and making stdio.h angle-bracketed will take away the
> > size_t warning:
>
> What I'm waiting for is a solution that does not touch the program 
> I've posted. My gut feeling is that our headers are busticated.

Quickly checking in MS's headers (an old version), there's a lot of 
typedef to define wchar_t.

Vincent

[Dimitrie O. Paun]

On November 19, 2002 10:57 am, Vincent Béron wrote:
> Quickly checking in MS's headers (an old version), there's a lot of
> typedef to define wchar_t.

I figured that much. I was hoping for a patch... :)

[Greg Turner]

On Tuesday 19 November 2002 09:58 am, Dimitrie O. Paun wrote:
> On November 19, 2002 10:57 am, Vincent Béron wrote:
> > Quickly checking in MS's headers (an old version), there's a lot of
> > typedef to define wchar_t.
>
> I figured that much. I was hoping for a patch... :)

The wine headers are very interesting to me right now.  I guess we need 
to do something like

#if (some hairy condition)
  typedef WCHAR wchar_t
  #endif

in the appropriate place (I guess, stddef.h)?

It would be helpful to me (not just for this problem, which I don't 
intend to try and solve) to get a clear picture of all usage scenarios 
that the wine headers are supposed to support...  Obviously there are

o compile wine under unix-like platforms, excluding cygwin
  o compile a c winelib app for unix-like platforms, excluding cygwin

but what else?  in particular, should we worry about any of these?

o compile wine for cygwin
  o compile winelib app under cygwin
  o compile wine under msvc
  o compile winelib app under msvc
  o be a replacement for a standard unix header (native compile)
  o be a replacement for an msvc header (native compile)
  o something else I didn't think of
  o c++ support combined with any of the above

I also get the impression that the same list of usage scenarios doesn't 
apply to all headers (for example, there was recent discussion about 
three categories of headers and include/wine/wine).

It would be good if somebody who knows this stuff could specify this, 
somewhere, so that clueless folks like myself don't create unneccesary 
complexity trying to support usage scenarios that should never occur.

Actually, I have similar questions about the programs and dlls trees of 
wine... for example, Alexandre has requested that I remove #ifdef's 
from rpcss... but can I safely code against the assumption that 
defined(NO_NAMELESS_STRUCT)?  The answer (or, more precisely, the 
ability to answer for myself without bothering you all about it) lies 
in knowing what the "officially" supported usage scenarios for the 
rpcss code are... but I'm not sure I do.

[Dimitrie O. Paun]

On November 19, 2002 12:55 pm, Greg Turner wrote:
> The wine headers are very interesting to me right now.  I guess we need
> to do something like
>
> #if (some hairy condition)
>   typedef WCHAR wchar_t
>   #endif
>
> in the appropriate place (I guess, stddef.h)?

Here's what I did:

Index: include/msvcrt/stddef.h
===================================================================
RCS file: /var/cvs/wine/include/msvcrt/stddef.h,v
retrieving revision 1.4
diff -u -r1.4 stddef.h
--- include/msvcrt/stddef.h     10 Mar 2002 00:02:38 -0000      1.4
+++ include/msvcrt/stddef.h     19 Nov 2002 17:09:20 -0000
@@ -32,6 +32,9 @@
 #endif

/* Best to leave this one alone: wchar_t */
+#ifdef WINE_DEFINE_WCHAR_T
+typedef short unsigned int wchar_t;
+#endif

#define offsetof(s,m)       (size_t)&(((s*)NULL)->m)
> It would be helpful to me (not just for this problem, which I don't
> intend to try and solve) to get a clear picture of all usage scenarios
> that the wine headers are supposed to support...  Obviously there are
>
> o compile wine under unix-like platforms, excluding cygwin
>   o compile a c winelib app for unix-like platforms, excluding cygwin
>
> but what else?  in particular, should we worry about any of these?
>
> o compile wine for cygwin
>   o compile winelib app under cygwin
>   o compile wine under msvc
>   o compile winelib app under msvc
>   o be a replacement for a standard unix header (native compile)
>   o be a replacement for an msvc header (native compile)
>   o something else I didn't think of
>   o c++ support combined with any of the above

Why not? All of the above should work in theory, no?

[Vincent Béron]

Greg Turner a écrit:
> The wine headers are very interesting to me right now.  I guess we need 
> to do something like
>
> #if (some hairy condition)
>   typedef WCHAR wchar_t
>   #endif
>
> in the appropriate place (I guess, stddef.h)?

Actually, in winnt.h (and wtypes.h, although it's #ifdef 0, and 
msvcrt/wctypes.h), we have the exact opposite: typedef wchar_t WCHAR, 
with a default to typedef unsigned short WCHAR if wchar_t is not 
defined. So we need to define wchar_t, not WCHAR.

BTW, I believe MS headers have the same order (wchar_t -> WCHAR).
> Actually, I have similar questions about the programs and dlls trees of 
> wine... for example, Alexandre has requested that I remove #ifdef's 
> from rpcss... but can I safely code against the assumption that 
> defined(NO_NAMELESS_STRUCT)?  The answer (or, more precisely, the 
> ability to answer for myself without bothering you all about it) lies 
> in knowing what the "officially" supported usage scenarios for the 
> rpcss code are... but I'm not sure I do.

DEFS        = @DLLFLAGS@ -DSTRICT -DNONAMELESSUNION -DNONAMELESSSTRUCT 
$(EXTRADEFS)

in Makeprogs.rules.in should answer one of your questions.

Vincent

[Greg Turner]

On Tuesday 19 November 2002 12:09 pm, Vincent Béron wrote:
> Greg Turner a écrit:
> > Actually, I have similar questions about the programs and dlls
> > trees of wine... for example, Alexandre has requested that I remove
> > #ifdef's from rpcss... but can I safely code against the assumption
> > that defined(NO_NAMELESS_STRUCT)?  The answer (or, more precisely,
> > the ability to answer for myself without bothering you all about
> > it) lies in knowing what the "officially" supported usage scenarios
> > for the rpcss code are... but I'm not sure I do.
>
> DEFS        = @DLLFLAGS@ -DSTRICT -DNONAMELESSUNION
> -DNONAMELESSSTRUCT $(EXTRADEFS)
>
> in Makeprogs.rules.in should answer one of your questions.
>
> Vincent

that is clear, indeed, but what I don't know is, should I be worried 
that somebody is compiling, say, under MSVC, completely outside of the 
control of the wine configure/make, where, in fact, 
!defined(NONAMELESSSTRUCT) && !defined(NONAMELESSUNION)...?

[Martin Wilck]

Am Die, 2002-11-19 um 15.59 schrieb Dimitrie O. Paun:
> Nevertheless, they solve only part of the problem:
>
> [dimi@dimi wine]$ gcc -fshort-wchar -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include test.c
> test.c: In function `main':
> test.c:8: `wchar_t' undeclared (first use in this function)
> test.c:8: (Each undeclared identifier is reported only once
> test.c:8: for each function it appears in.)
>
> This shouldn't have, should it?

s/wchar_t/WCHAR/g

The winemaker-generated build line would look somthing like

gcc -c -g -O2 -fPIC  -D_REENTRANT -DWINELIB  -I/home/martin/exp/include/wine/msvcrt  -I.  -I/home/martin/exp/include/wine test.c

Using this line and WCHAR instead of wchar_t, I'm fine. It prints "sizeof (WCHAR) = 2".

Martin

[Dimitrie O. Paun]

On November 19, 2002 10:51 am, Martin Wilck wrote:
> Using this line and WCHAR instead of wchar_t, I'm fine. It prints "sizeof
> (WCHAR) = 2".

I know, but this is not good enough. I want to port some apps over 
(eg putty) and that one uses wchar_t. Changing the source is not an
option IMO. In this case, we are clearly at fault, and a fix to our 
headers doesn't seem that outlandish, no?