If the problem occurs with fflush, most likely it will also occur
with fwrite, fclose, etc. fflush is merely the guinea pig here.
We may have to send bug reports for the systems where it does not always work.
However, even on those systems, this is change likely to be a big improvement.
I
That's the goal, but we need to iron out some technical difficulties
first, as there is an incompatibility with another gnulib module and
(more important) it's not yet clear that the proposed approach will
actually work.
If it works well to solve this problem for CVS, that's good e
Bruno Haible <[EMAIL PROTECTED]> writes:
> "lock.h" has the big benefit that it describes what it is
The word "lock" is good, but (unfortunately) lots of things are
locked, and there are different forms of locks. Files can be locked
with flock, for example. "lock.h" could refer to any of these
Bruno Haible <[EMAIL PROTECTED]> writes:
>> The gnulib module could set
>> something like that up, to avoid manual config.h additions.
>
> The name of the xxx_check_version function is something that each package
> will want to define explicitly. I don't think deducing its name through a
> rule is
Bruno Haible <[EMAIL PROTECTED]> writes:
> Maybe you could improve the handling when the translator didn't provide
> a translation? if (translation == msgid)...
> Currently the code returns
>
>(s == clocale_quoting_style ? "\"" : "`" or "'")
>
> If you improved this to test the locale_charset
Hello,
Some time (and sadly, a public release) back I inadvisedly changed the
default regexp syntax understood by GNU find from Emacs to POSIX
Basic. The syntax-controlling variable had previously been
uninitialised (hence being RE_SYNTAX_EMACS by coincidence). This
turned out to break some shel
Bruno Haible <[EMAIL PROTECTED]> writes:
> 2005-07-14 Bruno Haible <[EMAIL PROTECTED]>
>
> * argp.m4 (gl_ARGP): Remove invocation of gl_FUNC_GLIBC_UNLOCKED_IO.
> Instead, test for *_unlocked function declarations directly.
Thanks; I installed that, along with this other minor patch:
"Richard M. Stallman" <[EMAIL PROTECTED]> writes:
> I am not sure what job that program does. The program is too long for
> me to read it just to try to figure that out.
The program arranges for fflush to have a nontrivial amount of
buffered data to flush. It then calls fflush, so the buffer is
Bruno Haible <[EMAIL PROTECTED]> writes:
> if you ever want to go back from
>
> #if USE_UNLOCKED_IO
> # include "unlocked-io.h"
> #endif
>
> to a simple
>
> #include "unlocked-io.h"
>
> then --avoid will do the trick as well.
Sorry, I guess I'm just slow, because I don't quite follow. If you
mak
Paul Eggert wrote:
> I have one minor quibble: the name "lock".
> That's a generic name, and "lock.h" is likely to collide with file
> names already in use. I just checked, and OpenBSD has a ;
> I wouldn't be surprised if someone else (unwisely) grabbed .
FreeBSD is going away from , they renamed
Simon Josefsson wrote:
> > #define stringprep_check_version check_version
> > instead of a function that calls check_version.
>
> I assume you meant:
>
> #define check_version stringprep_check_version
Yes, it's backwards. (I was thinking about changing check_version into
a macro.)
> Perhaps che
The current regex.h says:-
|| /* If this bit is set, then an ending range point collating higher
|| than the starting range point, as in [z-a], is invalid.
|| If not set, then when ending range point collates higher than the
|| starting range point, the range is ignored. */
|| #
On Thu, Jul 14, 2005 at 11:34:51AM -0700, Paul Eggert wrote:
> How about if we use a name that is less likely to collide? For
> example, we use "lok", and the file names lok.h, lok.c, and lok.m4.
> Or perhaps you can think of a better name. ("gl-lock"? "gllock"? I
> like puns, so I'd go with "la
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> +const char *
>> +check_version (const char *req_version)
>> +{
>> + if (!req_version || strverscmp (req_version, VERSION) < 0)
>> +return VERSION;
>> +
>> + return NULL;
>> +}
>> ...
>> You will typically wrap the call to
Patrice Dumas <[EMAIL PROTECTED]> writes:
>> projects. I still think either a Lesser GNULib project is needed, or
>> that gnulib modules could become parametrized, or that gnulib could
>> contain multiple implementations of the same interface (with different
>> characteristics, license-wise, thre
I just checked FreeBSD libc, and it appears that fflush fails once its
underlying write fails with EAGAIN. So it appears that this approach
won't work under FreeBSD. That's not a good sign.
Isn't that a bug in FreeBSD?
We can try to work around bugs in various systems, but it is not
[EMAIL PROTECTED] (Karl Berry) writes:
> [lessergnulib]
>
> I remember this discussion (somewhat), but I was and am a bit puzzled.
> Is the only purpose is to make the functionality available under the
> LGPL?
Mostly, yes. I had some additional requirements, such as that all
code had to be t
Bruno Haible <[EMAIL PROTECTED]> writes:
> I propose to add a new module 'lock' to gnulib. It addresses these problems.
> It will be used in gettext 0.15.
Thanks very much for this. I have one minor quibble: the name "lock".
That's a generic name, and "lock.h" is likely to collide with file
name
Paul Eggert wrote:
> The first piece defines USE_UNLOCKED_IO and AC_LIBSOURCES
> unlocked-io.h, and is useful only in non-multithreaded apps. The 2nd
> piece requires gl_USE_SYSTEM_EXTENSIONS and checks for the
> declarations of clearerr_unlocked, etc. The 1st piece depends on the
> 2nd piece. A
Derek Price wrote:
> What is the policy for when to update it? With any change to the file?
Yes. The idea of this serial number is that when in two years you
encounter a patched copy of glob.m4 which appears to be a mix of serial 3
and serial 4 in gnulib, you are able
1. to see that it's a patc
Paul Eggert wrote:
> However, I just checked the translations for coreutils and got the
> following depressing statistics.
>
> Coreutils has 36 translations.
> ...
> 2 translate both to the empty string. Ouch!:
>
> no pt
If the PO file contains
msgstr ""
it actually means untranslated.
Paul Eggert wrote:
> xalloc-die, in contrast, doesn't have a substitute in gnulib; if you
> don't use gnulib xalloc-die but some gnulib code needs it, you have to
> implement it yourself (that is, the same API will not work unless you
> implement it). This seems to be what --avoid is for.
Yes, ex
Paul Eggert wrote:
>Derek Price <[EMAIL PROTECTED]> writes:
>
>
>
>>I didn't update the serial number. What's the procedure for macro
>>serial number updates?
>>
>>
>
>It's done by hand. I just did it for glob.m4 so you needn't worry about it.
>
>
What is the policy for when to update i
Derek Price <[EMAIL PROTECTED]> writes:
> I didn't update the serial number. What's the procedure for macro
> serial number updates?
It's done by hand. I just did it for glob.m4 so you needn't worry about it.
I dislike those serial numbers, myself -- I don't think they're worth
the trouble --
"Richard M. Stallman" <[EMAIL PROTECTED]> writes:
> Would you please include this module in gnulib?
That's the goal, but we need to iron out some technical difficulties
first, as there is an incompatibility with another gnulib module and
(more important) it's not yet clear that the proposed appro
Paul Eggert wrote:
>Other than that, it looks fine; please install.
>
>
Attached patch installed. I didn't update the serial number. What's
the procedure for macro serial number updates?
Regards,
Derek
Index: m4/glob.m4
===
RCS
Hi,
When you write a library which should be multithread-safe but needs some
global data (such as hash tables used as caches), you need some locking.
Problems are:
1. Your library should not become dependent on pthread, because in many
situations it will be used in single-threaded programs.
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> > I've just removed all tests for HAVE_FCNTL_H from coreutils.
>> > It's been gone in at least one place since coreutils-5.0 (2004-04-02)
[actually, that should have been 2003-04-02, not 2004]
>> The same applies to HAVE_UNISTD_H an
28 matches
Mail list logo
