fix 'striconv' on NetBSD

[Bruno Haible]

Hi,

NetBSD has an iconv() with a similar behaviour as Irix iconv().  I'm
applying this patch. It has the effect that the 'striconv' functions will
prefer returning a failure code rather than a string full of question marks.
In other words, it will make 'striconv' behave the same way on NetBSD as
on platforms with glibc or libiconv. It fixes a testsuite failure of
GNU gettext.

2006-10-24  Bruno Haible  <[EMAIL PROTECTED]>

* lib/striconv.c (mem_cd_iconv, str_cd_iconv): Treat all non-GNU
iconv implementations like Irix iconv.

*** gnulib-20061020/lib/striconv.c  2006-09-19 00:51:16.0 +0200
--- gnulib-20061020-modified/lib/striconv.c 2006-10-25 02:11:27.0 
+0200
***
*** 80,87 
else
  return -1;
  }
! # if !defined _LIBICONV_VERSION && (defined sgi || defined __sgi)
!   /* Irix iconv() inserts a NUL byte if it cannot convert.  */
else if (res > 0)
  {
errno = EILSEQ;
--- 80,90 
else
  return -1;
  }
! # if !defined _LIBICONV_VERSION && !defined __GLIBC__
!   /* Irix iconv() inserts a NUL byte if it cannot convert.
!  NetBSD iconv() inserts a question mark if it cannot convert.
!  Only GNU libiconv and GNU libc are known to prefer to fail rather
!  than doing a lossy conversion.  */
else if (res > 0)
  {
errno = EILSEQ;
***
*** 147,154 
else
  return -1;
  }
! # if !defined _LIBICONV_VERSION && (defined sgi || defined __sgi)
!   /* Irix iconv() inserts a NUL byte if it cannot convert.  */
else if (res > 0)
  {
errno = EILSEQ;
--- 150,160 
else
  return -1;
  }
! # if !defined _LIBICONV_VERSION && !defined __GLIBC__
!   /* Irix iconv() inserts a NUL byte if it cannot convert.
!  NetBSD iconv() inserts a question mark if it cannot convert.
!  Only GNU libiconv and GNU libc are known to prefer to fail rather
!  than doing a lossy conversion.  */
else if (res > 0)
  {
errno = EILSEQ;
***
*** 288,295 
else
  goto failed;
  }
! # if !defined _LIBICONV_VERSION && (defined sgi || defined __sgi)
!   /* Irix iconv() inserts a NUL byte if it cannot convert.  */
else if (res > 0)
  {
errno = EILSEQ;
--- 294,304 
else
  goto failed;
  }
