On 09/14/2010 07:56 AM, Bruno Haible wrote:
Regarding use of openbsd* in *.m4 files: You might also want to look at
c-stack.m4
gc-random.m4
host-os.m4
if you have access to such a machine.
Yes, I just installed a MirBSD 10 VM, so I can test pretty much anything
related to this system.
* tests/test-sys_wait.c (main): Relax test.
* tests/test-stdlib.c (main): Likewise.
Signed-off-by: Eric Blake
---
This test was passing on Linux but failing on cygwin; with this
patch it now passes on both.
ChangeLog |4
tests/test-stdlib.c | 18 +++---
tes
Cygwin was failing test-vc-list-files-{cvs,git}.sh, because of
spurious output on stderr.
../../tests/test-vc-list-files-cvs.sh (exe_shim): skipping directory:
/home/eblake/m4-branch/build-aux
All because build-aux was a directory containing just scripts, and
no .exe extensions. This fixes it.
In general, merging:
f(fd,args) and at(dir,name,args)
should produce:
fdat(fd,dir,name,args)
* lib/utimens.h (gl_futimens): Delete, and move signature...
(fdutimens): ...here.
(fdutimensat): Rearrange signature.
(lutimensat): Rename variable for clarity.
* lib/fdutimensat.c (fdutimensat): Updat
On 09/17/10 13:28, Eric Blake wrote:
> I guess you're starting to convince me: the _only_ interface pattern we
> need is:
>
> fdutimens (fd, name, time)
> fdutimensat (fd, dir, name, time, flag)
> fdchmod (fd, name, mode)
> fdchmodat (fd, dir, name, mode, flag)
>
> because they are fd* wrappers a
On 09/17/2010 02:17 PM, Paul Eggert wrote:
On 09/17/2010 01:40 PM, Eric Blake wrote:
not to mention inconsistent with all the other *at functions
On the contrary, the current gnulib name "fdutimens" is inconsistent
with the usual POSIX naming conventions. In POSIX, functions like
"fdopen" p
> On 09/17/2010 01:40 PM, Eric Blake wrote:
>> not to mention inconsistent with all the other *at functions
On the contrary, the current gnulib name "fdutimens" is inconsistent
with the usual POSIX naming conventions. In POSIX, functions like
"fdopen" put the fd first. "fdutimens" (and "fdutime
On 09/17/2010 01:40 PM, Eric Blake wrote:
The GNU tar convention is clearer, since it reflects the
semantics better: try FD first, and use that if it works;
otherwise fall back on DIR+FILE. Could we please switch to
this order, while we're changing the API anyway?
Hmm; I'm reluctant to make the
On 09/17/2010 12:14 PM, Paul Eggert wrote:
Thanks for adding that functionality to gnulib. I prepared a patch
to have GNU tar use it, but found one more problem. fdutimensat
uses this signature:
fdutimensat (int dir, char const *file, int fd, [ other args ] )
whereas the similar function in G
Recent discussions have highlighted some interesting issues.
There's an aim to sync glibc with GNU regex. (Great! Any help needed?
Or is it just slow because syncing with glibc is a slow process?) As a
result, there seems to be a desire not to change the API or ABI
further. As far as syncing with
Thanks for adding that functionality to gnulib. I prepared a patch
to have GNU tar use it, but found one more problem. fdutimensat
uses this signature:
fdutimensat (int dir, char const *file, int fd, [ other args ] )
whereas the similar function in GNU tar uses the following
order instead.
fdu
Bruno,
On Fri, Sep 17, 2010 at 1:23 PM, Bruno Haible wrote:
>
>> checking for getrlimit declaration... (cached) install-shextern int getrlimit
>> (enum __rlimit_resource, struct rlimit *);
>
> In all macros that I wrote, you can replace
>
> AC_MSG_RESULT([${ac_t:-
> }...])
>
> with
>
> AC
Eric Blake writes:
> Marking a macro obsolete in autoconf means that new code should not rely
> on it, but that the macro still exists and still does the same thing it
> used to do, so that old code that used it will continue to work.
Oh, okay, I misunderstood obsolete. Never mind, then. :)
-
On 08/28/2010 04:42 AM, Bruno Haible wrote:
+** Newly obsolete macros
+ The following macros have been marked obsolete. New programs should use
+ the corresponding Gnulib modules. Gnulib not only detects the particular
+ portability problems but also provides complete workarounds.
+
+
On 06/14/2010 06:08 PM, Russ Allbery wrote:
Bruno Haible writes:
At this point, it would be a good idea to mark all AC_FUNC_* macros that
request an AC_LIBOBJ replacement as obsolete and refer the user to Gnulib
for both the macro and the workaround code (and the documentation).
Except maybe A
On 08/28/2010 03:56 AM, Bruno Haible wrote:
2010-08-28 Bruno Haible
* doc/autoconf.texi (Particular Functions): Mark AC_FUNC_ERROR_AT_LINE,
AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK, AC_FUNC_MKTIME, AC_FUNC_STRTOD
as obsolete and refer to Gnulib.
* NEWS: Mention the
On 08/28/2010 07:08 AM, Bruno Haible wrote:
2010-08-28 Bruno Haible
AC_FUNC_STRNLEN: more realistic cross-compilation guess
* lib/autoconf/functions.m4 (AC_FUNC_STRNLEN): Require
AC_CANONICAL_HOST. When cross-compiling, guess it works everywhere
except on AIX.
On 09/17/2010 08:29 AM, Eric Blake wrote:
If you like, I can install the obvious patch.
Nah, I just did this (ignore atflag if fd is valid, and let utimensat
rather than fdutimensat validate atflag if fd was invalid):
And this, to keep the testsuite happy.
diff --git i/ChangeLog w/ChangeLog
On 09/16/2010 05:45 PM, Paul Eggert wrote:
{
int result = 1;
+ if (atflag& ~AT_SYMLINK_NOFOLLOW)
+{
+ errno = EINVAL;
+ return -1;
+}
Thanks, but unfortunately this doesn't look quite right for GNU tar's purposes.
Tar specifies a nonnegative FD along with a flag equal t
On 09/17/2010 01:01 PM, Reuben Thomas wrote:
So, you're saying that all the features in the gnulib version of GNU
regex have been in glibc for sufficiently long that I am very unlikely
ever to use a system with a sufficiently old version of glibc that it
is lacking a feature (e.g. a particular sy
On 15 September 2010 02:54, Bruno Haible wrote:
> Hi Reuben,
>
>> > Why can't you instead add \ escaping to all existing regex meta-characters
>> > that occur in the string, at which point you get the same effect without a
>> > new flag?
>>
>> Because that is error-prone (in particular, I would ha
On 15 September 2010 02:43, Bruno Haible wrote:
> Hi Reuben,
>
>> #include "regex.h"
>> uses the included regex.h, not the system one.
>
> Yes.
>
>> There are obvious potential problems with this: if the
>> ABI changes you could end up with a header that doesn't match the
>> linked code, and even
22 matches
Mail list logo
