Re: SIGABRT due double free
Fernando ApesteguXa schrieb: I'm developing a gtk/gnome application with two threads. An schema of the application is this: [SNIP] thread_func is updating data periodically with a sleep pause. At this point, I suppose the other thread is catching events normally (in fact, tabs of the notebook changes without problems). Well, at short time from run app, I get: *** glibc detected *** double free or corruption (!prev): 0x006115a0 *** Program received signal SIGABRT, Aborted. [SNIP] The curious thing is that I _have not_ any free, realloc or malloc in my code, only those that gtk/glib functions like g_file_get_contents can perform. This looks like a race condition due missing mutual exclusion. Did you read the API documentation and the various tutorials? http://www.gtk.org/api/2.6/gdk/gdk-Threads.html Cheers, Andy ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkUIManager help
Hi all, In my application I want to be able to dynamically add items to a menu after a configuration file has loaded and after a file has been opened. The menu's use gtk_ui_manager to initialise but I am unsure how to go about implementing to dynamic addition of menu items. Thanks in advance Adam Maintainer GNU Denemo a GTK+ frony end for GNU Lilypond ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
SIGABRT due double free
Thanks, now it appears to works fine. I thought gtk was completly thread safe, but is logic tu use a method for mutual exclusion. Really thanks a lot. We'll meet in my next post :) Best regards!! -- Forwarded message -- From: Andreas Stricker [EMAIL PROTECTED] Date: 24-nov-2005 9:27 Subject: Re: SIGABRT due double free To: gtk-app-devel-list@gnome.org Fernando ApesteguXa schrieb: I'm developing a gtk/gnome application with two threads. An schema of the application is this: [SNIP] thread_func is updating data periodically with a sleep pause. At this point, I suppose the other thread is catching events normally (in fact, tabs of the notebook changes without problems). Well, at short time from run app, I get: *** glibc detected *** double free or corruption (!prev): 0x006115a0 *** Program received signal SIGABRT, Aborted. [SNIP] The curious thing is that I _have not_ any free, realloc or malloc in my code, only those that gtk/glib functions like g_file_get_contents can perform. This looks like a race condition due missing mutual exclusion. Did you read the API documentation and the various tutorials? http://www.gtk.org/api/2.6/gdk/gdk-Threads.html Cheers, Andy ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkUIManager help
On 11/24/05, Adam [EMAIL PROTECTED] wrote:
In my application I want to be able to dynamically add items to a menu after a
configuration file has loaded and after a file has been opened. The menu's
use gtk_ui_manager to initialise but I am unsure how to go about implementing
to dynamic addition of menu items.
I do this by having a stub menuitem which I find and replace at runtime.
My UI XML looks like this:
menu action='ToolkitsMenu'
menuitem action='EditToolkits'/
separator/
menuitem action='Stub'/ /* Toolkits pasted here at runtime */
/menu
Stub is defined like this:
static GtkActionEntry mainw_actions[] = {
/* Dummy action ... replaced at runtime.
*/
{ Stub,
NULL, , NULL, , NULL },
I find and delete stub like this, making a note of the menu it's in:
/* Fetch the menu we add toolkit menus to.
*/
item = gtk_ui_manager_get_widget( mainw-ui_manager,
/MainwMenubar/ToolkitsMenu/Stub );
kitgview-menu = gtk_widget_get_parent( GTK_WIDGET( item ) );
/* Remove the stub item.
*/
gtk_widget_destroy( item );
Then add items like this:
kview-item = gtk_menu_item_new_with_label(
IOBJECT( kit )-name );
gtk_menu_shell_insert( GTK_MENU_SHELL( menu ),
kview-item,
ICONTAINER( kit )-pos + TOOLKITVIEW_MENU_OFFSET );
gtk_widget_show( kview-item );
Probably not the best way :-( but it seems to work.
John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Problem with icon_view auto dnd (gtk 2.8)
Hi ,
I have a problem using the IconView auto-dnd
(gtk_icon_view_enable_model_drag_source) and the item-activated signal.
On item-activate I show a dialog to the user, when the dialog is closed
the IconView start a drag operation incorrectly.
This is the complete code (is this a bug? or I made something Wrong?)
---
#include gtk/gtk.h
enum
{
COL_TEXT,
COL_PIXBUF,
NUM_COLS
};
static GtkTargetEntry targets[] =
{
{ text/uri-list, 0, 0 },
};
GtkWidget *window = NULL;
GtkWidget *icon_view;
GtkListStore *store;
static void
fill_store (GtkListStore *store)
{
GtkTreeIter iter;
GdkPixbuf *pixbuf = gdk_pixbuf_new_from_file (test.png, NULL);
/* First clear the store */
gtk_list_store_clear (store);
gtk_list_store_append (store, iter);
gtk_list_store_set (store, iter, COL_TEXT, test,COL_PIXBUF,pixbuf, -1);
}
static void
on_item_activated(GtkIconView *iconview,GtkTreePath
*arg1,gpointer user_data){
GtkWidget *dialog;
g_print(ACTIVATed\n);
dialog = gtk_dialog_new_with_buttons(TEST,
GTK_WINDOW(window),
GTK_DIALOG_MODAL |
GTK_DIALOG_DESTROY_WITH_PARENT | GTK_DIALOG_NO_SEPARATOR,
GTK_STOCK_CLOSE,GTK_RESPONSE_YES,
NULL);
gtk_dialog_run(GTK_DIALOG(dialog));
gtk_widget_destroy (dialog);
}
int main(int argc,char *argv[]){
gtk_init (argc, argv);
//window
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_window_set_default_size (GTK_WINDOW (window), 650, 400);
gtk_window_set_title (GTK_WINDOW (window), GtkIconView demo);
g_signal_connect (window, destroy,G_CALLBACK
(gtk_widget_destroyed), window);
//store
store = gtk_list_store_new (NUM_COLS, G_TYPE_STRING, GDK_TYPE_PIXBUF);
fill_store (store);
//icon_view
icon_view = gtk_icon_view_new_with_model (GTK_TREE_MODEL (store));
gtk_icon_view_set_text_column (GTK_ICON_VIEW (icon_view), COL_TEXT);
gtk_icon_view_set_pixbuf_column (GTK_ICON_VIEW (icon_view), COL_PIXBUF);
/* enable icon view auto D'n'D */
gtk_icon_view_enable_model_drag_source(GTK_ICON_VIEW(icon_view),GDK_BUTTON1_MASK,targets,1,GDK_ACTION_COPY);
gtk_icon_view_enable_model_drag_dest(GTK_ICON_VIEW(icon_view),targets,1,
GDK_ACTION_COPY);
gtk_signal_connect (GTK_OBJECT (icon_view), item-activated,
GTK_SIGNAL_FUNC (on_item_activated),NULL);
gtk_container_add (GTK_CONTAINER (window), icon_view);
gtk_widget_show_all (window);
gtk_main();
return 0;
}
--
Really thanks!
Dave Andreoli
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
on signals in an entry widget
hi all, i am a beginner in using gtk and i would just like to ask which signal i should use if i want to activate my entry widget on pressing tab or when i leave my entry widget (i.e., i want changes to take place when i hit tab, return key or when my cursor leaves the entry widget). I tried using activate but it only signals on the return key while changed signals everytime change something. So what could i use to ensure that the text in my entry widget only takes effect when tab is pressed, or the return key or when i leave that specific widget? thank you very much. any help would be greatly appreciated. christine ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Setting the background color of a GtkEntry
Hi there, Is it possible to change the background color of a GtkEntry? gtk_widget_modify_bg() does not do what I need - I want to modify the widget's true background, not to make a border around it (this is what gtk_widget_modify_bg() does); i.e. I want the text that user inputs appear on the background color I choose, not the standard one (white by default). Here is a conceptual image: http://kempniu.no-ip.com/files/gtkentry.jpg ;) Best regards, Michal Kepien ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Setting the background color of a GtkEntry
The white part of a text-accepting widget uses the base color, not
the bg color. The only way I know to set that is with a style:
style myEntry
{
base[NORMAL] = #ff# or whatever
}
class GtkEntry style myEntry
You can load this setting by placing that text in a file called foo
and then calling gtk_rc_parse(foo), or you can put it in a string
called bar and call gtk_rc_parse_string(bar).
-Alem
On 11/24/05, Michal Kepien [EMAIL PROTECTED] wrote:
Hi there,
Is it possible to change the background color of a GtkEntry?
gtk_widget_modify_bg() does not do what I need - I want to modify the widget's
true background, not to make a border around it (this is what
gtk_widget_modify_bg() does); i.e. I want the text that user inputs appear on
the background color I choose, not the standard one (white by default). Here
is a conceptual image: http://kempniu.no-ip.com/files/gtkentry.jpg ;)
Best regards,
Michal Kepien
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkUIManager help
On Thursday 24 November 2005 13:12, you wrote: [snip] Probably not the best way :-( but it seems to work. Thanks for that it seems to work quite well. I'm now encountering a different issue. As the data I'm using to populate the menu is coming from an XML file I'm encountering the following warning: (denemo:30177): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text() the string is a filepath i.e /home/adam/denemo/test.denemo. Is there anything that I should know about in converting from xmlChar * inserting into a GList and the extracting and converting to a gchar * ?? Adam Maintainer GNU Denemo a GTK+ frony end for GNU Lilypond ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkUIManager help
On 11/24/05, Adam [EMAIL PROTECTED] wrote: the string is a filepath i.e /home/adam/denemo/test.denemo. Is there anything that I should know about in converting from xmlChar * inserting into a GList and the extracting and converting to a gchar * ?? GTK+ is UTF-8 (almost) throughout. You need to find out what encoding your xml file is using (ascii? latin1?) and convert from that to UTF-8. Although I wonder what's invalid about your string ... is it null terminated? Also, the xmlChar typedef must die :-( it is very annoying. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Setting the background color of a GtkEntry
The white part of a text-accepting widget uses the base color, not
the bg color. The only way I know to set that is with a style:
style myEntry
{
base[NORMAL] = #ff# or whatever
}
class GtkEntry style myEntry
You can load this setting by placing that text in a file called foo
and then calling gtk_rc_parse(foo), or you can put it in a string
called bar and call gtk_rc_parse_string(bar).
This is some progress... However, what I want to achieve is to dynamically
change the background color without reopening the window (what I want to use the
color change for is validating input - if something's wrong then the entry goes
red, if the entry gets corrected it should be white again). Is it possible to
force a refresh and instantly change the background color of the GtkEntry? When
I use gtk_rc_parse_string() in the callback, it works, but the entry's color is
changed after i TAB a few entries forward.
Thanks again for any hints,
Michal Kepien
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkUIManager help
On Thursday 24 November 2005 21:46, John Cupitt wrote: On 11/24/05, Adam [EMAIL PROTECTED] wrote: the string is a filepath i.e /home/adam/denemo/test.denemo. Is there anything that I should know about in converting from xmlChar * inserting into a GList and the extracting and converting to a gchar * ?? GTK+ is UTF-8 (almost) throughout. You need to find out what encoding your xml file is using (ascii? latin1?) and convert from that to UTF-8. Although I wonder what's invalid about your string ... is it null terminated? Not sure but as it is a file name I used g_filename_to_utf8 and it seems to have resolved the issue. Also, the xmlChar typedef must die :-( it is very annoying. I'm using libxml to parse the file so these functions return xmlChar * types. Thanks Adam ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RFC: warnings on ignoring return value on some list operations
We recently had a bug in Nautilus where the return value from g_list_sort() was ignored. These sorts of bugs are not all that uncommon given the GList api, since its easy to forget the return value and from an OO point of view g_list_sort (list) looks very right. The attached patch adds a define for the gcc warn_unused_result function attribute, and uses it in a few list operations. I tried to be conservative in adding them, doing so only if it seems unreasonable to assume the programmer knew it was safe to ignore the return value. I.e. with g_list_prepend its never safe to ignore it, but with g_list_append its safe if you know the list isn't empty. Another example is g_list_remove(), where I think its uncommon to know that the removed item isn't first in the list, whereas I didn't add one for g_list_remove_link() since in that case its more likely that you know the position of the link. What do people think about this? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a shy albino shaman plagued by the memory of his family's brutal murder. She's a sharp-shooting streetsmart magician's assistant who dreams of becoming Elvis. They fight crime! Index: glib/gmacros.h === RCS file: /cvs/gnome/glib/glib/gmacros.h,v retrieving revision 1.26 diff -u -p -r1.26 gmacros.h --- glib/gmacros.h 8 Mar 2005 05:41:42 - 1.26 +++ glib/gmacros.h 24 Nov 2005 09:59:26 - @@ -95,6 +95,13 @@ #define G_GNUC_DEPRECATED #endif /* __GNUC__ */ +#if__GNUC__ 3 || (__GNUC__ == 3 __GNUC_MINOR__ = 4) +#define G_GNUC_WARN_UNUSED_RESULT \ + __attribute__((warn_unused_result)) +#else +#define G_GNUC_WARN_UNUSED_RESULT +#endif /* __GNUC__ */ + /* Wrap the gcc __PRETTY_FUNCTION__ and __FUNCTION__ variables with * macros, so we can refer to them as strings unconditionally. * usage not-recommended since gcc-3.0 Index: glib/glist.h === RCS file: /cvs/gnome/glib/glib/glist.h,v retrieving revision 1.8 diff -u -p -r1.8 glist.h --- glib/glist.h 8 Nov 2002 18:47:54 - 1.8 +++ glib/glist.h 24 Nov 2005 09:59:26 - @@ -44,34 +44,34 @@ struct _GList */ void g_list_push_allocator (GAllocator *allocator); void g_list_pop_allocator (void); -GList* g_list_alloc (void); +GList* g_list_alloc (void) G_GNUC_WARN_UNUSED_RESULT; void g_list_free (GList*list); void g_list_free_1 (GList*list); GList* g_list_append (GList*list, gpointer data); GList* g_list_prepend(GList*list, -gpointer data); +gpointer data) G_GNUC_WARN_UNUSED_RESULT; GList* g_list_insert (GList*list, gpointer data, gint position); GList* g_list_insert_sorted (GList*list, gpointer data, -GCompareFunc func); +GCompareFunc func) G_GNUC_WARN_UNUSED_RESULT; GList* g_list_insert_before (GList*list, GList*sibling, gpointer data); GList* g_list_concat (GList*list1, GList*list2); GList* g_list_remove (GList*list, -gconstpointer data); +gconstpointer data) G_GNUC_WARN_UNUSED_RESULT; GList* g_list_remove_all (GList*list, -gconstpointer data); +gconstpointer data) G_GNUC_WARN_UNUSED_RESULT; GList* g_list_remove_link(GList*list, GList*llink); GList* g_list_delete_link(GList*list, GList*link_); -GList* g_list_reverse(GList*list); -GList* g_list_copy (GList*list); +GList* g_list_reverse(GList*list) G_GNUC_WARN_UNUSED_RESULT; +GList* g_list_copy (GList*list) G_GNUC_WARN_UNUSED_RESULT; GList* g_list_nth(GList*list, guint n); GList* g_list_nth_prev (GList*list, @@ -92,10 +92,10 @@ void g_list_foreach(GList GFunc func, gpointer user_data); GList* g_list_sort (GList*list, -GCompareFunc compare_func); +GCompareFunc compare_func) G_GNUC_WARN_UNUSED_RESULT; GList* g_list_sort_with_data (GList*list, GCompareDataFunc compare_func, -gpointer user_data); +gpointer user_data) G_GNUC_WARN_UNUSED_RESULT; gpointer g_list_nth_data (GList*list, guint n); Index: glib/gslist.h === RCS file:
Re: RFC: warnings on ignoring return value on some list operations
On Thu, 24 Nov 2005, Alexander Larsson wrote: We recently had a bug in Nautilus where the return value from g_list_sort() was ignored. These sorts of bugs are not all that uncommon given the GList api, since its easy to forget the return value and from an OO point of view g_list_sort (list) looks very right. The attached patch adds a define for the gcc warn_unused_result function attribute, and uses it in a few list operations. I tried to be conservative in adding them, doing so only if it seems unreasonable to assume the programmer knew it was safe to ignore the return value. I.e. with g_list_prepend its never safe to ignore it, but with g_list_append its safe if you know the list isn't empty. Another example is g_list_remove(), where I think its uncommon to know that the removed item isn't first in the list, whereas I didn't add one for g_list_remove_link() since in that case its more likely that you know the position of the link. What do people think about this? i think that is a really good idea. however i'm more of the opinion that all list functions should have the warn_unused_result tag. code and conditions are easily changed, moved around or pasted so that missing the return value assignment for lists will become a problem. i.e. even if you know you're appending to a non-empty list, you should still write list = g_list_append (list, data); so i'd apprchiate if you extended the patch to cover all list functions that return possibly modified lists ;) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: warnings on ignoring return value on some list operations
On Thu, 2005-11-24 at 11:58 +0100, Tim Janik wrote: i think that is a really good idea. however i'm more of the opinion that all list functions should have the warn_unused_result tag. code and conditions are easily changed, moved around or pasted so that missing the return value assignment for lists will become a problem. i.e. even if you know you're appending to a non-empty list, you should still write list = g_list_append (list, data); so i'd apprchiate if you extended the patch to cover all list functions that return possibly modified lists ;) What happened to compatibility? Owen signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: warnings on ignoring return value on some list operations
On Thu, 2005-11-24 at 15:50 +0100, Tim Janik wrote:
On Thu, 24 Nov 2005, Owen Taylor wrote:
On Thu, 2005-11-24 at 11:58 +0100, Tim Janik wrote:
i think that is a really good idea. however i'm more of the opinion that
all
list functions should have the warn_unused_result tag. code and conditions
are easily changed, moved around or pasted so that missing the return value
assignment for lists will become a problem. i.e. even if you know you're
appending to a non-empty list, you should still write
list = g_list_append (list, data);
so i'd apprchiate if you extended the patch to cover all list functions
that return possibly modified lists ;)
What happened to compatibility?
could you please outline how you see compatibility affected by this?
if (head) {
g_list_append(tail, new);
tail = tail-next;
} else {
head = tail = g_list_append(null, new);
}
strikes me as acceptable code, and I know there are some examples like this
in GTK+. Maybe the gain is worth the pain ... unless someone is compiling
production code with -Werror it isn't going to *break* a build, and there
is no bin-compat issue. But it's definitely a compatibility break of some
sort.
Does
(void)g_list_append(tail, new);
Suppress the warning?
Regards,
Owen
signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: warnings on ignoring return value on some list operations
On Thu, 24 Nov 2005, Owen Taylor wrote:
if (head) {
g_list_append(tail, new);
tail = tail-next;
} else {
head = tail = g_list_append(null, new);
}
strikes me as acceptable code, and I know there are some examples like this
in GTK+. Maybe the gain is worth the pain ... unless someone is compiling
production code with -Werror it isn't going to *break* a build, and there
is no bin-compat issue. But it's definitely a compatibility break of some
sort.
i think one can argue both ways here, in the above code, i'd still write
head = g_list_append (tail, new); and recommend that people also do that,
because a) code is duplicated so often and this easily introduces errors
in another context, and b) i'd like to think of the list API as something
where i'm not allowed to ignore return values to avoid mistakes ;)
Does
(void)g_list_append(tail, new);
Suppress the warning?
i was assuming that, unfortunately that is not the case:
warn_unused_result.c
void* __attribute__ ((warn_unused_result)) bla (void) { return (void*) 5; }
int main () { (void) bla(); return 0; }
warn_unused_result.c
$ gcc-3.4 -Wall warn_unused_result.c
warn_unused_result.c: In function `main':
warn_unused_result.c:2: warning: ignoring return value of `bla', declared with
attribute warn_unused_result
the same happens with gcc-4.0.
unless you strongly object to it, i still think we should add the attribute to
all list functions that can return modified lists. it'll be stricter and thus
may require some adaptions when introduced, but better in the long-term because
it helps people to avoid easy errors.
Regards,
Owen
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: warnings on ignoring return value on some list operations
2005/11/24, Tim Janik [EMAIL PROTECTED]:
On Thu, 24 Nov 2005, Owen Taylor wrote:
if (head) {
g_list_append(tail, new);
tail = tail-next;
} else {
head = tail = g_list_append(null, new);
}
strikes me as acceptable code, and I know there are some examples like this
in GTK+. Maybe the gain is worth the pain ... unless someone is compiling
production code with -Werror it isn't going to *break* a build, and there
is no bin-compat issue. But it's definitely a compatibility break of some
sort.
i think one can argue both ways here, in the above code, i'd still write
head = g_list_append (tail, new); and recommend that people also do that,
because a) code is duplicated so often and this easily introduces errors
in another context, and b) i'd like to think of the list API as something
where i'm not allowed to ignore return values to avoid mistakes ;)
Append and perpend already have a big fat NOTE stating:
The return value is the new start of the list, which may have
changed, so make sure you store the new value.
so I would consider anyone not doing it misusing the API. Thus this
move would be just a case of enforcing correct API usage (a very wise
move if you ask me). Specially since it's compile-time only.
--
Kalle Vahlman, [EMAIL PROTECTED]
Powered by http://movial.fi
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: warnings on ignoring return value on some list operations
Qui, 2005-11-24 às 16:35 +0100, Tim Janik escreveu:
On Thu, 24 Nov 2005, Owen Taylor wrote:
if (head) {
g_list_append(tail, new);
tail = tail-next;
} else {
head = tail = g_list_append(null, new);
}
strikes me as acceptable code, and I know there are some examples like this
in GTK+. Maybe the gain is worth the pain ... unless someone is compiling
production code with -Werror it isn't going to *break* a build, and there
is no bin-compat issue. But it's definitely a compatibility break of some
sort.
i think one can argue both ways here, in the above code, i'd still write
head = g_list_append (tail, new); and recommend that people also do that,
because a) code is duplicated so often and this easily introduces errors
in another context, and b) i'd like to think of the list API as something
where i'm not allowed to ignore return values to avoid mistakes ;)
Does
(void)g_list_append(tail, new);
Suppress the warning?
i was assuming that, unfortunately that is not the case:
I don't see how:
(void)g_list_append(tail, new);
is any better than:
tail = g_list_append(tail, new);
and that still leaves the option:
GList *dummy = g_list_append(tail, new);
With more or less typing, this is an easy warning to fix. And don't
get me started again about the evil of -Werror :P
--
Gustavo J. A. M. Carneiro
[EMAIL PROTECTED] [EMAIL PROTECTED]
The universe is always one step beyond logic.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: warnings on ignoring return value on some list operations
On Thu, 24 Nov 2005 16:35:59 +0100 (CET) Tim Janik [EMAIL PROTECTED] wrote: unless you strongly object to it, i still think we should add the attribute to all list functions that can return modified lists. it'll be stricter and thus may require some adaptions when introduced, but better in the long-term because it helps people to avoid easy errors. (Hi all... new to this list but long-time user of GLib) Just my two cents (Euros, naturally). I think it sounds a great idea. 99% of cases which hit will the warning, will be genuine accidents... In the 1% of cases where you really do know it is safe to ignore, it will, as others have pointed out, be simple enough to avoid. (Shame that casting the return to void doesn't work though... :/ ) -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
