headers
Paolo Bonzini | 1 Jul 2011 08:19
Picon
Gravatar

Re: mingw: test-poll pipe part fails

On 06/30/2011 07:56 PM, Eric Blake wrote:
> >  Yes, Windows pipes are that broken.:(
> >
> >  Using socketpair is a possibly good idea, but I would do it on
> >  libvirtd only.  I don't know exactly how libvirtd uses this pipe, but
> >  perhaps it can be changed to an eventfd-like abstraction that can be
> >  used with both Windows and Unix.  This is similar to Eric's
> >  suggestion, but without the pipe at all.  It would also be a
> >  libvirtd-specific suggestion.
>
> I'm wondering if the problem here is that libvirt is trying to use the
> pipe-to-self mechanism as a fundamental event loop idiom.  That is, the
> reason libvirt is calling poll is in order to minimize CPU until
> something interesting happens, where interesting includes needing to
> wake up a helper thread to do an action inside locks in response to the
> receipt of a signal.
>
> Maybe you are on to something, and replacing all uses of pipe() with
> virPipeToSelf() (which uses pipe() for efficiency on Linux, but
> socketpair() on mingw), would allow libvirt to continue to use the
> pipe-to-self idiom while also using fds that can actually be poll'd on
> mingw.

Perhaps gnulib can provide an eventfd abstraction (or better, a slight 
variation that only returns 0/1) to be used for pipe-to-self.  In 
Windows it can use an autoreset event, in Linux an eventfd, in Unix a pipe.

Paolo
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Blake | 1 Jul 2011 18:27
Picon
Favicon
Gravatar

[PATCH] snprintf: guarantee %1$d, for libintl

Newer mingw (but not yet mingw64) provides two flavors of
snprintf: _snprintf defers straight to msvcrt, which has broken
return value and does not understand %llu or %zu; and snprintf,
which fixes these two bugs but does not understand %1$s.

Libintl specifically favors _snprintf, with broken return value,
even when compiled on mingw with a fixed snprintf, because the
only behavior which it wants to fix is %1$s handling.  But this
means that the replacement libintl_snprintf has a broken return.

If one uses the 'snprintf-posix' module, then the gnulib
replacement kicks in, and does everything that libintl needs, so
on mingw, <libintl.h> specifically avoids overriding snprintf if
it detected that gnulib replaced snprintf.  However, if one only
uses the 'snprintf' module and also uses libintl, this means
there are two problems:

1. The gnulib 'snprintf' module does not replace the mingw
snprintf function, because it has proper return values, while the
libintl.h header knows that %1$d is broken so snprintf must be
replaced, with the end result that the application gets the
libintl replacement snprintf with broken return values in spite
of the gnulib module.

2. Conversely, if the application did '#define snprintf snprintf',
that would be enough to make libintl avoid installing its own
replacement because libintl would see the define as a sign that
gnulib is happy with snprintf.  However, because gnulib didn't
enforce %1$s, users can end up with translated strings that break
when passed to the native snprintf.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Simon Josefsson | 1 Jul 2011 19:38
Favicon
Gravatar

Re: would like to break sys_select's dependency on sys_socket

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> On 06/30/11 04:45, Simon Josefsson wrote:
>> Is it native Windows or MinGW?
>
> Sorry, I don't know Windows well enough to answer that question.
> For Emacs, Windows support is done completely differently:
> it doesn't use gnulib, and it is done by other people, and I
> try to avoid thinking about it as much as I can.

The reason I asked is that gnulib supports Mingw, so we shouldn't break
things for it.  However, I haven't seen anything that indicates the
dependencies you mentioned were needed on Mingw.

Anyway, I guess we'll find out eventually if someone reports a problem
for mingw.  I'll try a Windows XP mingw gnulib boot now, it was a long
time ago since I tried it.

/Simon
Permalink | Reply | 2 comments |
headers
Ludovic Courtès | 1 Jul 2011 22:14
Picon

Re: PATH_MAX and test-stat.h

Hello,

karl <at> freefriends.org (Karl Berry) skribis:

> I am aware that conceptually there is no PATH_MAX on Hurd and no
> requirement for it to be a smallish constant, but it seems to me that
> any real-world system has to define PATH_MAX as a reasonable constant
> simply for compatibility with all the code that has been written with
> that assumption over the last 30+ years.

As you probably know, this is an instantiation of the GCS (info
"(standards) Semantics"):

  Avoid arbitrary limits on the length or number of _any_ data structure,
  including file names, lines, files, and symbols, by allocating all data
  structures dynamically.  In most Unix utilities, "long lines are
  silently truncated".  This is not acceptable in a GNU utility.

Thanks,
Ludo’.
Permalink | Reply | 0 comments |
headers
Simon Josefsson | 2 Jul 2011 08:44
Favicon
Gravatar

cygwin build report

Simon Josefsson <simon <at> josefsson.org> writes:

> Anyway, I guess we'll find out eventually if someone reports a problem
> for mingw.  I'll try a Windows XP mingw gnulib boot now, it was a long
> time ago since I tried it.

I meant a cygwin build..  Here is the build log:

http://autobuild.josefsson.org/gnulib/log-201107020516468723000.txt

This is on a fully up to date Windows XP and Cygwin as of 2011-07-01.
As can be seen in the log above, the build was done with "gnulib-tool
--create-testdir --with-tests --without-longrunning-tests".

First, some interesting statistics on execution time (hardware is an
atom based Dell Mini 10v laptop):

gnulib-tool: 8h47m
./configure: 48m
make: 35m
make check: 9m

The failures below seems relatively minor, so I think we are in quite
good shape.

There are two suspicious tests:

1)
./test-copy-acl.sh: line 230:  3828 Segmentation fault      (core dumped) setfacl -d group:0 tmpfile0
setfacl: illegal acl entries
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dagobert Michelsen | 2 Jul 2011 11:18
Favicon
Gravatar

