Does this include all the patches that have been flying around for NSK?
I've been meaning to apply those, but between some in gnulib, some in
coreutils, and some that need manual filtering to apply at all, I
haven't gotten to it.
That release includes a snapshot of gnulib state from
the day
Thanks for catching those. I prefer the 'const' after the type that
it modifies, so I installed the following into gnulib. (For coreutils
I guess I need to come up to speed on its new version control system.)
2006-10-24 Paul Eggert [EMAIL PROTECTED]
* lib/getdate.y (yyerror): Make
__cplusplus without
having variable-length arrays. Also, many C compilers other than GCC
have variable length arrays, and don't need to be penalized.
Bruno, how about this patch?
2006-10-24 Paul Eggert [EMAIL PROTECTED]
* lib/gettext.h (_LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS): Remove
it is used
directly within #if (i.e., not as the result of a macro
expansion).
I propose the following patch; unlike my earlier patch, it
doesn't assume gnulib.
2006-10-25 Paul Eggert [EMAIL PROTECTED]
* lib/gettext.h (_LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS):
Don't look
John Darrington [EMAIL PROTECTED] writes:
One that shows up from gnulib is is_basic_table from mbchar.c
This symbol should be const?
Makes sense to me. Here's a proposed patch.
2006-10-25 Paul Eggert [EMAIL PROTECTED]
* lib/mbchar.c (is_basic_table): Now const.
Problem
I installed this in gnulib to help explain the copyright issue a bit
better.
2006-10-26 Paul Eggert [EMAIL PROTECTED]
* COPYING: Explain how gnulib-tool converts licence headers.
Almost all wording by Eric Blake.
--- COPYING 15 Sep 2004 15:59:43 - 1.2
+++ COPYING
/stat_.h, and to reserve stat-macros for our own
stat-related macros. To start the ball rolling on this I installed
the following:
2006-10-27 Paul Eggert [EMAIL PROTECTED]
Move stat.h-substitute stuff from lib/stat-macros.h to lib/stat_.h.
stat-macros.h is now for our own macros
this patch instead.
2006-10-31 Paul Eggert [EMAIL PROTECTED]
Avoid some C++ diagnostics reported by Bruno Haible.
* lib/quotearg.c (clone_quoting_options): Use xmemdup rather than
xmalloc.
(quotearg_alloc): Use xcharalloc rather than xmalloc.
(struct
Bruno Haible [EMAIL PROTECTED] writes:
clean-temp.c:277: xmalloc (new_allocated * sizeof (struct tempdir *
volatile));
fatal-signal.c:210: xmalloc (new_actions_allocated * sizeof
(actions_entry_t));
fstrcmp.c:623: buffer = (int *) xmalloc (bufmax * (2 * sizeof (int)));
[EMAIL PROTECTED] (Karl Berry) writes:
How do people maintain the list of Gnulib source files for POTFILES.in?
I do it by hand, but have toyed with having the bootstrap script do
it. It already maintains .cvsignore and .gitignore files.
Charles Wilson [EMAIL PROTECTED] writes:
Precedent: the fts and fts-lgpl modules each provide functionality
similar to the other, under different licenses -- where the module
under the lesser license provides lesser, but still useful,
functionality. That is the case here, as well: the
Bruno Haible [EMAIL PROTECTED] writes:
#define XNMALLOC(n, t) ((t *) xnmalloc (n, sizeof (t)))
#define XCALLOC(n, t) ((t *) xcalloc (n, sizeof (t)))
Yes, this looks good. I'll use these names.
OK.
#ifdef __cplusplus
#define XALLOC_WITH_EXPRESSION(N,EXPR) xalloc_with_expression (N,
-11-03 Paul Eggert [EMAIL PROTECTED]
* lib/canonicalize.h: (canonicalize_mode_t, CAN_EXISTING):
(CAN_ALL_BUT_LAST, CAN_MISSING, canonicalize_filename_mode):
Define only if PROVIDE_CANONICALIZE_FILENAME_MODE is defined.
* m4/canonicalize.m4
Here is a slightly different proposal to add that module; it assumes
the 'canonicalize' changes I just installed. What do you think?
I guess the basic idea here is that we move this module from gettext
to gnulib, so I haven't worried about config/srclist.txt.
2006-11-03 Paul Eggert [EMAIL
Bruno Haible [EMAIL PROTECTED] writes:
Additionally, can we please add a comment here?
Sure. For consistency there should be a comment for
canonicalize_filename_mode so I installed the following patch for
canonicalize.h along with the other patches already mentioned.
Another consistency
installed this:
2006-11-06 Paul Eggert [EMAIL PROTECTED]
* lib/xalloc.h (xnmalloc, xnrealloc, x2nrealloc): Now static
inline functions that are identical with the old xnmalloc_inline,
xnrealloc_inline, x2nrealloc_inline of lib/xmalloc.c. This is so
that we can avoid
I installed this. Like vararrays, it should be migrated into Autoconf,
which is also on my list of things to do.
2006-11-06 Paul Eggert [EMAIL PROTECTED]
* MODULES.html.sh (Core language properties): New module flexmember.
* modules/flexmember, m4/flexmember.m4: New files
I installed this; it is an example of how to use the new flexmember
module.
2006-11-06 Paul Eggert [EMAIL PROTECTED]
* lib/idcache.c: Include stddef.h, for offsetof.
(struct userid.name): Change from char * to a flexible array member.
All uses changed.
* modules
By code inspection I noticed some other opportunities to use
XMALLOC instead of xmalloc, XCALLOC instead of xcalloc,
xmemdup instead of XNMALLOC+memcpy, and x2nrealloc instead of
a hand-written replacement. Here's a proposed (but untested)
patch.
2006-11-06 Paul Eggert [EMAIL PROTECTED
and long double.
But anyway, does this solve the problems you mentioned?
2006-11-07 Paul Eggert [EMAIL PROTECTED]
* lib/xalloc.h (XMALLOC, XNMALLOC, XZALLOC, XCALLOC): Move
definitions up, to avoid colliding with change below.
(static_inline) [HAVE_INLINE]: New macro
. We want a test case that fails
reliably on your platform but should succeed reliably on any
conforming host.
I installed the following patch into gnulib and will install
something similar into Autoconf shortly.
2006-11-07 Paul Eggert [EMAIL PROTECTED]
* m4/longlong.m4
Ralf Wildenhues [EMAIL PROTECTED] writes:
Why not go all the way and put it in Autoconf proper?
OK, I did so, by installing the following patch into Autoconf.
I figured flexible array members are in the same category, so
this patch adds them too.
2006-11-08 Paul Eggert [EMAIL PROTECTED
guess it's all right. To start off, I
installed this into gnulib:
2006-11-08 Paul Eggert [EMAIL PROTECTED]
* lib/quotearg.h (quotearg_free): New decl.
* lib/quotearg.c (quotearg_free): New function.
(slot0, nslots, slotvec0, slotvec):
Now file-scope so
. hello a b c outputs a less-than-helpful diagnostic, which doesn't
say that it's the hello program.
Here are proposed patches:
2006-11-09 Paul Eggert [EMAIL PROTECTED]
* src/hello.c (main): Make greeting const char *, to avoid
a violation of the C standard when assigning
patch to gnulib/lib/gettext.h, which works for me:
2006-11-09 Paul Eggert [EMAIL PROTECTED]
* lib/gettext.h (dgettext, dcgettext, ngettext) [! ENABLE_NLS]:
(dngettext, dcngettext, bindtextdomain) [! ENABLE_NLS]:
(bind_textdomain_codeset) [! ENABLE_NLS]:
Evaluate
Matthew Woehlke [EMAIL PROTECTED] writes:
Actually, while trying to compile m4, it looks like this may indeed be
a problem. OSS's sys/stat.h bombs if int64_t is not defined,
Can you please explain exactly why this problem occurs?
gnulib's stdint.h replacement should include the relevant
system
Matthew Woehlke [EMAIL PROTECTED] writes:
...which I assume those who have been following my NSK woes will
immediately spot the flaw in? :-)
Thanks, I installed this patch into gnulib:
2006-11-09 Paul Eggert [EMAIL PROTECTED]
* lib/stdint_.h (uintmax_t): Fix typo: int64_t
Matthew Woehlke [EMAIL PROTECTED] writes:
FYI: You probably know this, but the patch you pointed me at did not
apply at all (I think one hunk in total went through), so I had to
apply the changes by hand.
No, I didn't know that.
What happens if you omit that patch entirely? If it works
Matthew Woehlke [EMAIL PROTECTED] writes:
I'm quite certain I remember it bombing (there are 'unsigned long
long's sprinkled in there without it). But I am guessing the problem
is just that CVS is a little off of coreutils-6.4, which is what I was
trying to patch. I think the main problems
Eric Blake [EMAIL PROTECTED] writes:
What I should have done, of course, is:
#if HAVE_INLINE
static inline unsigned char to_uchar (char ch) { return ch; }
#else
# define to_uchar(C) ((unsigned char) (C))
#endif
No, let's not go that route! We should keep code simple, and not
sprinkle it
Bruno Haible [EMAIL PROTECTED] writes:
gnulib's lib directory now has over 600 source files. Only Paul and I have
an overview of what's in gnulib;
Hold on a second; you inadvertently omitted Jim Meyering's name here.
Jim has contributed a ton of source code to gnulib over the years. He
knows
deal with that, just as I can deal with other problems that
arise when I change CFLAGS without rerunning 'configure'.
2006-11-13 Paul Eggert [EMAIL PROTECTED]
* m4/inline.m4 (AC_C_INLINE): Don't test for __NO_INLINE__ at
configure-time. Instead, test for it at compile-time
Bruno Haible [EMAIL PROTECTED] writes:
If you want to force it to a certain value, I think we can consider a
--enable/--disable-inlining configure option.
Probably not worth the trouble. I can always configure with CC='gcc
-fno-inline'.
How would you deal with such a link error situation?
Bruno Haible [EMAIL PROTECTED] writes:
$ ./configure
$ make
$ make clean
$ make CFLAGS=-g -O0
be trapped in the link error: xmalloc.c, compiled with optimization, will
not define xnmalloc, whereas the main sources, compiled without optimization,
will require it.
How about if we
Jim Meyering [EMAIL PROTECTED] writes:
inttostr.c is barely 20 lines of code, and pretty simple.
And each of the other .c files is just a 3-line stub.
Changing the module to LGPL is fine with me, but Paul's the owner.
Fine with me too.
Jim Meyering [EMAIL PROTECTED] writes:
inttostr.c is barely 20 lines of code, and pretty simple.
And each of the other .c files is just a 3-line stub.
Changing the module to LGPL is fine with me, but Paul's the owner.
I should have also said: I changed it to LGPL.
Bruno Haible [EMAIL PROTECTED] writes:
You also combined adjacent sed invocations. Which rule are you using here?
When is it safe to combine
sed -e $expr1 | sed -e $expr2
into
sed -e $expr1 -e $expr2
?
That's a tricky question to answer in general, but if $expr1 and $expr
are both
Ralf Wildenhues [EMAIL PROTECTED] writes:
2006-11-14 Ralf Wildenhues [EMAIL PROTECTED]
* m4/inttypes.m4 (gl_INTTYPES_H): Use AC_CACHE_CHECK so that the
test for conforming inttypes.h is both announced and cached.
Thanks, I installed the following further change so that it's
Yoann Vandoorselaere [EMAIL PROTECTED] writes:
warning: argp is LGPL but depend on exitfail which is GPL
warning: canon-host is LGPL but depend on intprops which is GPL
warning: euidaccess is LGPL but depend on exitfail which is GPL
warning: fts-lgpl is LGPL but depend on exitfail which is
Eric Blake [EMAIL PROTECTED] writes:
OK to install?
2006-11-15 Eric Blake [EMAIL PROTECTED]
* m4/alloca.m4 (gl_FUNC_ALLOCA): Use AC_CACHE_CHECK to avoid a
random (cached) in configure output.
* m4/allocsa.m4 (gl_ALLOCSA): Don't invoke macro already picked
up by
Ralf Wildenhues [EMAIL PROTECTED] writes:
The allocsa.m4 change
contradicts
http://lists.gnu.org/archive/html/bug-gnulib/2006-10/msg00279.html
I don't see why it's contradictory. That URL says that gl_ALLOCSA
should not AC_REQUIRE gl_FUNC_ALLOCA. But the proposed allocsa.m4
change:
*
Jim Meyering [EMAIL PROTECTED] writes:
#define INT_BUFLEN_BOUND(t) ((sizeof (t) * CHAR_BIT) * 146 / 485 + 1 + 1)
That sounds reasonable to me, as a workaround.
[EMAIL PROTECTED] (Karl Berry) writes:
Would it be reasonable/possible to have gnulib-tool output only the
top-level #includes?
Yes, that makes sense.
?
2006-11-16 Paul Eggert [EMAIL PROTECTED]
* modules/getaddinfo (Depends-on): Remove inttostr; add snprintf.
* lib/getaddrinfo.c: Include snprintf.h rather than intprops.h
and inttostr.h. Use snprintf rather than uinttostr, so that
LGPLed code doesn't depend
Eric Blake [EMAIL PROTECTED] writes:
How about the following alternative - at configure time, if there is a
mismatch between sizeof(uintmax_t) and sizeof(intmax_t), we redefine these
two types to be the same size as the smaller of the two (effectively
disabling long long on Tandem NSK since
Matthew Woehlke [EMAIL PROTECTED] writes:
Perhaps there's a better way. In
http://lists.gnu.org/archive/html/bug-coreutils/2006-11/msg00069.html
I asked Matthew Woehlke why the patch was actually needed -- as it's
not 100% clear to me -- and that hasn't been followed up on yet.
...it's
Charles Wilson [EMAIL PROTECTED] writes:
http://lists.gnu.org/archive/html/bug-gnulib/2006-11/msg00054.html
Relevant to recent discussion about LGPL modules depending on GPL
ones, this file has no module so was missed during that discussion.
The message above sent last week provides a patch
it was easier just to fold the code into
openat.
2006-11-20 Paul Eggert [EMAIL PROTECTED]
* lib/openat.h (rpl_fstatat): New macro, if
[HAVE_OPENAT ! LSTAT_FOLLOWS_SLASHED_SYMLINK.
(fstatat): Define to rpl_fstatat under the same conditions,
unless COMPILING_FSTATAT
Matthew Woehlke [EMAIL PROTECTED] writes:
Maybe it would help if someone occasionally did builds with gcc's
strict-c89 mode
Even better, if someone would build CVS coreutils once a day with some
random non-GCC c89 compiler.
Perhaps you could arrange for that? (The usual idea is that the the
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.
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
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
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
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.
On 11/25/06, James Youngman [EMAIL PROTECTED] wrote:
I am using gettext version 0.14.6. Its version of po/Makefile.in.in
uses @MKINSTALLDIRS@,
mkinstalldirs is obsolete and is not maintained any more, and new
distributions shouldn't distribute it. install-sh now does the work
that
Nix [EMAIL PROTECTED] writes:
I suspect this wasn't noticed because a lot of people mount their
filesystems with the noatime option,
Actually, in my case it wasn't noticed because my system doesn't
support O_NOATIME. I guess a lot of developers are in my boat,
as it's a relatively new
Ben Pfaff [EMAIL PROTECTED] writes:
C99 added some useful functions to math.h, such as trunc and
round. Would there be objections to a module that adds
implementations of those functions? I am particularly interested
in those two functions, which are handy for GNU PSPP, and so I am
likely
I tried compiling coreutils with gcc -ansi -pedantic (ah, the good
old days!) and found some incompatibilities had crept into the
regex module. I installed this to fix them:
2006-11-26 Paul Eggert [EMAIL PROTECTED]
Fix some incompatibilities with gcc -ansi -pedantic.
* lib
gettext.h also has a problem with gcc -ansi -pedantic: it uses the
[restrict] syntax in that case, but GCC complains about it since
[restrict] isn't in C89. Here's a proposed patch:
2006-11-26 Paul Eggert [EMAIL PROTECTED]
* lib/gettext.h (_LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS
on the gettext.h patch I sent to bug-gnulib a few
minutes ago, in the sense that the resulting 'make distcheck' won't
succeed unless gettext.h is also fixed.
2006-11-26 Paul Eggert [EMAIL PROTECTED]
Fix some incompatibilities with gcc -ansi -pedantic.
* lib/regex.h
Jim Meyering [EMAIL PROTECTED] writes:
But that ChangeLog block is the one for gnulib.
Sorry about that. Here it is. I also put this into my own git
repository.
2006-11-26 Paul Eggert [EMAIL PROTECTED]
Improve the check for departures from C89, and fix the departures
I
Can substitutes in gnulib assume that the 'double' format is IEEE 754
(it is on all modern platforms; VAX was the last one with other formats) ?
Or should they be written in a slower, but more portable way?
This question is actually vital. If we can assume IEEE 754, then
I can use
Bruno Haible [EMAIL PROTECTED] writes:
Now that autoconf-2.61 provides AC_COMPUTE_INT, I think the macros should
use it. As long as people are still heavily using 2.59 or 2.60, we need to
provide a fallback.
Thanks, I like this change. I tested it for m4/stdint.m4, and
installed that part of
this patch?
Admittedly it's not a huge point, since gcc -std=c99 is fairly rare,
but it's nice to have this patch if only for accurate internal
documentation.
2006-11-27 Paul Eggert [EMAIL PROTECTED]
* lib/gettext.h (_LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS):
If GCC 3 or later
Ben Pfaff [EMAIL PROTECTED] writes:
The following actually makes an unconditional wrapper around
math.h, in the same way as the fcntl module does.
Is that needed? I'd think that the normal modern case wouldn't need
the wrapper. It'd be nice to avoid the wrapper in that case, since
the
Ralf Wildenhues [EMAIL PROTECTED] writes:
I could also just go ahead and commit the tests/ part of this,
that would be sufficient to fix the test failure, and avoid glibc
synchronization issues.
That sounds good to me. Please give Sergey a couple of days first,
but if he's too busy, then
Eric Blake [EMAIL PROTECTED] writes:
See http://tinyurl.com/yd5669 for details.
This message on the cygwin list has a good point,
For first-fit memory allocators, perhaps; but these are ancient
technology and I wouldn't worry about x2nrealloc on their account.
That being said, if you can
[EMAIL PROTECTED] (Karl Berry) writes:
Well, whatever. Even if Paul wants to address this, I'm sure it's
nothing to do for the first release.
Right you are. Right now I'm just trying to address security holes in
gzip, like buffer overruns (I just half an hour ago found another
hole, wow!
Simon Josefsson [EMAIL PROTECTED] writes:
I find these markers useful when comparing file dates when updating
old software, and I think it would be a clear disadvantage if moving
to git won't make the same thing possible.
They are controversial. I'd rather remove them, at least in the files
be
able to use it by configuring with 'configure CFLAGS='-g -O2
-DHAVE_BUGGY_NFS_TIME_STAMPS', or something like that. I can't see an
easy way to autoconfigure it, since an executable might be built on
(say) a non-buggy Linux 2.4 host and then executed on a buggy Linux
2.6.19 host.
2006-12-05 Paul
on older ones. Since it's been less-safe
for a decade without anyone complaining, I guess that's good enough.
2006-12-05 Paul Eggert [EMAIL PROTECTED]
Port to Tandem NSK/OSS, which lacks fchdir. Problem reported by
Matthew Woehlke in
http://lists.gnu.org/archive/html/bug-gzip
Matthew Woehlke [EMAIL PROTECTED] writes:
(Also, apologies for dropping bugs-gzip, I'm used to gmane handling
cross-posting, but obviously it doesn't if the list isn't on
gmane. Paul: I take it you have not heard back from them yet?)
No. Perhaps you can bug them separately?
Matthew Woehlke [EMAIL PROTECTED] writes:
While trying to build gzip 1.3.7, I noticed inconsistent usage of
gnulib's timespec.h via stat-time.h, which led me to dig up where
'struct timespec' is defined on NSK. It turns out the declaration is
in spt_types.h, included in spthread.h.
Does this
Matthew Woehlke [EMAIL PROTECTED] writes:
Given the difference (tv_secs signed vs unsigned), do you really
expect treating a signed as an unsigned to matter? Is tv_secs allowed
to be negative?
On most hosts, yes. POSIX doesn't specify what happens, but usually
it's the obvious thing of time
Bruno Haible [EMAIL PROTECTED] writes:
Objections?
I have no objections to this module, but for it to be useful won't we
also need to sprinkle $(NO_CXX) throughout the descriptions of all
modules that are not compilable with g++? How would that work?
.
2006-12-11 Paul Eggert [EMAIL PROTECTED]
* m4/openat.m4 (gl_FUNC_OPENAT): Don't compile mkdirat
and fchmodat unconditionally, since glibc 2.4 has them.
Problem reported by Arkadiusz Miskiewicz.
--- m4/openat.m420 Nov 2006 22:01:30 - 1.9
+++ m4/openat.m4
Jim Meyering [EMAIL PROTECTED] writes:
That looks fine to me.
OK, I installed it into gnulib.
or some nonzero status like that.
2. In coreutils, the command build-aux/config.guess outputs
i370-ibm-openedition.
If my guesses are right, the following patch should work, but I'd
like you to confirm my guesses before installing this. Thanks.
2006-12-17 Paul Eggert [EMAIL PROTECTED
installed:
2006-12-18 Paul Eggert [EMAIL PROTECTED]
and Eric Blake [EMAIL PROTECTED]
* lib/dirname.h (DOUBLE_SLASH_IS_DISTINCT_ROOT): Default to 0, not 1.
This is more consistent with the other defines here.
* m4/double-slash-root.m4 (gl_DOUBLE_SLASH_ROOT
[EMAIL PROTECTED] writes:
(But I've long been tempted to tender a suggestion that the
guessers should supply a version for z/OS as they do for other
OSes.)
Sounds reasonable to me. Can you please suggest patches to
[EMAIL PROTECTED]? Submit a context diff to config.guess
and/or config.sub,
Ralf Wildenhues [EMAIL PROTECTED] writes:
Module fcntl_h does not exist. OK to apply?
Yes, please. Thanks.
Ralf Wildenhues [EMAIL PROTECTED] writes:
the newer GCC exploits at -O2 the fact that integer overflow
produces undefined behavior
Wheeeoo! That optimization is going to break a _lot_ of GNU
software. (Silently. Oh my.)
This is a major change. Where is it documented and discussed? I
Eric Blake [EMAIL PROTECTED] writes:
Perhaps we should add an accessor function that sets a static
variable in the closeout module, defaulting to 0, but that an
application can call to register any errno that it wants tracked (in
this case, after failing fflush, m4 would call the accessor to
Ralf Wildenhues [EMAIL PROTECTED] writes:
Maybe it's also just an unintended bug I happened to observe
(and take for given behavior)?
I read up a bit more and it looks like it is intended behavior.
However, this disruptive change isn't documented in
http://gcc.gnu.org/gcc-4.2/changes.html,
Does the test hang forever?
No, the timeout works.
So the app builds. But it has latent bugs. Wonderful.
Is the performance gain by this change to gcc -O2 really worth all
this software engineering hassle and breakage for typical
applications? I'm talking about apps like 'date', 'touch',
Paolo Bonzini [EMAIL PROTECTED] writes:
I don't remember if it was Paul or Bruno who suggested that POLLHUP
does not increase the return value. What do you think?
It wasn't me, so I guess it was Bruno. I don't have any opinion on
this one, other than that if it seems good to you and Yoann,
) as the programmer intended,
while still doing loop induction optimizations, then we'd no
doubt use that option instead of -fwrapv. That sounds like
a reasonable compromise. I would argue that such an option
should be the default for -O2, as -O2 is so commonly used.
On Tue, 19 Dec 2006, Paul Eggert
Paolo Bonzini [EMAIL PROTECTED] writes:
On the autoconf mailing list, Paul Eggert mentioned as a good
compromise that GCC could treat signed overflow as undefined only for
loops and not in general.
What I meant to propose (and perhaps did not propose clearly
enough) is that if the C
Joseph S. Myers [EMAIL PROTECTED] writes:
Conversion of out-of-range integers to signed types is
implementation-defined not undefined,
Thanks for the correction; I keep forgetting that. However,
a conforming implementation is allowed to raise a signal for
those conversions, which could break
Ian Lance Taylor [EMAIL PROTECTED] writes:
We could disable VRP's assumptions about signed overflow. I don't
know what else we could do to fix this case. I don't even know how we
could issue a useful warning. Perhaps there is a way.
It is a knotty problem. Thanks for thinking about it.
it, but you may want to wait for the next
coreutils release.
2006-12-21 Paul Eggert [EMAIL PROTECTED]
* MODULES.html.sh: New module wctype.
* lib/wctype_.h, m4/wctype.m4, modules/wctype: New files.
* lib/fnmatch.c: Don't bother to include wchar.h before
wctype.h, since
Now that we have a wctype module we can simplify some of the other
modules to just include wctype.h and depend on the wctype module.
Here is a proposed patch.
2006-12-21 Paul Eggert [EMAIL PROTECTED]
* lib/mbchar.h: Just include wctype.h; the wctype module
handles its gotchas
I installed the following into Autoconf to fix the Autoconf side of
the problem.
2006-12-22 Paul Eggert [EMAIL PROTECTED]
* lib/autoconf/functions.m4 (AC_FUNC_MKTIME):
Include limits.h, and use its INT_MAX to rewrite the
j loop so that it does not overflow 'int
.
I'm willing to complicate the module implementation a bit to get
there. The idea is to enable simplifications like the patch proposed in
http://lists.gnu.org/archive/html/bug-gnulib/2006-12/msg00202.html.
How about the following patch instead? I installed it.
2006-12-23 Paul Eggert [EMAIL
Eric Blake [EMAIL PROTECTED] writes:
Paul Eggert eggert at CS.UCLA.EDU writes:
Now that we have a wctype module we can simplify some of the other
modules to just include wctype.h and depend on the wctype module.
Here is a proposed patch.
2006-12-21 Paul Eggert eggert at cs.ucla.edu
[EMAIL PROTECTED] writes:
$SED from gnulib-tool was used before, but that may not be valid
on the system where configure is run.
I fixed that in a different way here:
http://lists.gnu.org/archive/html/bug-gnulib/2006-12/msg00241.html
[EMAIL PROTECTED] (Karl Berry) writes:
rms sent me this note. I figured this was the group of people most
likely to have someone able and willing to tackle some regex work.
Anyone want to volunteer?
Perhaps the simplest thing to do would be to remove
http://ftp.gnu.org/pub/gnu/regex/, or to
[EMAIL PROTECTED] writes:
The original declaration conflicts with the declaration on line 523.
The same change was performed on glibc by Ulrich Drepper.
Thanks for mentioning that. I installed the patch as obvious.
[EMAIL PROTECTED] (Karl Berry) writes:
I suspect all he cares about is the regex source in Emacs.
Yes, that's probably right. In that case, I'm afraid his message
is not coherent enough for me to follow. Perhaps if he gave
the specific problems he ran into, with the actual compiler output.
to write, and I'd appreciate
any comments/reviews for it.
For those coming to this discussion late, the original version of the
patch and the followup thread are here:
http://lists.gnu.org/archive/html/autoconf-patches/2006-12/msg00091.html
2006-12-28 Paul Eggert [EMAIL PROTECTED]
* NEWS
501 - 600 of 5369 matches
Mail list logo
