On 11/11/2012 03:05 PM, Michael Stefaniuc wrote:
> On 11/11/2012 07:12 AM, Max TenEyck Woodbury wrote:
>> On 11/11/2012 01:01 AM, Nikolay Sivov wrote:
>>> On 11/11/2012 05:00, Max TenEyck Woodbury wrote:
I mentioned this a few days ago. It would have helped if you had
raised this point t
On 11/11/2012 07:12 AM, Max TenEyck Woodbury wrote:
> On 11/11/2012 01:01 AM, Nikolay Sivov wrote:
>> On 11/11/2012 05:00, Max TenEyck Woodbury wrote:
>>> I mentioned this a few days ago. It would have helped if you had
>>> raised this point then.
>>>
>>> As it stands, it is simply a way to adding
On 11/11/2012 03:00 AM, Max TenEyck Woodbury wrote:
> I mentioned this a few days ago. It would have helped if you had
> raised this point then.
I tried, but your email made no sense. You didn't even mention that
you're talking about COM interfaces.
> As it stands, it is simply a way to adding da
On 11/11/2012 01:01 AM, Nikolay Sivov wrote:
> On 11/11/2012 05:00, Max TenEyck Woodbury wrote:
>> I mentioned this a few days ago. It would have helped if you had
>> raised this point then.
>>
>> As it stands, it is simply a way to adding data members to an aggregate
>> with an interface.
>
> Dat
On 11/11/2012 05:00, Max TenEyck Woodbury wrote:
I mentioned this a few days ago. It would have helped if you had
raised this point then.
As it stands, it is simply a way to adding data members to an aggregate
with an interface.
Data members to an aggregate? What are you talking about and what
I mentioned this a few days ago. It would have helped if you had
raised this point then.
As it stands, it is simply a way to adding data members to an aggregate
with an interface. In that sense it is not an addition to the
interface since the Vtbl pointer remains exactly as before. The new
info
You can't do that as the COM standard specifies also the ABI.
A COM interface is a pointer to a virtual table; it is *not* a struct.
That's just an implementation detail in C.
On 11/10/2012 08:48 PM, m...@mtew.isa-geek.net wrote:
> From: Max TenEyck Woodbury
>
> ---
>
On 11/10/2012 22:48, m...@mtew.isa-geek.net wrote:
From: Max TenEyck Woodbury
---
tools/widl/header.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/tools/widl/header.c b/tools/widl/header.c
index 2f275c7..965dcbc 100644
--- a/tools/widl/header.c
2009/12/24 Gerald Pfeifer :
> On Mon, 21 Dec 2009, Henri Verbeet wrote:
>>> How shall we best tackle this?
>> At least for the wined3d ones, we might as well just add them to the
>> enum, the macros aren't strictly necessary.
>
> Done thusly. We just need to move WINEMAKEFOURCC to a local header,
2009/12/21 Gerald Pfeifer :
> How shall we best tackle this?
>
At least for the wined3d ones, we might as well just add them to the
enum, the macros aren't strictly necessary.
feedback you provided, and than show
why I started down this road.
On Thu, 2 Jul 2009, Rob Shearman wrote:
> 2009/6/28 Gerald Pfeifer :
>> diff --git a/tools/widl/parser.y b/tools/widl/parser.y
>> index c2f1abc..01aa060 100644
>> --- a/tools/widl/parser.y
>> +++ b/tools/
Huw Davies writes:
> @@ -280,9 +282,10 @@ unsigned char get_struct_fc(const type_t *type)
> if (get_enum_fc(t) == RPC_FC_ENUM16)
> return RPC_FC_BOGUS_STRUCT;
> break;
> -case TGT_POINTER:
> case TGT_ARRAY:
> -if (get_pointer_fc(t, field->attrs, FAL
2009/6/28 Gerald Pfeifer :
> diff --git a/tools/widl/parser.y b/tools/widl/parser.y
> index c2f1abc..01aa060 100644
> --- a/tools/widl/parser.y
> +++ b/tools/widl/parser.y
> @@ -622,56 +633,54 @@ m_expr: { $$
> = make_expr(EXPR_VOID);
On Fri, 2 May 2008, Robert Shearman wrote:
>> It turns out that current versions of bison do not enforce the documented
>> grammer as strictly as older ones such as bison 1.75. Fixed thusly.
> Oops, thanks for spotting it. Actually, I was developing on version 1.28
> and didn't get those errors so
r as strictly as older ones such as bison 1.75. Fixed thusly.
Gerald
ChangeLog:
Fix syntax to also work with older versions of bison.
Index: tools/widl/parser.y
===
RCS file: /home/wine/wine/tools/widl/parser.y,v
retrieving revision 1.
> gmake: *** [parser.tab.h] Error 1
>
> It turns out that current versions of bison do not enforce the documented
> grammer as strictly as older ones such as bison 1.75. Fixed thusly.
>
Oops, thanks for spotting it. Actually, I was developing on version 1.28
and didn't get
On Mon, 29 Oct 2007, Dan Hipschman wrote:
> Compiling with "-O2 -W -Wall" using either gcc 4.0 or 3.4 I don't get
> any warnings. Even adding -Wuninitialized doesn't do anything:
I am mostly using GCC 3.4 with -O2 -Wall as you did, and occasionally
a snapshot of GCC 4.3, with and without -Wextra
On Sun, Oct 28, 2007 at 07:07:15PM -0700, Dan Kegel wrote:
> To get uninitialized warnings, you have to also specify
> optimization (-O2). Without -O, gcc doesn't
> do the analysis that can detect uninitialized variables.
Compiling with "-O2 -W -Wall" using either gcc 4.0 or 3.4 I don't get
any w
On Sun, 28 Oct 2007, Dan Hipschman wrote:
> The logic is as follows:
Thanks for the explanation, Dan!
> Better than this would be to put "assert(is_user_type(type));" above the
> initializations to convince the programmer at least that name will get
> initialized correctly in get_user_type. If
Dan H. wrote:
> If you tell me what options you build with and I can reproduce the
> warning then I'll be more than happy to try to fix it. I build widl
> with -W -Wall and get two warnings.
To get uninitialized warnings, you have to also specify
optimization (-O2). Without -O, gcc doesn't
do th
On Mon, Oct 29, 2007 at 01:26:45AM +0100, Gerald Pfeifer wrote:
> I think the question is whether a compiler can reasonably be expected
> to deduce that the source is fine. If that deduction involves solving
> the halting problem (or similar) hacking the source to avoid the warning
> actually does
On Sun, Oct 28, 2007 at 01:51:34PM +0100, Gerald Pfeifer wrote:
> In tools/widl/typegen.c we have the following snippet
>
> static void write_user_tfs(FILE *file, type_t *type, unsigned int *tafsoff)
> {
> unsigned int start, absoff, flags;
> unsigned int ali
"Ge van Geldorp" <[EMAIL PROTECTED]> writes:
> I'm wondering what happened to the reworked widl patch at
> http://www.winehq.org/hypermail/wine-patches/2005/04/0371.html? It hasn't
> been applied yet, does that mean there's no interest on the Wine side and I
> can drop it from my TODO list?
There
I'm wondering what happened to the reworked widl patch at
http://www.winehq.org/hypermail/wine-patches/2005/04/0371.html? It hasn't
been applied yet, does that mean there's no interest on the Wine side and I
can drop it from my TODO list?
Best regards, Ge van Geldorp.
"Ge van Geldorp" <[EMAIL PROTECTED]> writes:
> This is a big problem for me. Eric Kohl (not me) did a lot of work on WIDL
> in the ReactOS tree, there's about 20 patches to follow after this one. If
> this first patch is not acceptable and needs to be rewritten, it means I can
> no longer simply p
> From: Alexandre Julliard
>
> You should add some sort of get_fc_name() function instead of
> duplicating a big switch like that every time you want to
> print a name.
This is a big problem for me. Eric Kohl (not me) did a lot of work on WIDL
in the ReactOS tree, there's about 20 patches to fo
Ge van Geldorp <[EMAIL PROTECTED]> writes:
> +switch(var->type->type)
> +{
> +case RPC_FC_BYTE:
> +print_client("0x4e,/* FC_IN_PARAM_BASETYPE */\n");
> +print_client("0x%02x,/* FC_BYTE */\n", RPC_FC_BYT
The addition of tools/widl/write_msft.c added the following four warnings,
basically doubling the number of warnings we are getting with GCC 3.4.
write_msft.c:582: warning: `ctl2_alloc_importinfo' defined but not used
write_msft.c:620: warning: `ctl2_alloc_importfile' defined bu
28 matches
Mail list logo