Problem detecting libsigsegv on gawk 4.0.0 on Solaris 9 Sparc w/Sun Studio 12

Hi,

I am trying to compile gawk 4.0.0 on Solaris 9 Sparc with Sun Studio 12 and
noticed that the presence of libsigsegv is not properly detected:

> configure:9825: checking for libsigsegv
> configure:9847: /opt/SUNWspro/bin/cc -o conftest -xO3 -m32 -xarch=386 -Xc -I/opt/csw/include -m32
-xarch=386 -L/opt/csw/lib conftest.c /opt/csw/lib/libsigsegv.so -R/opt/csw/lib -lm  >&5
> "/usr/include/ia32/sys/reg.h", line 297: syntax error before or at: uint64_t

This is due to a missing include in the detection code as a definition of uint64_t
is missing. This could be solved by including inttypes.h in the testcode.

> | #define HAVE_LIBM 1
> | /* end confdefs.h.  */
> | #include <sigsegv.h>

#include <inttypes.h>   <- adding this works

> | int
> | main ()
> | {
> | sigsegv_deinstall_handler();
> |   ;
> |   return 0;
> | }

As this is the expansion of gl_LIBSIGSEGV I cc'ed bug-gnulib.

Best regards
(Continue reading)

Permalink | Reply | 9 comments |
headers
Dagobert Michelsen | 2 Jul 2011 12:05
Favicon
Gravatar

Re: Problem detecting libsigsegv on gawk 4.0.0 on Solaris 9 Sparc w/Sun Studio 12

Hi,

