On 08/28/2016 04:45 AM, Paul Eggert wrote:
Dennis Clarke wrote:
lib/regcomp.c will not compile with C99 strict compiler because of
the usage of the non-standard "__restrict".
Thanks for the bug report. What are the diagnostics?
I didn't get to see much other than this :
CC regex.o
"regcomp.c", line 467: error: syntax error before or at: preg
"regcomp.c", line 467: warning: undefined or missing type for: preg
"regcomp.c", line 467: warning: undefined or missing type for: const
"regcomp.c", line 467: warning: undefined or missing type for: int
"regcomp.c", line 467: warning: parameter mismatch: 3 declared, 0 defined
"regcomp.c", line 470: error: undefined symbol: cflags
"regcomp.c", line 473: error: undefined symbol: preg
"regcomp.c", line 473: error: left operand of "->" must be pointer to
struct/union
"regcomp.c", line 474: error: left operand of "->" must be pointer to
struct/union
"regcomp.c", line 475: error: left operand of "->" must be pointer to
struct/union
"regcomp.c", line 478: error: left operand of "->" must be pointer to
struct/union
"regcomp.c", line 479: error: left operand of "->" must be pointer to
struct/union
"regcomp.c", line 490: error: non-unique member requires struct/union
pointer: newline_anchor
"regcomp.c", line 490: error: left operand of "->" must be pointer to
struct/union
"regcomp.c", line 493: error: non-unique member requires struct/union
pointer: newline_anchor
"regcomp.c", line 493: error: left operand of "->" must be pointer to
struct/union
"regcomp.c", line 494: error: left operand of "->" must be pointer to
struct/union
"regcomp.c", line 495: error: left operand of "->" must be pointer to
struct/union
"regcomp.c", line 497: error: undefined symbol: pattern
"regcomp.c", line 497: warning: improper pointer/integer combination: arg #1
"regcomp.c", line 497: warning: improper pointer/integer combination: arg #1
"regcomp.c", line 497: warning: improper pointer/integer combination: arg #2
"regcomp.c", line 508: warning: improper pointer/integer combination: arg #1
"regcomp.c", line 512: error: left operand of "->" must be pointer to
struct/union
"regcomp.c", line 513: error: left operand of "->" must be pointer to
struct/union
"regcomp.c", line 526: error: syntax error before or at: preg
"regcomp.c", line 526: warning: undefined or missing type for: preg
"regcomp.c", line 526: warning: undefined or missing type for: char
"regcomp.c", line 527: warning: undefined or missing type for: size_t
"regcomp.c", line 526: warning: parameter mismatch: 4 declared, 0 defined
"regcomp.c", line 545: error: undefined symbol: errbuf_size
"regcomp.c", line 551: error: undefined symbol: errbuf
"regcomp.c", line 551: error: cannot dereference non-pointer type
"regcomp.c", line 553: error: undefined symbol: errbuf
"regcomp.c", line 553: warning: improper pointer/integer combination: arg #1
c99: acomp failed for regex.c
gmake[3]: *** [regex.o] Error 2
gmake[3]: Leaving directory
`/usr/local/build/grep-2.25_SunOS5.10_sparcv9.001/lib'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory
`/usr/local/build/grep-2.25_SunOS5.10_sparcv9.001/lib'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory
`/usr/local/build/grep-2.25_SunOS5.10_sparcv9.001'
gmake: *** [all] Error 2
I compiled and tested 2.25 both with and without
the "restrict" and there was no measurable difference.
POSIX requires a 'restrict' here; see
<http://pubs.opengroup.org/onlinepubs/9699919799/functions/regcomp.html>.
(Whether
a compiler takes advantage of 'restrict' is not something under our
control....)
Right .. yes. I went and found that *after* the first rebuild where I
removed "__restrict" entirely and then put it back in as simply the
standard "restrict". Which of course, works fine and everything tests
just fine.
We may simply change "__restrict" to the C99 spec clean "restrict" or
remove it entirely with no worries.
The Gnulib code is supposed to be portable to compilers that do not
support 'restrict'. It does this by #defining 'restrict' to something
equivalent, on compilers that are picky about 'restrict' for one reason
or another. Sun C has this problem (actually C++), so the code #defines
'restrict' to '__restrict' to pacify it.
Guess that didn't work. However I didn't bother to go fishing to find if
the '__restrict' was defined somewhere to be 'restrict'. I was looking
for a quick fix and I felt a simple 'restrict' gets the job done nicely.
Sun C supports __restrict, so I'm puzzled as to why you're observing a
problem.
dunno :-\
However I went and looked at the source and when I saw the not so spec
standard double underscore there I simply muttered 'ah ha' and removed
it entirely because it is just a programmers notice of intent. Then
later there was some dust in the attic and I went and looked at
regcomp(3C) which is right there smack dab in the manpages :
Standard C Library Functions regcomp(3C)
NAME
regcomp, regexec, regerror, regfree - regular expression
matching
SYNOPSIS
#include <sys/types.h>
#include <regex.h>
int regcomp(regex_t *restrict preg, const char *restrict
pattern, int cflags);
So I thought .. oops .. better put that 'restrict' back in. No usage of
the double underscore however. Everything works great.
I did not have a problem building grep 2.25 on my Solaris 10
sparc host with Oracle Developer Studio 12.5. Please see the attached
compressed build log; you might want to compare it with your build's
output and debug any significant discrepancies (you can look in
config.log).
Well here comes the next interesting bit. This was one of my older
machines and it has Oracle Studio 12.4 on it. That may be the oddball
here but I doubt it. I will take a look at your logs however. Thank you
for the comparison data. Normally I never get data to look at.
One more thing: why use 'c99'? On Solaris it's typically better to use
'cc', as 'c99' is mainly for portability pedants. If 'grep' builds with
'cc' but not with 'c99', I'm inclined to declare victory with Oracle
Developer Studio.
I agree and yes I am a bit of a 'portability pedant' to be honest. For
general purpose building of gnuified sources I give c99 a whirl first
and see if the code compiles clean. If so .. be happy right? If not
then take a look at see if there is something trivial. That was what
happened here. If not trivial then change the CFLAGS and give up on ye
old -Xc strict compliance mode and switch to cc with -Xa and a pile of
other flags for my pedantic debugging mode needs :
mimas$ echo $CFLAGS
-m64 -xtarget=ultra2e -xarch=sparcvis -xchip=ultra2e -xcache=generic
-errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64
-xmemalign=8s -xnolibmil -Xc -xcode=pic32 -xregs=no%appl -xlibmieee -mc
-g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1
-D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
However portability is a real issue for me. Certainly with super
critical tools like 'grep' or 'ls' etc. If the code were tightly
constrained to C99 spec ISO/IEC 9899:TC3 with the use of strict posix
functions then everything would work everywhere. Utopia. Not very likely
to happen in this millenium.
Dennis
