add strnlen to libiberty (was Re: Assembly output optimisations)

As an addendum to my previous patch, I made an attempt to properly add
strnlen() to libiberty, with the code copied from gnulib. Unfortunately it 
seems I've messed it up somewhere since defining HAVE_STRNLEN to 0 doesn't 
seem to build strnlen.o for me. Any ideas?


Thanks,
Dimitris

=== modified file 'gcc/config.in'
--- gcc/config.in	2012-05-25 09:24:08 +0000
+++ gcc/config.in	2012-08-07 01:15:45 +0000
@@ -828,6 +828,13 @@
 #endif
 
 
+/* Define to 1 if we found a declaration for 'strnlen', otherwise define to 0.
+   */
+#ifndef USED_FOR_TARGET
+#undef HAVE_DECL_STRNLEN
+#endif
+
+
 /* Define to 1 if we found a declaration for 'strsignal', otherwise define to
    0. */
 #ifndef USED_FOR_TARGET

=== modified file 'gcc/configure'
--- gcc/configure	2012-07-24 09:49:56 +0000
+++ gcc/configure	2012-08-07 01:02:28 +0000
@@ -10462,7 +10462,7 @@ CFLAGS="$CFLAGS -I${srcdir} -I${srcdir}/
 saved_CXXFLAGS="$CXXFLAGS"
 CXXFLAGS="$CXXFLAGS -I${srcdir} -I${srcdir}/../include"
 for ac_func in getenv atol asprintf sbrk abort atof getcwd getwd \
-	strsignal strstr stpcpy strverscmp \
+	strsignal strstr stpcpy strverscmp strnlen \
 	errno snprintf vsnprintf vasprintf malloc realloc calloc \
 	free basename getopt clock getpagesize clearerr_unlocked feof_unlocked   ferror_unlocked fflush_unlocked fgetc_unlocked fgets_unlocked   fileno_unlocked fprintf_unlocked fputc_unlocked fputs_unlocked   fread_unlocked fwrite_unlocked getchar_unlocked getc_unlocked   putchar_unlocked putc_unlocked
 do
@@ -17973,7 +17973,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 17975 "configure"
+#line 17976 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -18079,7 +18079,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 18081 "configure"
+#line 18082 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H

