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

Re: Bug#121282: On i386, gcc-3.0 allows $ in indentifiers but not the asm



On Tue, 27 Nov 2001, Martin v. Loewis wrote:

> That isn't really true, is it? Atleast in the NTFS code, I cannot find
> such code (and I can't remember writing it, either :-).

Hehehe...I seem to remember seeing such code in the kernel source, but
that was some time ago and I haven't looked for it since.  When it comes
to the kernel, nothing would surprise me, though.

> GCC maintainers will keep it "on" by default as long as somebody
> shouts "I need it". I think Debian has a much clearer view of what is
> needed and what isn't, so it is in a better position than the GCC
> maintainers.

Well, I like to think that we know more about our specific needs than the
SC, which is something that I doubt they would argue vehemently against
:-)  So far, the only gripe that I've seen from them with a vendor is when
the vendor strays too far from expected behaviour or code base (hence, the
2.96 situation).  In those cases, they seem to be easily satisfied as long
as the vendor makes it obvious that it's a compiler that's been
"assembled" from CVS bits by the vendor and that it's not the official GNU
release (which would burden the SC and gcc community with needing to
support such a beast).  Changes like what we're discussing would probably
end up being done eventually anyway, but someone would need to evaluate
every gcc option before finding out that it's not working for every case
(as we've seen: c$b works, $b doesn't).

> GCC is frequently blamed for being to generous in accepting code as C
> and C++ which really isn't such code, for no apparent reason. Part of
> the problem is that nobody dares to remove extensions that users have
> long migrated away from.

Very true.  Then again, there's always those few that haven't migrated
(who are usually VERY vocal on lists when things finally do change :-P),
hence the long process for removing extensions.

C



Reply to: