James Youngman wrote:
> * modules/stat-size: New module. Provides macros for accessing
> file size information in instances of struct stat. Depends on the
> fileblocks module because it calls st_blocks.
> * lib/stat-size.h: New file, adapted from coreutils' system.h.
> * doc/gnulib.texi: Include
On Thu, Jun 9, 2011 at 11:01 AM, Jim Meyering wrote:
> Bruno Haible wrote:
>> Apparently, although fd 2 was closed in the parent process, it is open again
>> in the child process. This must happen in the exec* calls, since posix_spawn
>
> This is a security (mis)feature of HP-UX.
> I noticed it w
* modules/stat-size: New module. Provides macros for accessing
file size information in instances of struct stat. Depends on the
fileblocks module because it calls st_blocks.
* lib/stat-size.h: New file, adapted from coreutils' system.h.
* doc/gnulib.texi: Include stat-size.texi.
* doc/stat-size.
On Thu, Jun 9, 2011 at 2:08 AM, Bruno Haible wrote:
> Actually AC_STRUCT_ST_BLOCKS is already invoked from the module 'fileblocks',
> and this module is among the dependencies of your new module. So, I think
> you can just drop this invocation here.
Thanks for the advice, I'll send an updated pat
I guess I don't follow the purpose of involving glibc now. Because
whatever changes they might or might not agree to make, they obviously
won't reach user systems for years. So for anyone to make use of the
new options, it all has to be implemented in gnulib regex anyway. If
the goal is to minim
Bruno Haible wrote:
>> With my proposal, distros/people that use --with-included-regex would
>> get understandable semantics + no equivalence classes
>> ...
>> locale behavior of regex are irremediably
>> broken. For example, when you have a collation element, you can match
>> it using ranges (e.g
Hi,
I've released a new stable snapshot. See attached NEWS.stable for details.
At Bruno's suggestion, I avoided all the strerror-related patches.
As a consequence, the period over which I cherry-picked patches is
longer than normal, which explains why there are an unusually large
number of cherry
On 06/10/11 11:37, Bruno Haible wrote:
> Hi,
>
> Markus Duft wrote:
>> long long double is broken.
>
> You surely mean "long double"? There is no such type as "long long double"
> in C.
right; long long double is too long :)
>
>> this bites me in the gnulib vasnprintf implementation, which cal
Hi,
Markus Duft wrote:
> long long double is broken.
You surely mean "long double"? There is no such type as "long long double"
in C.
> this bites me in the gnulib vasnprintf implementation, which calls snprintf
> from libc which immediately crashes ... :(
gnulib and coreutils code now assume
Hi All.
This note is really encouraging - I was unaware of this change in the
latest standard. I will be revising gawk and its documentation to reflect
this, including the links Paul has supplied.
I have not been following the details of the rest of the discussion; esp.
as things have been arriv
10 matches
Mail list logo
