Am Montag, den 26.09.2005, 12:28 +0200 schrieb Alexander Larsson:
> You're mixing g_free/xmlFree in:
> + property = xmlGetProp (destination_file_node, NAUTILUS_METADATA_KEY_CUSTOM_ICON);
> + if (property != NULL && g_str_has_prefix (property, source_file_uri)) {
> + p = property;
> +
> + property = g_strconcat (destination_file_uri,
> + property + strlen (source_file_uri),
> + NULL);
> + xmlSetProp (destination_file_node, NAUTILUS_METADATA_KEY_CUSTOM_ICON, property);
> +
> + xmlFree (p);
> + }
> +
> + xmlFree (property);
>
> I recommend using p for the g_strconcat result instead and then
> g_free(p).
Maybe sb. could explain me what the influence of char signedness is in
practice, and in what conditions I can safely "mix" xmlChar and
(g)chars? I supposed I'm not supposed to mix them at all - hence the
namespacing? What if the numeric value of an xmLChar is greater than the
value a char is able to take and I pass it to g_strconcat?
> Its sort of strange that the metafile system special-cases a specific
> key entry like this. It would make more sense to e.g. store the custom
> icon with a relative filename. That would work for more cases than the
> prefix of the uri being identical too. For instance when there are
> symlinks etc involved.
Yup, I've had something like that on plate already. However, it didn't
seem trivial to make a relative out of two full URIs. Also, I wanted to
fix this in a way that does not force users to re-pick icons for their
existing folders.
--
Christian Neumair <chris gnome-de org>
Attachment:
signature.asc
Description: This is a digitally signed message part