On Sat, Sep 29, 2012 at 3:40 AM, Marc Balmer <m...@msys.ch> wrote:
> Am 29.09.12 03:29, schrieb Jon Trulson:
>> On Fri, 28 Sep 2012, Marc Balmer wrote:
>>
>>> for patch 1: don't roll your own strfunctions, use strlcpy or so
>>
>> I'm inclined to apply this - strlcpy isn't available on all systems
>> (on linux, requires bsd lib I think). In addition, strlcpy also does
>> not permit overlapping buffers, based on a google search. Was
>> valgrind detecting overlapping buffers? Did it fix a problem?
Hi, yes, per the commit comment this fixes a valgrind message [these
buffers are also obviously overlapping, just look at the code]. Using the
"obvious" implementation of strcpy there are no issues with the code,
but by the standard it's not guaranteed [and apparently implementations
do in fact do strange clever things.]
>
> Well, linking with libbsd is no problem, it is available on all Linux
> distributions. An alternativ could be to include your own copy of the
> strlcpy function from e.g. OpenBSD, which is really small. I would opt
> for a solutions that used zillions of time over a hand-made kludge.
>
> Or, maybe try to fix the underlying problem, if there is one.
>
>>
>>> for patch 2: hunk 1 and 3 are not needed
>>>
>>>
>>
>> Yeah, not sure about this one either... Confused.
>>
>> Marc says 1 and 3 are not needed, but if you omit them, then 2 cannot
>> work otherwise. I wonder if this is the real problem? Is this on a
>> 64b machine? I wonder if this patch just moved the problem somewhere
>> else?
>>
>> Comments on either of these?
This is on a 64-bit machine. Opening the help window works fine the
first time [and
their are no valgrind messages], but after closing it and opening it
again the program
segfaults, and there are a lot of valgrind messages about using freed
memory. If you
don't close the help window, it works fine and sends the help window
back to the top.
I'd expect the same issue on a 32-bit machine, but if it isn't there
then we could
investigate further.
So this fix seemed to be the correct change, because it sends the code
back on the
"there is no help window path" which works correctly.
>
> Well, I was thinking that hunk 1 and 3 just move the definition of the
> static variable outside the functions, but don't change the type, so the
> important part was hunk 2, which set the variable to NULL.
>
> But I might be wrong, I did just a glimpse over the code as was in a
> hurry (a fact that was reflected in the brevity of my reply :)
Yes, so hunk 2 is in fact in a different function [a callback for when
the window
closes]. So that's why I moved the variable up in scope [no lambdas in C].
>
> What I wanted to say is:
>
> void
> foo()
> {
> static int bla;
> ...
> bla = NULL;
> }
>
> is equal to
>
> static int bla;
>
> void
> foo()
> {
> bla = NULL;
> }
>
> and btw, variables declared outside a function need not be initialized
> to zero or NULL, they already are.
>
>>
>>
>
------------------------------------------------------------------------------
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219672;13503038;z?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
