Re: [Gimp-developer] Testing on NULL an unitialized values
A couple of very small coins.
On Thu, Apr 22, 2010 at 06:55, Martin Nordholts ense...@gmail.com wrote:
On 04/22/2010 03:54 AM, Marc Lehmann wrote:
On Wed, Apr 21, 2010 at 08:14:33PM +0200, Martin
Nordholtsense...@gmail.com wrote:
The compiler doesn't catch all cases, like this one:
#includestdio.h
int main(int argc, char **argv)
{
int var;
if (argc == 2)
var = 42;
printf (var = %d, var);
return 0;
}
1. initialising var will not fix the bug, if there is any.
It won't, but it will make the bug consistently occur, which is a big plus.
2. initialising var will prevent other static analysers
to diagnose a possible problem.
The problem to diagnose would be that of using an initialized variable,
no? The fix would then be to initialize the variable.
I think what he's trying to say here is that initializing it to 0 is
still uninitialized. Just deterministicly so. And no valgrind, or
static analyzers will notice that you're reading an uninitialized
zero. The fix would be to initialize the variable in all possible
execution paths, but not necessarily to 0.
3. initialising var will prevent weird effects
and just *might* decrease chances of finding the bug further.
Why would you want weird effects in software? That's exactly what you
don't want. At worst, a bug should manifest itself by making a program
not do what it was intended to do, not doing something unpredictable.
Undeterministic behavior will expose a bug, deterministic but slightly
wrong will probably hide it.
Since use of uninitlized variables very well can cause severe and
hard-to-reproduce crashes, and since unpredictability never is a good
Actually, it's easy to diagnose those bugs though, just look at the
coredump.
The coredump gives you the state of the program when it crashed, not the
cause leading up to the crash, which could have been an uninitlized
local variable that's no longer in any stack frame.
Yes, don't do it unnecessarily, it tends to hide bugs.
Rather As a rule of thumb, initialize local variables.. As always
there are cases where it's better not to initialize local variables.
The compiler is actually smart enough to give you a warning might be
used uninitialized, always initializing to something will hide that
warning. And you'll use your uninitialized value (which will always be
zero, or whatever) unaware of that it's not sensibly initialized.
Fredrik.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Testing on NULL an unitialized values
Zitat von Fredrik Alströmer r...@excu.se:
A couple of very small coins.
On Thu, Apr 22, 2010 at 06:55, Martin Nordholts ense...@gmail.com wrote:
On 04/22/2010 03:54 AM, Marc Lehmann wrote:
On Wed, Apr 21, 2010 at 08:14:33PM +0200, Martin
Nordholtsense...@gmail.com wrote:
The compiler doesn't catch all cases, like this one:
#includestdio.h
int main(int argc, char **argv)
{
int var;
if (argc == 2)
var = 42;
printf (var = %d, var);
return 0;
}
1. initialising var will not fix the bug, if there is any.
It won't, but it will make the bug consistently occur, which is a big plus.
2. initialising var will prevent other static analysers
to diagnose a possible problem.
The problem to diagnose would be that of using an initialized variable,
no? The fix would then be to initialize the variable.
I think what he's trying to say here is that initializing it to 0 is
still uninitialized. Just deterministicly so.
That's rhetoric saying.
And no valgrind, or
static analyzers will notice that you're reading an uninitialized
zero.
No problem.
You have that defined value, and with each run it gives you the same value.
That mean: the bug is not fixed, but can be recreated with every run.
This is: you can track it down, because it always gives you the same bevaiour.
In this case: the value seems not to be changes... a good start: you
know what to look for.
And if the bug is, that the value will be changed intermeidately,
then it's also easier to track this, becaue something that is not 0,
as it definitely has to be is easier to detect as something that can
range the whole range of possibilities that the variable can hold, to
compare with any other value.
For example: you set it to zero, know that no function should work on it,
an it changes nevertheless. If it starts with any value have fun
with debuggin ;-)
It's always god to know, from where to start.
Languages like OCaml for example have never undefined values.
If you create something, it has a value.
That's fun.
The fix would be to initialize the variable in all possible
execution paths, but not necessarily to 0.
Can you explain that?
Why should every initialization would make sense?
You first set it to 0 (or NULL when it's a pointer),
and rightly afterwards you set the right value.
So in the case of a correct code, you get your initialisation,
which yoh want to have it.
If it's a value that is definitley always !0, but fixed
(constant start value) than setting to THAT value is OK too.
But then it's best doing it at definition time, not one or many lines later.
And it's also good, not to hard code that fixed starting point there,
but use #define.
If you have a fixed starting point, that's good in debugging.
If you later remove your init, or if the function, that makes the init,
makes nonsense, you at least can detect the difference.
difference = A - B
If one of A and B is fixed, you can find the difference.
If both are undetermeined, happy debugging. ;-)
Bugs that are untrackable, are untrackable because of those problems.
If for example the x-mouse-value is always 0, even when you move it,
you know what's wrong at the beginning of debugging. And you know what
to look for. And a constant 0 is easier to see than a constnat
something.
It's distinct and clear. No need to look up manpages or science books.
You know there is always 0 or NULL. Fine, if that's wrong. :)
3. initialising var will prevent weird effects
and just *might* decrease chances of finding the bug further.
Why would you want weird effects in software? That's exactly what you
don't want. At worst, a bug should manifest itself by making a program
not do what it was intended to do, not doing something unpredictable.
Undeterministic behavior will expose a bug, deterministic but slightly
wrong will probably hide it.
Heheh. funny.
Deterministic behaviour will also expose a bug: it will show you
always the same wrong result.
Always the same wrong result is easier to track down than always a
behaviour that is different. And it's even more complicated, if it has
to be different every time. You have to compare all possible values
that should occure with all possible values that do occur.
See the difference-example above
In other words:
error = actual_value - wanted_value
If you know math, you know how to find the problem.
Since use of uninitlized variables very well can cause severe and
hard-to-reproduce crashes, and since unpredictability never is a good
Actually, it's easy to diagnose those bugs though, just look at the
coredump.
The coredump gives you the state of the program when it crashed, not the
cause leading up to the crash, which could have been an uninitlized
local variable that's no longer in any stack frame.
Yes, don't do it unnecessarily, it tends to hide bugs.
Rather As a rule of thumb, initialize local variables.. As always
there are cases where
Re: [Gimp-developer] Testing on NULL an unitialized values
On Thu, Apr 22, 2010 at 14:00, Oliver Bandel oli...@first.in-berlin.de wrote: Zitat von Fredrik Alströmer r...@excu.se: And no valgrind, or static analyzers will notice that you're reading an uninitialized zero. No problem. You have that defined value, and with each run it gives you the same value. That mean: the bug is not fixed, but can be recreated with every run. This is: you can track it down, because it always gives you the same bevaiour. In this case: the value seems not to be changes... a good start: you know what to look for. Let's say you pass that value down the stack, 0 IS a valid value for this particular algorithm, and will produce results which are similar, but not identical, to a non-zero value. If there are many factors which might distort the result, you'd have no idea where to start looking. If you DIDN'T initialize your variable, valgrind would tell you that the algorithm is reading uninitialized memory, and it'd also tell you which one. -snip- Languages like OCaml for example have never undefined values. If you create something, it has a value. That's fun. Right, so does Java, yet still they're uninitialized and produce a warning (or error actually, in some cases), if you use it. The fix would be to initialize the variable in all possible execution paths, but not necessarily to 0. Can you explain that? Well, if you end up with an uninitialized variable, there's an execution path which CAN reach that state, and chances are, you didn't think of it. And IN that case the variable needs to be initialized, but to what depends on the case (the one you forgot about). Why should every initialization would make sense? You first set it to 0 (or NULL when it's a pointer), and rightly afterwards you set the right value. So in the case of a correct code, you get your initialisation, which yoh want to have it. This is just... weird, if you initialize it directly, why bloat the code? If it's a value that is definitley always !0, but fixed (constant start value) than setting to THAT value is OK too. But then it's best doing it at definition time, not one or many lines later. And it's also good, not to hard code that fixed starting point there, but use #define. If you have a fixed starting point, that's good in debugging. If you later remove your init, or if the function, that makes the init, makes nonsense, you at least can detect the difference. difference = A - B If one of A and B is fixed, you can find the difference. If both are undetermeined, happy debugging. ;-) Bugs that are untrackable, are untrackable because of those problems. You've never used tools like static analyzers and valgrind, right? Bugs that are untrackable are usually not of this kind, rather pertaining to race conditions or intricate semantic problems. -- snip -- 3. initialising var will prevent weird effects and just *might* decrease chances of finding the bug further. Why would you want weird effects in software? That's exactly what you don't want. At worst, a bug should manifest itself by making a program not do what it was intended to do, not doing something unpredictable. Undeterministic behavior will expose a bug, deterministic but slightly wrong will probably hide it. Heheh. funny. Careful. Deterministic behaviour will also expose a bug: it will show you always the same wrong result. Always the same wrong result is easier to track down than always a behaviour that is different. And it's even more complicated, if it has to be different every time. You have to compare all possible values that should occure with all possible values that do occur. See the difference-example above In other words: error = actual_value - wanted_value If you know math, you know how to find the problem. This is true for obvious bugs. For not so obvious ones, where 0 IS a valid value, and SHOULD be 0 most of the time, you will NOT spot the error until someone hits that corner case where it shouldn't be. -- snip -- The compiler is actually smart enough to give you a warning might be used uninitialized, always initializing to something will hide that warning. And you'll use your uninitialized value (which will always be zero, or whatever) unaware of that it's not sensibly initialized. You don't need that warning anymore. They were invented for languages that allow undefined values, and prohgrammers that leave them undefined (mostly by accident). This is simply wrong. It's a rather naive to set uninitialized = undefined, as I've tried to explain above. As I also said, Java will also give you an error in this case even though it's still well defined. Using something uninitialized (defined or not) suggests you've forgotten an execution path, and your code is semantically wrong. You definitley know that there is one certain start value. But which value is it have? Is it always the same? And the same on all computers. If there was a way to define a
[Gimp-developer] Success-return-value
Hello, is there a convention for return values in Gimp, which says: on success return TRUE or a value, and on fauilure FALSE or NULL? Or can it be different at different sources, rather be a taste of the one who developped something? Ciao, oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Testing on NULL an unitialized values
On Wed, 2010-04-21 at 18:30 +0200, Martin Nordholts wrote: On 04/21/2010 01:58 PM, Oliver Bandel wrote: Even only temporarily valies, if set to a certain value, like 0 or NULL, will help in finding problems. I agree, and I try to initialize all local variables that I either add or modify the declaration of. I don't think it would be worth to commit a patch that initializes all variables though because it would break git blame. I don't think the git history of a file is a reason that should keep anyone from committing code cleanups. The question is rather if this particular cleanup is worth the hassle and if it would really result in an improvement when it comes to readability and maintainability of the code-base. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Testing on NULL an unitialized values
Hi, On Thu, 2010-04-22 at 14:38 +0200, Fredrik Alströmer wrote: For the record, I'm not necessarily against setting a predefined value to variables sometimes. I'm just against doing it for the wrong reasons, and I'd much rather have the compiler say Warning: might be used uninitialized in this context as a part of the static analysis, rather than chase down the bug where a value is 0 at run time (remember, I'm primarily talking corner cases here). Totally agreed. I also prefer the compiler telling me that a refactoring I've just done is not correct because I forgot to initialize a variable in a code path. This has happened to me and the compiler warning caught some potential bugs. If we would always initialize all variables this mistake would have gone unnoticed. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Success-return-value
On Thu, 2010-04-22 at 15:46 +0200, Oliver Bandel wrote: is there a convention for return values in Gimp, which says: on success return TRUE or a value, and on failure FALSE or NULL? That is the convention, yes. Or can it be different at different sources, rather be a taste of the one who developed something? Well, there is lots of plug-in code that follows different coding styles and conventions. We apply the GIMP coding style on all new files, but there is still cruft in some corners of the code-base that has not been cleaned up yet. So you might find code that uses a different convention for return values. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Trying to Make a Plug-In
Hey guys, I have very limited experience in programming, and none at all with making plugins, but I want to make a plugin that would make my life a whole lot easier. Unfortunately, it seems that all the information regarding this process is written for people who are experienced in programming or writing plugins or such, and is unintelligible to me. If someone would be willing to take pity on me and help walk me through the basics, that would be a huge help. I'm work on Mac OS 10.5, which is making the problem even worse because there's next to no information out there for coding, for Gimp, on Mac. My first question would be, what language should I be using and how do I set it up so that it will work. Thank you so much~! -- Callie (via www.gimpusers.com) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Trying to Make a Plug-In
On Thu, Apr 22, 2010 at 3:04 PM, Callie for...@gimpusers.com wrote: My first question would be, what language should I be using and how do I set it up so that it will work. I'd recommend python, as it is pretty easy to pick up even for the non-programmer. IIRC the OSX version of GIMP includes python support - you can check by selecting Filters-Python-Fu-Console. If that opens, you have python support. If so, place plugin (.py) files into [your home]/Library/Applications Support/Gimp/plug-ins (create directory if necessary). There's this article, which is a bit dated but still useful: http://www.gimp.org/docs/python/index.html Then you might check out the plug-in registry for plug-ins tagged 'python' and study how they are coded: http://registry.gimp.org/taxonomy/term/52 Also - you can interact with the current image (or create a new image) in the Python-Fu console, which can be useful. Also see Help-Procedure Browser. All of those functions can be called from python with pdb.finction_name() Happy hacking, Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] project gimp on sourceforge
Someone has registered gimp on souceforge - http://gimp.sourceforge.net/ I see there's a Donate Money link, and a non-working download link, both of which may be harmful; maybe it's worth asking sourceforge for this not-gimp project to be deleted? This was from someone who wouldn't share it openly on IRC, although I don't really see why not :-) Liam (Ankh) sbts Hi Ankh, a bit of info that I thought the team should know and discuss before making it public sbts It apears that someone has registered a project called gimp at sourceforge http://gimp.sourceforge.net/ it has been there for about 79 days, and just has the default template content. * Ankh looks Ankh so it does sbts It may be worth the team contacting Sourceforge and requesting a project takeover BEFORE any content goes up, even if you just use it as a point of redirection Ankh I'll send mail to the gimp developr list (or you can) sbts there are a number of policy items that you would have to meet to oficially be allowed to keep a sourceforge prescence, but I think it would possibly be worth it. sbts I am not a member of the list, and figured that it should come from within your community, but didn't want to have the universe knowing, and possibly hindering your efforts :) Ankh ok, thanks for letting us know sbts if you drop in at #sourceforge (on irc.freenode.net) and ask for the policy doc links, they can be redily provided from there. sbts np. sbts I found out because someone asked questions about problems they had with downloading gimp from sourceforge on #sourceforge, went and checked the page.. sbts will leave you with it. if you want to contact me just /msg sbts on the freenode network Ankh ok, thanks (I'm there too) -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
