Re: test for restrict fails with MS compiler

[Ralf Wildenhues]

Hello Jerker,

FYI, I've Cc:ed the list again.

* Jerker Bäck wrote on Thu, Jul 19, 2007 at 04:34:56PM CEST:
> 
> > You would have a case with this first issue if you could prove that
> > defining away `restrict' is a problem with MSVC.  
> 
> No, it should not cause any problem.

OK, good.  So this problem is solved then.

> > Second, a claim that MSVC fully implements restrict as conforming to
> > C99, is wrong, we've gone through this before.  You seem to claim that
> > it is worthwhile to support MSVC's incomplete support for restrict.
> 
> Who knows about this really except for the MS developers themselves?

Who knows *what*?
1) We know that `restrict' does not conform to C99, because
      typedef int * int_ptr;
      int foo (int_ptr restrict ip);

does not work as required.  C99 requires it, though.

2) Worthwhile?  The tradeoff is what I have discussed further down in my
previous message.

> We can
> only trust the documentation and I can't see any reason why they would lie.
> Have there been any indication that the claim is false? I still believe the
> compiler have a correct implementation of this feature and still think that
> the typedef limitation shouldn't have anything to do with this. And second,
> of course it's worthwhile, why wouldn't it be? 

Because it hurts other users of Autoconf.  Some developer used
AC_C_RESTRICT and had the typedef construct somewhere in his source
files.  He reported breakage with the HP-UX compiler, IIRC.  Wait, here
it is:
<http://thread.gmane.org/gmane.comp.sysutils.autoconf.general/7628>.
So we added the test so that `restrict' is turned off for compilers
which are buggy in this respect.

> > This implies a certain trade-off: some valid C99 programs will fail to
> > compile, but some other programs (yours, presumably) that use restrict
> > may end up being optimized better by MSVC.  Well, for Autoconf such a
> > choice is easily made: Autoconf is foremost a portability tool.  As such
> > getting more programs to run as widely as possible is more important
> > than getting some programs to compile to faster code, while others fail
> > to even compile at all.
> 
> That's taking it very far, I think. If the change I proposed would break
> another compiler, then it's of course not a good idea.

It breaks another package (when compiled with MSVC or that HP-UX
compiler), yes.  See the link above.

> But is that likely to be the case?

Yes.  See above.

> The change is very simple and just enough for the MS compiler
> to slip by. It's not like it's done at the expense of anyone else.

It is at the expense of someone else.  See above.

> > Because it *does not improve* portability.  Au contraire, it reduces it.
> > The arguments have all been presented: the way the macro is currently
> > written gets you the most portability, at the expense of possibily some
> > performance.
> 
> Hm, for me this is all a very practical issue. I'm not demanding anything
> here - just pointing on a solution regarding issues that may have been
> overlooked.

No, on the contrary.  The test is so strict *for a benefit*: to enhance
portability.  The implied cost is very small: for *two* specific buggy
compilers, the generated code *may be* suboptimal.  I say maybe, because
that difference has not been measured.

The added portability benefit of the current solution on the other hand,
has been measured: one more package succeeds to compile *even with* the
buggy HP-UX compiler and MSVC, and fails to compile without the strict
test.

> Which in turn may be understandable. I wouldn't dare to mention
> the stdbool or mmap test as examples for real mess in my environment.

Be encouraged to post about the issues you have.  AFAIK the w32 platform
does not have any mmap support whatsoever, no?  And as to stdbool, I
guess I should recommend the stdbool module of gnulib, which is also
mentioned in Autoconf's manual (where AC_HEADER_STDBOOL is discussed).

Hope that helps.

Cheers,
Ralf