GLR and strdup (Was: [GNU Bison 1.75a] testsuite: 89 90 91 92 93 94 95 96 97 failed)

[Akim Demaille]

| As per your request.  This is on dec-mips-ultrix.  Do you want me to try
| other platforms here? 

Well, beta testers are always extremely appreciated :)

| BTW: The strdup() problem is very common on Ultrix.  It's fixably by simply
| linking against libiberty.  So probably nothing to worry about in general.

That's my feeling too.

| 89. cxx-type.at:226: testing GLR: Resolve ambiguity, impure, no locations...
| cxx-type.at:227: bison -o types.c types.y
| stderr:
| types.y: warning: 1 reduce/reduce conflict
| cxx-type.at:227: $CC $CFLAGS $CPPFLAGS types.c -o types
| stderr:
| types.y: In function `yylex':
| types.y:99: warning: assignment makes pointer from integer without a cast
| /usr/tmp/ccSNtKkR.o: In function `yylex':
| 
/tmp_mnt/freeware/gnu-tools/bison/bison-1.75a/tests/testsuite.dir/89/types.y:99:
 undefined reference to `strdup'
| collect2: ld returned 1 exit status
| cxx-type.at:227: exit code was 1, expected 0
| 89. cxx-type.at:226: FAILED near `cxx-type.at:227'


I tend to think that we should not pollute the other skeletons (i.e.,
the others than yacc.c) with such portability issues.  In other words,
I would suggest that the test suite itself provide the portability
glue, not the skeleton.

But if other people think the converse, let's make glr.c more
portable; but in this case, I would suggest that we go to an Autoconf
like portability:

#if HAVE_CONFIG_H
# include <config.h>
#else
# define HAVE_STRDUP 0
#endif

#if !HAVE_STRDUP
char *
my_strdup (....)
....

# define strdup my_strdup
#endif