=== modified file 'gcc/configure.ac'
--- gcc/configure.ac	2012-07-24 09:49:56 +0000
+++ gcc/configure.ac	2012-08-07 01:38:59 +0000
@@ -1087,7 +1087,7 @@ CFLAGS="$CFLAGS -I${srcdir} -I${srcdir}/
 saved_CXXFLAGS="$CXXFLAGS"
 CXXFLAGS="$CXXFLAGS -I${srcdir} -I${srcdir}/../include"
 gcc_AC_CHECK_DECLS(getenv atol asprintf sbrk abort atof getcwd getwd \
-	strsignal strstr stpcpy strverscmp \
+	strsignal strstr stpcpy strverscmp strnlen \
 	errno snprintf vsnprintf vasprintf malloc realloc calloc \
 	free basename getopt clock getpagesize gcc_UNLOCKED_FUNCS, , ,[
 #include "ansidecl.h"

=== modified file 'gcc/system.h'
--- gcc/system.h	2012-07-24 22:25:18 +0000
+++ gcc/system.h	2012-08-07 01:54:49 +0000
@@ -451,6 +451,10 @@ extern char *strstr (const char *, const
 extern char *stpcpy (char *, const char *);
 #endif
 
+#if defined (HAVE_DECL_STRNLEN) && !HAVE_DECL_STRNLEN
+extern size_t strnlen(const char *, size_t);
+#endif
+
 #ifdef __cplusplus
 }
 #endif

On Mon, Aug 6, 2012 at 9:34 PM, Dimitrios Apostolou <jimis@gmx.net> wrote:
> As an addendum to my previous patch, I made an attempt to properly add
> strnlen() to libiberty, with the code copied from gnulib. Unfortunately it
> seems I've messed it up somewhere since defining HAVE_STRNLEN to 0 doesn't
> seem to build strnlen.o for me. Any ideas?

What do you mean by "defining HAVE_STRNLEN to 0"?  The thing that will
control building strnlen.o is having AC_REPLACE_FUNCS in
libiberty/configure.in fail to find strlen.  One way you can test this
is by adding this to libiberty/config.cache:

ac_cv_func_strnlen=${ac_cv_func_strnlen=yes}

before invoking configure.

Ian

On Mon, 6 Aug 2012, Ian Lance Taylor wrote:

> On Mon, Aug 6, 2012 at 9:34 PM, Dimitrios Apostolou <jimis@gmx.net> wrote:
>> As an addendum to my previous patch, I made an attempt to properly add
>> strnlen() to libiberty, with the code copied from gnulib. Unfortunately it
>> seems I've messed it up somewhere since defining HAVE_STRNLEN to 0 doesn't
>> seem to build strnlen.o for me. Any ideas?
>
> What do you mean by "defining HAVE_STRNLEN to 0"?  The thing that will
> control building strnlen.o is having AC_REPLACE_FUNCS in
> libiberty/configure.in fail to find strlen.  One way you can test this
> is by adding this to libiberty/config.cache:
>
> ac_cv_func_strnlen=${ac_cv_func_strnlen=yes}
>
> before invoking configure.

Thanks Ian, that helped a lot. I changed ac_cv_func_strnlen=no and 
reconfigured with -C, and strnlen.o was built. :-)

What else is missing to make this patch appropriate for libiberty? Should 
I change the prolog in strnlen.c, since I only copied it intact from 
gnulib?


Thanks,
Dimitris

On Mon, Aug 6, 2012 at 10:44 PM, Dimitrios Apostolou <jimis@gmx.net> wrote:
>
> What else is missing to make this patch appropriate for libiberty? Should I
> change the prolog in strnlen.c, since I only copied it intact from gnulib?

We generally try to avoid straight GPL source code without runtime
exception in libiberty, and I don't see a reason to bend that rule for
this trivial function.  I recommend that you write your own version
rather than copying it from elsewhere.

Ian

On Mon, 6 Aug 2012, Ian Lance Taylor wrote:
> On Mon, Aug 6, 2012 at 10:44 PM, Dimitrios Apostolou <jimis@gmx.net> wrote:
> >
> > What else is missing to make this patch appropriate for libiberty? Should I
> > change the prolog in strnlen.c, since I only copied it intact from gnulib?
>
> We generally try to avoid straight GPL source code without runtime
> exception in libiberty, and I don't see a reason to bend that rule for
> this trivial function.

Just don't forget that libiberty isn't a target library anymore.
To wit, the (GCC) run-time exception is moot for that code, AFAIK.
Maybe enough reason to abandon that rule so its code can be
truly and freely shared between GNU projects.

brgds, H-P

On Tue, Aug 7, 2012 at 2:30 AM, Hans-Peter Nilsson <hp@bitrange.com> wrote:
>
> Just don't forget that libiberty isn't a target library anymore.
> To wit, the (GCC) run-time exception is moot for that code, AFAIK.
> Maybe enough reason to abandon that rule so its code can be
> truly and freely shared between GNU projects.

The libiberty licensing is certainly confused.  I just don't want to
make it worse.

None of the code in libiberty is under the GCC Runtime Library
Exception, so I think that particular issue does not apply.

Ian

On Tue, 7 Aug 2012, Ian Lance Taylor wrote:

> On Tue, Aug 7, 2012 at 2:30 AM, Hans-Peter Nilsson <hp@bitrange.com> wrote:
> >
> > Just don't forget that libiberty isn't a target library anymore.
> > To wit, the (GCC) run-time exception is moot for that code, AFAIK.
> > Maybe enough reason to abandon that rule so its code can be
> > truly and freely shared between GNU projects.
> 
> The libiberty licensing is certainly confused.  I just don't want to
> make it worse.

I think the natural way to sort it out is to move all the FSF-copyright 
files therein (including include/) to GPLv3, no license exception, except 
for cp-demangle.c (used in libstdc++-v3) and the headers it includes, 
which should have the GCC Runtime Library Exception notice.  libiberty is 
a library for a limited number of GNU projects, all under GPLv3; as far as 
I know the only reason it hasn't been converted to GPLv3 is that noone got 
around to doing so.  (gnulib also uses the practice of putting GPLv3 
license notices on the files even if they are also available under other 
licenses, with separate metadata indicating other licenses under which 
files are available.)

That wouldn't sort out the question of what "This file is part of" notices 
should be present, but would deal with the other license confusion.

(Ideally I think most of libiberty would be replaced by use of gnulib in 
the projects using libiberty - I see no real advantage to the GNU Project 
in having those two separate libraries for substantially the same purposes 
- but that's a much larger and harder task, which would also involve, for 
each libiberty file replaced by a gnulib version, ascertaining whether 
there are any features or local changes in the libiberty version that 
should be merged into the gnulib version or any common upstream such as 
glibc.  And some files in libiberty would probably need adding to gnulib 
as part of such a project.)