This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: PATCH: `__norestrict' type qualifier




On Sun, 18 Jul 1999, Toon Moene wrote:
> 
> Because I made this suggestion at the time, perhaps it's appropriate for
> me to chime in.  I thought you would be discussing your proposal _of
> that time_ on comp.std.c, but apparently you took the opportunity of
> switching audiences as a chance of reformulating your proposal in the
> form of the "norestrict" qualifier to pointers.  That's fine with me.

I switched to the second suggestion because it became apparent that my
first proposal was just too disliked by people - and also because people
convinced me that it wasn't really a good proposal in the first place.

I'm flexible - what I really care about is resulting code quality with a
reasonably nice and maintainable source interface. I'd still like to have
the "extended warning system" (which I think it was you who proposed in
connection to my original proposal) just to find some of the cases
automatically, but I've become convinced that something like "norestrict"
is the way to go.

One nice thing about a simple norestrict approach is that for old compiler
versions it's trivial to have something like

	#ifndef __GNUC__ || (__GCC_MAJOR__ < 3)
	 #define norestrict 
	#else
	 #define norestrict __norestrict
	#endif

and the new code will compile cleanly with old compilers that do not do
the alias stuff..

(This was ugly for the --fno-strict-alias flag: we're playing games with
the Makefiles and using GNU make extensions to figure out whether we
should pass the flag to gcc or not:

	# use '-fno-strict-aliasing', but only if the compiler can take it
	CFLAGS += $(shell if $(CC) -fno-strict-aliasing -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-fno-strict-aliasing"; fi)

pretty it ain't, but it works)

> As far as I have been able to determine ("following" the discussion on
> DejaNews - I do not read comp.std.c) the proposal was broadly "accepted"
> in the sense that no-one could really shoot a hole in it.

In all fairness it also gathered a lot of people who didn't like it, but
none on tecnical grounds (several on the grounds of "don't add extensions
to the language").

But no, nobody shot it down on a "this is a bad idea because of xxxx"
basis.

> Perhaps I should have warned you for the catch-22 ("You implement that
> first so that we can see if it makes sense").  This is quite normal in
> language development; a feature might look sooo right on paper, but if
> it is impossible to implement it in a real, existing compiler, there
> might still be something wrong with it.

Reasonable.

		Linus


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]