Re: [PATCH 01/72] gettext.h: add no-op _() and N_() wrappers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Feb 20, 2011 at 03:01, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote:

> Ãvar ArnfjÃrà Bjarmason wrote:
>
>> Add a new header called gettext.h which is currently a no-op.
>
> Thanks. ÂI'd suggest squashing this with patch #2 (#including
> gettext.h in cache.h).
>
>> --- /dev/null
>> +++ b/gettext.h
>> @@ -0,0 +1,9 @@
>> +/*
>> + * Copyright (c) 2010 Ãvar ArnfjÃrà Bjarmason
>
> Is such a simple header file copyrightable? ÂBut I don't mind.
>
>> + *
>> + * This is a skeleton no-op implementation of gettext for Git. It'll
>> + * be replaced by something that uses libintl.h and wraps gettext() in
>> + * a future patch series.
>> + */
>> +#define N_(s) (s)
>
> Might be nice to make this an inline function, for type safety.
>
>> +#define _(s) (s)
>
> This one can't be a function, though, since it needs to transform
> literals to literals.
>
> Some possible tweaks:
>
> Â- protect against double inclusion
> Â- make _ into a function
> Â- add a comment vaguely explaining N_
> Â- avoid confusing errors if some other header has pre-defined _.
>
> Signed-off-by: Jonathan Nieder <jrnieder@xxxxxxxxx>
> ---
> Âgettext.h | Â 19 +++++++++++++++++--
> Â1 files changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/gettext.h b/gettext.h
> index c68bbe9..2f806cb 100644
> --- a/gettext.h
> +++ b/gettext.h
> @@ -1,3 +1,10 @@
> +#ifndef GETTEXT_H
> +#define GETTEXT_H
> +
> +#ifdef _
> +#error "namespace conflict: '_' is pre-defined?"
> +#endif
> +
> Â/*
> Â* Copyright (c) 2010 Ãvar ArnfjÃrà Bjarmason
> Â*
> @@ -5,5 +12,13 @@
> Â* be replaced by something that uses libintl.h and wraps gettext() in
> Â* a future patch series.
> Â*/
> -#define N_(s) (s)
> -#define _(s) (s)
> +
> +static inline const char *_(const char *msgid)
> +{
> + Â Â Â return msgid;
> +}
> +
> +/* Mark msgid for translation but do not translate it. */
> +#define N_(msgid) (msgid)
> +
> +#endif

Thanks for this. This was raised earlier in the discussion for this
series (by you, IIRC). I've considered it, and while I see your point
(type safety = good) I think I like my way of doing it better.

The _() macro/function is usually a macro and not a function. The good
thing about this is that I can prove that it's a no-op on all
compilers, whereas if it's an inline function (stupid) compilers will
actually make it into a function, which'll result in overhead,
which'll mean I can't advertise this series as a "no-op" anymore.

Check out some of the recent work in perl.git for reference. There's
now a probe in perl which check is the compiler can *really* handle
inline functions, and if not perl will fall back on using macros.

I'd rather not use inline functions for every string in Git without
such a probe, especially since it's for a very marginal gain. Using
_() for non-strings isn't going to make it past the list, and if it's
used with e.g. multiple arguments compilers will already whine about
it.

So that's why I didn't do it. But if everyone else feels strongly
about it I'll change my mind, I don't care *that* much about it, but
I'd prefer a macro.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]