bug#24323: "regcomp.c", line 467: error: syntax error before or at: preg

[Dennis Clarke]

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