This is the mail archive of the 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: Mistaken change in GCC (fwd)

On 24 Nov 00, at 11:06, Richard Stallman wrote:

> GCC supports features that come from ISO standard C, and other
> features which come from other origins but are just as important.  All
> of these features should be kept working, both individually and
> together.  We also want to add new extensions from time to
> time--whenever we have good ideas for them.
> Standards such as ISO C are very useful, and making GCC compile
> standard programs with their standard meanings is also very useful.
> But no standards committee is in charge of deciding what GCC should
> do; we do not follow any standard slavishly.  We look at the standard,
> and then we do what is most useful for us to do, which is usually a
> matter of serving the needs of the users.
> In many cases, what is useful for the users is to follow the standard.
> Users have written many programs in accord with ISO C, and if GCC does
> not compile them correctly, these users will be very disappointed with
> GCC.  When following the standard is what the users need, we do it.
> But we are not "obeying" the standard; we are satisfying users' needs
> which were shaped by the standard.
> In many other cases, whether we follow the standard is not directly
> important for users.  For instance, the ISO C standard requires many
> nonstandard constructs to be rejected.  We have instead defined
> meanings for some of them as GNU C extensions.  This "violates" the
> standard, but it is good for the users, since they find the extensions
> useful.
> GCC's default mode of operation does not entirely support ISO C; to
> get 100% ISO C support requires certain options.  The default mode is
> better, practically speaking, for the users than something strictl
> defined by ISO C would be.
> On rare occasions, a standard feature is so lousy that it should not
> be enabled unless a user specifically requests it.  That is how we
> handle trigraphs in GCC.
> Sometimes it is useful to offer two modes, one which "obeys" the
> standard, and another more useful mode which is the default.  That is
> what --pedantic is for.  Many GNU C extensions get warnings if you use
> --pedantic, so it is not usually a useful feature.  But it enables us
> to say that "We have a mode that conforms entirely to the C standard".
> Ten years ago, I believed we would need to be able to make a claim of
> supporting the C standard perfectly in order for GCC to be a success.
> Ten years ago, perhaps that was true.  Today, GCC could clearly
> succeed without --pedantic.  But since --pedantic works, and some
> people may use it, we should keep the feature working.
> So please do not base any work on GCC on the idea that its goal is to
> "compile standards-conforming ISO C programs".  Our goal is more than
> that, and the rest of our goal must not be left out.

Hmm yes I like gcc add-ons, the long long type in particular. But I 
would like to see a slim gcc distribution ready-made that is only C 
and Standard C++. 

Anyway, Here are some other features I would like to see added to 

Ability to define a structure to be used as a bitset without being 
limited to a bitset of 32 or 64 bits. If I want a bitset of 128 bits, I 
should be able to do it. Only Standard C++ and Java currently 
allow me to do this, as far as I know.

A built in "monitor" or "semaphore" type, since in designing OSes 
it would be nice for the developer to rely on the compiler to 
implement mutual exclusion somehow on a semaphore type 
without worrying how it is implemented. I have no idea if this is 
possible, Andrew Tanenbaum (Minix) seems to believe it is.

--- James Buchanan, aka Aussie Yob

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