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.
Hi Rob, first of all sorry for the delay in getting back to this. I
kept looking for alternative approaches, but now ended up figuring that
really laying down the issue at hand I was trying to solve in front of
everyone a priori will be the better approach.
Let me first respond to concrete feedba
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); }
> | expr
>
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 align = 0, ualign = 0;
> c
"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
14 matches
Mail list logo
