[Webkit-unassigned] [Bug 16401] [GTK] GObject/C DOM binding

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=16401





------- Comment #177 from christian at imendio.com  2009-02-15 16:13 PDT -------
(In reply to comment #175)
> (In reply to comment #165)
> 
> > We might also add a "g_return_val_if_fail (!error || !*error, 0);" here.
> > 
> > > if(ec)
> > 
> > What happens if "error" is not set? We probably need "if(ec && error)" here?
> 
> Actually the existing code is intended to allow the caller to pass NULL for
> error to ignore any error condition, so we don't want to g_return_val_if_fail
> (!error).  In the generated code, the call to g_set_error_literal() is benign
> if error == NULL, in which case that function does nothing by design (as
> described in its documentation).

You are misreading the code here. "!error || !*error" written out means "return
with a critical warning if error is non-NULL and *error is also non-NULL, pass
if error is NULL or if *error is NULL". In other words, pass NULL if you are
not interested in errors, but *if* you pass an error, it has to be initialized
as an empty error.

> > > gdom_html_table_row_element_set_ch_off (GdomHTMLTableRowElement *thiz, gchar * value)

> The easiest way to fix this is to simply stop checking all string arguments for
> NULL; instead, we can pass them to WebKit and let it complain if it's not happy
> with a NULL argument.  Can you confirm that this seems like a reasonable idea?

Letting *WebCore* complain from my experience usually means a segmentation
fault, I certainly don't want that. What I'm suggesting is to define NULL as
empty, and return NULL if a value is unset.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.