See attached patch. A quick review:
* SSM()'s third argument is supposed to be unsigned, so casting to uptr_t seems more correct.
* Various cases of foo() --> foo(void). (Come on guys... the only excuse is if you're older than dirt and still haven't broken your old K&R habits :)
* Make clear that editor_goto_line()'s third argument is an integer, not a double
* Add the gsize cast to the negative second argument of encodings_convert_to_utf8[_from_charset]() where missing, so that the compiler doesn't warn us that it is converting the value to unsigned
* HAVE_GIO should either be #defined to 1, or not #defined at all, per Autoconf convention. My build had broken because I had "#define HAVE_GIO 0" in config.h, and "#ifdef HAVE_GIO" in utils.c. ("#ifdef" only looks at whether the symbol is defined or not---the value doesn't matter.)
--Daniel
On Sun, 11 Jan 2009 02:40:58 -0500, "Daniel Richard G." skunk@iSKUNK.ORG wrote:
See attached patch. A quick review:
Thanks a lot Daniel, I just committed your changes.
- SSM()'s third argument is supposed to be unsigned, so casting to
uptr_t seems more correct.
Yes, I guess this was a C&P mistake by me.
- Various cases of foo() --> foo(void). (Come on guys... the only
excuse is if you're older than dirt and still haven't broken your old K&R habits :)
Hmm, there must be some script running here which removes the (void) which I insert usually...it's the only explanation.
:)
- HAVE_GIO should either be #defined to 1, or not #defined at all, per
Autoconf convention. My build had broken because I had "#define HAVE_GIO 0" in config.h, and "#ifdef HAVE_GIO" in utils.c. ("#ifdef" only looks at whether the symbol is defined or not---the value doesn't matter.)
Oops, sorry. I should have tested this better.
Regards, Enrico
On Sun, 2009 Jan 11 19:30:13 +0100, Enrico Tröger wrote:
Thanks a lot Daniel, I just committed your changes.
Yay! I've updated them in. There's a couple more things to address, covered in the attached patch:
* The new #include<gio/gio.h> in src/utils.c needs to be surrounded by "#ifdef HAVE_GIO". (Good thing I'm still on etch, and can catch little things like this!)
* I missed this before, but assignments to xxxxxxdir in Makefile.am should not have a trailing slash. Currently, you see this in a few places when you do "make install":
/usr/share/automake-1.9/install-sh -m 644 '/tmp/geany-svn/plugins/pluginmacros.h' '/opt/geany/include/geany//pluginmacros.h' /usr/share/automake-1.9/install-sh -m 644 '/tmp/geany-svn/plugins/geanyfunctions.h' '/opt/geany/include/geany//geanyfunctions.h'
(Note the double slashes near the end of each line)
--Daniel
On Sun, 11 Jan 2009 18:58:08 -0500, "Daniel Richard G." skunk@iSKUNK.ORG wrote:
On Sun, 2009 Jan 11 19:30:13 +0100, Enrico Tröger wrote:
Thanks a lot Daniel, I just committed your changes.
Yay! I've updated them in. There's a couple more things to address, covered in the attached patch:
- The new #include<gio/gio.h> in src/utils.c needs to be surrounded by
"#ifdef HAVE_GIO". (Good thing I'm still on etch, and can catch little things like this!)
Of course, sorry again. It's really not my day. I'll finally go sleeping now.
- I missed this before, but assignments to xxxxxxdir in Makefile.am
should not have a trailing slash. Currently, you see this in a few places
Hmm, I applied your patch though I don't think the double slashes hurt anything at all. But I'm not sure.
Regards, Enrico
On Sun, 11 Jan 2009 02:40:58 -0500 "Daniel Richard G." skunk@iSKUNK.ORG wrote:
- Various cases of foo() --> foo(void). (Come on guys... the only excuse is if you're older than dirt and still haven't broken your old K&R habits :)
Or you are used to C++ or C99 ;-) My brain keeps saying the 'void' is redundant. But I updated my function snippet a while ago to do it for me usually.
But the real problem is that gcc doesn't warn about it (or I haven't found an option for gcc 4.1 anyway).
Thanks for the patch though.
Regards, Nick
2009/1/19, Nick Treleaven nick.treleaven@btinternet.com:
On Sun, 11 Jan 2009 02:40:58 -0500 "Daniel Richard G." skunk@iSKUNK.ORG wrote:
- Various cases of foo() --> foo(void). (Come on guys... the only excuse
is if you're older than dirt and still haven't broken your old K&R habits :)
Or you are used to C++ or C99 ;-) My brain keeps saying the 'void' is redundant. But I updated my function snippet a while ago to do it for me usually.
Here is little example why you should use void, the following code:
void foo() {} int main() { foo(1); return 0; }
will compile using gcc -Wall -Wextra without any warrning. If you add void you will get:
a.c: In function 'main': a.c:10: error: too many arguments to function 'foo'
Best regards, Yura Siamashka
On Mon, 2009 Jan 19 18:23:05 +0000, Nick Treleaven wrote:
- Various cases of foo() --> foo(void). (Come on guys... the only excuse is if you're older than dirt and still haven't broken your old K&R habits :)
Or you are used to C++ or C99 ;-) My brain keeps saying the 'void' is redundant. But I updated my function snippet a while ago to do it for me usually.
It never hurts to make it explicit. In C, a prototype with empty parens is sort of like a "wildcard" that will be consistent with any same-named function prototype/definition that actually does give the formal params. That's something one would use if s/he (A) didn't know what the real formal params were, as in syscalls that take a void* or a char* depending on platform, or (B) were too lazy to care ^_^ It's good to just put "void" in there to make clear that neither of these is going on.
But the real problem is that gcc doesn't warn about it (or I haven't found an option for gcc 4.1 anyway).
-Wstrict-prototypes :-) The warning it gives you is "function declaration isn’t a prototype".
--Daniel
On Mon, 19 Jan 2009 14:25:00 -0500, "Daniel Richard G." skunk@iSKUNK.ORG wrote:
On Mon, 2009 Jan 19 18:23:05 +0000, Nick Treleaven wrote:
- Various cases of foo() --> foo(void). (Come on guys... the only
excuse is if you're older than dirt and still haven't broken your old K&R habits :)
Or you are used to C++ or C99 ;-) My brain keeps saying the 'void' is redundant. But I updated my function snippet a while ago to do it for me usually.
It never hurts to make it explicit. In C, a prototype with empty parens is sort of like a "wildcard" that will be consistent with any same-named function prototype/definition that actually does give the
On a similar note, I recently experienced some nasty crashes when using the geanyvc and spellcheck plugn together. After some investigation, I figured that in geanyvc.c there was a function 'execute_command' which was not declared static and without prototype. No problem so far. But the spellcheck plugin uses enchant and enchant loads libvoikko which loads libmalaga and libmalaga also has a function 'execute_command'. So there was a clash between these symbols for some reason causing weird segfaults when using any command of geanyvc which calls its 'execute_command'. Frank fixed this in r380 and the morale of the story is: use static whenever possible :). Probably a prototype for 'execute_command' had also fixed the problem.
But the real problem is that gcc doesn't warn about it (or I haven't found an option for gcc 4.1 anyway).
-Wstrict-prototypes :-) The warning it gives you is "function declaration isn’t a prototype".
But this option is not much fun since it causes many, many warnings in GLib/GTK headers.
Regards, Enrico
On Mon, 2009 Jan 19 20:48:51 +0100, Enrico Tröger wrote:
On a similar note, I recently experienced some nasty crashes when using the geanyvc and spellcheck plugn together. After some investigation, I figured that in geanyvc.c there was a function 'execute_command' which was not declared static and without prototype. No problem so far. But the spellcheck plugin uses enchant and enchant loads libvoikko which loads libmalaga and libmalaga also has a function 'execute_command'. So there was a clash between these symbols for some reason causing weird segfaults when using any command of geanyvc which calls its 'execute_command'. Frank fixed this in r380 and the morale of the story is: use static whenever possible :). Probably a prototype for 'execute_command' had also fixed the problem.
At least there would have been a possibility of a conflict, which would have revealed the problem sooner. Function clashes like that are a tricky animal---that's when the binutils folks start talking about "weak" symbols and the like. The other moral of your story is, if the function isn't going to be static (and *especially* if it's exported from a shared library), then for heaven's sake, namespace the name!
-Wstrict-prototypes :-) The warning it gives you is "function declaration isn’t a prototype".
But this option is not much fun since it causes many, many warnings in GLib/GTK headers.
Oh, of course. It's a rare luxury to be able to look at warnings directly during compilation; I usually postprocess the build log to filter out the ones I don't want to see.
Surely you're not going to let other people's laziness compromise *your* exacting standards, hmmm? ;-)
--Daniel
On Mon, 19 Jan 2009 20:48:51 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
But the real problem is that gcc doesn't warn about it (or I haven't found an option for gcc 4.1 anyway).
-Wstrict-prototypes :-) The warning it gives you is "function declaration isn’t a prototype".
OK, thanks, I missed it.
But this option is not much fun since it causes many, many warnings in GLib/GTK headers.
<Sigh> Another reason why C is so much fun *g*
I wonder why GLib/GTK builds with the old compilers then?
Regards, Nick