jwakely....@gmail.com (Jonathan Wakely) writes: > So let's do it. Let's write a statement saying that the GCC developers > consider software security to be of increasing importance, and that we > consider it irresponsible to default to accepting invalid constructs in the > name of backwards compatibility. State that we will make some changes which > were a break from GCC's traditional stance, for the good of the ecosystem.
I'm sorry you think that way. > Given recent pushes to discourage or outright ban the use of memory-safe > languages in some domains, I think it would be good to make a strong > statement about taking the topic seriously. And not just make a statement, > but take action too. > > If we don't do this, I believe it will harm GCC in the long run. The vocal > minority who want to preserve the C they're used to, like some kind of > historical reenactment society, would get their wish: it would become a > historical dead end and go nowhere. Vocal minority? Do you have any evidence to back this claim? What I see is that some reasonable organizations have already chosen other C compilers which are capable of supporting their existing large bodies of C code that have seen significant investment over many years, while others have chosen to revise their C code with each major change to the language. The organizations which did not wish to change their code did not vocally demand changes to GCC after GCC became unsuitable, but quietly arranged to license other compilers. Those that continue write traditional C code know what they are doing, and the limitations of traditional C do not affect the quality of their code. For example, on the Unix systems at my organization, the SGS is modified so that it will not link functions called through a declaration with no parameter specification with a different set of parameters than it was defined with. Naturally, the modified linker is not used to run configure scripts.
