+ do
+ r = ioctl (pfd[i].fd, FIONREAD, &avail);
+ while (r == -1 && (errno == EAGAIN || errno == EINTR));
+ if (avail < 0)
+ avail = 0;
When ioctl returns -1, maybe because FIONREAD is not supported or so,
this loops endlessl
"Nelson H. F. Beebe" <[EMAIL PROTECTED]> writes:
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=773937&group_id=1107&atid=101107
That's a bug report against the LSB spec, not against lsbcc.
As I understand it, the bug was resolved by saying that
the LSB spec defers to POSIX,
So, what should we do about the untranslated strings in xstrtol.h? Is it safe
to make xstrtol depend on gettext-h, to pull in gettext.h in a header? I tried
to look for other uses of translated strings in a .h, but the only example is
w32spawn.h, and it doesn't even include error.h, let alone
> with http://directory.fsf.org/gzip.html; no mention there)... which, of
1.3.5 is mentioned on that Directory page as the "(devel)" release.
Anyway, I wrote rms about the lack of official releases in recent
decades.
k
On 9/28/06, Nelson H. F. Beebe <[EMAIL PROTECTED]> wrote:
Neither ISO C89 nor ISO C99 Standards mention any header files in the
location.
This lack-of-definition failure is readily exhibited:
% cat bug-lsbcc.c
#include
size_t p;
% lsbcc -c bug-lsbcc.c
Paolo Bonzini wrote:
> + do
> + r = ioctl (pfd[i].fd, FIONREAD, &avail);
> + while (r == -1 && (errno == EAGAIN || errno == EINTR));
> + if (avail < 0)
> + avail = 0;
When ioctl returns -1, maybe because FIONREAD is not supported or s
Jim Meyering wrote:
> > The above makes me think your tools have incomplete "weak_alias" support,
> > so that lib/strndup.o ends up with a definition for a function
> > named __strndup, rather than rpl_strndup.
Huh? 'weak_alias' should never be defined, except inside glibc (i.e. if
_LIBC).
> No o
Paul Eggert <[EMAIL PROTECTED]> writes about the failure of
in the Linux Standards Base to define size_t.
>> ...
>> "Nelson H. F. Beebe" <[EMAIL PROTECTED]> writes:
>>
>> > This is the same problem as before with size_t being used before
>> > it is defined with this compiler.
>>
>> is one thing;
Ralf Wildenhues wrote:
> I missed this case the last time (as the test isn't executed on my
> system). OK to apply?
Yes. I applied this.
*** intmax.m4 24 Feb 2005 20:12:45 - 1.5
--- intmax.m4 28 Sep 2006 20:17:30 -
***
*** 1,4
! # intmax.m4 serial 2 (gettext-0.1
Paul Eggert wrote:
> the getlogin_r.m4 change (adding
> AC_REQUIRE([AC_GNU_SOURCE])) looks a bit GNU-specific. Wouldn't it be
> better to depend on the 'extensions' module instead? That would catch
> similar problems in non-GNU systems.
>
> (Come to think of it, doesn't a similar argument apply
Paul Eggert wrote:
> gl_SIZE_MAX should be retired, and I assume it will be once the next
> gettext release is out.
Code used in the intl/ directory will continue to use gl_SIZE_MAX for a
while, so that the autoconf checks done by AM_GNU_GETTEXT don't get too
time consuming.
But in other modules,
Jim Meyering <[EMAIL PROTECTED]> writes:
> I noticed that mkdir-p.c includes dirchownmod.c, rather than
> dirchownmod.h. I think that must have been unintentional
No kidding! Wow. Thanks for fixing that.
Since switching coreutils to use gnulib-tool, the lib directory
has had no automatically-generated dependencies.
I finally noticed it today when modifying a lib/*.h header file
and finding that things weren't recompiled.
IMHO, gnulib-tool should leave the default (generate them),
but provide an op
Paolo Bonzini <[EMAIL PROTECTED]> writes:
> I don't have CVS access to gnulib; anyway I preferred to have a second
> opinion.
I added you just now. Please install that patch, as it looks good.
<[EMAIL PROTECTED]> writes:
> http://permalink.gmane.org/gmane.comp.lib.gnulib.bugs/7179
> ...
> When building coreutils-5.97 from the long available stable tarball, make
> runs bison and works with Apple's provided versions of the tools.
That's not what that URL says. It says you built from CVS
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Hello Jim,
>
>> Is there any type of file system where readdir works?
>
> Yes. It does work on vfat file systems. No readdir bug reproducible there.
Thanks for checking.
>> What version of Darwin are you using?
>
> Darwin 7.9.0 = MacOS X 10.3.9.
>
> I wro
FYI,
I noticed that mkdir-p.c includes dirchownmod.c, rather than
dirchownmod.h. I think that must have been unintentional, since
it leads to warnings from ranlib on some systems.
Once changed, I found that it also needs , for
its close prototype.
Here's the patch:
2006-09-28 Jim Meyering <[EM
Hello Jim,
> Is there any type of file system where readdir works?
Yes. It does work on vfat file systems. No readdir bug reproducible there.
> What version of Darwin are you using?
Darwin 7.9.0 = MacOS X 10.3.9.
I wrote:
> In the run test, you can use /bin/rm, since /bin/rm has the same bug
>
Jim Meyering <[EMAIL PROTECTED]> wrote:
> "Gabor Z. Papp" <[EMAIL PROTECTED]> wrote:
> ...
>> gcc -std=gnu99 -g -O2 -Wl,--as-needed -o cp cp.o copy.o cp-hash.o
>> ../lib/libcoreutils.a ../lib/libcoreutils.a
>> ../lib/libcoreutils.a(xstrndup.o): In function `xstrndup':
>> /home/gzp/src/coreutil
* m4/poll.m4: Test for sys/ioctl.h and sys/filio.h.
* lib/poll.c (poll) [__APPLE__]: Use FIONREAD instead of MSG_PEEK.
Looks reasonable to me. But you don't need our permission to install;
you're the maintainer.
I don't have CVS access to gnulib; anyway I preferred to
20 matches
Mail list logo