! # if !defined _LIBICONV_VERSION && !defined __GLIBC__
!   /* Irix iconv() inserts a NUL byte if it cannot convert.
!  NetBSD iconv() inserts a question mark if it cannot convert.
!  Only GNU libiconv and GNU libc are known to prefer to fail rather
!  than doing a lossy conversion.  */
else if (res > 0)
  {
errno = EILSEQ;

Re: texinfo, dashes

[Bruno Haible]

Karl Berry wrote:
> Indeed, spaces around dashes is an American/European difference.
> ...
> However, nothing else in Texinfo documents in general, or the Gnulib
> document in particular, is typeset in European style, as far as I can
> see, so the spaces seem out of place to me.

But when I sit down for two hours to write a doc chapter, I want to have it
presented in a style that I find aesthetic.

> If you consider it important to emphasize that "GNU is not Unix", 
> 
> I don't, but rms does.  He's made a point of it several times.

The fact is that nowadays, with Ulrich Drepper and Paul being active in POSIX
standardization, GNU has becoming one of the driving forces in POSIX
development. Likewise, X11 technology gets its major push by Linux users,
which - according to RMS - are also part of GNU. (Although I doubt that
Keith Packard would consider himself a GNU user.)

> I changed it to "GNU, Unix, and Windows".  GNU first because it's a GNU
> manual, and I can't see why they should be listed chronologically, or
> that any reader would make the connection if they were.

That's fine with me.

Bruno

Re: gettext.h patch for portability to sunCC, pgCC, RHEL AS 4 g++

[Bruno Haible]

Paul Eggert wrote:
> However, gettext.h does attempt to be portable to C++, so the problems
> you found there suggest that a fix is needed.  It currently does this:
> 
>   #define _LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS \
> (__GNUC__ >= 3 || defined __cplusplus)
> 
> but (as you've found) older C++ compilers define __cplusplus without
> having variable-length arrays.  Also, many C compilers other than GCC
> have variable length arrays, and don't need to be penalized.
> 
> Bruno, how about this patch?
> 
> 2006-10-24  Paul Eggert  <[EMAIL PROTECTED]>
> 
>   * lib/gettext.h (_LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS): Remove.
>   All uses replaced by HAVE_C_VARARRAYS.
>   * modules/gettext-h: Depend on vararrays.

I cannot use this, because gettext.h is documented in the GNU gettext manual
and therefore meant to be used outside the context of gnulib. I could add
the invocation to AC_C_VARARRAYS to gettext.m4, but this doesn't seem right
either.

So gettext.h needs to contains a standalone approximation of what the
autoconf test would determine. I'm applying this.

*** lib/gettext.h   17 Oct 2006 12:07:03 -  1.2
--- lib/gettext.h   25 Oct 2006 13:04:32 -
***
*** 164,171 
  
  #include 
  
  #define _LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS \
!   (__GNUC__ >= 3 || defined __cplusplus)
  
  #if !_LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS
  #include 
--- 164,175 
  
  #include 
  
+ /* GCC supports variable-size arrays in C and C++ mode.
+ISO C++ supports variable-size arrays, but some older PGI and Sun compilers
+don't.  */
  #define _LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS \
!   (__GNUC__ >= 3 \
!|| (defined __cplusplus && !(defined __PGI || defined __SUNPRO_CC)))
  
  #if !_LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS
  #include 

The failure with "g++ -pedantic" will stay; failures obtained with -pedantic,
like -Werror, can be avoided by not using this option.

Bruno

Re: fts.c doesn't compile with C89 compiler

[Jim Meyering]

Jim Meyering <[EMAIL PROTECTED]> wrote:
> Bruno Haible <[EMAIL PROTECTED]> wrote:
...
>> fts.c:1076: warning: ISO C90 forbids mixed declarations and code
>>
>> gnulib still assumes C89 only. Here is a fix.
>>
>> Jim, OK to apply?
>
> That looks fine.
> Yes, thanks.

Thanks for checking it in.
However, I was surprised to see that your commit log message
was something very brief and not descriptive, like "ANSI C!",
nowhere near as useful as the ChangeLog entry:

* lib/fts.c (fts_build): Move variable declaration, for C89 compliance.

I've changed the log message.

I have found that it is useful to keep the commit log message
very similar to the ChangeLog entry.

Re: [bug-gnulib] cvs commit log messages

[Bruno Haible]

Jim Meyering wrote:
> I have found that it is useful to keep the commit log message
> very similar to the ChangeLog entry.

... whereas I find it useful to put rationale information into the cvs
commit message. (Because the ChangeLog entry is only supposed to mention
_what_ has changed, not _why_. And a comment in the source code would in
same case - like this one - be cluttering and disturbing.) Where else to
put rationale information?

Bruno

Re: cvs commit log messages

[Jim Meyering]

Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> I have found that it is useful to keep the commit log message
>> very similar to the ChangeLog entry.
>
> ... whereas I find it useful to put rationale information into the cvs
> commit message. (Because the ChangeLog entry is only supposed to mention
> _what_ has changed, not _why_. And a comment in the source code would in
> same case - like this one - be cluttering and disturbing.) Where else to
> put rationale information?

If the "GNU coding standards" guidelines suggest not to include "why"
a change was made in a ChangeLog entry, then it should be corrected.
The explanation for why a change has been made is often more important
than what has been done to solve the problem.

If you want to add *more* information to the commit log, that's fine,
but at least when it's a file that I maintain, please don't put less in
the commit log than what's in the ChangeLog.

I found the "ANSI C!" comment to be so terse that it was nearly useless.
Also, it didn't mention which function was affected.

Obviously this isn't a big deal for such a small change.  I just want to
make sure it won't happen again, later, with a more consequential change.

Re: gettext.h patch for portability to sunCC, pgCC, RHEL AS 4 g++

[Ben Pfaff]

Bruno Haible <[EMAIL PROTECTED]> writes:

> + /* GCC supports variable-size arrays in C and C++ mode.
> +ISO C++ supports variable-size arrays, but some older PGI and Sun 
> compilers
> +don't.  */

I don't understand this assertion that ISO C++ supports
variable-size arrays.  ISO C++98 shows the expression in an
array-declarator to be a constant-expression (see section 8.3.4).
If a later version of ISO C++ does support variable-size
arrays--I don't have any later version of the standard--then why
not test that __cplusplus is at least that version?
-- 
"The road to hell is paved with convenient shortcuts."
--Peter da Silva

Re: [bug-gnulib] C++ support?

[Bruno Haible]

Karl Berry asked:
> Is supporting compilation with C++ of interest?  (I'm not arguing for
> it, just reporting it, since Nelson went to the trouble of trying it.)

Yes, it is of interest in general. Some GNU projects use C++ in addition to
C for purposes that a C compiler cannot fulfill (such as tracing assignments
of all objects of a given type) or to workaround limitations on Woe32
platforms.

> Configure environment:  CC=pgCC CXX=pgCC FC=pgf77 F77=pgf77 
> LDFLAGS="-L/usr/local/lib64 -R/usr/local/lib64"
> 
> pgCC -DHAVE_CONFIG_H -I. -I../..  -I../../intl   -g -c xalloc-die.c
> "gettext.h", line 172: error: expression must have a constant value
> char msg_ctxt_id[msgctxt_len + msgid_len];
>  ^
> ...
> Configure environment:  CC=sunCC CXX=sunCC CFLAGS=-xarch=amd64  
> CXXFLAGS=-xarch=amd64  LDFLAGS="-L/usr/local/lib64 -R/usr/local/lib64"
> 
> sunCC -DHAVE_CONFIG_H -I. -I../..  -I../../intl   -xarch=amd64 -c xalloc-die.c
> "gettext.h", line 172: Error: An integer constant expression is required 
> within the array subscript operator.
> "gettext.h", line 218: Error: An integer constant expression is required 
> within the array subscript operator.
> 2 Error(s) detected.

Fixed.

Bruno


2006-10-25  Bruno Haible  <[EMAIL PROTECTED]>

* lib/gettext.h (_LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS): Define to
false for PGI C++ and Sun C++ compilers.
Reported by Nelson H. F. Beebe <[EMAIL PROTECTED]>.

diff -c -3 -r1.8 gettext.h
*** lib/gettext.h   17 Oct 2006 12:50:48 -  1.8
--- lib/gettext.h   25 Oct 2006 16:13:12 -
***
*** 163,170 
  
  #include 
  
  #define _LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS \
!   (__GNUC__ >= 3 || defined __cplusplus)
  
  #if !_LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS
  #include 
--- 163,174 
  
  #include 
  
+ /* GCC supports variable-size arrays in C and C++ mode.
+ISO C++ supports variable-size arrays, but some older PGI and Sun compilers
+don't.  */
  #define _LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS \
!   (__GNUC__ >= 3 \
!|| (defined __cplusplus && !(defined __PGI || defined __SUNPRO_CC)))
  
  #if !_LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS
  #include 

Re: [bug-gnulib] C++ support?

[Bruno Haible]

Bob Proulx wrote:
> My opinion (which counts for very little here) is that while C++ is
> designed to be as close to C as possible, but no closer, that it is
> still not C.  C++ is not a strict superset of C.  It is close but not
> perfect.

True. Regarding struct and enum type definitions, you have to work out a
set of idioms so that you can write code that is valid in both languages.

> In particular many of the memory handling parts are not 
> compatible.

I didn't find this to be a problem. I can use malloc, xmalloc, free etc. in
C++ as well.

> Silencing bogus C++ errors and warnings also silences 
> valid C errors and warnings.

In C++, you get errors for casts from 'void *' to 'something *'. You then
add casts at these places. Never did these added casts silence valid C
warnings, for me.

> It is possible to craft an environment using defines and inlines to
> make conditional compilation compile C in the C compiler and C++ in
> the C++ compiler to force it compile cleanly with either but this
> means the result is less than optimal in either too.

This sounds weirder than it is. #ifdefs for C++ are only needed in very few
places:
  - in headers, around the 'extern "C"' boilerplate,
  - when you define an 'alignof' macro.

> I have worked on projects where people have tried to be both a C
> project and a C++ project at the same time.  I found that C++
> programmers were always making C mistakes and C programmers were
> always making C++ mistakes.

True. You need to document clearly the idioms for programming in the
intersection between C and C++. And adjust your "make distcheck" target
to verify also the compilation in C++ mode.

> And neither were allowed to program in 
> their language of choice but instead were forced into the least common
> denominator overlay that we created.

Yes, the wealth of features of C++ is tempting. But in the end, you end up
thinking 50% of the time about the weird design of the C++ language features,
rather than on the problem you are programming. You can program in C
subconciously. In C++, you can't.

Bruno

Re: [bug-gnulib] gettext.h patch for portability to sunCC, pgCC, RHEL AS 4 g++

[Bruno Haible]

Ben Pfaff wrote:
> I don't understand this assertion that ISO C++ supports
> variable-size arrays.  ISO C++98 shows the expression in an
> array-declarator to be a constant-expression

You're right. I was confused. It's only some specific C++ compilers (such
as g++) which do support variable-size arrays.

Bruno

Re: gettext.h patch for portability to sunCC, pgCC, RHEL AS 4 g++

[Paul Eggert]

Bruno Haible <[EMAIL PROTECTED]> writes:

+ /* GCC supports variable-size arrays in C and C++ mode.
+ISO C++ supports variable-size arrays, but some older PGI and Sun compilers
+don't.  */
  #define _LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS \
!   (__GNUC__ >= 3 \
!|| (defined __cplusplus && !(defined __PGI || defined __SUNPRO_CC)))

Like Ben Pfaff, I don't understand the assertion that ISO
C++ supports variable-length arrays.  He checked the 1998
standard.  I just now checked the 2005-10-19 working draft
,
and it doesn't require support for variable length arrays
either; section 8.3.4 (page 156, the last line) says an
array size must be a constant expression.

And there's another problem, independent of C++.  A portable
C program cannot use "defined" within a #define; the C
standard requires "defined" to work only when it is used
directly within #if (i.e., not as the result of a macro
expansion).

I propose the following patch; unlike my earlier patch, it
doesn't assume gnulib.

2006-10-25  Paul Eggert  <[EMAIL PROTECTED]>

* lib/gettext.h (_LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS):
Don't look at __cplusplus, since C++ does not require support
for variable length arrays.  Instead, look at __STDC_VERSION__,
since ISO C99 does require them.

--- lib/gettext.h   25 Oct 2006 16:14:34 -  1.9
+++ lib/gettext.h   25 Oct 2006 17:00:06 -
@@ -164,11 +164,9 @@ npgettext_aux (const char *domain,
 #include 
 
 /* GCC supports variable-size arrays in C and C++ mode.
-   ISO C++ supports variable-size arrays, but some older PGI and Sun compilers
-   don't.  */
+   Also, ISO C99 requires them.  */
 #define _LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS \
-  (__GNUC__ >= 3 \
-   || (defined __cplusplus && !(defined __PGI || defined __SUNPRO_CC)))
+  (__GNUC__ >= 3 || __STDC_VERSION__ >= 199901L)
 
 #if !_LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS
 #include 

Re: gettext.h patch for portability to sunCC, pgCC, RHEL AS 4 g++

[Bruno Haible]

Paul Eggert wrote:
> Like Ben Pfaff, I don't understand the assertion that ISO
> C++ supports variable-length arrays.

Indeed, ISO C++ does not support variable-length arrays. Sorry for the
wrong statement.

> I just now checked the 2005-10-19 working draft
> ,

Thanks for the URL!

> And there's another problem, independent of C++.  A portable
> C program cannot use "defined" within a #define; the C
> standard requires "defined" to work only when it is used
> directly within #if (i.e., not as the result of a macro
> expansion).

You mean 6.10.1.(3)? I haven't seen it as a practical problem so far,
but here anyway I can avoid the problem by writing

  #define _LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS \
(__GNUC__ >= 3 || __GNUG__ >= 2)

> Instead, look at __STDC_VERSION__, since ISO C99 does require them.

__STDC__ and __STDC_VERSION__ are hardly usable in practice. We saw
compilers which defined __STDC__ and had either a traditional preprocessor
or no function prototypes (Coherent cc), and a compiler which has
__STDC_VERSION__ >= 199901L but doesn't support macros with variadic
arguments (OpenVMS 7.3 cc). Compiler vendors tend to implement the
features of a standard not all at once, and they define the macro
corresponding to that standard before they are done with all of the
features (or while some of the features are still buggy). I too have
been pushed into adding :ANSI-CL into clisp's *features* list early, for
marketing reasons. Therefore I don't think such tests will ever be reliable.

Bruno

Non const global in mbchar.c

[John Darrington]

I've been auditing our project for constness.

One that shows up from gnulib is is_basic_table from mbchar.c
This symbol should be const?

J'

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.




pgpHlJWHrHtJ1.pgp
Description: PGP signature

Re: Non const global in mbchar.c

[Paul Eggert]

John Darrington <[EMAIL PROTECTED]> writes:

> One that shows up from gnulib is is_basic_table from mbchar.c
> This symbol should be const?

Makes sense to me.  Here's a proposed patch.

2006-10-25  Paul Eggert  <[EMAIL PROTECTED]>

* lib/mbchar.c (is_basic_table): Now const.
Problem reported by John Darrington.
* lib/mbchar.h (is_basic_table): Likewise.

--- lib/mbchar.c14 Sep 2006 14:18:36 -  1.2
+++ lib/mbchar.c26 Oct 2006 05:55:13 -
@@ -24,7 +24,7 @@
 #if IS_BASIC_ASCII
 
 /* Bit table of characters in the ISO C "basic character set".  */
-unsigned int is_basic_table [UCHAR_MAX / 32 + 1] =
+const unsigned int is_basic_table [UCHAR_MAX / 32 + 1] =
 {
   0x1a00,  /* '\t' '\v' '\f' */
   0xffef,  /* ' '...'#' '%'...'?' */
--- lib/mbchar.h21 Aug 2006 18:28:02 -  1.7
+++ lib/mbchar.h26 Oct 2006 05:55:13 -
@@ -430,7 +430,7 @@ mb_copy (mbchar_t *new, const mbchar_t *
 /* The character set is ISO-646, not EBCDIC. */
 # define IS_BASIC_ASCII 1
 
-extern unsigned int is_basic_table[];
+extern const unsigned int is_basic_table[];
 
 static inline bool
 is_basic (char c)