From unknown Thu Jun 19 14:13:36 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#18699 <18699@debbugs.gnu.org> To: bug#18699 <18699@debbugs.gnu.org> Subject: Status: 25.0.50; Windows 7: Odd length text property list Reply-To: bug#18699 <18699@debbugs.gnu.org> Date: Thu, 19 Jun 2025 21:13:36 +0000 retitle 18699 25.0.50; Windows 7: Odd length text property list reassign 18699 emacs submitter 18699 oscarfv@telefonica.net (=C3=93scar Fuentes) severity 18699 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 12 20:59:22 2014 Received: (at submit) by debbugs.gnu.org; 13 Oct 2014 00:59:22 +0000 Received: from localhost ([127.0.0.1]:42278 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdTys-0003vx-01 for submit@debbugs.gnu.org; Sun, 12 Oct 2014 20:59:22 -0400 Received: from eggs.gnu.org ([208.118.235.92]:47241) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdTyn-0003vj-Up for submit@debbugs.gnu.org; Sun, 12 Oct 2014 20:59:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XdTyg-00079S-22 for submit@debbugs.gnu.org; Sun, 12 Oct 2014 20:59:17 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:54415) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdTyf-00079N-VP for submit@debbugs.gnu.org; Sun, 12 Oct 2014 20:59:09 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48827) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdTyZ-0001xn-Go for bug-gnu-emacs@gnu.org; Sun, 12 Oct 2014 20:59:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XdTyT-00074a-9A for bug-gnu-emacs@gnu.org; Sun, 12 Oct 2014 20:59:03 -0400 Received: from smtp10.acens.net ([86.109.99.134]:58571 helo=smtp.movistar.es) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdTyS-00074P-U2 for bug-gnu-emacs@gnu.org; Sun, 12 Oct 2014 20:58:57 -0400 X-CTCH-RefID: str=0001.0A0B0208.543B23CC.00B2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-Spam: Unknown Received: from qcore (79.158.173.198) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 54074B0E012DB66A for bug-gnu-emacs@gnu.org; Mon, 13 Oct 2014 00:58:52 +0000 From: oscarfv@telefonica.net (=?utf-8?Q?=C3=93scar?= Fuentes) To: bug-gnu-emacs@gnu.org Subject: 25.0.50; Windows 7: Odd length text property list Date: Mon, 13 Oct 2014 02:58:50 +0200 Message-ID: <87eguclr91.fsf@telefonica.net> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.3 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.3 (----) Emacs -Q won't start on a Windows 7 32 bits laptop. It prints the mentioned message on the console. Same for a Windows 7 64 bits VM. However, the same binary has no issues on Windows XP 32 bits nor on Windows 8 64 bits. It was compiled on a Windows XP machine with MinGW-w64. The sources are the same used for this instance of Emacs on GNU Linux that I'm using for writing this report. There is bug#18559 on Sep 25 about the same problem but it was confirmed as fixed that same day. My sources are from Oct 4. Also tried an emacs.exe binary with current trunk. In GNU Emacs 25.0.50.2 (x86_64-unknown-linux-gnu, X toolkit) of 2014-10-04 on qcore Windowing system distributor `The X.Org Foundation', version 11.0.11501000 System Description: Ubuntu 14.04.1 LTS From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 12 22:16:19 2014 Received: (at 18699) by debbugs.gnu.org; 13 Oct 2014 02:16:20 +0000 Received: from localhost ([127.0.0.1]:42310 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdVBK-00069H-CP for submit@debbugs.gnu.org; Sun, 12 Oct 2014 22:16:19 -0400 Received: from relayin10.dominioabsoluto.net ([217.116.26.78]:36487) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdVBD-000690-38 for 18699@debbugs.gnu.org; Sun, 12 Oct 2014 22:16:15 -0400 Received: from relaycp01.dominioabsoluto.net ([217.116.26.68]) by relayin10.dominioabsoluto.net with esmtp (Exim 4.84) (envelope-from ) id 1XdVB3-0004CF-F0 for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 04:16:06 +0200 Received: from smtp.movistar.es (smtp22.acens.net [86.109.99.146]) by relaycp01.dominioabsoluto.net (Postfix) with ESMTP id EDBF944F8 for <18699@debbugs.gnu.org>; Mon, 13 Oct 2014 04:35:34 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B020B.543B32AF.00E6, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-Spam: Unknown Received: from qcore (79.158.173.198) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 5408820F014B7831 for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 02:02:23 +0000 From: oscarfv@telefonica.net (=?utf-8?Q?=C3=93scar?= Fuentes) To: 18699@debbugs.gnu.org Subject: bug#18699: 25.0.50; Windows 7: Odd length text property list References: <87eguclr91.fsf@telefonica.net> Date: Mon, 13 Oct 2014 04:02:22 +0200 In-Reply-To: (GNU bug Tracking System's message of "Mon, 13 Oct 2014 01:00:04 +0000") Message-ID: <87a950lob5.fsf_-_@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Filter-ID: s0sct1PQhAABKnZB5plbIdivVjmWowShOp3/r5dMZLlA5ZUGyMBfXHmCqrn81lAQwS9kmloc0QPc 6NojePGshPhnewWNrpLu7jNERT14J6IJb3UEbL+7L4L46DrOC6xAG6YnCJP7ZutaZCXOQshxeK+k gfhqDoEz/673Kb4EDbe9ER1b6OaWZfaymrHy+DiNeIIxnlMJ7/m0L4gC+YfjxrTvWPYXU5L8HSuo 24hjxYqCPb5F/okT2lUPzXgjp+zgHAkk7g6W7v9zZ9HLerco52Hxc6Y1QhxqpkqCFMvQ8d7piqok eqT/++QdwkybH3MHP99nvuX1asuLDeNsLqAm3S4AvugwjHw1A7wsiJS9c6FW2rmRLdTVKi4KPywK neY5RAxvAWm/6xyf1hJp+0TVv52U+OqTltqdLUs9npyk6BVDHBIG0U1IYXErR0k7H8/2MNfrht2X 69J0m0cX16o3P9MXqwtzm3QF2tzj3+P0hUrp8O8NlDymrBcRiWamYZuhc5iuu8ul6HWByhfM/cd3 FtwlIcuco922P9B3v1HX6QoV3BdsZd4UrEG+1W4D4NgkPnb7rI0VfeqD9XJhW9OTh2Hxc6Y1Qhxq pkqCFMvQ8d7piqokeqT/++QdwkybH3MHy9XUM2wxpPwCncXmP1ltNOlchNIE65G1NKBqyMZ4mJE8 4fwweFjR+gGwCKbvOGwDAoO85BYtSoRw6SW8HWhiJNNy3rQv/dN44EU2ZcLdit8= X-Report-Abuse-To: spam@relayin10.dominioabsoluto.net X-Filter-Fingerprint: IFrWXGses7OKB5S5G8/dJR8Z5VD7FZiiT9tK6RAzQuhA3cTUQ1R++keuE7RDJ8Kg3RbMLUalw1oC mj99/u+PoqoVy8a3lsStJtAvpObFX0W9pwnCLfzqMQ4SqlQant4mUpndEJ0YoaLytXXo8BMTaX2p Mk7LBarWD9Fj4R3eIu6C5spubTEXAEkuBKN3yOZvUxf7JO+oAUByCkP7cAJnEooJtGZFyF6tI/I5 CWVQH2sjWUvnt4XQmbZjx+Gtm4/p X-Originating-IP: 217.116.26.68 X-SpamExperts-Domain: out.example.com X-SpamExperts-Username: 217.116.26.68 Authentication-Results: dominioabsoluto.net; auth=pass smtp.auth=217.116.26.68 X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.28) X-Recommended-Action: accept X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 18699 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Backtrace: #0 validate_plist (list=8577862) at ../../emacs/src/textprop.c:235 #1 0x0114d240 in add_text_properties_1 (start=start@entry=4, end=end@entry=48, properties=properties@entry=8577862, object=object@entry=22450013, set_type=set_type@entry=TEXT_PROPERTY_REPLACE) at ../../emacs/src/textprop.c:1181 #2 0x0114d607 in Fadd_text_properties (object=22450013, properties=8577862, end=end@entry=48, start=4) at ../../emacs/src/textprop.c:1306 #3 Fput_text_property (start=4, end=end@entry=48, property=21207346, value=22318226, object=22450013) at ../../emacs/src/textprop.c:1324 #4 0x01071e04 in produce_charset (coding=, pos=12, charbuf=0x82e39c) at ../../emacs/src/coding.c:7285 #5 produce_annotation (pos=12, coding=) at ../../emacs/src/coding.c:7328 #6 decode_coding (coding=coding@entry=0x82e5e0) at ../../emacs/src/coding.c:7423 #7 0x01076e6e in decode_coding_object (coding=, coding@entry=0x82e5e0, src_object=, src_object@entry=14478465, from=, from@entry=0, from_byte=, from_byte@entry=0, to=, to_byte=, dst_object=, dst_object@entry=21139106) at ../../emacs/src/coding.c:8149 #8 0x01078aea in code_convert_string (string=string@entry=14478465, coding_system=, coding_system@entry=22318258, dst_object=, encodep=encodep@entry=false, nocopy=nocopy@entry=false, norecord=norecord@entry=true) at ../../emacs/src/coding.c:9491 #9 0x01078f09 in code_convert_string_norecord (string=14478465, coding_system=coding_system@entry=22318258, encodep=encodep@entry=false) at ../../emacs/src/coding.c:9511 #10 0x01167840 in intern_font_name ( string=string@entry=0x82eb2c "Courier New") at ../../emacs/src/w32font.c:289 #11 0x01167ca7 in w32_enumfont_pattern_entity (frame=, requested_font=0x82ecd4, backend=21295146, font_type=4, physical_font=0x82e928, logical_font=0x82eb10) at ../../emacs/src/w32font.c:1085 #12 add_font_entity_to_list (logical_font=0x82eb10, physical_font=0x82e928, font_type=4, lParam=8580308) at ../../emacs/src/w32font.c:1500 #13 0x777004b5 in SetPixelV () from C:\Windows\system32\gdi32.dll #14 0x7770041e in SetPixelV () from C:\Windows\system32\gdi32.dll #15 0x777005db in GDI32!EnumFontFamiliesExA () from C:\Windows\system32\gdi32.dll #16 0x777005a8 in GDI32!EnumFontFamiliesExA () from C:\Windows\system32\gdi32.dll #17 0x011689a0 in w32font_list_internal ( f=f@entry=0x1810310 , font_spec=font_spec@entry=21240061, opentype_only=opentype_only@entry=1) at ../../emacs/src/w32font.c:833 #18 0x01178347 in uniscribe_list (f=0x1810310 , font_spec=21240061) at ../../emacs/src/w32uniscribe.c:74 #19 0x011179ca in font_list_entities (f=0x1810310 , spec=25013381) at ../../emacs/src/font.c:2804 #20 0x011181e4 in font_find_for_lface ( f=f@entry=0x1810310 , attrs=attrs@entry=0x82eeb4, spec=spec@entry=25232517, c=c@entry=-1) at ../../emacs/src/font.c:3281 #21 0x01118df2 in font_load_for_lface ( f=f@entry=0x1810310 , attrs=attrs@entry=0x82eeb4, spec=spec@entry=25232517) at ../../emacs/src/font.c:3354 #22 0x01118eb9 in font_open_by_spec ( f=f@entry=0x1810310 , spec=25232517) at ../../emacs/src/font.c:3416 #23 0x01118ef6 in font_open_by_name ( f=f@entry=0x1810310 , name=14478433) at ../../emacs/src/font.c:3432 #24 0x01157ffc in x_default_font_parameter ( f=f@entry=0x1810310 , parms=parms@entry=22486246) at ../../emacs/src/w32fns.c:4404 #25 0x0115fc4c in Fx_create_frame (parameters=22486246) at ../../emacs/src/w32fns.c:4568 #26 0x011044b2 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x82f094) at ../../emacs/src/eval.c:2723 #27 0x01136cda in exec_byte_code (bytestr=, vector=18883733, maxdepth=16, args_template=21139074, nargs=nargs@entry=0, args=, args@entry=0x0) at ../../emacs/src/bytecode.c:920 #28 0x0110401b in funcall_lambda (fun=18883685, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x82f240) at ../../emacs/src/eval.c:2956 #29 0x01104335 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x82f23c) at ../../emacs/src/eval.c:2784 #30 0x01136cda in exec_byte_code (bytestr=, vector=19180645, maxdepth=64, args_template=args_template@entry=1024, nargs=nargs@entry=1, args=, args@entry=0x82f3e8) at ../../emacs/src/bytecode.c:920 #31 0x0110409e in funcall_lambda (fun=19180597, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x82f3e8) at ../../emacs/src/eval.c:2890 #32 0x01104335 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x82f3e4) at ../../emacs/src/eval.c:2784 #33 0x01136cda in exec_byte_code (bytestr=, vector=19178765, maxdepth=24, args_template=args_template@entry=0, nargs=nargs@entry=0, args=, args@entry=0x82f578) at ../../emacs/src/bytecode.c:920 #34 0x0110409e in funcall_lambda (fun=19178725, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x82f578) at ../../emacs/src/eval.c:2890 #35 0x01104335 in Ffuncall (nargs=nargs@entry=1, args=args@entry=0x82f574) at ../../emacs/src/eval.c:2784 #36 0x01136cda in exec_byte_code (bytestr=, vector=19196101, maxdepth=68, args_template=args_template@entry=0, nargs=nargs@entry=0, args=, args@entry=0x82f73c) at ../../emacs/src/bytecode.c:920 #37 0x0110409e in funcall_lambda (fun=19196061, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x82f73c) at ../../emacs/src/eval.c:2890 #38 0x01104335 in Ffuncall (nargs=nargs@entry=1, args=args@entry=0x82f738) at ../../emacs/src/eval.c:2784 #39 0x01136cda in exec_byte_code (bytestr=, vector=19194541, maxdepth=48, args_template=args_template@entry=0, nargs=nargs@entry=0, args=, args@entry=0x82f870) at ../../emacs/src/bytecode.c:920 #40 0x0110409e in funcall_lambda (fun=fun@entry=19194501, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x82f870) at ../../emacs/src/eval.c:2890 #41 0x01103595 in apply_lambda (fun=, args=, count=count@entry=3) at ../../emacs/src/eval.c:2831 #42 0x01103865 in eval_sub (form=form@entry=22884086) at ../../emacs/src/eval.c:2253 #43 0x01106be9 in Feval (form=22884086, lexical=21139074) at ../../emacs/src/eval.c:1993 #44 0x01099b84 in top_level_2 () at ../../emacs/src/keyboard.c:1206 #45 0x01102c39 in internal_condition_case ( bfun=bfun@entry=0x1099b6b , handlers=21192610, hfun=hfun@entry=0x109dffd ) at ../../emacs/src/eval.c:1344 #46 0x01099b62 in top_level_1 (ignore=21139074) at ../../emacs/src/keyboard.c:1214 #47 0x01102b5c in internal_catch (tag=21189938, func=func@entry=0x1099b03 , arg=21139074) at ../../emacs/src/eval.c:1105 #48 0x0109dcb6 in command_loop () at ../../emacs/src/keyboard.c:1175 #49 recursive_edit_1 () at ../../emacs/src/keyboard.c:786 #50 0x0109df4b in Frecursive_edit () at ../../emacs/src/keyboard.c:857 #51 0x011ba1b8 in main (argc=, argv=0x8e2c30) at ../../emacs/src/emacs.c:1623 From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 13 01:31:57 2014 Received: (at 18699) by debbugs.gnu.org; 13 Oct 2014 05:31:57 +0000 Received: from localhost ([127.0.0.1]:42365 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdYEe-00039G-Q2 for submit@debbugs.gnu.org; Mon, 13 Oct 2014 01:31:57 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:37018) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdYEa-000393-M5 for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 01:31:55 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NDD00K00AUJFT00@mtaout25.012.net.il> for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 08:27:06 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDD00E4VB552Y70@mtaout25.012.net.il>; Mon, 13 Oct 2014 08:27:06 +0300 (IDT) Date: Mon, 13 Oct 2014 08:31:44 +0300 From: Eli Zaretskii Subject: Re: bug#18699: 25.0.50; Windows 7: Odd length text property list In-reply-to: <87a950lob5.fsf_-_@wanadoo.es> X-012-Sender: halo1@inter.net.il To: oscarfv@telefonica.net (=?iso-8859-1?Q?=D3scar?= Fuentes) Message-id: <8338as8ri7.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <87eguclr91.fsf@telefonica.net> <87a950lob5.fsf_-_@wanadoo.es> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18699 Cc: 18699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: oscarfv@telefonica.net (Óscar Fuentes) > Date: Mon, 13 Oct 2014 04:02:22 +0200 > > Backtrace: > > #0 validate_plist (list=8577862) at ../../emacs/src/textprop.c:235 > #1 0x0114d240 in add_text_properties_1 (start=start@entry=4, > end=end@entry=48, properties=properties@entry=8577862, > object=object@entry=22450013, > set_type=set_type@entry=TEXT_PROPERTY_REPLACE) > at ../../emacs/src/textprop.c:1181 > #2 0x0114d607 in Fadd_text_properties (object=22450013, properties=8577862, > end=end@entry=48, start=4) at ../../emacs/src/textprop.c:1306 > #3 Fput_text_property (start=4, end=end@entry=48, property=21207346, > value=22318226, object=22450013) at ../../emacs/src/textprop.c:1324 > #4 0x01071e04 in produce_charset (coding=, pos=12, > charbuf=0x82e39c) at ../../emacs/src/coding.c:7285 > #5 produce_annotation (pos=12, coding=) > at ../../emacs/src/coding.c:7328 > #6 decode_coding (coding=coding@entry=0x82e5e0) > at ../../emacs/src/coding.c:7423 > #7 0x01076e6e in decode_coding_object (coding=, > coding@entry=0x82e5e0, src_object=, > src_object@entry=14478465, from=, from@entry=0, > from_byte=, from_byte@entry=0, to=, > to_byte=, dst_object=, > dst_object@entry=21139106) at ../../emacs/src/coding.c:8149 > #8 0x01078aea in code_convert_string (string=string@entry=14478465, > coding_system=, coding_system@entry=22318258, > dst_object=, encodep=encodep@entry=false, > nocopy=nocopy@entry=false, norecord=norecord@entry=true) > at ../../emacs/src/coding.c:9491 > #9 0x01078f09 in code_convert_string_norecord (string=14478465, > coding_system=coding_system@entry=22318258, encodep=encodep@entry=false) > at ../../emacs/src/coding.c:9511 > #10 0x01167840 in intern_font_name ( > string=string@entry=0x82eb2c "Courier New") > at ../../emacs/src/w32font.c:289 > #11 0x01167ca7 in w32_enumfont_pattern_entity (frame=, > requested_font=0x82ecd4, backend=21295146, font_type=4, > physical_font=0x82e928, logical_font=0x82eb10) > at ../../emacs/src/w32font.c:1085 > #12 add_font_entity_to_list (logical_font=0x82eb10, physical_font=0x82e928, > font_type=4, lParam=8580308) at ../../emacs/src/w32font.c:1500 > #13 0x777004b5 in SetPixelV () from C:\Windows\system32\gdi32.dll > #14 0x7770041e in SetPixelV () from C:\Windows\system32\gdi32.dll > #15 0x777005db in GDI32!EnumFontFamiliesExA () > from C:\Windows\system32\gdi32.dll > #16 0x777005a8 in GDI32!EnumFontFamiliesExA () > from C:\Windows\system32\gdi32.dll > #17 0x011689a0 in w32font_list_internal ( > f=f@entry=0x1810310 , > font_spec=font_spec@entry=21240061, opentype_only=opentype_only@entry=1) > at ../../emacs/src/w32font.c:833 Looks exactly like #18559, but that one was fixed. Which version of GCC did you use to build this binary? The function add_font_entity_to_list is decorated with a GCC attribute that should cause GCC to emit a few instructions in the function's prologue to ensure the stack is 8-byte aligned. Do you see that in the disassembly of that function? If not, can you show the preprocessed source of the first few line of that function, including its definition line? In any case, please continue using the current trunk and reporting results from it, not from the Oct 4 version. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 13 02:14:19 2014 Received: (at 18699) by debbugs.gnu.org; 13 Oct 2014 06:14:19 +0000 Received: from localhost ([127.0.0.1]:42372 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdYte-0004Ee-Ly for submit@debbugs.gnu.org; Mon, 13 Oct 2014 02:14:18 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:64059) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdYtb-0004ER-Tx for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 02:14:17 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NDD00800D6UKY00@a-mtaout20.012.net.il> for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 09:14:14 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDD008RSDBPEM20@a-mtaout20.012.net.il>; Mon, 13 Oct 2014 09:14:14 +0300 (IDT) Date: Mon, 13 Oct 2014 09:14:07 +0300 From: Eli Zaretskii Subject: Re: bug#18699: 25.0.50; Windows 7: Odd length text property list In-reply-to: <8338as8ri7.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: oscarfv@telefonica.net Message-id: <83wq847az4.fsf@gnu.org> References: <87eguclr91.fsf@telefonica.net> <87a950lob5.fsf_-_@wanadoo.es> <8338as8ri7.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18699 Cc: 18699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Mon, 13 Oct 2014 08:31:44 +0300 > From: Eli Zaretskii > Cc: 18699@debbugs.gnu.org > > The function add_font_entity_to_list is decorated with a GCC attribute > that should cause GCC to emit a few instructions in the function's > prologue to ensure the stack is 8-byte aligned. Do you see that in the > disassembly of that function? If not, can you show the preprocessed > source of the first few line of that function, including its > definition line? Here's what I see in the preprocessed source on my machine: static int __attribute__((__stdcall__)) __attribute__((force_align_arg_pointer)) add_font_entity_to_list (ENUMLOGFONTEX *logical_font, NEWTEXTMETRICEX *physical_font, DWORD font_type, LPARAM lParam) { struct font_callback_data *match_data = (struct font_callback_data *) lParam; Lisp_Object backend = match_data->opentype_only ? Quniscribe : Qgdi; Lisp_Object entity; The important part is the force_align_arg_pointer attribute. This is set up in w32term.h, like this: #ifdef __GNUC__ # if USE_STACK_LISP_OBJECTS && !defined _W64 && !defined __x86_64__ \ && __GNUC__ + (__GNUC_MINOR__ > 1) >= 5 # define ALIGN_STACK __attribute__((force_align_arg_pointer)) # else # define ALIGN_STACK # endif /* USE_STACK_LISP_OBJECTS */ #endif Is it possible that the MinGW64 compiler somehow trips here? E.g., is it possible that, even in a 32-bit build, it defines _W64 or __x86_64__? If so, what other preprocessor macros are available in MinGW64 to distinguish between a 32-bit and a 64-bit build? From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 13 06:27:47 2014 Received: (at 18699) by debbugs.gnu.org; 13 Oct 2014 10:27:48 +0000 Received: from localhost ([127.0.0.1]:42440 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xdcqx-0002n8-Gq for submit@debbugs.gnu.org; Mon, 13 Oct 2014 06:27:47 -0400 Received: from relaycp03.dominioabsoluto.net ([217.116.26.84]:39904) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xdcqu-0002my-5B for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 06:27:45 -0400 Received: from smtp.movistar.es (smtp08.acens.net [86.109.99.132]) by relaycp03.dominioabsoluto.net (Postfix) with ESMTP id DA4B06E4188; Mon, 13 Oct 2014 12:27:42 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B020B.543BA91E.03DE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-Spam: Unknown Received: from qcore (79.158.173.198) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 540881B401257AC0; Mon, 13 Oct 2014 10:27:42 +0000 From: oscarfv@telefonica.net (=?utf-8?Q?=C3=93scar?= Fuentes) To: Eli Zaretskii Subject: Re: bug#18699: 25.0.50; Windows 7: Odd length text property list References: <87eguclr91.fsf@telefonica.net> <87a950lob5.fsf_-_@wanadoo.es> <8338as8ri7.fsf@gnu.org> <83wq847az4.fsf@gnu.org> Date: Mon, 13 Oct 2014 12:27:41 +0200 In-Reply-To: <83wq847az4.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 13 Oct 2014 09:14:07 +0300") Message-ID: <8761fol0wy.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 18699 Cc: 18699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Eli Zaretskii writes: > The important part is the force_align_arg_pointer attribute. > > This is set up in w32term.h, like this: > > #ifdef __GNUC__ > # if USE_STACK_LISP_OBJECTS && !defined _W64 && !defined __x86_64__ \ > && __GNUC__ + (__GNUC_MINOR__ > 1) >= 5 > # define ALIGN_STACK __attribute__((force_align_arg_pointer)) The problem is _W64, which is defined to _w64. This doesn't make much sense to me. I'll ask on the MinGW-w64 ml. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 13 07:37:34 2014 Received: (at 18699) by debbugs.gnu.org; 13 Oct 2014 11:37:34 +0000 Received: from localhost ([127.0.0.1]:42502 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XddwT-0005wz-Vz for submit@debbugs.gnu.org; Mon, 13 Oct 2014 07:37:34 -0400 Received: from mtaout26.012.net.il ([80.179.55.182]:46780) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XddwS-0005wr-6R for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 07:37:33 -0400 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NDD00200S0ULB00@mtaout26.012.net.il> for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 14:35:45 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDD00LJUS7LQ560@mtaout26.012.net.il>; Mon, 13 Oct 2014 14:35:45 +0300 (IDT) Date: Mon, 13 Oct 2014 14:37:24 +0300 From: Eli Zaretskii Subject: Re: bug#18699: 25.0.50; Windows 7: Odd length text property list In-reply-to: <8761fol0wy.fsf@wanadoo.es> X-012-Sender: halo1@inter.net.il To: oscarfv@telefonica.net (=?iso-8859-1?Q?=D3scar?= Fuentes) Message-id: <83ppdw6w0b.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <87eguclr91.fsf@telefonica.net> <87a950lob5.fsf_-_@wanadoo.es> <8338as8ri7.fsf@gnu.org> <83wq847az4.fsf@gnu.org> <8761fol0wy.fsf@wanadoo.es> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18699 Cc: 18699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: oscarfv@telefonica.net (Óscar Fuentes) > Cc: 18699@debbugs.gnu.org > Date: Mon, 13 Oct 2014 12:27:41 +0200 > > > #ifdef __GNUC__ > > # if USE_STACK_LISP_OBJECTS && !defined _W64 && !defined __x86_64__ \ > > && __GNUC__ + (__GNUC_MINOR__ > 1) >= 5 > > # define ALIGN_STACK __attribute__((force_align_arg_pointer)) > > The problem is _W64, which is defined to _w64. This doesn't make much > sense to me. I'll ask on the MinGW-w64 ml. Thanks. So this _is_ the same as 18559. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 13 07:41:54 2014 Received: (at control) by debbugs.gnu.org; 13 Oct 2014 11:41:55 +0000 Received: from localhost ([127.0.0.1]:42510 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xde0g-000646-3Y for submit@debbugs.gnu.org; Mon, 13 Oct 2014 07:41:54 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:42984) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xde0c-00063t-Do for control@debbugs.gnu.org; Mon, 13 Oct 2014 07:41:51 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NDD00D00RZ4RU00@mtaout27.012.net.il> for control@debbugs.gnu.org; Mon, 13 Oct 2014 14:36:36 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDD00ASTS900D40@mtaout27.012.net.il> for control@debbugs.gnu.org; Mon, 13 Oct 2014 14:36:36 +0300 (IDT) Date: Mon, 13 Oct 2014 14:41:43 +0300 From: Eli Zaretskii Subject: Re: Processed (with 1 errors): Re: Processed: Re: bug#18699: 25.0.50; Windows 7: Odd length text property list In-reply-to: X-012-Sender: halo1@inter.net.il To: control@debbugs.gnu.org (GNU bug tracker automated control server) Message-id: <83mw906vt4.fsf@gnu.org> References: <83oatg6vyk.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) reopen 18559 merge 18699 18559 thanks From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 13 07:48:10 2014 Received: (at 18699) by debbugs.gnu.org; 13 Oct 2014 11:48:11 +0000 Received: from localhost ([127.0.0.1]:42517 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xde6k-0007Ub-DR for submit@debbugs.gnu.org; Mon, 13 Oct 2014 07:48:10 -0400 Received: from smtp08.acens.net ([86.109.99.132]:17297 helo=smtp.movistar.es) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xde6g-0007UR-PZ for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 07:48:08 -0400 X-CTCH-RefID: str=0001.0A0B020D.543BBBF3.0301, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-Spam: Unknown Received: from qcore (79.158.173.198) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 540881B401260C93; Mon, 13 Oct 2014 11:48:03 +0000 From: oscarfv@telefonica.net (=?utf-8?Q?=C3=93scar?= Fuentes) To: 18699@debbugs.gnu.org Subject: Re: bug#18699: 25.0.50; Windows 7: Odd length text property list Date: Mon, 13 Oct 2014 13:46:22 +0200 Lines: 22 References: <87eguclr91.fsf@telefonica.net> <87a950lob5.fsf_-_@wanadoo.es> <8338as8ri7.fsf@gnu.org> <83wq847az4.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-From-Line: nobody Mon Oct 13 13:46:24 2014 Message-ID: <8761fojiml.fsf@telefonica.net> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 18699 Cc: Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) The MinGW-w64 guys say that _W64 is not the rigth way of checking that we are targeting Windows 64. _WIN64 is. http://sourceforge.net/p/mingw-w64/mailman/message/32925577/ AFAIU the fact that we are using _W64 for detecting MinGW-w64 (on both 32 and 64 bit variants) is also wrong. _W64 is a MS thing and not specific to MinGW-w64, as explained on the StackOverflow question linked from the above message. It just happens that MinGW does not define it. The right way to detect MinGW-w64 is to test for __MINGW64_VERSION_MAJOR *after* including some C runtime header or _mingw.h, because it is not a preprocessor predefined macro. It is explained here: http://sourceforge.net/p/mingw-w64/discussion/723798/thread/ea355c1f/#d4db I propose to fix the ALIGN_STACK issue by replacing _W64 with _WIN64 and later fix the places where _W64 is used for detecting MinGW-w64 with the right method. Eli, can you take care of the ALIGN_STACK fix? I'll send a patch for the rest of _W64 cases, if nobody beats me to it. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 13 08:49:28 2014 Received: (at 18699) by debbugs.gnu.org; 13 Oct 2014 12:49:28 +0000 Received: from localhost ([127.0.0.1]:42546 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xdf43-0000cI-KL for submit@debbugs.gnu.org; Mon, 13 Oct 2014 08:49:28 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:38358) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xdf3z-0000c7-VV for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 08:49:25 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NDD00200V4NXS00@mtaout27.012.net.il> for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 15:44:09 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDD00LW6VDIQM60@mtaout27.012.net.il>; Mon, 13 Oct 2014 15:44:09 +0300 (IDT) Date: Mon, 13 Oct 2014 15:49:13 +0300 From: Eli Zaretskii Subject: Re: bug#18699: 25.0.50; Windows 7: Odd length text property list In-reply-to: <8761fojiml.fsf@telefonica.net> X-012-Sender: halo1@inter.net.il To: oscarfv@telefonica.net (=?iso-8859-1?Q?=D3scar?= Fuentes) Message-id: <83k3446som.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <87eguclr91.fsf@telefonica.net> <87a950lob5.fsf_-_@wanadoo.es> <8338as8ri7.fsf@gnu.org> <83wq847az4.fsf@gnu.org> <8761fojiml.fsf@telefonica.net> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18699 Cc: 18699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: oscarfv@telefonica.net (Óscar Fuentes) > Cc: Eli Zaretskii > Date: Mon, 13 Oct 2014 13:46:22 +0200 > > The MinGW-w64 guys say that _W64 is not the rigth way of checking that > we are targeting Windows 64. _WIN64 is. I'm quite sure at some point someone told me the exact opposite of this, whcih is why you see what you see in nt/inc/. > The right way to detect MinGW-w64 is to test for __MINGW64_VERSION_MAJOR > *after* including some C runtime header or _mingw.h, because it is not a > preprocessor predefined macro. It is a PITA that the MinGW64 compiler doesn't define some clear-cut macro for that without the need to include headers. IME this is a terrible maintenance headache in the long run. Perhaps you could ask the MinGW64 developers to change their mind about that. What about __x86_64__, does it perhaps fit the bill already? > Eli, can you take care of the ALIGN_STACK fix? Done in trunk revision 118105. > I'll send a patch for the rest of _W64 cases, if nobody beats me to > it. TIA From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 13 09:57:27 2014 Received: (at 18699-done) by debbugs.gnu.org; 13 Oct 2014 13:57:28 +0000 Received: from localhost ([127.0.0.1]:42797 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xdg7q-0003bj-Rg for submit@debbugs.gnu.org; Mon, 13 Oct 2014 09:57:27 -0400 Received: from relaycp01.dominioabsoluto.net ([217.116.26.68]:50048) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xdg7l-0003bV-JA for 18699-done@debbugs.gnu.org; Mon, 13 Oct 2014 09:57:24 -0400 Received: from smtp.movistar.es (smtp09.acens.net [86.109.99.133]) by relaycp01.dominioabsoluto.net (Postfix) with ESMTP id D4E595121; Mon, 13 Oct 2014 16:30:32 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B0205.543BDA3F.016D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-Spam: Unknown Received: from qcore (79.158.173.198) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 54077A760155633E; Mon, 13 Oct 2014 13:57:19 +0000 From: oscarfv@telefonica.net (=?utf-8?Q?=C3=93scar?= Fuentes) To: Eli Zaretskii Subject: Re: bug#18699: 25.0.50; Windows 7: Odd length text property list References: <87eguclr91.fsf@telefonica.net> <87a950lob5.fsf_-_@wanadoo.es> <8338as8ri7.fsf@gnu.org> <83wq847az4.fsf@gnu.org> <8761fojiml.fsf@telefonica.net> <83k3446som.fsf@gnu.org> Date: Mon, 13 Oct 2014 15:57:17 +0200 In-Reply-To: <83k3446som.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 13 Oct 2014 15:49:13 +0300") Message-ID: <871tqcjcn6.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 18699-done Cc: 18699-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Eli Zaretskii writes: [snip] > It is a PITA that the MinGW64 compiler doesn't define some clear-cut > macro for that without the need to include headers. IME this is a > terrible maintenance headache in the long run. Agreed. > Perhaps you could ask the MinGW64 developers to change their mind > about that. I could try, but my understanding is that they are not interested on doing that, for multiple reasons. One of them is that, in theory, you could use the MinGW-w64 compiler with the MinGW headers and libraries. > What about __x86_64__, does it perhaps fit the bill already? __x86_64__ is about the processor. It is also defined by gcc 4.8.2 on my Kubuntu x86_64. Of course, being MinGW on x86_64 implies Windows 64. But I've seen quite a few patch submissions about ARM support on the MinGW-w64 ml, so an hypothetical Emacs compiled for Windows ARM 64bits by MinGW would fail the __x86_64__ test. If that Emacs comes to light, we probably would need to determine what's the right thing wrt ALIGN_STACK, though. So in this specific case __x86_64__ does not harm, but it is superfluous on the presence on _WIN64. >> Eli, can you take care of the ALIGN_STACK fix? > > Done in trunk revision 118105. Thanks! From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 13 15:07:34 2014 Received: (at 18699) by debbugs.gnu.org; 13 Oct 2014 19:07:34 +0000 Received: from localhost ([127.0.0.1]:42865 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xdkxx-0002hU-LP for submit@debbugs.gnu.org; Mon, 13 Oct 2014 15:07:34 -0400 Received: from mtaout29.012.net.il ([80.179.55.185]:53450) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xdkxt-0002hJ-EX for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 15:07:31 -0400 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NDE00I00D0QRP00@mtaout29.012.net.il> for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 22:06:30 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDE00872D2U1VA0@mtaout29.012.net.il>; Mon, 13 Oct 2014 22:06:30 +0300 (IDT) Date: Mon, 13 Oct 2014 22:07:22 +0300 From: Eli Zaretskii Subject: Re: bug#18699: 25.0.50; Windows 7: Odd length text property list In-reply-to: <871tqcjcn6.fsf@wanadoo.es> X-012-Sender: halo1@inter.net.il To: oscarfv@telefonica.net (=?iso-8859-1?Q?=D3scar?= Fuentes) Message-id: <83iojn7pqt.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <87eguclr91.fsf@telefonica.net> <87a950lob5.fsf_-_@wanadoo.es> <8338as8ri7.fsf@gnu.org> <83wq847az4.fsf@gnu.org> <8761fojiml.fsf@telefonica.net> <83k3446som.fsf@gnu.org> <871tqcjcn6.fsf@wanadoo.es> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18699 Cc: 18699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: oscarfv@telefonica.net (Óscar Fuentes) > Cc: 18699-done@debbugs.gnu.org > Date: Mon, 13 Oct 2014 15:57:17 +0200 > > > Perhaps you could ask the MinGW64 developers to change their mind > > about that. > > I could try, but my understanding is that they are not interested on > doing that, for multiple reasons. One of them is that, in theory, you > could use the MinGW-w64 compiler with the MinGW headers and libraries. That's a nice theory, but I don't think it will hold, since (AFAIU) the two compilers use different methods of throwing C++ exceptions between DLLs. > > What about __x86_64__, does it perhaps fit the bill already? > > __x86_64__ is about the processor. It is also defined by gcc 4.8.2 on my > Kubuntu x86_64. Of course, being MinGW on x86_64 implies Windows 64. But > I've seen quite a few patch submissions about ARM support on the > MinGW-w64 ml, so an hypothetical Emacs compiled for Windows ARM 64bits > by MinGW would fail the __x86_64__ test. If that Emacs comes to light, > we probably would need to determine what's the right thing wrt > ALIGN_STACK, though. > > So in this specific case __x86_64__ does not harm, but it is superfluous > on the presence on _WIN64. It is there for Cygwin's sake, but I thought it could also serve MinGW64. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 13 15:14:55 2014 Received: (at 18699) by debbugs.gnu.org; 13 Oct 2014 19:14:55 +0000 Received: from localhost ([127.0.0.1]:42869 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xdl54-0002sT-OV for submit@debbugs.gnu.org; Mon, 13 Oct 2014 15:14:55 -0400 Received: from limerock02.mail.cornell.edu ([128.84.13.242]:60226) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xdl52-0002sL-CQ for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 15:14:53 -0400 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite3.serverfarm.cornell.edu [10.16.197.8]) by limerock02.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id s9DJEpAV024626; Mon, 13 Oct 2014 15:14:51 -0400 Received: from [128.84.234.253] (dhcp253.math.cornell.edu [128.84.234.253]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id s9DJEos3026708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 13 Oct 2014 15:14:51 -0400 Message-ID: <543C24AD.7090101@cornell.edu> Date: Mon, 13 Oct 2014 15:14:53 -0400 From: Ken Brown User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Eli Zaretskii , =?windows-1252?Q?=D3scar_Fuentes?= Subject: Re: bug#18699: 25.0.50; Windows 7: Odd length text property list References: <87eguclr91.fsf@telefonica.net> <87a950lob5.fsf_-_@wanadoo.es> <8338as8ri7.fsf@gnu.org> <83wq847az4.fsf@gnu.org> <8761fojiml.fsf@telefonica.net> <83k3446som.fsf@gnu.org> <871tqcjcn6.fsf@wanadoo.es> <83iojn7pqt.fsf@gnu.org> In-Reply-To: <83iojn7pqt.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 18699 Cc: 18699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) On 10/13/2014 3:07 PM, Eli Zaretskii wrote: >> From: oscarfv@telefonica.net (Óscar Fuentes) >> Cc: 18699-done@debbugs.gnu.org >> Date: Mon, 13 Oct 2014 15:57:17 +0200 >> >>> Perhaps you could ask the MinGW64 developers to change their mind >>> about that. >> >> I could try, but my understanding is that they are not interested on >> doing that, for multiple reasons. One of them is that, in theory, you >> could use the MinGW-w64 compiler with the MinGW headers and libraries. > > That's a nice theory, but I don't think it will hold, since (AFAIU) > the two compilers use different methods of throwing C++ exceptions > between DLLs. > >>> What about __x86_64__, does it perhaps fit the bill already? >> >> __x86_64__ is about the processor. It is also defined by gcc 4.8.2 on my >> Kubuntu x86_64. Of course, being MinGW on x86_64 implies Windows 64. But >> I've seen quite a few patch submissions about ARM support on the >> MinGW-w64 ml, so an hypothetical Emacs compiled for Windows ARM 64bits >> by MinGW would fail the __x86_64__ test. If that Emacs comes to light, >> we probably would need to determine what's the right thing wrt >> ALIGN_STACK, though. >> >> So in this specific case __x86_64__ does not harm, but it is superfluous >> on the presence on _WIN64. > > It is there for Cygwin's sake, Right. And it's *not* about the processor. gcc running under 32-bit Cygwin will not define __x86_64__, regardless of the processor. Ken From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 13 15:39:42 2014 Received: (at 18699) by debbugs.gnu.org; 13 Oct 2014 19:39:42 +0000 Received: from localhost ([127.0.0.1]:42876 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdlT3-0003UF-KM for submit@debbugs.gnu.org; Mon, 13 Oct 2014 15:39:42 -0400 Received: from relaycp01.dominioabsoluto.net ([217.116.26.68]:36582) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdlSz-0003U1-0k for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 15:39:39 -0400 Received: from smtp.movistar.es (smtp22.acens.net [86.109.99.146]) by relaycp01.dominioabsoluto.net (Postfix) with ESMTP id 8B10D44A8; Mon, 13 Oct 2014 22:12:49 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B0207.543C2A76.0344, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-Spam: Unknown Received: from qcore (79.158.173.198) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 543BDF950002128F; Mon, 13 Oct 2014 19:39:34 +0000 From: oscarfv@telefonica.net (=?utf-8?Q?=C3=93scar?= Fuentes) To: Ken Brown Subject: Re: bug#18699: 25.0.50; Windows 7: Odd length text property list References: <87eguclr91.fsf@telefonica.net> <87a950lob5.fsf_-_@wanadoo.es> <8338as8ri7.fsf@gnu.org> <83wq847az4.fsf@gnu.org> <8761fojiml.fsf@telefonica.net> <83k3446som.fsf@gnu.org> <871tqcjcn6.fsf@wanadoo.es> <83iojn7pqt.fsf@gnu.org> <543C24AD.7090101@cornell.edu> Date: Mon, 13 Oct 2014 21:39:33 +0200 In-Reply-To: <543C24AD.7090101@cornell.edu> (Ken Brown's message of "Mon, 13 Oct 2014 15:14:53 -0400") Message-ID: <87wq83iwsq.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 18699 Cc: Eli Zaretskii , 18699@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Ken Brown writes: > Right. And it's *not* about the processor. gcc running under 32-bit > Cygwin will not define __x86_64__, regardless of the processor. It is about the *target* processor of the compiler. Obviously if you target x86 then __x86_64__ is expected to be undefined, regardless of the *host* processor. OTOH if you are saying that Cygwin does not define __x86_64__ when you are cross-compiling to a x86_64 target on a x86 host, I'll consider that a bug. My understanding now is that the __x86_64__ test is there because Cygwin does not define _WIN64. Eli, both MinGW and MinGW-w64 compilers support sjlj and Dwarf exception methods on x86. Maybe MinGW only supports one method on its official binaries, but that's just a detail that can change at any moment. Plus the user can build his own toolchain. And since when we do care about C++ here? ;-) From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 13 16:25:28 2014 Received: (at 18699) by debbugs.gnu.org; 13 Oct 2014 20:25:28 +0000 Received: from localhost ([127.0.0.1]:42900 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdmBK-0004pc-T8 for submit@debbugs.gnu.org; Mon, 13 Oct 2014 16:25:27 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:47058) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdmBH-0004pR-Ho for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 16:25:25 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NDE00G00GFH2300@a-mtaout20.012.net.il> for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 23:25:21 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDE00FFXGQ9W030@a-mtaout20.012.net.il>; Mon, 13 Oct 2014 23:25:21 +0300 (IDT) Date: Mon, 13 Oct 2014 23:25:16 +0300 From: Eli Zaretskii Subject: Re: bug#18699: 25.0.50; Windows 7: Odd length text property list In-reply-to: <87wq83iwsq.fsf@wanadoo.es> X-012-Sender: halo1@inter.net.il To: oscarfv@telefonica.net (=?iso-8859-1?Q?=D3scar?= Fuentes) Message-id: <83fver7m4z.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <87eguclr91.fsf@telefonica.net> <87a950lob5.fsf_-_@wanadoo.es> <8338as8ri7.fsf@gnu.org> <83wq847az4.fsf@gnu.org> <8761fojiml.fsf@telefonica.net> <83k3446som.fsf@gnu.org> <871tqcjcn6.fsf@wanadoo.es> <83iojn7pqt.fsf@gnu.org> <543C24AD.7090101@cornell.edu> <87wq83iwsq.fsf@wanadoo.es> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18699 Cc: 18699@debbugs.gnu.org, kbrown@cornell.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: oscarfv@telefonica.net (Óscar Fuentes) > Cc: Eli Zaretskii , 18699@debbugs.gnu.org > Date: Mon, 13 Oct 2014 21:39:33 +0200 > > Ken Brown writes: > > > Right. And it's *not* about the processor. gcc running under 32-bit > > Cygwin will not define __x86_64__, regardless of the processor. > > It is about the *target* processor of the compiler. Obviously if you > target x86 then __x86_64__ is expected to be undefined, regardless of > the *host* processor. > > OTOH if you are saying that Cygwin does not define __x86_64__ when you > are cross-compiling to a x86_64 target on a x86 host, I'll consider that > a bug. > > My understanding now is that the __x86_64__ test is there because Cygwin > does not define _WIN64. A 64-bit build on Windows, whether a Cygwin build or a MinGW64 build, doesn't need the force_align_arg_pointer, since the 64-bit ABI requires the 8-byte alignment. The __x86_64__ is there to exclude the 64-bit Cygwin build. If it can also exclude the MinGW64 build, we don't need any MinGW64-specific symbols there. > Eli, both MinGW and MinGW-w64 compilers support sjlj and Dwarf exception > methods on x86. But what is the default one? That's what's important. > And since when we do care about C++ here? ;-) At least the DWARF2-based exceptions machinery comes into play in C programs as well, see the few Emacs crashes we had with libraries linked against the libgcc DLL. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 13 16:35:55 2014 Received: (at 18699) by debbugs.gnu.org; 13 Oct 2014 20:35:55 +0000 Received: from localhost ([127.0.0.1]:42904 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdmLS-00059q-3p for submit@debbugs.gnu.org; Mon, 13 Oct 2014 16:35:54 -0400 Received: from smtp08.acens.net ([86.109.99.132]:19998 helo=smtp.movistar.es) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdmLN-00059c-JI for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 16:35:52 -0400 X-CTCH-RefID: str=0001.0A0B0204.543C37A3.0134, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-Spam: Unknown Received: from qcore (79.158.173.198) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 543BDCB40003273F; Mon, 13 Oct 2014 20:35:47 +0000 From: oscarfv@telefonica.net (=?utf-8?Q?=C3=93scar?= Fuentes) To: Eli Zaretskii Subject: Re: bug#18699: 25.0.50; Windows 7: Odd length text property list References: <87eguclr91.fsf@telefonica.net> <87a950lob5.fsf_-_@wanadoo.es> <8338as8ri7.fsf@gnu.org> <83wq847az4.fsf@gnu.org> <8761fojiml.fsf@telefonica.net> <83k3446som.fsf@gnu.org> <871tqcjcn6.fsf@wanadoo.es> <83iojn7pqt.fsf@gnu.org> <543C24AD.7090101@cornell.edu> <87wq83iwsq.fsf@wanadoo.es> <83fver7m4z.fsf@gnu.org> Date: Mon, 13 Oct 2014 22:35:45 +0200 In-Reply-To: <83fver7m4z.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 13 Oct 2014 23:25:16 +0300") Message-ID: <87siiriu72.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 18699 Cc: 18699@debbugs.gnu.org, kbrown@cornell.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Eli Zaretskii writes: > A 64-bit build on Windows, whether a Cygwin build or a MinGW64 build, > doesn't need the force_align_arg_pointer, since the 64-bit ABI > requires the 8-byte alignment. The __x86_64__ is there to exclude the > 64-bit Cygwin build. If it can also exclude the MinGW64 build, we > don't need any MinGW64-specific symbols there. As mentioned on a previous message, __x86_64__ will exclude Windows 64 on x86* processors, but not on others (i.e. ARM). >> Eli, both MinGW and MinGW-w64 compilers support sjlj and Dwarf exception >> methods on x86. > > But what is the default one? That's what's important. MinGW-w64 has no default. Both sjlj and Dwarf have official binaries on x86 and sjlj and SEH on x86_64. MinGW only distributes Dwarf, IIRC, but that can change anytime. But we are off-topic now. From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 14 02:09:42 2014 Received: (at 18699) by debbugs.gnu.org; 14 Oct 2014 06:09:42 +0000 Received: from localhost ([127.0.0.1]:43109 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdvIk-0005Fz-1J for submit@debbugs.gnu.org; Tue, 14 Oct 2014 02:09:42 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:61993) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdvIg-0005Fo-LE for 18699@debbugs.gnu.org; Tue, 14 Oct 2014 02:09:40 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NDF00K007OKTC00@a-mtaout20.012.net.il> for 18699@debbugs.gnu.org; Tue, 14 Oct 2014 09:09:35 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDF00KZC7RZOJ30@a-mtaout20.012.net.il>; Tue, 14 Oct 2014 09:09:35 +0300 (IDT) Date: Tue, 14 Oct 2014 09:09:31 +0300 From: Eli Zaretskii Subject: Re: bug#18699: 25.0.50; Windows 7: Odd length text property list In-reply-to: <87siiriu72.fsf@wanadoo.es> X-012-Sender: halo1@inter.net.il To: oscarfv@telefonica.net (=?iso-8859-1?Q?=D3scar?= Fuentes) Message-id: <83bnpf6v38.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <87eguclr91.fsf@telefonica.net> <87a950lob5.fsf_-_@wanadoo.es> <8338as8ri7.fsf@gnu.org> <83wq847az4.fsf@gnu.org> <8761fojiml.fsf@telefonica.net> <83k3446som.fsf@gnu.org> <871tqcjcn6.fsf@wanadoo.es> <83iojn7pqt.fsf@gnu.org> <543C24AD.7090101@cornell.edu> <87wq83iwsq.fsf@wanadoo.es> <83fver7m4z.fsf@gnu.org> <87siiriu72.fsf@wanadoo.es> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18699 Cc: 18699@debbugs.gnu.org, kbrown@cornell.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: oscarfv@telefonica.net (Óscar Fuentes) > Cc: kbrown@cornell.edu, 18699@debbugs.gnu.org > Date: Mon, 13 Oct 2014 22:35:45 +0200 > > Eli Zaretskii writes: > > > A 64-bit build on Windows, whether a Cygwin build or a MinGW64 build, > > doesn't need the force_align_arg_pointer, since the 64-bit ABI > > requires the 8-byte alignment. The __x86_64__ is there to exclude the > > 64-bit Cygwin build. If it can also exclude the MinGW64 build, we > > don't need any MinGW64-specific symbols there. > > As mentioned on a previous message, __x86_64__ will exclude Windows 64 > on x86* processors, but not on others (i.e. ARM). We could decide not to worry about that until we need to support a Windows build on any of those others. Like we do with Cygwin. From unknown Thu Jun 19 14:13:36 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 11 Nov 2014 12:24:03 +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