From: Fabian Maurer dark.shadow4@web.de
Signed-off-by: Fabian Maurer dark.shadow4@web.de --- include/bluetoothapis.h | 2 -- 1 file changed, 2 deletions(-)
diff --git a/include/bluetoothapis.h b/include/bluetoothapis.h index d3b5c941b7c..e50c572df1d 100644 --- a/include/bluetoothapis.h +++ b/include/bluetoothapis.h @@ -112,8 +112,6 @@ typedef BOOL (WINAPI *PFN_AUTHENTICATION_CALLBACK)(void *, PBLUETOOTH_DEVICE_INF
#define BLUETOOTH_DEVICE_INFO BLUETOOTH_DEVICE_INFO_STRUCT
-typedef BLUETOOTH_DEVICE_INFO *PBLUETOOTH_DEVICE_INFO; - typedef enum _BLUETOOTH_AUTHENTICATION_METHOD { BLUETOOTH_AUTHENTICATION_METHOD_LEGACY = 0x1, BLUETOOTH_AUTHENTICATION_METHOD_OOB,
From: Fabian Maurer dark.shadow4@web.de
Signed-off-by: Fabian Maurer dark.shadow4@web.de --- include/dbgeng.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/dbgeng.h b/include/dbgeng.h index 4322eff5302..423f2c47cbc 100644 --- a/include/dbgeng.h +++ b/include/dbgeng.h @@ -210,9 +210,9 @@ DEFINE_GUID(IID_IDebugSystemObjects3, 0xe9676e2f, 0xe286, 0x4ea3, 0xb0, 0xf9
#ifndef __IDebugClient_FWD_DEFINED__ #define __IDebugClient_FWD_DEFINED__ -typedef interface IDebugClient IDebugClient; -#ifdef __cplusplus interface IDebugClient; +#ifdef __cplusplus +typedef interface IDebugClient IDebugClient; #endif /* __cplusplus */ #endif
@@ -388,7 +388,7 @@ DECLARE_INTERFACE_(IDebugBreakpoint, IUnknown) /* IDebugBreakpoint */ STDMETHOD(GetId)(THIS_ PULONG id) PURE; STDMETHOD(GetType)(THIS_ PULONG breaktype, PULONG proc) PURE; - STDMETHOD(GetAdder)(THIS_ IDebugClient **adder) PURE; + STDMETHOD(GetAdder)(THIS_ interface IDebugClient **adder) PURE; STDMETHOD(GetFlags)(THIS_ PULONG flags) PURE; STDMETHOD(AddFlags)(THIS_ ULONG flags) PURE; STDMETHOD(RemoveFlags)(THIS_ ULONG flags) PURE; @@ -420,7 +420,7 @@ DECLARE_INTERFACE_(IDebugBreakpoint2, IUnknown) /* IDebugBreakpoint */ STDMETHOD(GetId)(THIS_ PULONG id) PURE; STDMETHOD(GetType)(THIS_ PULONG breaktype, PULONG proc) PURE; - STDMETHOD(GetAdder)(THIS_ IDebugClient **adder) PURE; + STDMETHOD(GetAdder)(THIS_ interface IDebugClient **adder) PURE; STDMETHOD(GetFlags)(THIS_ PULONG flags) PURE; STDMETHOD(AddFlags)(THIS_ ULONG flags) PURE; STDMETHOD(RemoveFlags)(THIS_ ULONG flags) PURE;
From: Fabian Maurer dark.shadow4@web.de
Signed-off-by: Fabian Maurer dark.shadow4@web.de --- include/mfapi.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/mfapi.h b/include/mfapi.h index 3185fc6944f..702c3ec683a 100644 --- a/include/mfapi.h +++ b/include/mfapi.h @@ -506,7 +506,6 @@ typedef enum #define MF_E_DXGI_VIDEO_DEVICE_LOCKED ((HRESULT)0x80041002)
struct tagVIDEOINFOHEADER; -typedef struct tagVIDEOINFOHEADER VIDEOINFOHEADER;
HRESULT WINAPI MFAddPeriodicCallback(MFPERIODICCALLBACK callback, IUnknown *context, DWORD *key); HRESULT WINAPI MFAllocateSerialWorkQueue(DWORD target_queue, DWORD *queue); @@ -588,7 +587,7 @@ HRESULT WINAPI MFTGetInfo(CLSID clsid, WCHAR **name, MFT_REGISTER_TYPE_INFO **in BOOL WINAPI MFIsFormatYUV(DWORD format); HRESULT WINAPI MFInitAttributesFromBlob(IMFAttributes *attributes, const UINT8 *buffer, UINT size); HRESULT WINAPI MFInitMediaTypeFromAMMediaType(IMFMediaType *mediatype, const AM_MEDIA_TYPE *am_type); -HRESULT WINAPI MFInitMediaTypeFromVideoInfoHeader(IMFMediaType *media_type, const VIDEOINFOHEADER *vih, +HRESULT WINAPI MFInitMediaTypeFromVideoInfoHeader(IMFMediaType *media_type, const struct tagVIDEOINFOHEADER *vih, UINT32 size, const GUID *subtype); HRESULT WINAPI MFInitMediaTypeFromWaveFormatEx(IMFMediaType *mediatype, const WAVEFORMATEX *format, UINT32 size); HRESULT WINAPI MFInitVideoFormat_RGB(MFVIDEOFORMAT *format, DWORD width, DWORD height, DWORD d3dformat);
From: Fabian Maurer dark.shadow4@web.de
Signed-off-by: Fabian Maurer dark.shadow4@web.de --- dlls/ndis.sys/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dlls/ndis.sys/main.c b/dlls/ndis.sys/main.c index b5ce2fd8f5b..d8ea668b2bb 100644 --- a/dlls/ndis.sys/main.c +++ b/dlls/ndis.sys/main.c @@ -31,9 +31,9 @@ #include "winsock2.h" #include "ws2ipdef.h" #include "iphlpapi.h" -#include "netioapi.h" #include "ddk/wdm.h" #include "ddk/ndis.h" +#include "netioapi.h" #include "winreg.h" #include "wine/debug.h"
From: Fabian Maurer dark.shadow4@web.de
Signed-off-by: Fabian Maurer dark.shadow4@web.de --- dlls/mshtml/mshtml_private.h | 1 - 1 file changed, 1 deletion(-)
diff --git a/dlls/mshtml/mshtml_private.h b/dlls/mshtml/mshtml_private.h index 4bc492f7532..7694e6ac7dd 100644 --- a/dlls/mshtml/mshtml_private.h +++ b/dlls/mshtml/mshtml_private.h @@ -77,7 +77,6 @@ #define MSHTML_E_NODOC 0x800a025c #define MSHTML_E_NOT_FUNC 0x800a138a
-typedef struct DOMEvent DOMEvent; typedef struct HTMLDOMNode HTMLDOMNode; typedef struct ConnectionPoint ConnectionPoint; typedef struct BSCallback BSCallback;
From: Fabian Maurer dark.shadow4@web.de
Signed-off-by: Fabian Maurer dark.shadow4@web.de --- include/ddk/wsk.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/ddk/wsk.h b/include/ddk/wsk.h index 3e0debb1c0f..cdb74fbc1ac 100644 --- a/include/ddk/wsk.h +++ b/include/ddk/wsk.h @@ -58,7 +58,7 @@ typedef enum _WSK_INSPECT_ACTION WskInspectAccept, } WSK_INSPECT_ACTION;
-typedef struct _WSK_CLIENT_CONNECTION_DISPATCH WSK_CLIENT_CONNECTION_DISPATCH, *PWSK_CLIENT_CONNECTION_DISPATCH; +struct _WSK_CLIENT_CONNECTION_DISPATCH;
typedef struct _WSK_BUF { @@ -102,7 +102,7 @@ typedef NTSTATUS (WINAPI *PFN_WSK_SOCKET)(WSK_CLIENT *client, ADDRESS_FAMILY fam PEPROCESS process, PETHREAD thread, SECURITY_DESCRIPTOR *security, IRP *irp); typedef NTSTATUS (WINAPI *PFN_WSK_SOCKET_CONNECT)(WSK_CLIENT *client, USHORT type, ULONG protocol, SOCKADDR *local, SOCKADDR *remote, ULONG flags, void *context, - const WSK_CLIENT_CONNECTION_DISPATCH *dispatch, PEPROCESS process, PETHREAD owning, + const struct _WSK_CLIENT_CONNECTION_DISPATCH *dispatch, PEPROCESS process, PETHREAD owning, SECURITY_DESCRIPTOR *descriptor, IRP *irp); typedef NTSTATUS (WINAPI *PFN_WSK_CONTROL_CLIENT)(WSK_CLIENT *client, ULONG control, SIZE_T input_size, void *input, SIZE_T output_size, void *output, SIZE_T *returned,
From: Fabian Maurer dark.shadow4@web.de
Signed-off-by: Fabian Maurer dark.shadow4@web.de --- include/xact3.h | 41 ++++++++++++++++++++--------------------- 1 file changed, 20 insertions(+), 21 deletions(-)
diff --git a/include/xact3.h b/include/xact3.h index 939a80e2af5..b888ad4b572 100644 --- a/include/xact3.h +++ b/include/xact3.h @@ -59,11 +59,10 @@ DEFINE_GUID(CLSID_XACTDebugEngine, 0x02860630, 0xbf3b, 0x42a8, 0xb1, 0x4e, 0x DEFINE_GUID(IID_IXACT3Engine, 0xb1ee676a, 0xd9cd, 0x4d2a, 0x89, 0xa8, 0xfa, 0x53, 0xeb, 0x9e, 0x48, 0x0b); #endif
-typedef struct IXACT3SoundBank IXACT3SoundBank; -typedef struct IXACT3WaveBank IXACT3WaveBank; -typedef struct IXACT3Cue IXACT3Cue; -typedef struct IXACT3Wave IXACT3Wave; -typedef struct IXACT3Engine IXACT3Engine; +struct IXACT3SoundBank; +struct IXACT3WaveBank; +struct IXACT3Cue; +struct IXACT3Wave;
typedef WORD XACTCATEGORY; typedef BYTE XACTCHANNEL; @@ -336,10 +335,10 @@ typedef struct XACT_NOTIFICATION_DESCRIPTION { XACTNOTIFICATIONTYPE type; BYTE flags; - IXACT3SoundBank *pSoundBank; - IXACT3WaveBank *pWaveBank; - IXACT3Cue *pCue; - IXACT3Wave *pWave; + struct IXACT3SoundBank *pSoundBank; + struct IXACT3WaveBank *pWaveBank; + struct IXACT3Cue *pCue; + struct IXACT3Wave *pWave; XACTINDEX cueIndex; XACTINDEX waveIndex; void* pvContext; @@ -349,37 +348,37 @@ typedef const XACT_NOTIFICATION_DESCRIPTION *LPCXACT_NOTIFICATION_DESCRIPTION; typedef struct XACT_NOTIFICATION_CUE { XACTINDEX cueIndex; - IXACT3SoundBank *pSoundBank; - IXACT3Cue *pCue; + struct IXACT3SoundBank *pSoundBank; + struct IXACT3Cue *pCue; } XACT_NOTIFICATION_CUE, *LPXACT_NOTIFICATION_CUE; typedef const XACT_NOTIFICATION_CUE *LPCXACT_NOTIFICATION_CUE;
typedef struct XACT_NOTIFICATION_MARKER { XACTINDEX cueIndex; - IXACT3SoundBank *pSoundBank; - IXACT3Cue *pCue; + struct IXACT3SoundBank *pSoundBank; + struct IXACT3Cue *pCue; DWORD marker; } XACT_NOTIFICATION_MARKER, *LPXACT_NOTIFICATION_MARKER; typedef const XACT_NOTIFICATION_MARKER *LPCXACT_NOTIFICATION_MARKER;
typedef struct XACT_NOTIFICATION_SOUNDBANK { - IXACT3SoundBank *pSoundBank; + struct IXACT3SoundBank *pSoundBank; } XACT_NOTIFICATION_SOUNDBANK, *LPXACT_NOTIFICATION_SOUNDBANK; typedef const XACT_NOTIFICATION_SOUNDBANK *LPCXACT_NOTIFICATION_SOUNDBANK;
typedef struct XACT_NOTIFICATION_WAVEBANK { - IXACT3WaveBank *pWaveBank; + struct IXACT3WaveBank *pWaveBank; } XACT_NOTIFICATION_WAVEBANK, *LPXACT_NOTIFICATION_WAVEBANK; typedef const XACT_NOTIFICATION_WAVEBANK *LPCXACT_NOTIFICATION_WAVEBANK;
typedef struct XACT_NOTIFICATION_VARIABLE { XACTINDEX cueIndex; - IXACT3SoundBank *pSoundBank; - IXACT3Cue *pCue; + struct IXACT3SoundBank *pSoundBank; + struct IXACT3Cue *pCue; XACTVARIABLEINDEX variableIndex; XACTVARIABLEVALUE variableValue; BOOL local; @@ -394,12 +393,12 @@ typedef const XACT_NOTIFICATION_GUI *LPCXACT_NOTIFICATION_GUI;
typedef struct XACT_NOTIFICATION_WAVE { - IXACT3WaveBank *pWaveBank; + struct IXACT3WaveBank *pWaveBank; XACTINDEX waveIndex; XACTINDEX cueIndex; - IXACT3SoundBank *pSoundBank; - IXACT3Cue *pCue; - IXACT3Wave *pWave; + struct IXACT3SoundBank *pSoundBank; + struct IXACT3Cue *pCue; + struct IXACT3Wave *pWave; } XACT_NOTIFICATION_WAVE, *LPXACT_NOTIFICATION_WAVE; typedef const XACT_NOTIFICATION_WAVE *LPCXACT_NOTIFICATION_NAME;
From: Fabian Maurer dark.shadow4@web.de
Signed-off-by: Fabian Maurer dark.shadow4@web.de --- include/xact.h | 41 ++++++++++++++++++++--------------------- 1 file changed, 20 insertions(+), 21 deletions(-)
diff --git a/include/xact.h b/include/xact.h index c6b34cc2c05..84d84a8bd31 100644 --- a/include/xact.h +++ b/include/xact.h @@ -82,11 +82,10 @@ DEFINE_GUID(IID_IXACTEngine, 0x0aa000a0, 0xf404, 0x11d9, 0xbd, 0x7a, 0x00, 0x10, 0xdc, 0x4f, 0x8f, 0x81); #endif
-typedef struct IXACTSoundBank IXACTSoundBank; -typedef struct IXACTWaveBank IXACTWaveBank; -typedef struct IXACTCue IXACTCue; -typedef struct IXACTWave IXACTWave; -typedef struct IXACTEngine IXACTEngine; +struct IXACTSoundBank; +struct IXACTWaveBank; +struct IXACTCue; +struct IXACTWave;
typedef WORD XACTCATEGORY; typedef BYTE XACTCHANNEL; @@ -404,8 +403,8 @@ typedef struct typedef struct XACT_NOTIFICATION_CUE { XACTINDEX cueIndex; - IXACTSoundBank *pSoundBank; - IXACTCue *pCue; + struct IXACTSoundBank *pSoundBank; + struct IXACTCue *pCue; } XACT_NOTIFICATION_CUE, *LPXACT_NOTIFICATION_CUE; typedef const XACT_NOTIFICATION_CUE *LPCXACT_NOTIFICATION_CUE;
@@ -413,11 +412,11 @@ typedef struct XACT_NOTIFICATION_DESCRIPTION { XACTNOTIFICATIONTYPE type; BYTE flags; - IXACTSoundBank *pSoundBank; - IXACTWaveBank *pWaveBank; - IXACTCue *pCue; + struct IXACTSoundBank *pSoundBank; + struct IXACTWaveBank *pWaveBank; + struct IXACTCue *pCue; #if XACT3_VER >= 0x0205 - IXACTWave *pWave; + struct IXACTWave *pWave; #endif XACTINDEX cueIndex; #if XACT3_VER >= 0x0205 @@ -436,23 +435,23 @@ typedef const XACT_NOTIFICATION_GUI *LPCXACT_NOTIFICATION_GUI; typedef struct XACT_NOTIFICATION_MARKER { XACTINDEX cueIndex; - IXACTSoundBank *pSoundBank; - IXACTCue *pCue; + struct IXACTSoundBank *pSoundBank; + struct IXACTCue *pCue; DWORD marker; } XACT_NOTIFICATION_MARKER, *LPXACT_NOTIFICATION_MARKER; typedef const XACT_NOTIFICATION_MARKER *LPCXACT_NOTIFICATION_MARKER;
typedef struct XACT_NOTIFICATION_SOUNDBANK { - IXACTSoundBank *pSoundBank; + struct IXACTSoundBank *pSoundBank; } XACT_NOTIFICATION_SOUNDBANK, *LPXACT_NOTIFICATION_SOUNDBANK; typedef const XACT_NOTIFICATION_SOUNDBANK *LPCXACT_NOTIFICATION_SOUNDBANK;
typedef struct XACT_NOTIFICATION_VARIABLE { XACTINDEX cueIndex; - IXACTSoundBank *pSoundBank; - IXACTCue *pCue; + struct IXACTSoundBank *pSoundBank; + struct IXACTCue *pCue; XACTVARIABLEINDEX variableIndex; XACTVARIABLEVALUE variableValue; BOOL local; @@ -461,20 +460,20 @@ typedef const XACT_NOTIFICATION_VARIABLE *LPCXACT_NOTIFICATION_VARIABLE;
typedef struct XACT_NOTIFICATION_WAVE { - IXACTWaveBank *pWaveBank; + struct IXACTWaveBank *pWaveBank; XACTINDEX waveIndex; XACTINDEX cueIndex; - IXACTSoundBank *pSoundBank; - IXACTCue *pCue; + struct IXACTSoundBank *pSoundBank; + struct IXACTCue *pCue; #if XACT3_VER >= 0x0205 - IXACTWave *pWave; + struct IXACTWave *pWave; #endif } XACT_NOTIFICATION_WAVE, *LPXACT_NOTIFICATION_WAVE; typedef const XACT_NOTIFICATION_WAVE *LPCXACT_NOTIFICATION_NAME;
typedef struct XACT_NOTIFICATION_WAVEBANK { - IXACTWaveBank *pWaveBank; + struct IXACTWaveBank *pWaveBank; } XACT_NOTIFICATION_WAVEBANK, *LPXACT_NOTIFICATION_WAVEBANK; typedef const XACT_NOTIFICATION_WAVEBANK *LPCXACT_NOTIFICATION_WAVEBANK;
Jacek Caban (@jacek) commented about include/mfapi.h:
#define MF_E_DXGI_VIDEO_DEVICE_LOCKED ((HRESULT)0x80041002)
struct tagVIDEOINFOHEADER; -typedef struct tagVIDEOINFOHEADER VIDEOINFOHEADER;
This is typedefed here in Windows SDK.
On Wed Jun 14 15:38:45 2023 +0000, Jacek Caban wrote:
This is typedefed here in Windows SDK.
Do we need to copy them 100%? Is there harm in deviating?
I could add a `WINE_HAVE_VIDEOINFOHEADER` define to prevent redefinition if that's better?
On Wed Jun 14 18:54:53 2023 +0000, Fabian Maurer wrote:
Do we need to copy them 100%? Is there harm in deviating? I could add a `WINE_HAVE_VIDEOINFOHEADER` define to prevent redefinition if that's better?
We don't need to be 100% compatible, but we want code that builds with Windows SDK to build with Wine headers as well. Public headers may need additional guards, unfortunately.
On Mon Jul 3 12:40:46 2023 +0000, Jacek Caban wrote:
We don't need to be 100% compatible, but we want code that builds with Windows SDK to build with Wine headers as well. Public headers may need additional guards, unfortunately.
Would be define a usable approach?
I don't think this is worth fixing. Typedef redefinitions are a C11 feature, and Wine already requires the compiler to support other C11 features like anonymous unions and designated initializers. I would prefer to just document that Wine requires the compiler to support C11 and not attempt to support any compiler that falls short.
On Wed Jul 5 22:39:58 2023 +0000, Alex Henrie wrote:
I don't think this is worth fixing. Typedef redefinitions are a C11 feature, and Wine already requires the compiler to support other C11 features like anonymous unions and designated initializers. I would prefer to just document that Wine requires the compiler to support C11 and not attempt to support any compiler that falls short.
I don't know the general stance of compiler support, but I was under the impression that gcc 4.3 is still supported, at least in theory. I already submitted a few patches for gcc 4.3 a while ago, which were accepted.
To be honest, I don't really mind, I just wanted to help the people who wanted to use 4.3 on their old distros. I guess an official statement would be nice, because I heard different opinions.
I don't think this is worth fixing. Typedef redefinitions are a C11 feature, and Wine already requires the compiler to support other C11 features like anonymous unions and designated initializers. I would prefer to just document that Wine requires the compiler to support C11 and not attempt to support any compiler that falls short.
We don't compile code with a C standard, we compile it with the actual compilers that people have on their machine, none of which are 100% standards-compliant.
If actual users are running into a problem, we want to make an effort to fix it. If the fix turns out to be too complicated or ugly, we may decide not to implement it, but we should never refuse to support users just because of what some C standard says.
On Thu Jul 6 10:10:11 2023 +0000, Alexandre Julliard wrote:
I don't think this is worth fixing. Typedef redefinitions are a C11
feature, and Wine already requires the compiler to support other C11 features like anonymous unions and designated initializers. I would prefer to just document that Wine requires the compiler to support C11 and not attempt to support any compiler that falls short. We don't compile code with a C standard, we compile it with the actual compilers that people have on their machine, none of which are 100% standards-compliant. If actual users are running into a problem, we want to make an effort to fix it. If the fix turns out to be too complicated or ugly, we may decide not to implement it, but we should never refuse to support users just because of what some C standard says.
Hi Alexandre, thanks for chiming in.
The problem with not having a standard is that it makes it very difficult for contributors to know which language features are allowed in Wine and which are not. For example, right now anonymous unions, designated initializers, and flexible array members are required (which break old compilers), whereas // comments and declaring variables in the middle of a function or at the beginning of a for loop are forbidden (presumably for the benefit of old compilers), and typedef redefinitions are a gray area. What C compiler supports designated initializers but not // comments?
Maybe Wine's rules about comments and variables are just for stylistic reasons and not compatibility. If that is the case, let's clearly explain it in the wiki. Let's also clearly explain what other language features are not allowed and why (such as duplicate typedef definitions because of GCC 4.3).
On Thu Jul 6 23:45:09 2023 +0000, Alex Henrie wrote:
Hi Alexandre, thanks for chiming in. The problem with not having a standard is that it makes it very difficult for contributors to know which language features are allowed in Wine and which are not. For example, right now anonymous unions, designated initializers, and flexible array members are required (which break old compilers), whereas // comments and declaring variables in the middle of a function or at the beginning of a for loop are forbidden (presumably for the benefit of old compilers), and typedef redefinitions are a gray area. What C compiler supports designated initializers but not // comments? Maybe Wine's rules about comments and variables are just for stylistic reasons and not compatibility. If that is the case, let's clearly explain it in the wiki. Let's also clearly explain what other language features are not allowed and why (such as duplicate typedef definitions because of GCC 4.3).
Sure, it would be great to have a list of language features and their status. I agree that the wiki sounds like the right place for it. Do you want to start working on this?
On Fri Jul 7 07:21:46 2023 +0000, Alexandre Julliard wrote:
Sure, it would be great to have a list of language features and their status. I agree that the wiki sounds like the right place for it. Do you want to start working on this?
Sure, I would be happy to update the wiki. What is the status of the language features I mentioned and why?
On Fri Jul 7 16:08:21 2023 +0000, Alex Henrie wrote:
Sure, I would be happy to update the wiki. What is the status of the language features I mentioned and why?
Great! Please start by building a list of all the features that would be interesting to know about, and we can then fill in the status.
The why is usually "because someone reported breakage". You could make it point to the corresponding bug report if you can find it.
On Fri Jul 7 16:56:13 2023 +0000, Alexandre Julliard wrote:
Great! Please start by building a list of all the features that would be interesting to know about, and we can then fill in the status. The why is usually "because someone reported breakage". You could make it point to the corresponding bug report if you can find it.
Just to help out a bit, here's some things I'm aware of:
* MSVC used to break on designated initializers, although newer versions don't, and patches using them have basically been committed since that fact was pointed out: https://www.winehq.org/mailman3/hyperkitty/list/wine-devel@winehq.org/messag...
* gcc 4.3.4 allows nameless unions, but can't parse them in designated initializers: https://bugs.winehq.org/show_bug.cgi?id=50378
* I was able to find a mention of very old versions of GCC that don't support nameless unions: https://www.winehq.org/mailman3/hyperkitty/list/wine-devel@winehq.org/messag...
* For 0-length array members, I found this: https://www.winehq.org/mailman3/hyperkitty/list/wine-devel@winehq.org/messag...
* I do not know of any compiler that forbids C++ comments. Granted, I haven't been contributing to Wine for nearly long enough to be aware of these things, but I've only seen them mentioned under vague terms like "we don't use them in Wine". Even if there isn't a compiler that cares, it's not clear to me whether they're proscribed because of taste (I think I've seen some subsystem maintainers express that, but I can't remember where), or if they'd be perfectly acceptable if anyone cared to use them.
Alexandre, I think this is one of the points Alex is confused about, and is trying to ask for a ruling on. If you feel that this is too minor an issue to give a formal ruling on, fine, I'd just like to make that clarification lest anyone else get too much more frustrated.
* Declaration-after-statement falls into pretty much the same category. We specifically have a warning on for this, so it's pretty clearly proscribed, but I'm not sure if it's done for compatibility reasons or aesthetic ones (again, I've seen some people express a strong aesthetic preference for this, and I'm inclined to agree—if only because I've become used to looking towards the top of a block for declarations). The warning was added back in 2005 (f8cb48b515), but I wasn't able to easily find any inciting incidents.
* Initial declarations in 'for' loops are a special case of the above. We used to regularly get bug reports for this (e.g. https://bugs.winehq.org/show_bug.cgi?id=47262) but I think that may just be because old versions of gcc defaulted to -std=c89, and are actually fine with it as long as we set -std=c99, which we do since 0aa31b735cc. Despite disliking declaration-after-statement in the general case, I'm actually inclined to think that declarations in for loops are desirable—that helps the programmer ensure they don't accidentally use a loop iterator outside of the loop's scope. Others might disagree, though; I'm not sure whether I've heard an opinion on the aesthetics of this one.
* I don't think I've seen typedef redefinitions come up before.
I do not know of any compiler that forbids C++ comments. Granted, I haven't been contributing to Wine for nearly long enough to be aware of these things, but I've only seen them mentioned under vague terms like "we don't use them in Wine". Even if there isn't a compiler that cares, it's not clear to me whether they're proscribed because of taste (I think I've seen some subsystem maintainers express that, but I can't remember where), or if they'd be perfectly acceptable if anyone cared to use them.
Alexandre, I think this is one of the points Alex is confused about, and is trying to ask for a ruling on. If you feel that this is too minor an issue to give a formal ruling on, fine, I'd just like to make that clarification lest anyone else get too much more frustrated.
C++ comments used to be an issue with some compilers a long time ago, but nowadays it's mostly tradition, and individual taste. Personally I'd rather avoid them, but if some maintainers want to allow them for their subsystems I wouldn't object.
I decided to give up on this and focus my time on more important things. All in all, gcc 4.3 support is quite a mess that I don't want to work on anymore.
This merge request was closed by Fabian Maurer.
-
Alex Henrie (＠alexhenrie) -
Alexandre Julliard (＠julliard)
-
Fabian Maurer
-
Fabian Maurer (＠DarkShadow44)
-
Jacek Caban (＠jacek)
-
Zebediah Figura (＠zfigura)