[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: test for restrict fails with MS compiler

From: Jerker Bäck
Subject: RE: test for restrict fails with MS compiler
Date: Thu, 19 Jul 2007 18:45:32 +0200

Hello Ralf,

> 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.
> 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? 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? 

> 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. But is that likely to
be the case? 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.

> 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. 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.

Regards Jerker

reply via email to

[Prev in Thread] Current Thread [Next in Thread]