Hi Paul,
I wrote:
> If we add such a wrapper to gnulib, it could be called 'astrxfrm'
>
> extern char * astrxfrm (const char *s, char *resultbuf, size_t *lengthp);
>
> and then I would agree to renaming memxfrm -> amemxfrm, for consistency.
I'm doing the renaming:
2010-08-14 Bruno Haible
> > extern char * astrxfrm (const char *s, char *resultbuf, size_t *lengthp);
>
> Yes, that looks like a useful addition. Thanks for the suggestion.
I'm implementing it as follows. Hope the logic is all right. (It's more
complicated than one would expect.)
2010-08-14 Bruno Haible
Reuben Thomas wrote:
> New patch attached.
I've applied it for you.
Bruno
[reducing to bug-gnulib]
unhappy with code-generated documentation.
We can have code-generated documentation *if* you (or someone) writes
rms with a detailed explanation of the situation (I can review any
draft). He always (to my knowledge) has had various
requests/recommendations for how t
On 14 August 2010 19:48, Bruno Haible wrote:
> Reuben Thomas wrote:
>> In the end I found very little to change on a first look. The attached patch:
>>
>> 1. Removes mentions of regex.c.
>
> I've committed this part for you.
>
>> 2. Adds documentation of not_eol.
>
> I haven't committed this part,
re_set_registers is not documented; there's a note about this. I'd be
happy to write some documentation for that.
I see no reason not to. I don't know why we never got to it.
There's also the technique of re-using a registers data structure by
NOT re_compile_fastmap, but using t
On Sat, Aug 14, 2010 at 4:51 PM, Reuben Thomas wrote:
> On 14 August 2010 16:46, Reuben Thomas wrote:
>> On 4 August 2010 09:54, James Youngman wrote:
>>> I'm not sure the two options need to be exclusive.
>>
>> Fair enough, especially as it's machine generated, so the maintenance
>> problem I
Reuben Thomas wrote:
> gnulib people: you seem to be unhappy with code-generated
> documentation. How would you like to proceed?
It's OK to have documentation include pieces of the code if the
extraction and update is done by us (the maintainers). What we would
like to avoid is that people/distros
Reuben Thomas wrote:
> In the end I found very little to change on a first look. The attached patch:
>
> 1. Removes mentions of regex.c.
I've committed this part for you.
> 2. Adds documentation of not_eol.
I haven't committed this part, because you added a paragraph about not_eol
in the sectio
Hi,
Brian Gough found out how to make use of the git-merge-changelog program for
'git'. Let me add his findings as documentation. Thanks a lot, Brian!
2010-08-14 Brian Gough
Bruno Haible
git-merge-changelog: add doc relating to use with bzr and hg.
* lib/git-mer
On 3 August 2010 23:21, Bruno Haible wrote:
> Feel free to submit a patch that Eric or Karl or I can apply.
In the end I found very little to change on a first look. The attached patch:
1. Removes mentions of regex.c.
2. Adds documentation of not_eol.
The other questions which I asked are most
On 14 August 2010 16:46, Reuben Thomas wrote:
> On 4 August 2010 09:54, James Youngman wrote:
>> On Wed, Aug 4, 2010 at 1:02 AM, Reuben Thomas wrote:
>>
>>> "in regexprops-generic.texi, I think that having a plain English
>>> definition of the various syntaxes obscures the fact that each is
>>>
On 4 August 2010 09:54, James Youngman wrote:
> On Wed, Aug 4, 2010 at 1:02 AM, Reuben Thomas wrote:
>
>> "in regexprops-generic.texi, I think that having a plain English
>> definition of the various syntaxes obscures the fact that each is
>> defined as a strict combination of features. Would you
Matthias Bolte wrote:
> diff --git a/modules/pthread b/modules/pthread
> index 9b930b1..76eca90 100644
> --- a/modules/pthread
> +++ b/modules/pthread
> @@ -18,7 +18,7 @@ BUILT_SOURCES += $(PTHREAD_H)
> # We need the following in order to create when the system
> # doesn't have one that works wi
Paul Eggert wrote:
> One simple way to fix the problem is to define a global
> variable program_name and arrange for your
> main function to set it from argv[0].
Or import the module 'progname' from gnulib, and start the main()
function of your program with the statement
set_program_name (argv[
On 08/13/10 16:37, Peter Johansson wrote:
> /usr/bin/ld: Undefined symbols:
> _program_name
dirname depends on xalloc to allocate storage,
and that depends on xalloc-die, which needs
to know your program's name. One simple
way to fix the problem is to define a global
variable program_name and arr
16 matches
Mail list logo
