Re: g_strcmp0

[Milosz Derezynski <internalerror gmail com>]

Thanks, that was the point I was trying to make!

2010/9/1 richard boaz <ivor boaz gmail com>

2010/9/1 David Nečas <yeti physics muni cz>

On Tue, Aug 31, 2010 at 10:38:13PM +0200, Milosz Derezynski wrote:
> Well, to be honest, the g_ stuff serves as an abstraction layer; I don't
> think that currently there is any problem with using the plain C type
> instead of the g_ type in this (or other) functions, but for consistency's
> sake and for the case that this typedef will become more complex depending
> on other platforms supported in the future I would consider this a minor bug
> and opt to get it fixed.

I am not against changing the function prototype.  However, the
reasoning that the typedef can change is bogus.  The type is equivalent
to the C type and has been always specified so:

   Types which correspond exactly to standard C types, but are included
   for completeness - gchar, gint, gshort, glong, gfloat, gdouble.

A typedef to something else would be a major API breakage.

Yeti

desiring consistency is never a bogus reason.  making it right now, since, as you say, it is currently equivalent, would cause no API breakage (what breaks exactly?).

when, and if, the typedef wrapper ever does need to change, this would indeed result in API breakage.

better to fix now when no harm possible, rather than waiting till a necessary change necessarily breaks the API.  the longer into the future that the typedef remains unchanged, the less likely it will cause harm in old code.

or, why should it remain wrong just because it wasn't right in the first place?  i.e., this "wrongness" works now, but is not guaranteed to work forever.

richard

-- 
Please note that according to the German law on data retention,
information on every electronic information exchange with me is
retained for a period of six months.
[Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]