The file lib/progreloc.c has no module, and carries an embedded GPL
license. However, the intent for this file is that it is LGPL,
according to the check-in message for revision 1.5, here:
http://cvs.savannah.gnu.org/viewcvs/gnulib/gnulib/lib/progreloc.c?rev=1.10&view=log
"Change copyright not
By code inspection I noticed some other opportunities to use
XMALLOC instead of xmalloc, XCALLOC instead of xcalloc,
xmemdup instead of XNMALLOC+memcpy, and x2nrealloc instead of
a hand-written replacement. Here's a proposed (but untested)
patch.
2006-11-06 Paul Eggert <[EMAIL PROTECTED]>
Hello Bruno,
OK to apply? AFAICS these are the only remaining // style comments in
lib/.
Cheers,
Ralf
2006-11-06 Ralf Wildenhues <[EMAIL PROTECTED]>
* lib/gl_oset.h: Use C comment style, not C++ comment style.
Index: lib/gl_oset.h
===
[ adding bug-automake ]
Hello Bruno,
* Bruno Haible wrote on Mon, Nov 06, 2006 at 02:43:09PM CET:
>
> I've been experimenting with modules that have files in subdirectories of
> lib/.
> gnulib-tool didn't handle this. With this patch, it nearly works - modulo
> an automake bug.
Could you be bo
I installed this; it is an example of how to use the new flexmember
module.
2006-11-06 Paul Eggert <[EMAIL PROTECTED]>
* lib/idcache.c: Include , for offsetof.
(struct userid.name): Change from char * to a flexible array member.
All uses changed.
* modules/idcach
I installed this. Like vararrays, it should be migrated into Autoconf,
which is also on my list of things to do.
2006-11-06 Paul Eggert <[EMAIL PROTECTED]>
* MODULES.html.sh (Core language properties): New module flexmember.
* modules/flexmember, m4/flexmember.m4: New files.
I
Bruno Haible <[EMAIL PROTECTED]> writes:
> ! /* Return a pointer to a new buffer of N bytes. This is like xmalloc,
> !except it returns char *.
> !xcharalloc (N) is equivalent to XNMALLOC (N, char). */
> static inline char *
> ! xcharalloc (size_t n)
> {
> ! return (char *) xmalloc
Bob Proulx wrote:
> > Compiling GNU gettext with a C++ compiler revealed a bug: an assignment
> > between an 'int' variable and an 'enum' variable that was not intended.
>
> Although I am sure it was not intended, what bad consequences would
> have resulted from the enum and int mixup?
msgfmt, on
Bruno Haible <[EMAIL PROTECTED]> writes:
> Additionally, can we please add a comment here?
Sure. For consistency there should be a comment for
canonicalize_filename_mode so I installed the following patch for
canonicalize.h along with the other patches already mentioned.
Another consistency cha
Bruno Haible wrote:
> Compiling GNU gettext with a C++ compiler revealed a bug: an assignment
> between an 'int' variable and an 'enum' variable that was not intended.
Although I am sure it was not intended, what bad consequences would
have resulted from the enum and int mixup?
> This confirms on
Paul Eggert wrote:
> I guess the basic idea here is that we move this module from gettext
> to gnulib
Yes, this is the idea.
> Here is a slightly different proposal to add that module; it assumes
> the 'canonicalize' changes I just installed. What do you think?
Looks fine. I too like the idea o
Hi,
I've been experimenting with modules that have files in subdirectories of lib/.
gnulib-tool didn't handle this. With this patch, it nearly works - modulo
an automake bug.
2006-11-05 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool (func_import, func_create_testdir): Create directori
This was an ANSI C compliance bug, but g++ stumbled upon it as well, like
non-gcc C compilers would do.
2006-11-05 Bruno Haible <[EMAIL PROTECTED]>
* lib/gl_array_list.c (gl_array_iterator_next): Make pointer decrement
ANSI C compliant.
*** gnulib-20061026/lib/gl_array_list.c 2
To avoid C++ name mangling of the exported symbols, I applied this.
2006-11-03 Bruno Haible <[EMAIL PROTECTED]>
* lib/c-ctype.h [C++]: Define functions without name mangling.
* lib/fwriteerror.h [C++]: Likewise.
* lib/gcd.h [C++]: Likewise.
* lib/linebreak.h [C++
Paul Eggert wrote:
> > #ifdef __cplusplus
> > #define XALLOC_WITH_EXPRESSION(N,EXPR) xalloc_with_expression (N, &(EXPR))
>
> That doesn't look right in general, since there can be side effects in
> computing the address of EXPR.
And also, if the programmer writes
result = XALLOC_WITH_EXPRESSIO
Sergey Poznyakoff wrote:
> The idea of a compendium textual domain, which
> gnulib is at TP, is that a translator, preparing his localzation will
> download it and merge with his translaton using msgmerge.
Do you know how many translators actually do this? Very few, I would say.
I don't have preci
Bruno Haible <[EMAIL PROTECTED]> wrote:
> What's missing is that gnulib-tool copies the POT & PO files into the
> destination project, possibly with measures to avoid collisions with other
> versions, and/or arranges to define DEFAULT_TEXT_DOMAIN to "gnulib".
I doubt it should. The idea of a com
17 matches
Mail list logo
