the title "Copying" of gpl.texi makes no sense
I agree, but I don't think we should change the node name in the
canonical gpl.texi. So many manuals already use "Copying".
The other title "Library Copying" is nonsense as well, since
RMS doesn't recomment the LGPL for libraries.
Good
Furthermore lgpl.texi creates an entry in the index, but gpl.texi doesn't.
Also when you have a package partially under GPL, partially under LGPL,
and partially under FDL, the title "Copying" of gpl.texi makes no sense
any more. The other title "Library Copying" is nonsense as well, since
RMS does
Simon Josefsson wrote:
> --- gpl.texi 16 Jun 2006 17:35:17 +0200 1.4
> +++ gpl.texi 04 Sep 2006 17:39:43 +0200
> @@ -1,5 +1,5 @@
> @node Copying
> [EMAIL PROTECTED] GNU GENERAL PUBLIC LICENSE
> [EMAIL PROTECTED] GNU General Public License
> @center Version 2, June 1991
>
> @c This
[Re-added bug-gnulib in CC.]
Hello Davide,
Thanks for the new code. Looks quite good now. The second loop, however,
will crash when passed a string consisting entirely of whitespace.
I see also you've partially adopted the GNU style for this code. Fine!
Indeed, before we put code into gnulib, we
I'm looking at the texi output from gpl.texi and lgpl.texi, especially
PDF, and they are not very nice.
Reasons:
* GPL and LGPL titles are all in upper case.
* gpl.texi uses @unnumbered instead of @appendixsec, which both
fdl.texi and lgpl.texi does. The consequence is that GPL look
differe
Bruno Haible <[EMAIL PROTECTED]> writes:
> Hi Simon,
>
> I'm trying to unify your 'iconvme' module and my 'iconvstring' module (from
> GNU gettext).
...
> How does that sound? Is it acceptable?
Hi! The interface sounds good to me, let's see the code. ;)
The only concern I can think of would be
Oskar Liljeblad wrote:
> it would however be very useful if these functions would
> null-terminate the generated strings properly as well. I assume str_iconv
> and str_cd_iconv would add a single null-byte
Yes. the str_* functions expect a C string as input and produce one as
output, i.e. the from
On Monday, September 04, 2006 at 14:53, Bruno Haible wrote:
Hi Bruno
[..]
> All of these options are useful in some way or the other. Therefore I'd like
> to keep all the options, and distinguish them through a consistent
> nomenclature.
> - "str" vs. "mem",
> - infix "cd" vs. none (similar
Hi Simon,
I'm trying to unify your 'iconvme' module and my 'iconvstring' module (from
GNU gettext).
extern char *iconv_string (const char *string, const char *from_code,
const char *to_code);
extern char *iconv_alloc (iconv_t cd, const char *string);
vs.
exter
Hello Davide,
The first loop looks fine, safe for multibyte locales. But in the second loop:
> > In multibyte strings you cannot "go backwards". You have to write the
> > algorithm in a way that progresses from the first to the last multibyte
> > character. (*) In this case, you can do so by movi
Hi,
This change is needed so that the detection of shared libraries works on the
mingw platform.
2006-09-03 Bruno Haible <[EMAIL PROTECTED]>
* lib-link.m4 (AC_LIB_LINKFLAGS_BODY): Locate mingw shared libraries
correctly.
diff -r -c3 gettext-0.15/autoconf-lib-link/m4/lib-link.m
11 matches
Mail list logo
