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(a)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(a)dimi wine]$ First off, are we supposed to die on the va_list stuff? Second, why is wchar_t undeclared? -- Dimi. P.S. Please do not ask why so many includes, I know they are not needed, but it should work, right?
On November 19, 2002 09:46 am, Dimitrie O. Paun wrote:
[dimi(a)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(a)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? -- Dimi.
Dimitrie O. Paun wrote:
On November 19, 2002 09:46 am, Dimitrie O. Paun wrote:
[dimi(a)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(a)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
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. -- Dimi.
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
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. -- gmt "War is an ugly thing, but not the ugliest of things; the decayed and degraded state of moral and patriotic feeling which thinks that nothing is worth war is much worse. A man who has nothing for which he is willing to fight; nothing he cares about more than his own personal safety; is a miserable creature who has no chance of being free, unless made and kept so by the exertions of better persons than himself." -- John Stuart Mill
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? -- Dimi.
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
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)...? -- gmt "War is an ugly thing, but not the ugliest of things; the decayed and degraded state of moral and patriotic feeling which thinks that nothing is worth war is much worse. A man who has nothing for which he is willing to fight; nothing he cares about more than his own personal safety; is a miserable creature who has no chance of being free, unless made and kept so by the exertions of better persons than himself." -- John Stuart Mill
Am Die, 2002-11-19 um 15.59 schrieb Dimitrie O. Paun:
Nevertheless, they solve only part of the problem:
[dimi(a)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 -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
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? -- Dimi.
participants (5)
-
David Fraser -
Dimitrie O. Paun -
Greg Turner -
Martin Wilck -
Vincent Béron