Re: version control system
Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> Would anyone be averse to switching gnulib development from CVS to git? >> I switched coreutils a month ago and am very happy with the result. > > Do you have a comparison of git with mercurial, monotone, bzr? There are *lots* of git vs. mercurial comments on the fedora-maintainers thread I referred you to. Here's a well-written piece from someone else who's switched to git: http://keithp.com/blog/Repository_Formats_Matter.html As for monotone and bzr, here's a dated (~6mo-1yr-old) comparison of decentralized VCS: http://zooko.com/revision_control_quick_ref.html I searched a little, e.g., http://www.google.com/search?&q=%22distributed+version+control%22+comparison but didn't find anything compelling. Even a survey that's just 6 months old is seriously out of date. That was evident in the fedora-maintainers discussion. > What kind of support does savannah offer? The most interesting support > features IMO would be: > - automatic daily backup, Not relevant. With git or hg, anyone who pulls gets the entire repository. If you want backups, just arrange to pull regularly, and save each copy on your favorite backup medium. > - web interface similar to viewcvs. Maybe you didn't see this savannah (sv) link? http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=summary
Re: version control system
Jim Meyering <[EMAIL PROTECTED]> wrote: > Bruno Haible <[EMAIL PROTECTED]> wrote: >> Jim Meyering wrote: >>> Would anyone be averse to switching gnulib development from CVS to git? >>> I switched coreutils a month ago and am very happy with the result. >> >> Do you have a comparison of git with mercurial, monotone, bzr? Here's a comparison of mercurial and bzr, from May 2006, so it's five months old and probably significantly out of date by now: http://lists.freestandards.org/pipermail/lsb-futures/2006-May/002080.html Here's a final link with comparisons that look accurate. See the "Comparison of CVS, GIT, Subversion, and SVK" table at the bottom of the page: http://wiki.winehq.org/HackingTips
Re: git for Darwin?
<[EMAIL PROTECTED]> wrote: > On 2006-11-21 07:56:27 -0600, Jim Meyering <[EMAIL PROTECTED]> said: >> Would anyone be averse to switching gnulib development from CVS to git? >> I switched coreutils a month ago and am very happy with the result. > > I found this Fink pkg -- is it the same thing? > http://pdb.finkproject.org/pdb/package.php/git Probably. You'd have to look. > If so, as you can see, it's still regard as "unstable". > And users still on Panther or earlier won't have a pkg. ... > AFAIK we don't have an interface for this SCM into XCode > as we already do for cvs, svn, and perforce. Unless you are checking in changes for upstream gnulib, this change would not force you to learn about or use git. As with coreutils, if/when we switch gnulib to another version control system, we would require that the current CVS repository remain sync'd (automatically) with the new master (e.g., git) repository.
clock_time.m4, euidaccess.m4: tiny changes
FYI, I've just checked these in: * m4/clock_time.m4 (gl_CLOCK_TIME): Quote AC_SUBST argument. * m4/euidaccess.m4 (gl_PREREQ_EUIDACCESS): Likewise. Index: m4/clock_time.m4 === RCS file: /sources/gnulib/gnulib/m4/clock_time.m4,v retrieving revision 1.7 diff -u -p -r1.7 clock_time.m4 --- m4/clock_time.m42 Mar 2006 07:36:41 - 1.7 +++ m4/clock_time.m422 Nov 2006 13:38:19 - @@ -1,10 +1,14 @@ -# clock_time.m4 serial 7 -dnl Copyright (C) 2002, 2003, 2004, 2005, 2006 Free Software Foundation, Inc. +# clock_time.m4 serial 8 +dnl Copyright (C) 2002-2006 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, dnl with or without modifications, as long as this notice is preserved. -# Check for clock_gettime and clock_settime, and sets LIB_CLOCK_GETTIME. +# Check for clock_gettime and clock_settime, and set LIB_CLOCK_GETTIME. +# For a program named, say foo, you should add a line like the following +# in the corresponding Makefile.am file: +# foo_LDADD = $(LDADD) $(LIB_CLOCK_GETTIME) + AC_DEFUN([gl_CLOCK_TIME], [ dnl Persuade glibc and Solaris to declare these functions. @@ -20,7 +24,7 @@ AC_DEFUN([gl_CLOCK_TIME], AC_SEARCH_LIBS(clock_gettime, [rt posix4], [test "$ac_cv_search_clock_gettime" = "none required" || LIB_CLOCK_GETTIME=$ac_cv_search_clock_gettime]) -AC_SUBST(LIB_CLOCK_GETTIME) +AC_SUBST([LIB_CLOCK_GETTIME]) AC_CHECK_FUNCS(clock_gettime clock_settime) LIBS=$gl_saved_libs ]) Index: m4/euidaccess.m4 === RCS file: /sources/gnulib/gnulib/m4/euidaccess.m4,v retrieving revision 1.5 diff -u -p -r1.5 euidaccess.m4 --- m4/euidaccess.m42 May 2005 07:00:50 - 1.5 +++ m4/euidaccess.m422 Nov 2006 13:38:19 - @@ -1,5 +1,5 @@ -# euidaccess.m4 serial 6 -dnl Copyright (C) 2002, 2003, 2004, 2005 Free Software Foundation, Inc. +# euidaccess.m4 serial 7 +dnl Copyright (C) 2002-2006 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, dnl with or without modifications, as long as this notice is preserved. @@ -41,7 +41,7 @@ AC_DEFUN([gl_PREREQ_EUIDACCESS], [ AC_SEARCH_LIBS(eaccess, [gen], [test "$ac_cv_search_eaccess" = "none required" || LIB_EACCESS=$ac_cv_search_eaccess]) -AC_SUBST(LIB_EACCESS) +AC_SUBST([LIB_EACCESS]) AC_CHECK_FUNCS(eaccess) LIBS=$gl_saved_libs ])
kernel_sinl bug?
Looking at the "kernel_sinl" function in "sincosl.c" file I found that
the limit value for choosing the computation method is wrong with
respect of the remaining code:
kernel_sinl (long double x, long double y, int iy)
{
...
if (x < 0.148375L)/* |x| < 0.1484375 */
The correct line should be:
if (x < 0.1484375L)/* |x| < 0.1484375 */
Probably a better approach would be defining this limit as a macro.
Regards,
Bob
Re: git for Darwin?
this change would not force you to learn about or use git. Granting that git is a zillion times better than cvs, even so, far fewer people can contribute to a git repository than cvs. As I understand it, the reason for the proposal is because branches are supported better in git. But isn't wanting to make branches tantamount to making releases? And isn't that something we already concluded (a dozen times) that we do not want to do for gnulib? Do we want to change the entire infrastructure to support it in an "ideal" way? Are the simpler solutions suggested by Bruno (don't run cvs update) and/or Paul (having a special gnulib-srcdir) for the run-up to a release unlivable? karl
Re: git for Darwin?
[EMAIL PROTECTED] (Karl Berry) wrote: > this change would not force you to learn about or use git. > > Granting that git is a zillion times better than cvs, even so, far fewer > people can contribute to a git repository than cvs. > > As I understand it, the reason for the proposal is because branches are > supported better in git. But isn't wanting to make branches tantamount > to making releases? And isn't that something we already concluded (a > dozen times) that we do not want to do for gnulib? Do we want to > change the entire infrastructure to support it in an "ideal" way? > > Are the simpler solutions suggested by Bruno (don't run cvs update) > and/or Paul (having a special gnulib-srcdir) for the run-up to a release > unlivable? Hi Karl, My suggestion to use a dVCS was mostly independent of branching. As I said in reply to Eric, just specifying a date should be good enough for purposes of "tagging". No need for tags after all. cvs can checkout based on a date, after all. Git is good for lots of reasons, not least of which, each developer has the entire repository at his/her fingertips (locally), common operations are blindingly fast (e.g., no network latency for diffs) For me, the main reasons involve immediate access to logs and history, as well as speedy diffs. Obviously I have not explained the usage scenario clearly enough. I'll try again. There would be two repositories, one CVS, one git. They would be kept in sync automatically. People would be able to get the latest sources by checking out or updating from either of them. Patches made against one would apply equally well against the other (but we'd commit changes only against the git repo), so contributing by sending patches would still work just as well. I.e., you could continue to use CVS and to run "cvs update" to get the latest. The only difference comes if you want to check in changes. Then you'd need to learn some git basics and end up doing "git commit file..." instead of "cvs commit file...". clear as mud?
Re: [bug-gnulib] kernel_sinl bug?
Robinson Mittmann wrote:
> Looking at the "kernel_sinl" function in "sincosl.c" file I found that
> the limit value for choosing the computation method is wrong with
> respect of the remaining code:
>
> kernel_sinl (long double x, long double y, int iy)
> {
> ...
> if (x < 0.148375L)/* |x| < 0.1484375 */
>
> The correct line should be:
>
> if (x < 0.1484375L)/* |x| < 0.1484375 */
Thanks, this is indeed a typo in the code (since the comments agree with the
value that the current glibc sources use). I've applied your fix.
> Probably a better approach would be defining this limit as a macro.
It would be, if this code was under heavy development.
Bruno
2006-11-22 Robinson Mittmann <[EMAIL PROTECTED]> (tiny change)
* lib/sincosl.c (kernel_sinl): Fix typo in threshold.
*** lib/sincosl.c 14 May 2005 06:03:58 - 1.3
--- lib/sincosl.c 22 Nov 2006 18:23:16 -
***
*** 1,5
/* Quad-precision floating point trigonometric functions on <-pi/4,pi/4>.
!Copyright (C) 1999 Free Software Foundation, Inc.
This file is part of the GNU C Library.
Contributed by Jakub Jelinek <[EMAIL PROTECTED]>
--- 1,5
/* Quad-precision floating point trigonometric functions on <-pi/4,pi/4>.
!Copyright (C) 1999, 2006 Free Software Foundation, Inc.
This file is part of the GNU C Library.
Contributed by Jakub Jelinek <[EMAIL PROTECTED]>
***
*** 113,119
sign = -1;
}
! if (x < 0.148375L)/* |x| < 0.1484375 */
{
/* Argument is small enough to approximate it by a Chebyshev
polynomial of degree 17. */
--- 113,119
sign = -1;
}
! if (x < 0.1484375L) /* |x| < 0.1484375 */
{
/* Argument is small enough to approximate it by a Chebyshev
polynomial of degree 17. */
Re: git for Darwin?
My suggestion to use a dVCS was mostly independent of branching. Oh. Sorry, I didn't get that. but we'd commit changes only against the git repo That was my point. Have you written a cheat sheet for coreutils git users? Or maybe one exists independently? You know, (a) how to check out (b) how to update (c) how to commit Without surrounding foofaraw about how great it is or how the repository can be distributed all over the Internet, etc. clear as mud? Indeed :). I can't say that logs, history, and diffs are terribly important to me, but that's because I'm a very minor developer these days. So if the consensus among the heavy-duty users like you and Paul and Bruno is go git it, I'll come along for the ride, of course. Thanks, k
Re: version control system
> > Do you have a comparison of git with mercurial, monotone, bzr? Reading the wikipedia articles on each of them http://en.wikipedia.org/wiki/Git_(software) http://en.wikipedia.org/wiki/Mercurial_(software) http://en.wikipedia.org/wiki/Monotone_(software) http://en.wikipedia.org/wiki/Bazaar_(vcs) it convinced me of two major advantages of git: - speed, - community support: 3 web interfaces, several GUIs. > Here's a well-written piece from someone else who's switched to git: > > http://keithp.com/blog/Repository_Formats_Matter.html ... which adds a third major advantage: - robustness of the repository structure. > > - automatic daily backup, > > Not relevant. > With git or hg, anyone who pulls gets the entire repository. Hmm, but if the central repository got lost, and was restored through - say - my copy, everyone would see my temporary branches, and see the patches in the order in which I pulled them and merged them with my patches, which is not the original order. No? Bruno
backup question
Hello Sylvain, Can you please tell: Are the git repositories visible in http://git.sv.gnu.org/gitweb/ stored on a disk that is regularly backed up? If so, with which frequency (daily, weekly, monthly)? I'm asking because we are considering moving gnulib to this area as well. Bruno
Re: [bug-gnulib] git for Darwin?
[EMAIL PROTECTED] wrote: > It'd be a blank slate for me, learning git from ground up. There are two tutorials for people with a CVS background: http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html http://git.or.cz/course/cvs.html > How well/easily would git sessions work thru firewalls & such? Easier: For CVS you had to ask your firewall admin to open the port, since it was below 1024. AFAIK, the git port is > 1024. Bruno
Re: [bug-gnulib] git for Darwin?
Karl Berry wrote: > As I understand it, the reason for the proposal is because branches are > supported better in git. But isn't wanting to make branches tantamount > to making releases? The reasons to make branches are: 1) for temporary small changes, testing etc., 2) for adding features that are more experimental than those on the HEAD/trunk. 3) for cooling down a release. Reasons 2) and 3) are well-known from CVS; reason 1) is new. One of the situations where a distributed VCS will be useful for me is when travelling with a laptop without internet connection. I can then make commits that will be pulled in the main repository later. (OK, I expect conflicts in the ChangeLog file; let's see how well the merge strategies will work...) Bruno
Re: coreutils-6.5: yet another C89 problem
Matthew Woehlke <[EMAIL PROTECTED]> writes: > I could probably do it on > this box, but since it's Linux, it would still be with gcc. Even that would be helpful, since our current buildbot doesn't do the particular combination of GCC options you're interested in.
Re: coreutils-6.5: yet another C89 problem
Paul Eggert wrote: Matthew Woehlke writes: I could probably do it on this box, but since it's Linux, it would still be with gcc. Even that would be helpful, since our current buildbot doesn't do the particular combination of GCC options you're interested in. Ok, happen to have a quick how-to? (A cron job that *doesn't* mail me unless there is a problem would be nice :-).) -- Matthew "Two IIRC's must make a right" -- Larry Hall (paraphrased)
Re: version control system
Bruno Haible <[EMAIL PROTECTED]> wrote: ... >> > - automatic daily backup, >> >> Not relevant. >> With git or hg, anyone who pulls gets the entire repository. > > Hmm, but if the central repository got lost, and was restored through - say - > my copy, everyone would see my temporary branches, No problem. Just make a copy (clone your repo) and remove your temporary branches in the copy before publishing it. > and see the patches in the > order in which I pulled them and merged them with my patches, which is not > the original order. No? No. Deltas in a git repository can't get "out of order".
Re: git for Darwin?
[EMAIL PROTECTED] (Karl Berry) wrote: ... > but we'd commit changes only against the git repo > > That was my point. Have you written a cheat sheet for coreutils git > users? Or maybe one exists independently? You know, > (a) how to check out On the command line, it's probably best to start off using cogito wrappers. That hides git's "index" concept, which can be a little annoying, at first. Run this to create a checked-out directory named "any-name-you-want": cg-clone git://git.sv.gnu.org/coreutils any-name-you-want or omit the destination dir-name to create a directory named "coreutils": cg-clone git://git.sv.gnu.org/coreutils > (b) how to update cg-pull > (c) how to commit [into your local copy of the repository] cg-commit Browsing a local repository, it can be nice to use one of the GUI-based tools, like qgit or gitk. But there's much more. There are many use cases outlined in git's own Documentation directory. E.g., http://www.kernel.org/pub/software/scm/git/docs/tutorial.html http://www.kernel.org/pub/software/scm/git/docs/everyday.html
coreutils 6.6 HP-UX build error
I got the following error (in gnulib) building coreutils 6.6 on HP-UX.
source='fts.c' object='fts.o' libtool=no \
DEPDIR=.deps depmode=hp /bin/sh ../build-aux/depcomp \
cc -I. -I/home/install/gnu/hp700_hpux/include -g -c fts.c
cc: "fts.c", line 734: error 1654: Expression type is too large for switch
expression.
cc: "fts.c", line 736: error 1653: Case label too big for the type of the
switch expression
cc: "fts.c", line 739: error 1653: Case label too big for the type of the
switch expression
I'm suggesting the following patch (formed by hand, sorry if the line
numbers are off!):
diff -ur lib/fts.c
--- lib/fts.c
+++ lib/fts.c
@@ -731,16 +731,10 @@
check_for_dir:
if (p->fts_info == FTS_NSOK)
{
- switch (p->fts_statp->st_size)
- {
- case FTS_STAT_REQUIRED:
- p->fts_info = fts_stat(sp, p, false);
- break;
- case FTS_NO_STAT_REQUIRED:
- break;
- default:
- abort ();
- }
+ if (p->fts_statp->st_size == FTS_STAT_REQUIRED)
+ p->fts_info = fts_stat(sp, p, false);
+ else if (p->fts_statp->st_size != FTS_NO_STAT_REQUIRED)
+ abort ();
}
sp->fts_cur = p;
if (p->fts_info == FTS_D)
--
Matthew
"Two IIRC's must make a right" -- Larry Hall (paraphrased)
Re: coreutils 6.6 HP-UX build error
Matthew Woehlke <[EMAIL PROTECTED]> wrote: > I got the following error (in gnulib) building coreutils 6.6 on HP-UX. > >> source='fts.c' object='fts.o' libtool=no \ >> DEPDIR=.deps depmode=hp /bin/sh ../build-aux/depcomp \ >> cc -I. -I/home/install/gnu/hp700_hpux/include -g -c fts.c >> cc: "fts.c", line 734: error 1654: Expression type is too large for switch >> expression. >> cc: "fts.c", line 736: error 1653: Case label too big for the type of the >> switch expression >> cc: "fts.c", line 739: error 1653: Case label too big for the type of the >> switch expression > > I'm suggesting the following patch (formed by hand, sorry if the line > numbers are off!): Thanks for the report and patch. What version of HP-UX (and, if possible, the compiler) is that? It must be rather old. I know the existing code compiles fine with the compilers from HP-UX 11.11 and HP-UX 11.23.
Re: coreutils 6.6 HP-UX build error
Jim Meyering wrote:
Matthew Woehlke wrote:
I got the following error (in gnulib) building coreutils 6.6 on HP-UX.
source='fts.c' object='fts.o' libtool=no \
DEPDIR=.deps depmode=hp /bin/sh ../build-aux/depcomp \
cc -I. -I/home/install/gnu/hp700_hpux/include -g -c fts.c
cc: "fts.c", line 734: error 1654: Expression type is too large for switch
expression.
cc: "fts.c", line 736: error 1653: Case label too big for the type of the
switch expression
cc: "fts.c", line 739: error 1653: Case label too big for the type of the
switch expression
I'm suggesting the following patch (formed by hand, sorry if the line
numbers are off!):
Thanks for the report and patch.
What version of HP-UX (and, if possible, the compiler) is that?
It must be rather old.
I know the existing code compiles fine with the compilers
from HP-UX 11.11 and HP-UX 11.23.
The OS is 11.00, and I can't tell about the compiler ('cc -v' is giving
some odd output but no version number). FWIW, aCC is A.03.30. My guess
would be that 'cc' hasn't been updated, though. So far I've only had the
problem on the one box, but I can't build on our HP Itanium box at the
moment (although that one is 11.22 IIRC and probably won't have this
problem).
I build on lots of "old" stuff. :-) (More accurately, I generally build
on the oldest box I can find and trust the binaries to work on a newer
box as well, and "the oldest box I can find" is usually the same one we
build our own products on; i.e. it is the oldest stuff that *we* still
support.)
--
Matthew
"Two IIRC's must make a right" -- Larry Hall (paraphrased)
Re: coreutils 6.6 HP-UX build error
Matthew Woehlke <[EMAIL PROTECTED]> wrote:
> The OS is 11.00, and I can't tell about the compiler ('cc -v' is giving
FYI, I've checked in a slightly different change:
Work around a compile-time error from the HP-UX 11.00 /bin/cc.
* lib/fts.c (enum Fts_stat): Give this previously-anon enum a name.
(fts_read): Use a temporary to narrow the overused st_size member
before using it in a switch statement. Reported by Matthew Woehlke.
Index: lib/fts.c
===
RCS file: /sources/gnulib/gnulib/lib/fts.c,v
retrieving revision 1.28
diff -u -p -r1.28 fts.c
--- lib/fts.c 21 Nov 2006 09:15:22 - 1.28
+++ lib/fts.c 22 Nov 2006 23:48:25 -
@@ -92,7 +92,7 @@ static char sccsid[] = "@(#)fts.c 8.6 (B
# define DT_MUST_BE(d, t) false
#endif
-enum
+enum Fts_stat
{
FTS_NO_STAT_REQUIRED = 1,
FTS_STAT_REQUIRED = 2
@@ -731,7 +731,8 @@ name: t = sp->fts_path + NAPPEND(p->fts
check_for_dir:
if (p->fts_info == FTS_NSOK)
{
- switch (p->fts_statp->st_size)
+ enum Fts_stat need_stat = p->fts_statp->st_size;
+ switch (need_stat)
{
case FTS_STAT_REQUIRED:
p->fts_info = fts_stat(sp, p, false);
Re: coreutils-6.5: yet another C89 problem
Matthew Woehlke <[EMAIL PROTECTED]> writes: > Ok, happen to have a quick how-to? (A cron job that *doesn't* mail me > unless there is a problem would be nice :-).) http://buildbot.sourceforge.net/ I haven't built one myself, but others have
Re: coreutils 6.6 HP-UX build error
Jim Meyering <[EMAIL PROTECTED]> writes: > Thanks for the report and patch. > What version of HP-UX (and, if possible, the compiler) is that? > It must be rather old. Come to think of it, since we want the code to stay portable to C89, then we can't use switch (V) ... when V is of type off_t. This is because off_t is typically 'long long int', and C89 (which lacks 'long long int') does not require support for a switch whose expression is of type 'long long int'. Also, I suspect that many would-be C99 compilers might have trouble with this usage, since it's pretty rare to have a switch (off_t). I suppose I should add a test to AC_TYPE_LONG_LONG_INT to catch this particular diagnostic. But even that wouldn't cure this particular problem, since the code doesn't depend on HAVE_LONG_LONG_INT. Sigh. I'd say we should give up on this particular battle, and just rewrite the 'switch' to if-then-else, as Matthew Woehlke suggested.
Re: coreutils 6.6 HP-UX build error
Jim Meyering <[EMAIL PROTECTED]> writes: > + enum Fts_stat need_stat = p->fts_statp->st_size; > + switch (need_stat) Dunno if this matters, but on typical 64-bit platforms converting to enum Fts_stat and then switching won't abort in the rare cases when p->fts_statp->st_size equals 2**32 + 1 or 2**32 + 2, whereas the previous code would correctly abort in those two cases.
Re: coreutils 6.6 HP-UX build error
Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: >> +enum Fts_stat need_stat = p->fts_statp->st_size; >> +switch (need_stat) > > Dunno if this matters, but on typical 64-bit platforms converting to > enum Fts_stat and then switching won't abort in the rare cases when > p->fts_statp->st_size equals 2**32 + 1 or 2**32 + 2, whereas the > previous code would correctly abort in those two cases. Thanks, but that doesn't matter. When st_size is used that way (when ->fts_info == FTS_NSOK), its value must be FTS_STAT_REQUIRED (1) or FTS_NO_STAT_REQUIRED (2). If there is a way to make it have any other value, it's a bug.
Re: coreutils 6.6 HP-UX build error
Paul Eggert <[EMAIL PROTECTED]> writes: > Come to think of it, since we want the code to stay portable to C89, > then we can't use switch (V) ... when V is of type off_t. This is > because off_t is typically 'long long int', and C89 (which lacks 'long > long int') does not require support for a switch whose expression is > of type 'long long int'. I don't understand this rationale. C89 requires that the switch expression be of integral type. For C89 compilers with the long long int extension, a long long int is an integral type, so it should be supported. Are there actual implementations that support long long int but not its use as a switch expression? -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org
Re: coreutils 6.6 HP-UX build error
Jim Meyering <[EMAIL PROTECTED]> writes: > Thanks, but that doesn't matter. When st_size is used that way (when > ->fts_info == FTS_NSOK), its value must be FTS_STAT_REQUIRED (1) or > FTS_NO_STAT_REQUIRED (2). If there is a way to make it have any other > value, it's a bug. Yes, but the point of the switch is that it attempts to detect these bugs, and to abort if there is a bug by falling into the default case. Formerly the code detected the bug when st_size was 2**32 + 2. Currently the code does not detect the bug in this case; it treats 2**32 + 2 like FTS_STAT_REQUIRED. It's a very minor point, and not worth much worry. (I'm just trying to explain the point at this point. :-)
Re: coreutils 6.6 HP-UX build error
Ben Pfaff <[EMAIL PROTECTED]> writes: > I don't understand this rationale. C89 requires that the switch > expression be of integral type. For C89 compilers with the long > long int extension, a long long int is an integral type No, because there's no standard for the "long long int" extension in C89. A conforming C89 compiler can support every feature of C99 long long int except for switch(). Such a compiler will still execute every C89 program correctly, so the implementation conforms to C89. For example, some conforming C89 systems have long long but use %Ld rather than %lld for printf formats; that also conforms to C89 (but not C99, obviously). > Are there actual implementations that support long long int but > not its use as a switch expression? Yes, apparently the HP-UX compiler in question is like this.
Re: backup question
On Wed, Nov 22, 2006 at 07:42:58PM +0100, Bruno Haible wrote: > Hello Sylvain, > > Can you please tell: Are the git repositories visible in > > http://git.sv.gnu.org/gitweb/ > > stored on a disk that is regularly backed up? If so, with which frequency > (daily, weekly, monthly)? > > I'm asking because we are considering moving gnulib to this area as well. It's Savannah, backed-up daily :) Glad you're considering trying this out. -- Sylvain
