Can we do something like throw up a message box before loading the
debugger,
asking if we want to debug? Or perhaps there should be a command-line
option to
the debugger that presents said dialog, then use that option when
starting the
debugger in the event of an crash.
RTFM
hints: AeDebug,
On Tuesday 10 December 2002 01:10 am, Jeff Smith wrote:
Can we do something like throw up a message box before loading the
debugger, asking if we want to debug? Or perhaps there should be a
command-line option to
the debugger that presents said dialog, then use that option when
starting the
You caught me... I thought something like this existed.
I would say that by default, Auto should be 0.
I think this would be best for the average user.
They are probably even less likely than me to read the
debugging documentation (and want to change a registry
setting like this).
-- Jeff S
Dimitrie O. Paun wrote:
On December 5, 2002 11:16 am, Alexandre Julliard wrote:
It's the kind of thinking that leads to having an exception
handler inside strlen() like Windows does. It's just plain wrong.
nod/. This is generally true for other things as well:
1. Many places in
On Tue, 3 Dec 2002, Michal Janusz Miroslaw wrote:
[...]
Since we are talking about catenating strings only (no %d and family),
then I would suggest combining speed of cpycat (in glibc there's stpcpy)
and ease of use of sprintf and use something like that:
[...]
Then we could write:
On 2 Dec 2002, Morten Welinder wrote:
[...]
Unless we're talking an inner and very intensive loop, all this is a
bit silly.
However, assuming that it does make sense, sprintf variants are not
part of the answer. They're interpreted and var-arg type
Why would vararg be a problem
On Mon, 9 Dec 2002 [EMAIL PROTECTED] wrote:
[...]
Being too free with let the code crash is a bad idea. Microsoft got a lot
of really bad heckling in the Windows 3.1 era for GPFs. Wine doesn't want to
crash if it's reasonably harmless to continue (like for a failed screen
update). Does want to
Francois Gouget wrote:
Of course, that implies that we should promptly fix any such crash.
Otherwise it just makes Wine unusable without any benefit.
That's the catch. I'm not approaching Wine as a Wine developer. Wine is almost ready
for
prime time now and as a non-Wine developer (who's
On Mon, 9 Dec 2002 [EMAIL PROTECTED] wrote:
Francois Gouget wrote:
Of course, that implies that we should promptly fix any such crash.
Otherwise it just makes Wine unusable without any benefit.
That's the catch. I'm not approaching Wine as a Wine developer. Wine is almost ready
for
On December 9, 2002 05:29 pm, [EMAIL PROTECTED] wrote:
Do you agree with the way I've explained how I see the difference between
redundant defensive programming and detecting and reporting problems which
need to be fixed? If not, where do you differ and why?
Let me try to explain a bit more
From: [EMAIL PROTECTED]
Francois Gouget wrote:
Of course, that implies that we should promptly fix any such crash.
Otherwise it just makes Wine unusable without any benefit.
That's the catch. I'm not approaching Wine as a Wine developer. Wine is
almost ready for
prime time now and as a
On Mon, 2 Dec 2002, Francois Gouget wrote:
Other observations:
* my naive strcpy/strcat implementation seems more efficient than the
one in the glibc! That's pretty weird.
If you have glibc from binary package compiled with optimizations for
other processor that you have, it is possible.
*
Unless we're talking an inner and very intensive loop, all this is a
bit silly.
However, assuming that it does make sense, sprintf variants are not
part of the answer. They're interpreted and var-arg type, both of
which are little good for efficiency. More like something along
these lines:
On December 5, 2002 11:16 am, Alexandre Julliard wrote:
It's the kind of thinking that leads to having an exception
handler inside strlen() like Windows does. It's just plain wrong.
nod/. This is generally true for other things as well:
1. Many places in our code where we have invariant
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On
Behalf Of Alexandre Julliard
Sent: Monday, December 02, 2002 9:03 AM
To: Shachar Shemesh
Cc: David Laight; David Fraser; Shachar Shemesh; Francois Gouget;
[EMAIL PROTECTED]
Subject: Re: strcat+strcat+strcat
Am Mon, 2002-12-02 um 20.15 schrieb David Laight:
Actually I don't have glibc - I'm running netbsd not linux.
Netbsd might benefit from faster strxxx routines.
Can't you use an optimized glibc on NetBSD?
OTOH the times are very dependant on the cpu model!
My slotA athlon 700 executes my
With gcc 3.2? That compiler optimizes the jmp away in an if statement,
apparently assuming that the if clause is executed much more often.
The else clause, OTOH, jmp's to the end of the subroutine and jumps
back afterwards. Thus if the compiler guesses wrongly, the CPU'll have
to do two more
probably that
you were underestimating the time required to parse the format string,
which is probably greater than anything else. Everything else is simple
searching and copying whereas the parsing is probably at least a
quadratic-order function.
No it will be linear (on the length of the
With higher O values, the difference becomes bigger, but I'm not sure
then that some of the operations are not optimized out of the process,
which makes the entire benchmark useless.
I don't think they would be, and it is easy enough to check
(objdump -d way1). Benchmarking is meaningless
I suggest implementing strlcat and strlcpy, as in OpenBSD. I can write
them, but I'm not sure where to place them. They should either be
inlined (as in - implemented in an include file as a static func), or in
some library that will be linked (statically, I hope). Ideas?
Inlining them
On Mon, 2 Dec 2002, Shachar Shemesh wrote:
When I'm wrong, I'm wrong.
sun@sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way1 -DWAY1
sun@sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way2 -DWAY2
sun@sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way3 -DWAY3
sun@sun:~/sources/wine/test$ ./way1
David Laight wrote:
Inlining them would (probably) be bad news. They are not
a completely trivial size (ie smaller than the call sequence)
and they are more likely to be resident in the Icache if they
are functions.
Yes, but they are much more likely to fit into the function scope
David Laight wrote:
probably that
you were underestimating the time required to parse the format string,
which is probably greater than anything else. Everything else is simple
searching and copying whereas the parsing is probably at least a
quadratic-order function.
No it will be linear
I suggest implementing strlcat and strlcpy, as in OpenBSD. I
can write
them, but I'm not sure where to place them. They should either be
inlined (as in - implemented in an include file as a static
func), or in
some library that will be linked (statically, I hope). Ideas?
Since the do
optimizations: -O2
strcpy/cat sprintf snprintf str_add stpcpy
2.926220 1.427674 1.408928 3.405458 0.892890 1000
2.622081 1.308464 1.292384 3.062085 0.867009 900
2.363464 1.169335 1.152487 2.727685 0.740690 800
Shachar Shemesh [EMAIL PROTECTED] writes:
I suggest implementing strlcat and strlcpy, as in OpenBSD. I can write
them, but I'm not sure where to place them. They should either be
inlined (as in - implemented in an include file as a static func), or
in some library that will be linked
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On
Behalf Of Alexandre Julliard
Sent: Monday, December 02, 2002 9:03 AM
To: Shachar Shemesh
Cc: David Laight; David Fraser; Shachar Shemesh; Francois Gouget;
[EMAIL PROTECTED]
Subject: Re: strcat+strcat+strcat
And in any case the right approach to writing
correct and secure code is not to truncate every string in sight to
some fixed buffer size; it's to make sure you allocate buffers of the
right size, and then you can use standard strcpy/strcat/sprintf/etc.
without worrying about lengths.
Am Son, 2002-12-01 um 23.07 schrieb Shachar Shemesh:
When I'm wrong, I'm wrong.
sun@sun:~/sources/wine/test$ ./way1
Operation took 0 seconds 450763 usec
sun@sun:~/sources/wine/test$ ./way2
Operation took 0 seconds 598408 usec
sun@sun:~/sources/wine/test$ ./way3
Operation took 0 seconds
Am Mon, 2002-12-02 um 13.57 schrieb David Laight:
It is as if the code from your program is executing far
slower than anything from libc!
That is very well possible if he has the right libc. Take a look at the
optimizations in the string functions in glibc, and you'll have an idea
why. Unless
David Laight [EMAIL PROTECTED] writes:
Yes, but even then strcpy may not be safe! Another thread could change
the length after you've counted it.
Please, this is silly. If another thread is changing the string, all
string functions will break, strlcpy is not magically safer than
strcpy.
--
It is as if the code from your program is executing far
slower than anything from libc!
That is very well possible if he has the right libc. Take a look at the
optimizations in the string functions in glibc, and you'll have an idea
why. Unless you are a assembler programming Guru for a
On 30 Nov 2002, Alexandre Julliard wrote:
Francois Gouget [EMAIL PROTECTED] writes:
I don't like pieces of code that go:
strcpy(foo, bar1);
strcat(foo, bar2);
strcat(foo, bar3);
strcat(foo, bar4);
strcat(foo, bar5);
strcat(foo, bar6);
It's really inefficient: the
Attached the source of my benchmark program in case anyone wants to
have a look at it.
--
Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/
We are Pentium of Borg. You will be approximated. Division is futile.
#include stdio.h
#include stdlib.h
#include sys/time.h
Other observations:
* my naive strcpy/strcat implementation seems more efficient than the
one in the glibc! That's pretty weird.
Probably because the glibc routines are heavily optimised for long
strings. I did a load of experiments with different versions of
memcpy, the instruction setup
Alexandre Julliard wrote:
Francois Gouget [EMAIL PROTECTED] writes:
Well, no, the cost is linear. It would only be quadratic if the number
of strcat calls depended on the length of the string.
Well - still snprintf is more efficient.
It's more efficient to do:
sprintf(foo,
Shachar Shemesh [EMAIL PROTECTED] writes:
Well - still snprintf is more efficient.
I don't think so, but feel free to provide benchmarks.
But there is also no reason not to welcome these submissions if
someone already took the time to submit them.
There's no objective reason why sprintf is
Alexandre Julliard wrote:
Shachar Shemesh [EMAIL PROTECTED] writes:
Well - still snprintf is more efficient.
I don't think so, but feel free to provide benchmarks.
Benchmark will follow soon. In the mean time, think about the fact that,
compared to linear copying of the strings in,
I said that due to the wall to wall agreement over the superiority of
sprintf/snprintf. If there is a consensus, we should stick to it.
But the performance of it will suck badly.
Something like:
char *
str_add(char *s, char *lim, const char *a)
{
int c;
do {
When I'm wrong, I'm wrong.
sun@sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way1 -DWAY1
sun@sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way2 -DWAY2
sun@sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way3 -DWAY3
sun@sun:~/sources/wine/test$ ./way1
Operation took 0 seconds 450763 usec
Shachar Shemesh wrote:
Benchmark will follow soon. In the mean time, think about the fact
that, compared to linear copying of the strings in, these are the
overheads (neglecting function call overhead, which is not neglectible
but is fair):
n - number of strings in the final string
m(i) -
Francois Gouget [EMAIL PROTECTED] writes:
I don't like pieces of code that go:
strcpy(foo, bar1);
strcat(foo, bar2);
strcat(foo, bar3);
strcat(foo, bar4);
strcat(foo, bar5);
strcat(foo, bar6);
It's really inefficient: the cost increases quadratically with the size
of the
On Sat, Nov 30, 2002 at 10:49:34AM -0800, Alexandre Julliard wrote:
It's more efficient to do:
sprintf(foo, %s%s%s%s%s%s, bar1,bar2,bar3,bar4,bar5,bar6);
In case you cannot be 100% sure of the lengths, it might still be worth it
with snprintf, but otherwise, it's a matter of taste.
It's really inefficient: the cost increases quadratically with the size
of the resulting string.
Well, no, the cost is linear. It would only be quadratic if the number
of strcat calls depended on the length of the string.
It's more efficient to do:
sprintf(foo, %s%s%s%s%s%s,
44 matches
Mail list logo