Am 02.07.2011 um 11:18 schrieb Dagobert Michelsen:
> I am trying to compile gawk 4.0.0 on Solaris 9 Sparc with Sun Studio 12 and
> noticed that the presence of libsigsegv is not properly detected:
> 
>> configure:9825: checking for libsigsegv
>> configure:9847: /opt/SUNWspro/bin/cc -o conftest -xO3 -m32 -xarch=386 -Xc -I/opt/csw/include -m32
-xarch=386 -L/opt/csw/lib conftest.c /opt/csw/lib/libsigsegv.so -R/opt/csw/lib -lm  >&5
>> "/usr/include/ia32/sys/reg.h", line 297: syntax error before or at: uint64_t
> 
> This is due to a missing include in the detection code as a definition of uint64_t
> is missing. This could be solved by including inttypes.h in the testcode.
> 
>> | #define HAVE_LIBM 1
>> | /* end confdefs.h.  */
>> | #include <sigsegv.h>
> 
> #include <inttypes.h>   <- adding this works
> 
>> | int
>> | main ()
>> | {
>> | sigsegv_deinstall_handler();
>> |   ;
>> |   return 0;
>> | }
> 
> As this is the expansion of gl_LIBSIGSEGV I cc'ed bug-gnulib.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bruno Haible | 2 Jul 2011 13:56

Re: Problem detecting libsigsegv on gawk 4.0.0 on Solaris 9 Sparc w/Sun Studio 12

[CCing bug-libsigsegv. This is a reply to
<http://lists.gnu.org/archive/html/bug-gnulib/2011-07/msg00008.html>].

Dagobert Michelsen wrote:
> I am trying to compile gawk 4.0.0 on Solaris 9 Sparc with Sun Studio 12 and
> noticed that the presence of libsigsegv is not properly detected:
> 
> > configure:9825: checking for libsigsegv
> > configure:9847: /opt/SUNWspro/bin/cc -o conftest -xO3 -m32 -xarch=386 -Xc -I/opt/csw/include -m32
-xarch=386 -L/opt/csw/lib conftest.c /opt/csw/lib/libsigsegv.so -R/opt/csw/lib -lm  >&5
> > "/usr/include/ia32/sys/reg.h", line 297: syntax error before or at: uint64_t
> 
> 
> This is due to a missing include in the detection code as a definition of uint64_t
> is missing. This could be solved by including inttypes.h in the testcode.
> 
> > | #define HAVE_LIBM 1
> > | /* end confdefs.h.  */
> > | #include <sigsegv.h>
> 
> #include <inttypes.h>   <- adding this works
> 
> > | int
> > | main ()
> > | {
> > | sigsegv_deinstall_handler();
> > |   ;
> > |   return 0;
> > | }
>
(Continue reading)

Permalink | Reply | 7 comments |
headers
Bruno Haible | 2 Jul 2011 17:54

good place for blogging on C/POSIX programming?

Hi,

Which places do you read, or do have have occiasionally read, and on which
lessons / tutorials about C programming with POSIX API would be expected or
welcome?

I've written some text about "How to read from standard input" [1] (lessons
learned by discussing with Pádraig Brady) and would like to publish that,
in a medium that does not come with advertisements.

Would it be OK and appropriate to create a "News" section in the Savannah
project page for gnulib and post it there? Then it would appear on
planet.gnu.org, right? Or should the "News" section not be abused like that?

Bruno

[1] http://www.haible.de/bruno/mycat-blog.txt
--

-- 
In memoriam Andrés Escobar <http://en.wikipedia.org/wiki/Andrés_Escobar>
Permalink | Reply | 14 comments |
headers
Paul Eggert | 2 Jul 2011 18:19
Favicon

Re: good place for blogging on C/POSIX programming?

On 07/02/11 08:54, Bruno Haible wrote:
> Would it be OK and appropriate to create a "News" section in the Savannah
> project page for gnulib and post it there? Then it would appear on
> planet.gnu.org, right? Or should the "News" section not be abused like that?

I think it'd be fine to do that, and wouldn't be abusing the "News"
section.  Perhaps the "News" section should contain a brief pointer
to the real thing, rather than the whole thing?  The whole thing could
be put into the gnulib manual, perhaps.  (I don't know how planet.gnu.org
works; I never read it I'm afraid.)
Permalink | Reply | 0 comments |

Gmane