From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Christoph Bauer Newsgroups: gmane.emacs.devel Subject: Re: [Christoph.Bauer@lms-gmbh.de: HP-UX: link error] Date: Thu, 23 Mar 2006 12:51:53 +0100 Message-ID: <26EB47FDD566A7469FC862DAF373792FE20E62@kaiserslautern1.lmsintl.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: sea.gmane.org 1143114742 28193 80.91.229.2 (23 Mar 2006 11:52:22 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 23 Mar 2006 11:52:22 +0000 (UTC) Cc: cyd@stupidchicken.com, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 23 12:52:20 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FMOMU-0003Ru-HF for ged-emacs-devel@m.gmane.org; Thu, 23 Mar 2006 12:52:18 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FMOMU-00012Z-4E for ged-emacs-devel@m.gmane.org; Thu, 23 Mar 2006 06:52:18 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FMOMB-00011o-Gh for emacs-devel@gnu.org; Thu, 23 Mar 2006 06:51:59 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FMOM9-00010z-8R for emacs-devel@gnu.org; Thu, 23 Mar 2006 06:51:58 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FMOM9-00010t-3D for emacs-devel@gnu.org; Thu, 23 Mar 2006 06:51:57 -0500 Original-Received: from [213.68.136.230] (helo=mail-outfwd.lms.be) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FMOMh-0005qd-TM; Thu, 23 Mar 2006 06:52:32 -0500 Original-Received: from localhost (unknown [127.0.0.1]) by mail-outfwd.lms.be (Postfix) with ESMTP id 58B4F7F429; Thu, 23 Mar 2006 12:58:22 +0100 (CET) Original-Received: from mail-kl.lmsintl.com ([127.0.0.1]) by localhost (kl-ftp [127.0.0.1]) (amavisd-new, port 20024) with ESMTP id 23063-05; Thu, 23 Mar 2006 12:58:22 +0100 (CET) Original-Received: from kaiserslautern1.lmsintl.com (unknown [10.2.0.100]) by mail-kl.lmsintl.com (Postfix) with ESMTP id 43B46B6EC6; Thu, 23 Mar 2006 12:58:22 +0100 (CET) Original-Received: by kaiserslautern1.lmsintl.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Mar 2006 12:51:54 +0100 Original-To: rms@gnu.org X-Mailer: Internet Mail Service (5.5.2653.19) X-Virus-Scanned: by IT Services X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:52000 Archived-At: > > So is not included (_LIBC in not defined). > When I define MULTIBYTE_IS_FORMAT_SAFE in config.h, the build > succeeds. This was just a stupid test. As formerly written with -D_INCLUDE__STDC_A1_SOURCE the definition of MULTIBYTE_IS_FORMAT_SAFE isn't necessary. > > That does not necessarily mean it is correct to define that > symbol. Here's the explanation of it: > > /* Do multibyte processing if multibytes are supported, unless > multibyte sequences are safe in formats. Multibyte sequences are > safe if they cannot contain byte sequences that look like format > conversion specifications. The GNU C Library uses UTF8 multibyte > encoding, which is safe for formats, but strftime.c can be used > with other C libraries that use unsafe encodings. */ > #define DO_MULTIBYTE (HAVE_MBLEN && ! MULTIBYTE_IS_FORMAT_SAFE) > > So, are multibyte sequences safe on your system? man page of printf(3S) says: Locale The LC_CTYPE category affects the following features: + Plain characters within format strings are interpreted as single byte and/or multibyte characters. + Field width is given in terms of bytes. As characters are placed on the output stream, they are interpreted as single byte or multibyte characters and the field width is decremented by the length of the character. + Precision is given in terms of bytes. As characters are placed on the output stream, they are interpreted as single byte or multibyte characters and the precision is decremented by the length of the character. + The return value is given in terms of bytes. As characters are placed on the output stream, they are interpreted as single byte or multibyte characters and the byte count that makes up the return value is incremented by the length of the character. The LC_NUMERIC category determines the radix character used to print floating-point numbers, and the thousands' grouping characters if the grouping flag ' is on. International Code Set Support Single byte character code sets are supported. Multibyte character code sets are also supported as described in the LC_CTYPE category above. So it depends on LC_CTYPE.