Eli Schwartz <eschwart...@gmail.com> writes: > Right, this is what I said. Although your bullet points 1 and 2 don't > really have much of anything to do with it. > > In between points 3 and 4, I noted that you wish to *use* such bad code. > I didn't say you wish to write it, merely that you wish to use it > (without judging when it was written).
[...] > Absolutely! It's a very good point. It's a point that people writing > traditional not-C in this day and age are doing so with highly complex > toolchains they have personally written to do things that no non-bespoke > toolchain does. As such, they are unaffected by any and all decisions > GCC makes. But if they were affected by such decisions, they would have > the technical knowledge to modify GCC to suit themselves. Upper management types performed a cost analysis and decided that it would be more appropriate to license another C compiler. Please don't expect that only technical ability affects decisions made in the real world. > But your bespoke toolchain did not support the code which you need to > compile either. That's why you began hacking on it at all, to suit your > needs. > > So if neither GCC nor your bespoke toolchain support the code you need > to compile, and you must modify *something* to suit yourself, then it is > definitely possible to do it for GCC instead. > > I don't see what the welcome for making these modifications into the > default flagship experience for the entire free software ecosystem, has > to do with your being welcome to hack on GCC for your own personal use. > > Do you feel welcome by your proprietary vendor, who refuses to let you > touch it at all by withholding source code? No, I do not. I can not speak for my management. But I also do not feel any welcome from a group of developers who are interested in breaking other code, some of which I have written for myself, and then religiously defend their decisions. In short, I do not like being told what to do with my own code! > BRB, renaming all my python files to *.c and symlinking /usr/bin/cc to > /usr/bin/python. > > ... > > No, the criteria for whether something constitutes a given programming > language are not "the file extension says so" or "the compiler name says > so". > > A programming language is defined by the syntax and meaning of that > programming language. OK, and the Portable C Compiler from Bell Labs followed one such definition of its syntax and meaning. ANSI and ISO simply define several such variants of the C language, collectively known as Standard C. 1st edition K&R defines another, and each compiler, in practice, defines its own. Just like there are different varieties of English, or perhaps German. > (If we were to replace this conversation with a definition of what > constitutes python, then as a scripted language, all files without file > extensions could be python scripts. And similarly, people play > interesting games with C files by naming them unconventional names and > passing -xc to the compiler. File extension autodetection isn't everything.) This is pure pedantry. My point is: If it looks like a duck, and quacks like a duck, then it is a duck. or, IOW: If it looks like C, compiles in a C compiler, then it is C. > Well no, because if they are sufficiently dedicated to their existing > code to not have changed in over 30 years then they are writing c89 code > and passing -std=c89, and this is acceptable as far as GCC is concerned > and their code will still compile. They are not writing ``C89'' code. They are writing ``GNU99'', or perhaps ``GNU11'' code. > So they won't feel inclined to find some other compiler, and quite > frankly, if they were doing the right thing in accordance with the > standard way to use the language they prefer to use, then they probably > will not notice that GCC changed anything? What gives you the right to dictate what the Right Thing is and what is not? > What guarantees of the future do you have for anything? > > What guarantees do you have that a meteor won't hit Earth and wipe out > all human life in a great catastrophe? > > What guarantees do you have that GCC will still be run by the current > maintainers? > > What guarantees do you have that GCC will still be maintained at all? > > What guarantees do you have that GCC won't decide next year that they > are deleting all support for std > c89, making -traditional the default, > and becoming a historical recreation society? > > What guarantees do you have that GCC won't decide next year that they > are deleting all support for std < c23, mandating that everyone upgrade > to the very latest std that isn't even fully implemented today? > > What guarantees do you have that reality exists as you think of it? > Maybe you are a pink elephant and computers are a figment of your > imagination. You are arguing to absurdity. > I think that what-ifs aren't the most productive use of our time. The > current proposal provides for -std=c89 and similar, so the current > proposal does not cause current GCC users to be unable to use GCC after > the proposed change. Perhaps you must try writing a program which strictly conforms to the Standard, since you seem to be asking everyone to write in such a way. My point is that there is a very significant body of economically valuable code written in the dialect of C actually implemented by GCC, as it stands right now, just as there is a significant (albiet not so much) body of traditional C (K&R) code. If GCC is no longer able to compile such code, it will attract the legitimate anger of its users. And making users angry is not productive in any way. > If a future proposal causes current GCC users to be unable to use GCC > after the future proposal is implemented, then, and only then, should we > worry about whether it will be possible to use GCC. Then, and only then, > will a threat to prevent doing so have actually materialized. Parse error.
