From unknown Thu Jun 19 14:04:37 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#8675 <8675@debbugs.gnu.org> To: bug#8675 <8675@debbugs.gnu.org> Subject: Status: lisp_string_width and strings wider than INT_MAX Reply-To: bug#8675 <8675@debbugs.gnu.org> Date: Thu, 19 Jun 2025 21:04:37 +0000 retitle 8675 lisp_string_width and strings wider than INT_MAX reassign 8675 emacs submitter 8675 Paul Eggert severity 8675 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Mon May 16 01:07:58 2011 Received: (at submit) by debbugs.gnu.org; 16 May 2011 05:07:58 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QLq29-0003CU-25 for submit@debbugs.gnu.org; Mon, 16 May 2011 01:07:58 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QLq26-0003CH-AE for submit@debbugs.gnu.org; Mon, 16 May 2011 01:07:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QLq1y-0007U1-RF for submit@debbugs.gnu.org; Mon, 16 May 2011 01:07:48 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:55335) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QLq1y-0007Tv-Mn for submit@debbugs.gnu.org; Mon, 16 May 2011 01:07:46 -0400 Received: from eggs.gnu.org ([140.186.70.92]:34055) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QLq1w-00019g-8j for bug-gnu-emacs@gnu.org; Mon, 16 May 2011 01:07:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QLq1t-0007T3-GV for bug-gnu-emacs@gnu.org; Mon, 16 May 2011 01:07:44 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]:60988) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QLq1s-0007ST-Rf for bug-gnu-emacs@gnu.org; Mon, 16 May 2011 01:07:41 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 744EE39E8141 for ; Sun, 15 May 2011 22:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HaFWVCQWLff8 for ; Sun, 15 May 2011 22:07:36 -0700 (PDT) Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id BD9B239E8140 for ; Sun, 15 May 2011 22:07:36 -0700 (PDT) Message-ID: <4DD0B118.1040205@cs.ucla.edu> Date: Sun, 15 May 2011 22:07:36 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: bug-gnu-emacs@gnu.org Subject: lisp_string_width and strings wider than INT_MAX Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -4.7 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.7 (----) lisp_string_width requires that the precision be less than INT_MAX, and if no precision is given, misbehaves badly when dealing with strings whose widths are greater than INT_MAX. To address this, I plan to install the following patch (PATCH 3) after some more testing. PATCH 3 depends on two obvious patches: PATCH 2 introduces a helper no-return function string_overflow, and PATCH 1 updates to the latest version of gnulib. One thing about PATCH 3: when used in Emacs, the new lisp_string_width correctly signals an overflow when the string's width cannot be represented, but when used outside Emacs (in mulelib) it silently ignores the problem, just as before. I don't know much about mulelib and so don't know how to address this. But anyway, mulelib uses should be no worse off than before. PATCH 3 --------------------------------------------------- === modified file 'src/ChangeLog' --- src/ChangeLog 2011-05-16 01:11:54 +0000 +++ src/ChangeLog 2011-05-16 01:25:38 +0000 @@ -1,5 +1,14 @@ 2011-05-16 Paul Eggert + * character.c (lisp_string_width): Check for string overflow. + Use EMACS_INT, not int, for string indexes and lengths; in + particular, 2nd arg is now EMACS_INT, not int. Do not crash if + the resulting string length overflows an EMACS_INT; instead, + report a string overflow if no precision given. When checking for + precision exhaustion, use a check that cannot possibly have + integer overflow. + * character.h (lisp_string_width): Adjust to new signature. + * alloc.c (string_overflow): New function. (Fmake_string): Use it. This doesn't change behavior, but saves a few bytes and will simplify future changes. === modified file 'src/character.c' --- src/character.c 2011-05-16 01:11:54 +0000 +++ src/character.c 2011-05-16 01:17:19 +0000 @@ -35,6 +35,7 @@ #include #include +#include #include "lisp.h" #include "character.h" #include "buffer.h" @@ -404,7 +405,7 @@ in *NCHARS and *NBYTES respectively. */ EMACS_INT -lisp_string_width (Lisp_Object string, int precision, +lisp_string_width (Lisp_Object string, EMACS_INT precision, EMACS_INT *nchars, EMACS_INT *nbytes) { EMACS_INT len = SCHARS (string); @@ -419,7 +420,7 @@ while (i < len) { - int chars, bytes, thiswidth; + EMACS_INT chars, bytes, thiswidth; Lisp_Object val; int cmp_id; EMACS_INT ignore, end; @@ -437,7 +438,11 @@ int c; if (multibyte) - c = STRING_CHAR_AND_LENGTH (str + i_byte, bytes); + { + int cbytes; + c = STRING_CHAR_AND_LENGTH (str + i_byte, cbytes); + bytes = cbytes; + } else c = str[i_byte], bytes = 1; chars = 1; @@ -455,8 +460,14 @@ } } - if (precision > 0 - && (width + thiswidth > precision)) + if (precision <= 0) + { +#ifdef emacs + if (INT_ADD_OVERFLOW (width, thiswidth)) + string_overflow (); +#endif + } + else if (precision - width < thiswidth) { *nchars = i; *nbytes = i_byte; === modified file 'src/character.h' --- src/character.h 2011-04-11 03:39:45 +0000 +++ src/character.h 2011-05-16 01:13:28 +0000 @@ -612,7 +612,7 @@ extern EMACS_INT strwidth (const char *, EMACS_INT); extern EMACS_INT c_string_width (const unsigned char *, EMACS_INT, int, EMACS_INT *, EMACS_INT *); -extern EMACS_INT lisp_string_width (Lisp_Object, int, +extern EMACS_INT lisp_string_width (Lisp_Object, EMACS_INT, EMACS_INT *, EMACS_INT *); extern Lisp_Object Qcharacterp; PATCH 2 --------------------------------------------------- === modified file 'src/ChangeLog' --- src/ChangeLog 2011-05-15 17:17:44 +0000 +++ src/ChangeLog 2011-05-16 01:11:54 +0000 @@ -1,3 +1,11 @@ +2011-05-16 Paul Eggert + + * alloc.c (string_overflow): New function. + (Fmake_string): Use it. This doesn't change behavior, but saves + a few bytes and will simplify future changes. + * character.c (string_escape_byte8): Likewise. + * lisp.h (string_overflow): New decl. + 2011-05-15 Paul Eggert Fixups, following up to the user-interface timestamp change. === modified file 'src/alloc.c' --- src/alloc.c 2011-05-12 07:07:06 +0000 +++ src/alloc.c 2011-05-16 01:11:54 +0000 @@ -2174,6 +2174,11 @@ current_sblock = tb; } +void +string_overflow (void) +{ + error ("Maximum string size exceeded"); +} DEFUN ("make-string", Fmake_string, Smake_string, 2, 2, 0, doc: /* Return a newly created string of length LENGTH, with INIT in each element. @@ -2206,7 +2211,7 @@ EMACS_INT string_len = XINT (length); if (string_len > MOST_POSITIVE_FIXNUM / len) - error ("Maximum string size exceeded"); + string_overflow (); nbytes = len * string_len; val = make_uninit_multibyte_string (string_len, nbytes); p = SDATA (val); === modified file 'src/character.c' --- src/character.c 2011-05-12 07:07:06 +0000 +++ src/character.c 2011-05-16 01:11:54 +0000 @@ -823,7 +823,7 @@ { if ((MOST_POSITIVE_FIXNUM - nchars) / 3 < byte8_count || (MOST_POSITIVE_FIXNUM - nbytes) / 2 < byte8_count) - error ("Maximum string size exceeded"); + string_overflow (); /* Convert 2-byte sequence of byte8 chars to 4-byte octal. */ val = make_uninit_multibyte_string (nchars + byte8_count * 3, @@ -832,7 +832,7 @@ else { if ((MOST_POSITIVE_FIXNUM - nchars) / 3 < byte8_count) - error ("Maximum string size exceeded"); + string_overflow (); /* Convert 1-byte sequence of byte8 chars to 4-byte octal. */ val = make_uninit_string (nbytes + byte8_count * 3); } === modified file 'src/lisp.h' --- src/lisp.h 2011-05-15 17:17:44 +0000 +++ src/lisp.h 2011-05-16 01:11:54 +0000 @@ -2710,6 +2710,7 @@ EXFUN (Fvector, MANY); EXFUN (Fmake_symbol, 1); EXFUN (Fmake_marker, 0); +extern void string_overflow (void) NO_RETURN; EXFUN (Fmake_string, 2); extern Lisp_Object build_string (const char *); extern Lisp_Object make_string (const char *, EMACS_INT); PATCH 1 --------------------------------------------------- === modified file 'doc/misc/texinfo.tex' --- doc/misc/texinfo.tex 2011-04-06 05:07:27 +0000 +++ doc/misc/texinfo.tex 2011-05-16 00:51:54 +0000 @@ -3,7 +3,7 @@ % Load plain if necessary, i.e., if running under initex. \expandafter\ifx\csname fmtname\endcsname\relax\input plain\fi % -\def\texinfoversion{2011-03-25.11} +\def\texinfoversion{2011-05-11.16} % % Copyright 1985, 1986, 1988, 1990, 1991, 1992, 1993, 1994, 1995, % 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, @@ -8424,7 +8424,7 @@ % % Latin1 (ISO-8859-1) character definitions. \def\latonechardefs{% - \gdef^^a0{~} + \gdef^^a0{\tie} \gdef^^a1{\exclamdown} \gdef^^a2{\missingcharmsg{CENT SIGN}} \gdef^^a3{{\pounds}} @@ -8546,7 +8546,7 @@ % Latin2 (ISO-8859-2) character definitions. \def\lattwochardefs{% - \gdef^^a0{~} + \gdef^^a0{\tie} \gdef^^a1{\ogonek{A}} \gdef^^a2{\u{}} \gdef^^a3{\L} @@ -9395,6 +9395,8 @@ \message{and turning on texinfo input format.} +\def^^L{\par} % remove \outer, so ^L can appear in an @comment + % DEL is a comment character, in case @c does not suffice. \catcode`\^^? = 14 === modified file 'lib/gnulib.mk' --- lib/gnulib.mk 2011-05-04 07:19:21 +0000 +++ lib/gnulib.mk 2011-05-16 00:51:54 +0000 @@ -167,7 +167,8 @@ ## begin gnulib module ignore-value -libgnu_a_SOURCES += ignore-value.h + +EXTRA_DIST += ignore-value.h ## end gnulib module ignore-value @@ -779,6 +780,7 @@ -e 's|@''GNULIB_GETLOGIN_R''@|$(GNULIB_GETLOGIN_R)|g' \ -e 's|@''GNULIB_GETPAGESIZE''@|$(GNULIB_GETPAGESIZE)|g' \ -e 's|@''GNULIB_GETUSERSHELL''@|$(GNULIB_GETUSERSHELL)|g' \ + -e 's|@''GNULIB_GROUP_MEMBER''@|$(GNULIB_GROUP_MEMBER)|g' \ -e 's|@''GNULIB_LCHOWN''@|$(GNULIB_LCHOWN)|g' \ -e 's|@''GNULIB_LINK''@|$(GNULIB_LINK)|g' \ -e 's|@''GNULIB_LINKAT''@|$(GNULIB_LINKAT)|g' \ @@ -817,6 +819,7 @@ -e 's|@''HAVE_GETHOSTNAME''@|$(HAVE_GETHOSTNAME)|g' \ -e 's|@''HAVE_GETLOGIN''@|$(HAVE_GETLOGIN)|g' \ -e 's|@''HAVE_GETPAGESIZE''@|$(HAVE_GETPAGESIZE)|g' \ + -e 's|@''HAVE_GROUP_MEMBER''@|$(HAVE_GROUP_MEMBER)|g' \ -e 's|@''HAVE_LCHOWN''@|$(HAVE_LCHOWN)|g' \ -e 's|@''HAVE_LINK''@|$(HAVE_LINK)|g' \ -e 's|@''HAVE_LINKAT''@|$(HAVE_LINKAT)|g' \ @@ -883,9 +886,10 @@ ## begin gnulib module verify if gl_GNULIB_ENABLED_verify -libgnu_a_SOURCES += verify.h endif +EXTRA_DIST += verify.h + ## end gnulib module verify ## begin gnulib module warn-on-use === modified file 'lib/intprops.h' --- lib/intprops.h 2011-01-30 19:22:02 +0000 +++ lib/intprops.h 2011-05-16 00:51:54 +0000 @@ -17,70 +17,298 @@ /* Written by Paul Eggert. */ -#ifndef GL_INTPROPS_H -# define GL_INTPROPS_H - -# include +#ifndef _GL_INTPROPS_H +#define _GL_INTPROPS_H + +#include + +/* Return a integer value, converted to the same type as the integer + expression E after integer type promotion. V is the unconverted value. + E should not have side effects. */ +#define _GL_INT_CONVERT(e, v) ((e) - (e) + (v)) /* The extra casts in the following macros work around compiler bugs, e.g., in Cray C 5.0.3.0. */ /* True if the arithmetic type T is an integer type. bool counts as an integer. */ -# define TYPE_IS_INTEGER(t) ((t) 1.5 == 1) +#define TYPE_IS_INTEGER(t) ((t) 1.5 == 1) /* True if negative values of the signed integer type T use two's complement, ones' complement, or signed magnitude representation, respectively. Much GNU code assumes two's complement, but some people like to be portable to all possible C hosts. */ -# define TYPE_TWOS_COMPLEMENT(t) ((t) ~ (t) 0 == (t) -1) -# define TYPE_ONES_COMPLEMENT(t) ((t) ~ (t) 0 == 0) -# define TYPE_SIGNED_MAGNITUDE(t) ((t) ~ (t) 0 < (t) -1) +#define TYPE_TWOS_COMPLEMENT(t) ((t) ~ (t) 0 == (t) -1) +#define TYPE_ONES_COMPLEMENT(t) ((t) ~ (t) 0 == 0) +#define TYPE_SIGNED_MAGNITUDE(t) ((t) ~ (t) 0 < (t) -1) + +/* True if the signed integer expression E uses two's complement. */ +#define _GL_INT_TWOS_COMPLEMENT(e) (~ _GL_INT_CONVERT (e, 0) == -1) /* True if the arithmetic type T is signed. */ -# define TYPE_SIGNED(t) (! ((t) 0 < (t) -1)) - -/* The maximum and minimum values for the integer type T. These +#define TYPE_SIGNED(t) (! ((t) 0 < (t) -1)) + +/* Return 1 if the integer expression E, after integer promotion, has + a signed type. E should not have side effects. */ +#define _GL_INT_SIGNED(e) (_GL_INT_CONVERT (e, -1) < 0) + + +/* Minimum and maximum values for integer types and expressions. These macros have undefined behavior if T is signed and has padding bits. If this is a problem for you, please let us know how to fix it for your host. */ -# define TYPE_MINIMUM(t) \ - ((t) (! TYPE_SIGNED (t) \ - ? (t) 0 \ - : TYPE_SIGNED_MAGNITUDE (t) \ - ? ~ (t) 0 \ + +/* The maximum and minimum values for the integer type T. */ +#define TYPE_MINIMUM(t) \ + ((t) (! TYPE_SIGNED (t) \ + ? (t) 0 \ + : TYPE_SIGNED_MAGNITUDE (t) \ + ? ~ (t) 0 \ : ~ TYPE_MAXIMUM (t))) -# define TYPE_MAXIMUM(t) \ - ((t) (! TYPE_SIGNED (t) \ - ? (t) -1 \ +#define TYPE_MAXIMUM(t) \ + ((t) (! TYPE_SIGNED (t) \ + ? (t) -1 \ : ((((t) 1 << (sizeof (t) * CHAR_BIT - 2)) - 1) * 2 + 1))) -/* Return zero if T can be determined to be an unsigned type. - Otherwise, return 1. - When compiling with GCC, INT_STRLEN_BOUND uses this macro to obtain a - tighter bound. Otherwise, it overestimates the true bound by one byte - when applied to unsigned types of size 2, 4, 16, ... bytes. - The symbol signed_type_or_expr__ is private to this header file. */ -# if __GNUC__ >= 2 -# define signed_type_or_expr__(t) TYPE_SIGNED (__typeof__ (t)) -# else -# define signed_type_or_expr__(t) 1 -# endif +/* The maximum and minimum values for the type of the expression E, + after integer promotion. E should not have side effects. */ +#define _GL_INT_MINIMUM(e) \ + (_GL_INT_SIGNED (e) \ + ? - _GL_INT_TWOS_COMPLEMENT (e) - _GL_SIGNED_INT_MAXIMUM (e) \ + : _GL_INT_CONVERT (e, 0)) +#define _GL_INT_MAXIMUM(e) \ + (_GL_INT_SIGNED (e) \ + ? _GL_SIGNED_INT_MAXIMUM (e) \ + : _GL_INT_CONVERT (e, -1)) +#define _GL_SIGNED_INT_MAXIMUM(e) \ + (((_GL_INT_CONVERT (e, 1) << (sizeof ((e) + 0) * CHAR_BIT - 2)) - 1) * 2 + 1) + + +/* Return 1 if the __typeof__ keyword works. This could be done by + 'configure', but for now it's easier to do it by hand. */ +#if 2 <= __GNUC__ || 0x5110 <= __SUNPRO_C +# define _GL_HAVE___TYPEOF__ 1 +#else +# define _GL_HAVE___TYPEOF__ 0 +#endif + +/* Return 1 if the integer type or expression T might be signed. Return 0 + if it is definitely unsigned. This macro does not evaluate its argument, + and expands to an integer constant expression. */ +#if _GL_HAVE___TYPEOF__ +# define _GL_SIGNED_TYPE_OR_EXPR(t) TYPE_SIGNED (__typeof__ (t)) +#else +# define _GL_SIGNED_TYPE_OR_EXPR(t) 1 +#endif /* Bound on length of the string representing an unsigned integer value representable in B bits. log10 (2.0) < 146/485. The smallest value of B where this bound is not tight is 2621. */ -# define INT_BITS_STRLEN_BOUND(b) (((b) * 146 + 484) / 485) +#define INT_BITS_STRLEN_BOUND(b) (((b) * 146 + 484) / 485) /* Bound on length of the string representing an integer type or expression T. Subtract 1 for the sign bit if T is signed, and then add 1 more for - a minus sign if needed. */ -# define INT_STRLEN_BOUND(t) \ - (INT_BITS_STRLEN_BOUND (sizeof (t) * CHAR_BIT - signed_type_or_expr__ (t)) \ - + signed_type_or_expr__ (t)) + a minus sign if needed. + + Because _GL_SIGNED_TYPE_OR_EXPR sometimes returns 0 when its argument is + signed, this macro may overestimate the true bound by one byte when + applied to unsigned types of size 2, 4, 16, ... bytes. */ +#define INT_STRLEN_BOUND(t) \ + (INT_BITS_STRLEN_BOUND (sizeof (t) * CHAR_BIT \ + - _GL_SIGNED_TYPE_OR_EXPR (t)) \ + + _GL_SIGNED_TYPE_OR_EXPR (t)) /* Bound on buffer size needed to represent an integer type or expression T, including the terminating null. */ -# define INT_BUFSIZE_BOUND(t) (INT_STRLEN_BOUND (t) + 1) - -#endif /* GL_INTPROPS_H */ +#define INT_BUFSIZE_BOUND(t) (INT_STRLEN_BOUND (t) + 1) + + +/* Range overflow checks. + + The INT__RANGE_OVERFLOW macros return 1 if the corresponding C + operators might not yield numerically correct answers due to + arithmetic overflow. They do not rely on undefined or + implementation-defined behavior. Their implementations are simple + and straightforward, but they are a bit harder to use than the + INT__OVERFLOW macros described below. + + Example usage: + + long int i = ...; + long int j = ...; + if (INT_MULTIPLY_RANGE_OVERFLOW (i, j, LONG_MIN, LONG_MAX)) + printf ("multiply would overflow"); + else + printf ("product is %ld", i * j); + + Restrictions on *_RANGE_OVERFLOW macros: + + These macros do not check for all possible numerical problems or + undefined or unspecified behavior: they do not check for division + by zero, for bad shift counts, or for shifting negative numbers. + + These macros may evaluate their arguments zero or multiple times, + so the arguments should not have side effects. The arithmetic + arguments (including the MIN and MAX arguments) must be of the same + integer type after the usual arithmetic conversions, and the type + must have minimum value MIN and maximum MAX. Unsigned types should + use a zero MIN of the proper type. + + These macros are tuned for constant MIN and MAX. For commutative + operations such as A + B, they are also tuned for constant B. */ + +/* Return 1 if A + B would overflow in [MIN,MAX] arithmetic. + See above for restrictions. */ +#define INT_ADD_RANGE_OVERFLOW(a, b, min, max) \ + ((b) < 0 \ + ? (a) < (min) - (b) \ + : (max) - (b) < (a)) + +/* Return 1 if A - B would overflow in [MIN,MAX] arithmetic. + See above for restrictions. */ +#define INT_SUBTRACT_RANGE_OVERFLOW(a, b, min, max) \ + ((b) < 0 \ + ? (max) + (b) < (a) \ + : (a) < (min) + (b)) + +/* Return 1 if - A would overflow in [MIN,MAX] arithmetic. + See above for restrictions. */ +#define INT_NEGATE_RANGE_OVERFLOW(a, min, max) \ + ((min) < 0 \ + ? (a) < - (max) \ + : 0 < (a)) + +/* Return 1 if A * B would overflow in [MIN,MAX] arithmetic. + See above for restrictions. */ +#define INT_MULTIPLY_RANGE_OVERFLOW(a, b, min, max) \ + ((b) < 0 \ + ? ((a) < 0 \ + ? (a) < (max) / (b) \ + : (b) < -1 && (min) / (b) < (a)) \ + : (0 < (b) \ + && ((a) < 0 \ + ? (a) < (min) / (b) \ + : (max) / (b) < (a)))) + +/* Return 1 if A / B would overflow in [MIN,MAX] arithmetic. + See above for restrictions. Do not check for division by zero. */ +#define INT_DIVIDE_RANGE_OVERFLOW(a, b, min, max) \ + ((min) < 0 && (b) == -1 && (a) < - (max)) + +/* Return 1 if A % B would overflow in [MIN,MAX] arithmetic. + See above for restrictions. Do not check for division by zero. + Mathematically, % should never overflow, but on x86-like hosts + INT_MIN % -1 traps, and the C standard permits this, so treat this + as an overflow too. */ +#define INT_REMAINDER_RANGE_OVERFLOW(a, b, min, max) \ + INT_DIVIDE_RANGE_OVERFLOW (a, b, min, max) + +/* Return 1 if A << B would overflow in [MIN,MAX] arithmetic. + See above for restrictions. Here, MIN and MAX are for A only, and B need + not be of the same type as the other arguments. The C standard says that + behavior is undefined for shifts unless 0 <= B < wordwidth, and that when + A is negative then A << B has undefined behavior and A >> B has + implementation-defined behavior, but do not check these other + restrictions. */ +#define INT_LEFT_SHIFT_RANGE_OVERFLOW(a, b, min, max) \ + ((a) < 0 \ + ? (a) < (min) >> (b) \ + : (max) >> (b) < (a)) + + +/* The _GL*_OVERFLOW macros have the same restrictions as the + *_RANGE_OVERFLOW macros, except that they do not assume that operands + (e.g., A and B) have the same type as MIN and MAX. Instead, they assume + that the result (e.g., A + B) has that type. */ +#define _GL_ADD_OVERFLOW(a, b, min, max) \ + ((min) < 0 ? INT_ADD_RANGE_OVERFLOW (a, b, min, max) \ + : (a) < 0 ? (b) <= (a) + (b) \ + : (b) < 0 ? (a) <= (a) + (b) \ + : (a) + (b) < (b)) +#define _GL_SUBTRACT_OVERFLOW(a, b, min, max) \ + ((min) < 0 ? INT_SUBTRACT_RANGE_OVERFLOW (a, b, min, max) \ + : (a) < 0 ? 1 \ + : (b) < 0 ? (a) - (b) <= (a) \ + : (a) < (b)) +#define _GL_MULTIPLY_OVERFLOW(a, b, min, max) \ + (((min) == 0 && (((a) < 0 && 0 < (b)) || ((b) < 0 && 0 < (a)))) \ + || INT_MULTIPLY_RANGE_OVERFLOW (a, b, min, max)) +#define _GL_DIVIDE_OVERFLOW(a, b, min, max) \ + ((min) < 0 ? (b) == _GL_INT_CONVERT (min, -1) && (a) < - (max) \ + : (a) < 0 ? (b) <= (a) + (b) - 1 \ + : (b) < 0 && (a) + (b) <= (a)) +#define _GL_REMAINDER_OVERFLOW(a, b, min, max) \ + ((min) < 0 ? (b) == _GL_INT_CONVERT (min, -1) && (a) < - (max) \ + : (a) < 0 ? (a) % (b) != ((max) - (b) + 1) % (b) \ + : (b) < 0 && ! _GL_UNSIGNED_NEG_MULTIPLE (a, b, max)) + +/* Return a nonzero value if A is a mathematical multiple of B, where + A is unsigned, B is negative, and MAX is the maximum value of A's + type. A's type must be the same as (A % B)'s type. Normally (A % + -B == 0) suffices, but things get tricky if -B would overflow. */ +#define _GL_UNSIGNED_NEG_MULTIPLE(a, b, max) \ + (((b) < -_GL_SIGNED_INT_MAXIMUM (b) \ + ? (_GL_SIGNED_INT_MAXIMUM (b) == (max) \ + ? (a) \ + : (a) % (_GL_INT_CONVERT (a, _GL_SIGNED_INT_MAXIMUM (b)) + 1)) \ + : (a) % - (b)) \ + == 0) + + +/* Integer overflow checks. + + The INT__OVERFLOW macros return 1 if the corresponding C operators + might not yield numerically correct answers due to arithmetic overflow. + They work correctly on all known practical hosts, and do not rely + on undefined behavior due to signed arithmetic overflow. + + Example usage: + + long int i = ...; + long int j = ...; + if (INT_MULTIPLY_OVERFLOW (i, j)) + printf ("multiply would overflow"); + else + printf ("product is %ld", i * j); + + These macros do not check for all possible numerical problems or + undefined or unspecified behavior: they do not check for division + by zero, for bad shift counts, or for shifting negative numbers. + + These macros may evaluate their arguments zero or multiple times, so the + arguments should not have side effects. + + These macros are tuned for their last argument being a constant. + + Return 1 if the integer expressions A * B, A - B, -A, A * B, A / B, + A % B, and A << B would overflow, respectively. */ + +#define INT_ADD_OVERFLOW(a, b) \ + _GL_BINARY_OP_OVERFLOW (a, b, _GL_ADD_OVERFLOW) +#define INT_SUBTRACT_OVERFLOW(a, b) \ + _GL_BINARY_OP_OVERFLOW (a, b, _GL_SUBTRACT_OVERFLOW) +#define INT_NEGATE_OVERFLOW(a) \ + INT_NEGATE_RANGE_OVERFLOW (a, _GL_INT_MINIMUM (a), _GL_INT_MAXIMUM (a)) +#define INT_MULTIPLY_OVERFLOW(a, b) \ + _GL_BINARY_OP_OVERFLOW (a, b, _GL_MULTIPLY_OVERFLOW) +#define INT_DIVIDE_OVERFLOW(a, b) \ + _GL_BINARY_OP_OVERFLOW (a, b, _GL_DIVIDE_OVERFLOW) +#define INT_REMAINDER_OVERFLOW(a, b) \ + _GL_BINARY_OP_OVERFLOW (a, b, _GL_REMAINDER_OVERFLOW) +#define INT_LEFT_SHIFT_OVERFLOW(a, b) \ + INT_LEFT_SHIFT_RANGE_OVERFLOW (a, b, \ + _GL_INT_MINIMUM (a), _GL_INT_MAXIMUM (a)) + +/* Return 1 if the expression A B would overflow, + where OP_RESULT_OVERFLOW (A, B, MIN, MAX) does the actual test, + assuming MIN and MAX are the minimum and maximum for the result type. + + This macro assumes that A | B is a valid integer if both A and B are, + which is true of all known practical hosts. If this is a problem + for you, please let us know how to fix it for your host. */ +#define _GL_BINARY_OP_OVERFLOW(a, b, op_result_overflow) \ + op_result_overflow (a, b, \ + _GL_INT_MINIMUM ((a) | (b)), \ + _GL_INT_MAXIMUM ((a) | (b))) + +#endif /* _GL_INTPROPS_H */ === modified file 'lib/unistd.in.h' --- lib/unistd.in.h 2011-04-18 04:03:18 +0000 +++ lib/unistd.in.h 2011-05-16 00:51:54 +0000 @@ -871,6 +871,22 @@ #endif +#if @GNULIB_GROUP_MEMBER@ +/* Determine whether group id is in calling user's group list. */ +# if !@HAVE_GROUP_MEMBER@ +_GL_FUNCDECL_SYS (group_member, int, (gid_t gid)); +# endif +_GL_CXXALIAS_SYS (group_member, int, (gid_t gid)); +_GL_CXXALIASWARN (group_member); +#elif defined GNULIB_POSIXCHECK +# undef group_member +# if HAVE_RAW_DECL_GROUP_MEMBER +_GL_WARN_ON_USE (group_member, "group_member is unportable - " + "use gnulib module group-member for portability"); +# endif +#endif + + #if @GNULIB_LCHOWN@ /* Change the owner of FILE to UID (if UID is not -1) and the group of FILE to GID (if GID is not -1). Do not follow symbolic links. === modified file 'm4/unistd_h.m4' --- m4/unistd_h.m4 2011-04-18 04:03:18 +0000 +++ m4/unistd_h.m4 2011-05-16 00:51:54 +0000 @@ -1,4 +1,4 @@ -# unistd_h.m4 serial 55 +# unistd_h.m4 serial 56 dnl Copyright (C) 2006-2011 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, @@ -36,8 +36,8 @@ ]], [chown dup2 dup3 environ euidaccess faccessat fchdir fchownat fsync ftruncate getcwd getdomainname getdtablesize getgroups gethostname getlogin getlogin_r getpagesize getusershell setusershell - endusershell lchown link linkat lseek pipe pipe2 pread pwrite readlink - readlinkat rmdir sleep symlink symlinkat ttyname_r unlink unlinkat + endusershell group_member lchown link linkat lseek pipe pipe2 pread pwrite + readlink readlinkat rmdir sleep symlink symlinkat ttyname_r unlink unlinkat usleep]) ]) @@ -72,6 +72,7 @@ GNULIB_GETLOGIN_R=0; AC_SUBST([GNULIB_GETLOGIN_R]) GNULIB_GETPAGESIZE=0; AC_SUBST([GNULIB_GETPAGESIZE]) GNULIB_GETUSERSHELL=0; AC_SUBST([GNULIB_GETUSERSHELL]) + GNULIB_GROUP_MEMBER=0; AC_SUBST([GNULIB_GROUP_MEMBER]) GNULIB_LCHOWN=0; AC_SUBST([GNULIB_LCHOWN]) GNULIB_LINK=0; AC_SUBST([GNULIB_LINK]) GNULIB_LINKAT=0; AC_SUBST([GNULIB_LINKAT]) @@ -110,6 +111,7 @@ HAVE_GETHOSTNAME=1; AC_SUBST([HAVE_GETHOSTNAME]) HAVE_GETLOGIN=1; AC_SUBST([HAVE_GETLOGIN]) HAVE_GETPAGESIZE=1; AC_SUBST([HAVE_GETPAGESIZE]) + HAVE_GROUP_MEMBER=1; AC_SUBST([HAVE_GROUP_MEMBER]) HAVE_LCHOWN=1; AC_SUBST([HAVE_LCHOWN]) HAVE_LINK=1; AC_SUBST([HAVE_LINK]) HAVE_LINKAT=1; AC_SUBST([HAVE_LINKAT]) From debbugs-submit-bounces@debbugs.gnu.org Mon May 16 01:31:00 2011 Received: (at 8675) by debbugs.gnu.org; 16 May 2011 05:31:01 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QLqOS-0003iP-BS for submit@debbugs.gnu.org; Mon, 16 May 2011 01:31:00 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QLqOP-0003i7-Kx for 8675@debbugs.gnu.org; Mon, 16 May 2011 01:30:59 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LL900E00WM6VJ00@a-mtaout22.012.net.il> for 8675@debbugs.gnu.org; Mon, 16 May 2011 08:30:20 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.228.84.222]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LL900DSEWMFY6D0@a-mtaout22.012.net.il>; Mon, 16 May 2011 08:30:20 +0300 (IDT) Date: Mon, 16 May 2011 08:30:13 +0300 From: Eli Zaretskii Subject: Re: bug#8675: lisp_string_width and strings wider than INT_MAX In-reply-to: <4DD0B118.1040205@cs.ucla.edu> X-012-Sender: halo1@inter.net.il To: Paul Eggert Message-id: <83pqnjdxga.fsf@gnu.org> References: <4DD0B118.1040205@cs.ucla.edu> X-Spam-Score: -2.1 (--) X-Debbugs-Envelope-To: 8675 Cc: 8675@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > Date: Sun, 15 May 2011 22:07:36 -0700 > From: Paul Eggert > > PATCH 3 depends on two obvious patches: PATCH 2 introduces a helper > no-return function string_overflow, and PATCH 1 updates to the latest > version of gnulib. Thanks, but why do these patches come with unrelated changes in texinfo.tex? From debbugs-submit-bounces@debbugs.gnu.org Mon May 16 01:33:12 2011 Received: (at 8675) by debbugs.gnu.org; 16 May 2011 05:33:12 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QLqQa-0003lr-IG for submit@debbugs.gnu.org; Mon, 16 May 2011 01:33:12 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QLqQY-0003le-9C for 8675@debbugs.gnu.org; Mon, 16 May 2011 01:33:11 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id B30A039E8141; Sun, 15 May 2011 22:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+I61ACBc9ZN; Sun, 15 May 2011 22:33:04 -0700 (PDT) Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 4A0C939E8140; Sun, 15 May 2011 22:33:04 -0700 (PDT) Message-ID: <4DD0B70F.7090801@cs.ucla.edu> Date: Sun, 15 May 2011 22:33:03 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#8675: lisp_string_width and strings wider than INT_MAX References: <4DD0B118.1040205@cs.ucla.edu> <83pqnjdxga.fsf@gnu.org> In-Reply-To: <83pqnjdxga.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 8675 Cc: 8675@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) On 05/15/11 22:30, Eli Zaretskii wrote: >> Date: Sun, 15 May 2011 22:07:36 -0700 >> From: Paul Eggert >> >> PATCH 3 depends on two obvious patches: PATCH 2 introduces a helper >> no-return function string_overflow, and PATCH 1 updates to the latest >> version of gnulib. > > Thanks, but why do these patches come with unrelated changes in > texinfo.tex? Because that's part of PATCH 1, which updates to the latest version of gnulib. Gnulib contains texinfo.tex. PATCH 1 was generated entirely automatically by "make sync-from-gnulib". From debbugs-submit-bounces@debbugs.gnu.org Mon May 16 03:57:48 2011 Received: (at 8675) by debbugs.gnu.org; 16 May 2011 07:57:48 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QLsgV-0006xj-Vu for submit@debbugs.gnu.org; Mon, 16 May 2011 03:57:48 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QLsgS-0006xV-Vq for 8675@debbugs.gnu.org; Mon, 16 May 2011 03:57:46 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LLA00G003DLZY00@a-mtaout22.012.net.il> for 8675@debbugs.gnu.org; Mon, 16 May 2011 10:57:38 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.228.84.222]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LLA00G833G0FQ50@a-mtaout22.012.net.il>; Mon, 16 May 2011 10:57:37 +0300 (IDT) Date: Mon, 16 May 2011 10:57:34 +0300 From: Eli Zaretskii Subject: Re: bug#8675: lisp_string_width and strings wider than INT_MAX In-reply-to: <4DD0B70F.7090801@cs.ucla.edu> X-012-Sender: halo1@inter.net.il To: Paul Eggert Message-id: <83mxindqmp.fsf@gnu.org> References: <4DD0B118.1040205@cs.ucla.edu> <83pqnjdxga.fsf@gnu.org> <4DD0B70F.7090801@cs.ucla.edu> X-Spam-Score: -2.1 (--) X-Debbugs-Envelope-To: 8675 Cc: 8675@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > Date: Sun, 15 May 2011 22:33:03 -0700 > From: Paul Eggert > CC: 8675@debbugs.gnu.org > > On 05/15/11 22:30, Eli Zaretskii wrote: > >> Date: Sun, 15 May 2011 22:07:36 -0700 > >> From: Paul Eggert > >> > >> PATCH 3 depends on two obvious patches: PATCH 2 introduces a helper > >> no-return function string_overflow, and PATCH 1 updates to the latest > >> version of gnulib. > > > > Thanks, but why do these patches come with unrelated changes in > > texinfo.tex? > > Because that's part of PATCH 1, which updates to the latest version > of gnulib. Gnulib contains texinfo.tex. PATCH 1 was generated > entirely automatically by "make sync-from-gnulib". When you merge, could you please make the texinfo.tex update a separate commit on the trunk, then? No one will ever expect to find that file in a commit logged as "sync from gnulib", which will make forensics more difficult than it needs to (since your commits are always merge-commits). TIA From debbugs-submit-bounces@debbugs.gnu.org Mon May 16 12:37:16 2011 Received: (at 8675) by debbugs.gnu.org; 16 May 2011 16:37:16 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QM0nE-0003Uc-7D for submit@debbugs.gnu.org; Mon, 16 May 2011 12:37:16 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QM0nB-0003UL-KA for 8675@debbugs.gnu.org; Mon, 16 May 2011 12:37:14 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 2822A39E8145; Mon, 16 May 2011 09:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOZUfkHdbB-R; Mon, 16 May 2011 09:37:07 -0700 (PDT) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id A265439E8143; Mon, 16 May 2011 09:37:07 -0700 (PDT) Message-ID: <4DD152B3.3020208@cs.ucla.edu> Date: Mon, 16 May 2011 09:37:07 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Thunderbird/3.1.10 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#8675: lisp_string_width and strings wider than INT_MAX References: <4DD0B118.1040205@cs.ucla.edu> <83pqnjdxga.fsf@gnu.org> <4DD0B70F.7090801@cs.ucla.edu> <83mxindqmp.fsf@gnu.org> In-Reply-To: <83mxindqmp.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.2 (---) X-Debbugs-Envelope-To: 8675 Cc: 8675@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.2 (---) On 05/16/11 00:57, Eli Zaretskii wrote: > When you merge, could you please make the texinfo.tex update a > separate commit on the trunk, then? No one will ever expect to find > that file in a commit logged as "sync from gnulib", which will make > forensics more difficult than it needs to (since your commits are > always merge-commits). Currently what I do is "make sync-from-gnulib" followed by "bzr commit". This is requesting that I go to more work, by breaking up the merge from gnulib into smaller functional pieces, one for each functional change in gnulib, and installing them individually. I'd rather not. Not only would this be more work, it would run contrary to other advice I've gotten, which is to batch changes instead of installing lots of little changes one at a time. Besides, I doubt whether including texinfo.tex confuses forensics much, so it's not at all clear that the extra work would be an overall win. Gnulib changes are like autogen changes. They're mostly ignorable, but if a problem comes up, one can do forensics by going to the repository we're importing from and looking at its history. When autotools change, we don't commit the resulting changes to "configure" individually, and that's a similar situation. From debbugs-submit-bounces@debbugs.gnu.org Mon May 16 12:48:49 2011 Received: (at 8675) by debbugs.gnu.org; 16 May 2011 16:48:49 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QM0yO-0003kk-St for submit@debbugs.gnu.org; Mon, 16 May 2011 12:48:49 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QM0yJ-0003kV-Va for 8675@debbugs.gnu.org; Mon, 16 May 2011 12:48:48 -0400 Received: from 213-159-126-200.fibertel.com.ar ([200.126.159.213]:33058 helo=ceviche.home) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1QM0yC-0002DK-L4; Mon, 16 May 2011 12:48:37 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 4750E66140; Mon, 16 May 2011 13:48:33 -0300 (ART) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#8675: lisp_string_width and strings wider than INT_MAX Message-ID: References: <4DD0B118.1040205@cs.ucla.edu> <83pqnjdxga.fsf@gnu.org> <4DD0B70F.7090801@cs.ucla.edu> <83mxindqmp.fsf@gnu.org> Date: Mon, 16 May 2011 13:48:33 -0300 In-Reply-To: <83mxindqmp.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 16 May 2011 10:57:34 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -6.0 (------) X-Debbugs-Envelope-To: 8675 Cc: Paul Eggert , 8675@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.0 (------) > When you merge, could you please make the texinfo.tex update a > separate commit on the trunk, then? Why? > No one will ever expect to find that file in a commit logged as "sync > from gnulib", I, for one, do. texinfo.tex is not a file we maintain, so I fully expect to find its changes in some kind of "sync from outside" commit. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue May 17 05:52:50 2011 Received: (at 8675) by debbugs.gnu.org; 17 May 2011 09:52:50 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QMGxO-0002ZK-Ba for submit@debbugs.gnu.org; Tue, 17 May 2011 05:52:50 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QMGxM-0002Z6-W3 for 8675@debbugs.gnu.org; Tue, 17 May 2011 05:52:49 -0400 Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1QMGxG-0004M2-L8; Tue, 17 May 2011 05:52:42 -0400 Date: Tue, 17 May 2011 05:52:42 -0400 Message-Id: From: Eli Zaretskii To: Stefan Monnier In-reply-to: (message from Stefan Monnier on Mon, 16 May 2011 13:48:33 -0300) Subject: Re: bug#8675: lisp_string_width and strings wider than INT_MAX References: <4DD0B118.1040205@cs.ucla.edu> <83pqnjdxga.fsf@gnu.org> <4DD0B70F.7090801@cs.ucla.edu> <83mxindqmp.fsf@gnu.org> X-Spam-Score: -6.6 (------) X-Debbugs-Envelope-To: 8675 Cc: eggert@cs.ucla.edu, 8675@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) > From: Stefan Monnier > Cc: Paul Eggert , 8675@debbugs.gnu.org > Date: Mon, 16 May 2011 13:48:33 -0300 > > > When you merge, could you please make the texinfo.tex update a > > separate commit on the trunk, then? > > Why? > > > No one will ever expect to find that file in a commit logged as "sync > > from gnulib", > > I, for one, do. texinfo.tex is not a file we maintain, so I fully > expect to find its changes in some kind of "sync from outside" commit. I'm moving this sub-thread to emacs-devel, as it is no longer a casual remark related to this bug. From debbugs-submit-bounces@debbugs.gnu.org Tue May 17 21:33:35 2011 Received: (at 8675-done) by debbugs.gnu.org; 18 May 2011 01:33:36 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QMVdm-0007ix-N9 for submit@debbugs.gnu.org; Tue, 17 May 2011 21:33:34 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QMVdk-0007if-5G; Tue, 17 May 2011 21:33:33 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 1840039E816B; Tue, 17 May 2011 18:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HONdNdJcLcZ; Tue, 17 May 2011 18:33:25 -0700 (PDT) Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id BC8CE39E8106; Tue, 17 May 2011 18:33:25 -0700 (PDT) Message-ID: <4DD321E5.2020202@cs.ucla.edu> Date: Tue, 17 May 2011 18:33:25 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: 8675-done@debbugs.gnu.org, 8664-done@debbugs.gnu.org Subject: committed fix into trunk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 8675-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) Bzr 104265,which I just committed into the trunk, should contain the fix discussed above, so I'm marking this as "done". As requested I separated the gnulib merge into a separate commit, bzr 104264. From debbugs-submit-bounces@debbugs.gnu.org Tue May 17 22:26:19 2011 Received: (at 8675) by debbugs.gnu.org; 18 May 2011 02:26:20 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QMWSp-0000Xg-Jl for submit@debbugs.gnu.org; Tue, 17 May 2011 22:26:19 -0400 Received: from mail-iw0-f172.google.com ([209.85.214.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QMWSn-0000XU-9H for 8675@debbugs.gnu.org; Tue, 17 May 2011 22:26:18 -0400 Received: by iwn39 with SMTP id 39so957760iwn.3 for <8675@debbugs.gnu.org>; Tue, 17 May 2011 19:26:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cGsHSlChMZW8jRdQT1hQi0Ps99cI8PUXzrH7W2zI4+o=; b=O2F40qIYd2KU6fpPSf19bl3HnpS+6KfGA21zje58UI7hp5+mfMP1SGXplvLTtF5UXo pyaP8OEZ4UFgZMqOGTb1w4i3IqEZRzOrtdRy4iD4Ho87Xxbyt5+4lzsuNG6QIWSCKdXF 7dAyk98JTe5UbBKGR1RDgOvw0FORUnpoymn0o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=lIxduUqQVInjntWWznih3MkvvbwNwBbLfztX1ITk4RaU9y3b1zDRKckHbYWDQlFT/n YSAxnjj9YU8+bex2zBZ+Fyx1pNRFTLs3TC4mOnKS0931q0o0wjGTE0V32cjPgUI/HE0i EAcIhxaZ5wgBSg/VTIzwnRZQCnIIw5gTkCSf4= Received: by 10.42.161.134 with SMTP id t6mr1472561icx.384.1305685571725; Tue, 17 May 2011 19:26:11 -0700 (PDT) Received: from [192.168.1.5] (71-208-134-56.hlrn.qwest.net [71.208.134.56]) by mx.google.com with ESMTPS id c6sm458340ibj.55.2011.05.17.19.26.10 (version=SSLv3 cipher=OTHER); Tue, 17 May 2011 19:26:11 -0700 (PDT) Message-ID: <4DD32E3C.7080408@gmail.com> Date: Tue, 17 May 2011 20:26:04 -0600 From: Christoph Scholtes User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: 8675@debbugs.gnu.org, eggert@cs.ucla.edu Subject: Re: bug#8675: committed fix into trunk References: <4DD0B118.1040205@cs.ucla.edu> <4DD321E5.2020202@cs.ucla.edu> In-Reply-To: <4DD321E5.2020202@cs.ucla.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: 8675 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.0 (----) On 5/17/2011 7:33 PM, Paul Eggert wrote: > Bzr 104265,which I just committed into the trunk, > should contain the fix discussed above, so I'm > marking this as "done". As requested I separated > the gnulib merge into a separate commit, bzr 104264. bzr 104264 breaks the current build on GNU/Linux (Debian Squeeze with gcc - Debian 4.4.5-8): gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../src -I/home/devel/emacs/trunk/src -g -O2 -MT careadlinkat.o -MD -MP -MF .deps/careadlinkat.Tpo -c -o careadlinkat.o careadlinkat.c In file included from careadlinkat.h:24, from careadlinkat.c:23: ./unistd.h:1186:5: error: token "@" is not valid in preprocessor expressions make[3]: *** [careadlinkat.o] Error 1 make[3]: Leaving directory `/home/devel/emacs/trunk/lib' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/devel/emacs/trunk/lib' make[1]: *** [lib] Error 2 make[1]: Leaving directory `/home/devel/emacs/trunk' make: *** [bootstrap] Error 2 From unistd.h, l.1186: #if @GNULIB_GROUP_MEMBER@ /* Determine whether group id is in calling user's group list. */ # if !@HAVE_GROUP_MEMBER@ _GL_FUNCDECL_SYS (group_member, int, (gid_t gid)); # endif Note, that there are other instances with @ in the file. Christoph From debbugs-submit-bounces@debbugs.gnu.org Tue May 17 22:49:01 2011 Received: (at 8675) by debbugs.gnu.org; 18 May 2011 02:49:01 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QMWom-000188-Vt for submit@debbugs.gnu.org; Tue, 17 May 2011 22:49:01 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QMWoj-00017u-50 for 8675@debbugs.gnu.org; Tue, 17 May 2011 22:48:58 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 3554C39E8108; Tue, 17 May 2011 19:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4AEsEkTKZGF; Tue, 17 May 2011 19:48:50 -0700 (PDT) Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id D1E2839E8106; Tue, 17 May 2011 19:48:50 -0700 (PDT) Message-ID: <4DD33392.7020907@cs.ucla.edu> Date: Tue, 17 May 2011 19:48:50 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Christoph Scholtes Subject: Re: bug#8675: committed fix into trunk References: <4DD0B118.1040205@cs.ucla.edu> <4DD321E5.2020202@cs.ucla.edu> <4DD32E3C.7080408@gmail.com> In-Reply-To: <4DD32E3C.7080408@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 8675 Cc: 8675@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) On 05/17/11 19:26, Christoph Scholtes wrote: > ./unistd.h:1186:5: error: token "@" is not valid in preprocessor expressions I can't reproduce the problem on Ubuntu 11.04 (stock gcc 4.5.2-8ubuntu4) with bzr 104265. That diagnostic is a symptom of doing a "bzr up" over a (partly?) built old checkout. I suggest trying "./autogen.sh; ./configure; make clean; make" or you can simply start with a fresh checkout of the trunk. From debbugs-submit-bounces@debbugs.gnu.org Tue May 17 23:19:44 2011 Received: (at 8675) by debbugs.gnu.org; 18 May 2011 03:19:44 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QMXIW-0001rI-Hw for submit@debbugs.gnu.org; Tue, 17 May 2011 23:19:44 -0400 Received: from mail-iy0-f172.google.com ([209.85.210.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QMXIU-0001r5-UQ for 8675@debbugs.gnu.org; Tue, 17 May 2011 23:19:43 -0400 Received: by iyn15 with SMTP id 15so981959iyn.3 for <8675@debbugs.gnu.org>; Tue, 17 May 2011 20:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qz4VeD8Rn+aBXv/3Ozigk6+m2PviKYoZju7LmiyjbpU=; b=XzLtw/mCwK//oZMCz+pxwpS+lYw2kQx/NStJxmCkOaV7qCX6yWFjeLYcjEK0j5H1Tf Q6O6nADmIwkBXEMMzTzWlabvhZU+zwmBMptFqtBsd/eksjqmqZvQdpvfYqA+pjKO8/jJ EMIsv4m2mOKA0Z0zGZjhOkey0YyxPFBjndIuI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=E6vkXXRY4xxUAbq8I008lkleCXO1/szAhamWqdF9X63Ox71zzql2keXhE/qFRFD71A vEoVYMfpsL0+z6jrHaYS74FmiwUK64D8Yidnnf3Xx4d6XxQJ0BC4/lcnGOsrBtr9DEnv 53jGHLSD8Zygxn+NEHulvoNFkUjI2wCSoPoJs= Received: by 10.231.165.212 with SMTP id j20mr980780iby.139.1305688776503; Tue, 17 May 2011 20:19:36 -0700 (PDT) Received: from [192.168.1.5] (71-208-134-56.hlrn.qwest.net [71.208.134.56]) by mx.google.com with ESMTPS id 19sm479416ibx.52.2011.05.17.20.19.34 (version=SSLv3 cipher=OTHER); Tue, 17 May 2011 20:19:35 -0700 (PDT) Message-ID: <4DD33AC0.4080903@gmail.com> Date: Tue, 17 May 2011 21:19:28 -0600 From: Christoph Scholtes User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Paul Eggert Subject: Re: bug#8675: committed fix into trunk References: <4DD0B118.1040205@cs.ucla.edu> <4DD321E5.2020202@cs.ucla.edu> <4DD32E3C.7080408@gmail.com> <4DD33392.7020907@cs.ucla.edu> In-Reply-To: <4DD33392.7020907@cs.ucla.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: 8675 Cc: 8675@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.0 (----) On 5/17/2011 8:48 PM, Paul Eggert wrote: > On 05/17/11 19:26, Christoph Scholtes wrote: >> ./unistd.h:1186:5: error: token "@" is not valid in preprocessor expressions > > I can't reproduce the problem on Ubuntu 11.04 (stock gcc 4.5.2-8ubuntu4) > with bzr 104265. > > That diagnostic is a symptom of doing a "bzr up" over a (partly?) built > old checkout. I suggest trying "./autogen.sh; ./configure; make clean; make" > or you can simply start with a fresh checkout of the trunk. The ./autogen.sh seemed to have fixed the issue. Sorry for the noise. From debbugs-submit-bounces@debbugs.gnu.org Wed May 18 08:39:47 2011 Received: (at 8675) by debbugs.gnu.org; 18 May 2011 12:39:47 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QMg2V-0007gb-1Z for submit@debbugs.gnu.org; Wed, 18 May 2011 08:39:47 -0400 Received: from mail-out.m-online.net ([212.18.0.9]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QMg2S-0007g1-5G for 8675@debbugs.gnu.org; Wed, 18 May 2011 08:39:45 -0400 Received: from frontend1.mail.m-online.net (unknown [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id AE3A31C1D9FA; Wed, 18 May 2011 14:39:37 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.8.164]) by mail.m-online.net (Postfix) with ESMTP id 16F021C0011D; Wed, 18 May 2011 14:39:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.180]) by localhost (dynscan1.mail.m-online.net [192.168.8.164]) (amavisd-new, port 10024) with ESMTP id E2Ht5UuYj2TY; Wed, 18 May 2011 14:39:36 +0200 (CEST) Received: from hase (ppp-93-104-151-90.dynamic.mnet-online.de [93.104.151.90]) by mail.mnet-online.de (Postfix) with ESMTP; Wed, 18 May 2011 14:39:35 +0200 (CEST) From: Andreas Schwab To: Paul Eggert Subject: Re: bug#8675: committed fix into trunk References: <4DD0B118.1040205@cs.ucla.edu> <4DD321E5.2020202@cs.ucla.edu> <4DD32E3C.7080408@gmail.com> <4DD33392.7020907@cs.ucla.edu> X-Yow: Three attractive BANK ROBBERS are discussing RELIGIOUS DIFFERENCES and MAKE-UP TECHNIQUE with them!! Date: Wed, 18 May 2011 14:39:34 +0200 In-Reply-To: <4DD33392.7020907@cs.ucla.edu> (Paul Eggert's message of "Tue, 17 May 2011 19:48:50 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 8675 Cc: Christoph Scholtes , 8675@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Paul Eggert writes: > That diagnostic is a symptom of doing a "bzr up" over a (partly?) built > old checkout. If that does not work, then proper dependencies are missing. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From debbugs-submit-bounces@debbugs.gnu.org Wed May 18 15:55:23 2011 Received: (at 8675) by debbugs.gnu.org; 18 May 2011 19:55:23 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QMmq3-0002PF-41 for submit@debbugs.gnu.org; Wed, 18 May 2011 15:55:23 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QMmpz-0002P2-Pr for 8675@debbugs.gnu.org; Wed, 18 May 2011 15:55:21 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 4995C39E8128; Wed, 18 May 2011 12:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tztQOk4lt+JI; Wed, 18 May 2011 12:55:13 -0700 (PDT) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 6352939E80F9; Wed, 18 May 2011 12:55:13 -0700 (PDT) Message-ID: <4DD42421.6090906@cs.ucla.edu> Date: Wed, 18 May 2011 12:55:13 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Thunderbird/3.1.10 MIME-Version: 1.0 To: Andreas Schwab Subject: Re: error: token "@" is not valid in preprocessor expressions References: <4DD0B118.1040205@cs.ucla.edu> <4DD321E5.2020202@cs.ucla.edu> <4DD32E3C.7080408@gmail.com> <4DD33392.7020907@cs.ucla.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.2 (---) X-Debbugs-Envelope-To: 8675 Cc: Christoph Scholtes , Bug-gnulib , 8675@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.2 (---) [Adding bug-gnulib to this thread. For bug-gnulib readers, the scenario is in Emacs a "bzr update; make" failed with: ./unistd.h:1186:5: error: token "@" is not valid in preprocessor expressions because unistd.h was built with the old Makefile. Full thread at . ] On 05/18/11 05:39, Andreas Schwab wrote: > If that does not work, then proper dependencies are missing. I don't see how adding a dependency would fix this problem. In this case, lib/Makefile in turn depended on 'configure', 'configure.in', 'm4/longlong.m4', etc., etc., and one of these files got updated, so lib/Makefile was regenerated; but as I understand it, the 'make' that was (still) running was based on the out-of-date lib/Makefile, and it generated the a bad lib/unistd.h. Adding a dependency "unistd.h: Makefile" wouldn't fix this problem. This sort of problem is not due to gnulib per se; it's inherent to any project that uses makefiles. In general, if a patch modifies a makefile, or anything the makefile depends on, then you must regenerate everything from scratch with a fresh 'make' invocation. That being said, I've run into Christoph's problem myself more than once, and it's a hassle, and it'd be nice to address it somehow. How about this idea? I expect it would have worked around this problem. Currently lib/Makefile contains something like this: unistd.h: Suppose we change this rule to look like this: unistd.h: Makefile case ' $? ,$(USING_NEW_MAKEFILE)' in \ *' Makefile '*,) \ exec $(MAKE) $(AM_MAKEFLAGS) USING_NEW_MAKEFILE=yes $@;; \ esac; \ This would be a gnulib change, so I'll CC: this to bug-gnulib. A similar pattern would apply to every module that generates a .h file with a big hairy command that uses 'make' variables. From debbugs-submit-bounces@debbugs.gnu.org Wed May 18 16:36:05 2011 Received: (at 8675) by debbugs.gnu.org; 18 May 2011 20:36:05 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QMnTR-0003L2-0V for submit@debbugs.gnu.org; Wed, 18 May 2011 16:36:05 -0400 Received: from mail-out.m-online.net ([212.18.0.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QMnTP-0003KZ-FD for 8675@debbugs.gnu.org; Wed, 18 May 2011 16:36:04 -0400 Received: from frontend1.mail.m-online.net (frontend1.mail.intern.m-online.net [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id 02E80188A18D; Wed, 18 May 2011 22:35:55 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.8.164]) by mail.m-online.net (Postfix) with ESMTP id CFBCB1C000A3; Wed, 18 May 2011 22:35:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.180]) by localhost (dynscan1.mail.m-online.net [192.168.8.164]) (amavisd-new, port 10024) with ESMTP id aq9fs6qLtG-i; Wed, 18 May 2011 22:35:55 +0200 (CEST) Received: from igel.home (ppp-93-104-151-90.dynamic.mnet-online.de [93.104.151.90]) by mail.mnet-online.de (Postfix) with ESMTP; Wed, 18 May 2011 22:35:55 +0200 (CEST) Received: by igel.home (Postfix, from userid 501) id DF20ECA29C; Wed, 18 May 2011 22:35:54 +0200 (CEST) From: Andreas Schwab To: Paul Eggert Subject: Re: error: token "@" is not valid in preprocessor expressions References: <4DD0B118.1040205@cs.ucla.edu> <4DD321E5.2020202@cs.ucla.edu> <4DD32E3C.7080408@gmail.com> <4DD33392.7020907@cs.ucla.edu> <4DD42421.6090906@cs.ucla.edu> X-Yow: Is the EIGHTIES when they had ART DECO and GERALD McBOING-BOING lunch boxes?? Date: Wed, 18 May 2011 22:35:54 +0200 In-Reply-To: <4DD42421.6090906@cs.ucla.edu> (Paul Eggert's message of "Wed, 18 May 2011 12:55:13 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 8675 Cc: Christoph Scholtes , Bug-gnulib , 8675@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Paul Eggert writes: > I don't see how adding a dependency would fix this problem. In this > case, lib/Makefile in turn depended on 'configure', 'configure.in', > 'm4/longlong.m4', etc., etc., and one of these files got updated, so > lib/Makefile was regenerated; but as I understand it, the 'make' that was > (still) running was based on the out-of-date lib/Makefile, and it > generated the a bad lib/unistd.h. Looks like an orderring problem. Normally, if GNU make sees that a makefile is remade it rereads it automatically. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From debbugs-submit-bounces@debbugs.gnu.org Wed May 18 18:59:22 2011 Received: (at 8675) by debbugs.gnu.org; 18 May 2011 22:59:22 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QMpi5-0006c4-RV for submit@debbugs.gnu.org; Wed, 18 May 2011 18:59:22 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QMpi4-0006bs-Ch for 8675@debbugs.gnu.org; Wed, 18 May 2011 18:59:21 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id E27D439E8116; Wed, 18 May 2011 15:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blY6HqC4X-ol; Wed, 18 May 2011 15:59:14 -0700 (PDT) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 6ED0439E80F9; Wed, 18 May 2011 15:59:14 -0700 (PDT) Message-ID: <4DD44F42.1050405@cs.ucla.edu> Date: Wed, 18 May 2011 15:59:14 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Thunderbird/3.1.10 MIME-Version: 1.0 To: Andreas Schwab Subject: Re: error: token "@" is not valid in preprocessor expressions References: <4DD0B118.1040205@cs.ucla.edu> <4DD321E5.2020202@cs.ucla.edu> <4DD32E3C.7080408@gmail.com> <4DD33392.7020907@cs.ucla.edu> <4DD42421.6090906@cs.ucla.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.2 (---) X-Debbugs-Envelope-To: 8675 Cc: Christoph Scholtes , Bug-gnulib , 8675@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.2 (---) On 05/18/11 13:35, Andreas Schwab wrote: > Normally, if GNU make sees that a > makefile is remade it rereads it automatically. Ah, thanks, I didn't know that. So if we care only about GNU make, then all we need to do is to have unistd.h depend on Makefile. And, once unistd.h depends on Makefile then it need not depend on config.status (as Makefile already depends on config.status). Like this: --- a/modules/unistd +++ b/modules/unistd @@ -20,7 +20,7 @@ BUILT_SOURCES += unistd.h # We need the following in order to create an empty placeholder for # when the system doesn't have one. -unistd.h: unistd.in.h $(top_builddir)/config.status $(CXXDEFS_H) $(ARG_NONNULL_H) $(WARN_ON_USE_H) +unistd.h: unistd.in.h Makefile $(CXXDEFS_H) $(ARG_NONNULL_H) $(WARN_ON_USE_H) $(AM_V_GEN)rm -f $@-t $@ && \ { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \ sed -e 's|@''HAVE_UNISTD_H''@|$(HAVE_UNISTD_H)|g' \ Looking at the existing gnulib modules, I see that almost all of them have the .h file depend on config.status, but there's one exception: configmake.h depends on Makefile. Shouldn't they all depend on Makefile rather than on config.status? That should have helped to avoid this problem. From debbugs-submit-bounces@debbugs.gnu.org Wed May 18 20:27:37 2011 Received: (at 8675) by debbugs.gnu.org; 19 May 2011 00:27:37 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QMr5U-000088-R2 for submit@debbugs.gnu.org; Wed, 18 May 2011 20:27:37 -0400 Received: from mo-p00-ob.rzone.de ([81.169.146.160]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QMr5R-00007q-Uo for 8675@debbugs.gnu.org; Wed, 18 May 2011 20:27:35 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1305764847; l=2951; s=domk; d=haible.de; h=Content-Transfer-Encoding:Content-Type:MIME-Version:In-Reply-To: References:Cc:Date:Subject:To:From:X-RZG-CLASS-ID:X-RZG-AUTH; bh=9AGvdFsJGCmzA5ojjN4y1qdsLww=; b=GuWT2rRlJ8xwmPMkdxXQzBa9KR36cGmab5KBjFCb1PlyRgrXK08ksiR8sXUihJJKQnu h36O1oEMCscXO4Gz6QtDjSXYoOQOBS/KMWh7PvRbYs9ZKveZ92rqqdfX1phvlK9WfmTbz uxCCGctgwE3s5mEBeIzoaT5EMva13HsxJck= X-RZG-AUTH: :Ln4Re0+Ic/6oZXR1YgKryK8brksyK8dozXDwHXjf9hj/zDNRbvU45h26 X-RZG-CLASS-ID: mo00 Received: from linuix.haible.de (dslb-088-068-073-041.pools.arcor-ip.net [88.68.73.41]) by post.strato.de (cohen mo1) (RZmta 25.18) with ESMTPA id e03564n4ILG2nD ; Thu, 19 May 2011 02:27:26 +0200 (MEST) From: Bruno Haible To: bug-gnulib@gnu.org Subject: Re: error: token "@" is not valid in preprocessor expressions Date: Thu, 19 May 2011 02:27:24 +0200 User-Agent: KMail/1.9.9 References: <4DD0B118.1040205@cs.ucla.edu> <4DD44F42.1050405@cs.ucla.edu> In-Reply-To: <4DD44F42.1050405@cs.ucla.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201105190227.26215.bruno@clisp.org> X-Spam-Score: -3.6 (---) X-Debbugs-Envelope-To: 8675 Cc: Christoph Scholtes , 8675@debbugs.gnu.org, Paul Eggert , Andreas Schwab X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) Hi Paul, > all we need to do is to have unistd.h > depend on Makefile. And, once unistd.h depends on Makefile > then it need not depend on config.status (as Makefile already > depends on config.status). Like this: > > --- a/modules/unistd > +++ b/modules/unistd > @@ -20,7 +20,7 @@ BUILT_SOURCES += unistd.h > > # We need the following in order to create an empty placeholder for > # when the system doesn't have one. > -unistd.h: unistd.in.h $(top_builddir)/config.status $(CXXDEFS_H) $(ARG_NONNULL_H) $(WARN_ON_USE_H) > +unistd.h: unistd.in.h Makefile $(CXXDEFS_H) $(ARG_NONNULL_H) $(WARN_ON_USE_H) > $(AM_V_GEN)rm -f $@-t $@ && \ > { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \ > sed -e 's|@''HAVE_UNISTD_H''@|$(HAVE_UNISTD_H)|g' \ > Such a change would have the effect that hand-editing a Makefile would cause all gnulib *.h files to be regenerated and, with it, all *.o files would be recompiled. However, hand-editing a Makefile is necessary in two situations at least: 1) to test a certain modification of compilation commands, before putting the changes into Makefile.am, 2) to trace the effect of C compiler bugs, by compiling different *.o files with different compiler optimization levels. I'm therefore vehemently opposed to such a change. In fact, in the thread starting at we developed some Automake tests for guaranteeing that everything is properly rebuilt, and it turned out that 1. some specific code pattern is necessary in the module descriptions, and it was implemented on 2011-04-03, 2. GNU make is necessary as well. But that's it. So, if the reporter was using GNU make and the previous Makefile.in was based on gnulib 2011-04-03 or newer and the reporter did a make command in the top-level directory that recreated config.status before recursing into lib/ and then into src/, then the situation cannot have occurred. If the reporter was not using GNU make, he should do so. It has become clear through the tests in Automake that GNU make is a requirement for rebuilds to be reliable. If the previous Makefile.in was not based on gnulib 2011-04-03 or newer, we need to do nothing; the problem is already fixed. If the reporter did "make" in the top-level directory of emacs and it did not rebuild config.status, even after configure changed, it needs to be fixed in emacs. If the reporter only did "make" in the lib/ or src/ subdirectory and not in the top-level directory, then either he needs to change his way of working, or a rule like ../config.status : $(srcdir)/../configure ../config.status --recheck needs to be added in every subdirectory's Makefile. Automake generated Makefiles contain such a rule, so maybe that's what is missing in emacs/src/Makefile? Bruno -- In memoriam Eli Cohen From debbugs-submit-bounces@debbugs.gnu.org Wed May 18 21:48:02 2011 Received: (at 8675) by debbugs.gnu.org; 19 May 2011 01:48:03 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QMsLJ-00020V-MR for submit@debbugs.gnu.org; Wed, 18 May 2011 21:48:02 -0400 Received: from mail-iy0-f172.google.com ([209.85.210.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QMsLH-00020F-UY for 8675@debbugs.gnu.org; Wed, 18 May 2011 21:48:00 -0400 Received: by iyn15 with SMTP id 15so1832163iyn.3 for <8675@debbugs.gnu.org>; Wed, 18 May 2011 18:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GOHxDsNskZcsts3qhBd9zKM52n8cZ1Y2sUR6PJRdbrk=; b=vBLx+8ED6/FM6VV4DPhF9JNRDndpJPfHz0tvCidBDLtbp7vsAr1MlW87kwGRbbzjyP DG2ztAfZR7dG/KIZbpPnrUv3echtQ+NEHRXzvcEywTaFR1yCZ1Zih+HY/xJKc/oNa1xd m0nL8KTNJ5PuOmA67XhvYY5iUqWHjy9XN4yzI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=s5z+HTS7tYvoBONd/A2OTLASQ0/sZDRe5tCPRcKGOxjL38h6kYceJbwTNwG6Mz/Leb TSerbG0TJWcg13k9NZXTNtZmy3MhbSaxU5+9ygoysu1Tj0G8IbLC4zlWH1zwfCRS6JbX dqLiUCcKNgBL2TIlbFuAQHY8bOAvLeLVYS3aI= Received: by 10.42.141.65 with SMTP id n1mr3118269icu.315.1305769674448; Wed, 18 May 2011 18:47:54 -0700 (PDT) Received: from [192.168.1.5] (71-208-134-56.hlrn.qwest.net [71.208.134.56]) by mx.google.com with ESMTPS id d9sm872089ibb.53.2011.05.18.18.47.51 (version=SSLv3 cipher=OTHER); Wed, 18 May 2011 18:47:53 -0700 (PDT) Message-ID: <4DD476BF.1040109@gmail.com> Date: Wed, 18 May 2011 19:47:43 -0600 From: Christoph Scholtes User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bruno Haible Subject: Re: bug#8675: error: token "@" is not valid in preprocessor expressions References: <4DD0B118.1040205@cs.ucla.edu> <4DD44F42.1050405@cs.ucla.edu> <201105190227.26215.bruno@clisp.org> In-Reply-To: <201105190227.26215.bruno@clisp.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: 8675 Cc: Andreas Schwab , 8675@debbugs.gnu.org, Paul Eggert , bug-gnulib@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.0 (----) On 5/18/2011 6:27 PM, Bruno Haible wrote: > So, if the reporter was using GNU make > and the previous Makefile.in was based on gnulib 2011-04-03 or newer > and the reporter did a make command in the top-level directory that > recreated config.status before recursing into lib/ and then into > src/, > then the situation cannot have occurred. I was using Debian Squeeze with GNU make 3.81. I executed `make maintainer-clean' at the root and then `./configure' and `make bootstrap' when it failed. > If the previous Makefile.in was not based on gnulib 2011-04-03 or newer, > we need to do nothing; the problem is already fixed. I am not sure what version of gnulib my Makefile was based on. > If the reporter did "make" in the top-level directory of emacs and it did > not rebuild config.status, even after configure changed, it needs to be > fixed in emacs. I am not sure how to determine if this was the case, since running ./autogen.sh, ./configure and make bootstrap fixed the problem. Let me know if I can help to further troubleshoot this. Christoph From debbugs-submit-bounces@debbugs.gnu.org Thu May 19 03:39:57 2011 Received: (at 8675) by debbugs.gnu.org; 19 May 2011 07:39:57 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QMxps-00049P-OO for submit@debbugs.gnu.org; Thu, 19 May 2011 03:39:56 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QMxpp-00049C-W6 for 8675@debbugs.gnu.org; Thu, 19 May 2011 03:39:55 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 5022239E818A; Thu, 19 May 2011 00:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-HkeZ3yM8BM; Thu, 19 May 2011 00:39:47 -0700 (PDT) Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 986F939E80F2; Thu, 19 May 2011 00:39:47 -0700 (PDT) Message-ID: <4DD4C943.4060205@cs.ucla.edu> Date: Thu, 19 May 2011 00:39:47 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Christoph Scholtes Subject: Re: bug#8675: error: token "@" is not valid in preprocessor expressions References: <4DD0B118.1040205@cs.ucla.edu> <4DD44F42.1050405@cs.ucla.edu> <201105190227.26215.bruno@clisp.org> <4DD476BF.1040109@gmail.com> In-Reply-To: <4DD476BF.1040109@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 8675 Cc: bug-gnulib@gnu.org, Andreas Schwab , 8675@debbugs.gnu.org, Bruno Haible X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.0 (---) >> If the previous Makefile.in was not based on gnulib 2011-04-03 or newer, >> we need to do nothing; the problem is already fixed. > > I am not sure what version of gnulib my Makefile was based on. The previous Emacs trunk commit (i.e., the commit before the one that caused you a problem) was based on gnulib 2011-05-06. I also updated Emacs trunk from gnulib on 2011-04-26, 2011-04-17, 2011-04-10, 2011-04-06, and 2011-04-05. So if you've been keeping up to date regularly with Emacs, your old Makefile was based on a suitably-recent gnulib. >> If the reporter did "make" in the top-level directory of emacs and it did >> not rebuild config.status, even after configure changed, it needs to be >> fixed in emacs. > > I am not sure how to determine if this was the case, since running > ./autogen.sh, ./configure and make bootstrap fixed the problem. > > Let me know if I can help to further troubleshoot this. Perhaps you could try checking out the old version, building it, and then doing a "bzr up", and see whether the problem recurs? The top-level Emacs directory does have a dependency of config.status on configure, for what that's worth, so a top-level "make" should rebuild config.status. > If the reporter only did "make" in the lib/ or src/ subdirectory and not > in the top-level directory, then either he needs to change his way of working, > or a rule like > > ../config.status : $(srcdir)/../configure > ../config.status --recheck > > needs to be added in every subdirectory's Makefile. Automake generated > Makefiles contain such a rule, so maybe that's what is missing in > emacs/src/Makefile? His problem occurred in emacs/lib, and emacs/lib/Makefile is generated by Automake, so I expect this is not the problem. From unknown Thu Jun 19 14:04:37 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 18 Jun 2011 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator