After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 168268 - 0 should be NULL in one gtk call
0 should be NULL in one gtk call
Status: RESOLVED FIXED
Product: gtkmm
Classification: Bindings
Component: build
2.2
Other Linux
: Normal normal
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2005-02-23 14:51 UTC by Marcus Meissner
Modified: 2005-03-03 11:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gtkmm2-null.patch (559 bytes, patch)
2005-02-23 14:51 UTC, Marcus Meissner
none Details | Review

Description Marcus Meissner 2005-02-23 14:51:32 UTC
Distribution/Version: SUSE

there is a terminating 0 where a NULL should be. see attached patch.
Comment 1 Marcus Meissner 2005-02-23 14:51:49 UTC
Created attachment 37836 [details] [review]
gtkmm2-null.patch
Comment 2 Murray Cumming 2005-02-24 09:53:26 UTC
Does this cause a build error? Why do you need this? Please remember to patch
the ChangeLog in future.
Comment 3 Marcus Meissner 2005-02-24 10:01:49 UTC
no, just a warning with gcc4 and annotated gtk2 headers. 
 
It might break on runtime on 64bit systems. 
 
Comment 4 Murray Cumming 2005-02-24 19:00:19 UTC
Could you show us the warning please? What do you mean by "annotated" gtk2 headers?

In general we use 0 for null pointers all over gtkmm. It's kind of a C++ thing.
Comment 5 Marcus Meissner 2005-02-25 08:31:07 UTC
This is a new gcc 4.0 warning. 
 
For varargs functions you can specify if the vararg list should be terminated 
by a NULL pointer using a gcc specific attribute: 
	__attribute__((__sentinel__(0)))  
 
the compiler will then warn like this: 
treeview.cc: In member function 'int Gtk::TreeView::insert_column(const 
Glib::ustring&, Gtk::CellRenderer&, int)': 
treeview.cc:274: warning: missing sentinel in function call 
 
The base patches for this are at: 
 
http://bugzilla.gnome.org/show_bug.cgi?id=164706 
http://bugzilla.gnome.org/show_bug.cgi?id=165682 
 
However they need an additional C++ patch for gcc4 to work correctly (and not 
warn too much). 
 
0 is ok if the compiler knows about the argument being a pointer (it will then 
auto convert it to the correct NULL ptr representation). 
 
However in varg arg lists it cannot know that 0 is not a pointer, so it will 
be stored as 32bit integer. The retrieving function will however retrieve 
a pointer which on 64bit machines is 64bit. 
 
For instance on AMD64 those varargs might be passed in a register and that 
would cause the upper 32bit not cleared.  
 
We had during initial AMD64 porting several of those problems and only now got 
compiler support in gcc 4. 
 
I hope this explanation satisfies :) 
Comment 6 Murray Cumming 2005-02-28 10:02:57 UTC
This seems to be dependent on the 2 other patches, so I'll wait for them to be
committed. Hopefully you can apply it locally in the meantime.

Is (void*)(0) also an option?

I don't like revisiting the old NULL==0 question, which is apparently different
in C than C++. Hopefully we won't have to.
Comment 7 Marcus Meissner 2005-02-28 12:29:15 UTC
yes, (void*)(0) can be used too. 
Comment 8 Murray Cumming 2005-03-03 11:42:40 UTC
OK, that's what I've used. Thanks.