Please forget this patch. It's superseded by another.
expected end of file) into a warning, which may be
> troublesome in general.
> I hope it doesn't break anything else...
I guess the safest way is to make it optional. As a result, the old
behavior will be kept for other users of wpp and only D3DCompiler will
be affected by this change.
Il 14 marzo 2012 23:02, Józef Kucia ha scritto:
> @@ -679,11 +649,23 @@ void pp_writestring(const char *format, ...)
> }
> }
> \\. add_string(ppy_text, ppy_leng);
> -\n {
> +\n {
> newline(1);
> add_string(ppy_text, ppy_le
.
This is patch is ugly. Just keeping the unused parameter warning is way
better. Code needs to be optimized for the human reader not perverted to
make a tool stfu.
bye
michael
> Or would you rather see a patch that remove WANT_NEAR_INDICATION
> altogether?
>
> Gerald
>
>
together?
Gerald
diff --git a/libs/wpp/preproc.c b/libs/wpp/preproc.c
index 99934d6..996c0f8 100644
--- a/libs/wpp/preproc.c
+++ b/libs/wpp/preproc.c
@@ -684,7 +684,11 @@ int pp_get_if_depth(void)
/* #define WANT_NEAR_INDICATION */
-static void generic_msg(const char *s, const char *t, const
Gerald Pfeifer writes:
> I sent basically this in February without any feedback, and it still
> applies.
It's still wrong, the parameter is used inside the #ifdef.
--
Alexandre Julliard
julli...@winehq.org
On Mon, Jul 26, 2010 at 12:38 PM, Travis Athougies wrote:
> Resending patch with proper line wrapping
You forgot the patch :-).
--
-Austin
Hi,
Your Patch got wrapped. Try change some settings in you Mailclient please and
resubmit.
Thx
--
Best Regards, André Hentschel
gt; --
> Alexandre Julliard
> julli...@winehq.org
>
Which is the best way to notify the condition? ppy_error and
ppy_warning don't seem to be applicable here either, debug channels
aren't used in wpp. Is it ok to simply keep the fprintf?
Matteo Bruni writes:
> From 79aebdb612334b9816375abce58c65b90130732a Mon Sep 17 00:00:00 2001
> From: Matteo Bruni
> Date: Tue, 29 Sep 2009 12:10:24 +0200
> Subject: wpp: Remove the assumption pp_internal_error calls exit()
Actually it's OK for it to exit(), though assert()
Matteo Bruni writes:
> @@ -82,8 +82,7 @@ void *pp_xmalloc(size_t size)
> res = malloc(size);
> if(res == NULL)
> {
> -fprintf(stderr, "Virtual memory exhausted.\n");
> -exit(2);
> +pp_internal_error(__FILE__, __LINE__, "Virtual memory exhausted.\n");
>
2009/8/17 Juan Lang :
> Hi Matteo,
>
> this approach seems pretty inflexible to me:
>
> +/* Whether to exit the app on errors (default: true) */
> +extern void wpp_set_exit_on_error( int exit );
>
> @@ -646,7 +654,8 @@ int ppy_error(const char *s, ...)
> va_start(ap, s);
> generic_msg
Hi Matteo,
this approach seems pretty inflexible to me:
+/* Whether to exit the app on errors (default: true) */
+extern void wpp_set_exit_on_error( int exit );
@@ -646,7 +654,8 @@ int ppy_error(const char *s, ...)
va_start(ap, s);
generic_msg(s, "Error", ppy_text, ap);
v
Hi Juan,
these I/O hooks are needed to use wpp as a preprocessor for d3d shader
assembling, where I have to read files with CreateFile/ReadFile
(Windows-style) or from memory. I plan to send the assembler patches
not immediately (in particular, the patch which makes use of wpp is
not so near). On
Hi Matteo,
it'd be easier to review your patch if you sent it along with a
subsequent patch that made use of the I/O hooks. As it is, it's hard
to know why this is necessary.
Cheers,
--Juan
"Rob Shearman" <[EMAIL PROTECTED]> writes:
> diff --git a/libs/wpp/ppl.l b/libs/wpp/ppl.l
> index 3e84a2e..829ac35 100644
> --- a/libs/wpp/ppl.l
> +++ b/libs/wpp/ppl.l
> @@ -163,6 +163,9 @@ ul
> [uUlL]|[uUlL][lL]|[lL][uU]|[lL][lL][uU]|[uU][lL][lL]|[lL
Gerald Pfeifer <[EMAIL PROTECTED]> writes:
> In ISO C, operations involving both signed and unsigned types are
> using signed. If the case of ui = ui OP si is really ment to make
> use of this (despite the result being stored in an unsigned type),
> we'd need to handle this via two casts, but I
(cpy);
> #endif
> + }
> fprintf(stderr, "\n");
> }
>
Related, although not really a great solution:
http://www.winehq.org/pipermail/wine-cvs/2006-September/026094.html
I forget, are the extra "near" messages actually helpful, or misleading?
In any case, whatever ends up happening here should probably also happen
in widl, since it uses wpp and consistent warning/error messages are
nice.
Robert Shearman <[EMAIL PROTECTED]> writes:
> I disagree. I had a resource file that had an error because I forgot
> to define "IDC_STATIC" to a number and all I got from wrc was an
> unhelpful "syntax error" that seemed to point to the wrong line. I
> ended up using the debugging option to find o
wpp will currently silently drop non-preprocessor stuff (typedefs, function
prototypes etc.) when #including a .c or .h file. However, if you preprocess
e.g. a .rc file externally and then feed it to wrc (which in turn will feed
it through wpp) the non-preprocessor stuff isn't removed. The
Am Donnerstag, 6. Januar 2005 18:49 schrieb Jacek Caban:
> Stefan Leichter wrote:
> >Hello,
> >
> >here is a another backtrace of widl with libefence. The crash is from
> >wine-20041227-1114. The patch applied to wine before this snapshot raises
> > the problem. The patch was:
> >
> >Modified files
AIL PROTECTED]>
Generate only wanted files.
Patch: http://cvs.winehq.org/patch.py?id=15042
Bye
Stefan
I think I found the bug. Could you try the attached patch?
Thanks,
Jacek
Index: libs/wpp/wpp.c
===
RCS file: /home/win
from /lib/i686/libc.so.6
#6 0x0805e880 in version_string ()
#7 0x0001 in ?? ()
#8 0xbfffef80 in ?? ()
#9
#10 0x400a6243 in strlen () from /lib/i686/libc.so.6
#11 0x08052641 in pp_xstrdup (str=0x4022bfe0 "../../wipe/include/basetô_/@ø\177\037@" )
at ../../../wipe/libs/wpp/preproc.
Alexandre Julliard wrote:
Jacek Caban <[EMAIL PROTECTED]> writes:
--- libs/wpp/ppy.y 1 May 2003 03:16:21 - 1.1
+++ libs/wpp/ppy.y 30 Dec 2004 10:11:39 -
@@ -537,7 +537,10 @@ static int boolean(cval_t *v)
static marg_t *new_marg(char *str, def_arg_t type)
{
marg_t *ma = pp_x
Jacek Caban <[EMAIL PROTECTED]> writes:
> --- libs/wpp/ppy.y1 May 2003 03:16:21 - 1.1
> +++ libs/wpp/ppy.y30 Dec 2004 10:11:39 -
> @@ -537,7 +537,10 @@ static int boolean(cval_t *v)
> static marg_t *new_marg(char *str, def_arg_t type)
> {
>
25 matches
Mail list logo
