Arsen Arsenović writes:
> Any development style making documentation a source of truth matches
> this principle. This does not refer to ISO specifications specifically,
> though, normally, unless the standard disagrees with reality, as
> implicit-... did many years ago, ISO decisions are taken s
Jonathan Wakely writes:
> Wrong. I wouldn't bother replying to you again in this thread, but I
> feel that as a gcc maintainer I should confirm that Eli S. is right
> here; and nobody else I know agrees with your definition of extension
> as "every non-standard aspect of the compiler's behaviour,
Eli Schwartz writes:
> Does this mean you've conceded the point, and no longer think it is
> written in C++?
No.
> You are correct in reading my sentence, that is indeed what I said.
>
> Aside: you have reiterated "the behavior of the translator itself" over
> and over again, but it hasn't been
Eli Schwartz writes:
> GNU C does not define any such thing. It may happen to turn out that
> way, but that is not the same as defining its behavior.
It is.
>> Nor does GCC conform to the Standard by default: while it is okay for a
>> conforming implementation to translate programs relying on i
Eli Schwartz writes:
> Quoting my previous reply on the topic.
>
> Until everyone is on the same page as you about whether these are GNUC
> extensions, this conversation will go nowhere.
>
> You are of the opinion that "GCC currently behaves a certain way when
> compiling the code" means that the
Thomas Koenig writes:
> C99, 6.7.2, "Type specifiers"
>
> # Constraints
>
> # At least one type specifier shall be given in the declaration
> # specifiers in each declaration, and in the specifier-qualifier
> # list in each struct declaration and type name.
And?
> In C99 and onwards, this is an
Gabriel Ravier writes:
> ...You're joking, right ? You can't possibly be seriously arguing
> this, you have to be kidding... right ?
No, I'm not. The meaning of a variable declaration with only a storage
class specifier is extremely clear: the type of the variable is `int'.
There's absolutely n
Gabriel Ravier writes:
> As somebody that spends a lot of time helping beginners, yes,
> constantly. I'd go as far as to say it's an error that seemingly
> everyone has made at least once.
Really? And after making this mistake (and learning its solution), did
they continue to make the same mist
Eli Schwartz writes:
> This sounds like a "you" problem.
I don't write these Makefiles. Others do.
It wasn't the problem of their authors before, so why should it be now?
Gabriel Ravier writes:
> It's "extra work" to add 10 characters to a Makefile, but normal to
> add random faulty declarations everywhere ?
You're assuming that people are willing to edit Makefiles, which is all
kinds of pain, and then put up with a complete recompile of whatever
software is bei
Pedro Alves writes:
> Then write a wrapper script named "cc", and put that in the PATH:
>
> $ cat cc
> #!/bin/sh
>
> exec /my/real/gcc -fwhatever "$@"
>
> Done.
And how many people are going to be forced to do this?
Though this is a good point: I suspect if such an option were actually
added
Jonathan Wakely writes:
> Then they should not use implicit int and implicit function
> declarations.
And why is that? Is GCC really arrogant enough to think that it is the
only C translator in the world?
BTW, standards.info used to say something along the lines of:
Do not declare functions
Jonathan Wakely writes:
> It's not about popularity. If that's your takeaway then you're not
> paying attention, whatever you claim about reading everything in the
> thread. It's about helping people write correct code, first time,
> without some of the avoidable traps that C presents.
>
> The C
Eli Schwartz writes:
> Instead of adding one flag to their Makefile, which is too much work,
Once again, you're making the silly assumption that adding
`-fpermissive' to many different Makefiles is easy. Especially when the
Makefiles also have to be used with compilers which do not understand
s
Jason Merrill writes:
> You shouldn't have to change any of those, just configure with CC="gcc
> -fwhatever".
If it were so simple...
Many Makefiles come with a habit of using not CC_FOR_BUILD, but just
`cc', to build programs which are run on the build machine.
These programs are intended to
Eli Schwartz writes:
> There are ***not*** thousands of Makefiles that have this issue. But if
> there were, then Makefiles are very easy to update, and only have to be
> updated once per project, not thousands of times. So this is fine. You
> may have to update your Makefile, but that is no big
Sam James writes:
> They're using > c89/gnu89 often because defaults have changed (a point
> others have raised, including Arsen and Eli Schwartz) even though they
> weren't intended to be compiled with newer C.
>
> A fair amount of other projects do explicitly ask for either c99/gnu99
> or c11/g
Sam James writes:
> And I would not want to see that happen either, nor do I think Florian
> would, or many of the other participants in this thread.
>
> Indeed, for some projects, where it's hopeless^Wlots of work,
> we're using -std=c89 or -std=gnu89 as appropriate - as already stated.
>
> But
Eli Schwartz writes:
> Except this thread is not arguing to remove support for -std=c89 as far
> as I can tell?
>
> The argument is that on newer values for -std (such as the one GCC
> defaults to if no -std is specified), GCC should adapt its diagnostics
> better for the std in question. These n
Eli Schwartz writes:
> This discussion thread is about having very good technical reasons -- as
> explained multiple times, including instances where you agreed that the
> technical reasons were good.
>
> Furthermore, even despite those technical reasons, GCC is *still*
> committed to not breakin
Arsen Arsenović writes:
> Indeed they should be - but warning vs. error holds significance. A
> beginner is much less likely to be writing clever code that allegedly
> uses these features properly than to be building new code, and simply
> having made an error that they do not want and will suff
Eli Schwartz writes:
> I expect no such thing, but I do expect that people making decisions in
> the real world acknowledge that ***they*** (and no one else) made those
> decisions of their own volition.
>
> I am unsure what "decisions made in the real world" has to do with my
> observation that
Arsen Arsenović writes:
> Seems that the algorithm and I agree. I don't see any use in the int()
> guess that the compiler does, besides accepting old code (which makes it
> candidate for -fpermissive).
I believe:
extern int foo ();
covers at least 50% of all C functions, since they are gen
Jonathan Wakely writes:
> On Thu, 11 May 2023 at 09:31, Po Lu wrote:
>> (BTW, I thought implicit int was being discussed, not implicit
>>function declarations, but here goes.)
>
> Then you're not paying attention, the very first mail in the thread
> starts by saying:
>
> TL;DR: This message
Arsen Arsenović writes:
> Relying on human scrutiny when an algorithm can trivially deduce an
> answer more quickly and more reliably (because even in the case that the
> code you showed compiles, it assumes processor specific facts) has
> historic precedent as being a bad idea.
The algorithm in
Jonathan Wakely writes:
> This is about a change in defaults. There would be options to continue
> compiling that code. It would not be banned, so the histrionics are
> unnecessary.
Please read the wording Sam used. It clearly made reference to a ``ban''.
Arsen Arsenović writes:
> Good. The above code is nonsense, the chances that foo will be
> incorrectly called are high.
Yet lint (or scrutiny, as should be performed with any declaration,
implicit or not) makes sure that does not happen.
> What is this meant to produce?
It was just an example
Arsen Arsenović writes:
> None of these result in a whisper-level warning before a severe but
> difficult to detect breakage.
Really? Why not run lint?
Besides, how is this any different from allowing people to write:
extern int foo ();
or perhaps even
extern int foo (struct bar *, long
Eli Schwartz writes:
> P.S. No, it is not realistic that GCC will remove support for a language
> feature of c89, until and unless GCC removes support for -std=c89. So I
> do not know why you are talking about -Wno-implicit. That isn't the
> question, that's not what's up for debate here. The que
Eli Schwartz 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 ju
Eli Schwartz writes:
>> Unfortunately, we do not have the source code for our compiler. Would
>> you care to ask people here to restore `gcc -traditional'?
>
>
> This would appear to be a self-inflicted wound. If I understand the
> chain of events properly...
The chain of events actually is:
Jonathan Wakely via Gcc writes:
> On Wed, 10 May 2023, 03:32 Eli Zaretskii, wrote:
>
>>
>> And then people will start complaining about GCC unnecessarily
>> erroring out, which is a compiler bug, since there's no problem
>> producing correct code in these cases.
>>
>
>
> What is the correct code
jwakely@gmail.com (Jonathan Wakely) writes:
> No, the proposed changes are to give errors (instead of warnings) for
> rules introduced in C99. GCC is just two decades late in enforcing the
> C99 rules properly!
The Standard requires that a diagnostic be issued upon encountering
certain kinds
Sam James writes:
> I think the group of people dedicated enough to patch their linker would
> be able to pass a flag to the compiler to allow old constructs.
Unfortunately, we do not have the source code for our compiler. Would
you care to ask people here to restore `gcc -traditional'?
Sam James writes:
> Nobody here is suggesting that the ability to compile this code at
> all would be removed. Throughout this thread, people discuss methods
> like e.g. adding -fpermissive to allow it.
Here, I'm saying that making it annoying to compile such code is not
going to convince people
Sam James writes:
> No, we're talking about "things which ISO C made invalid in 1999, but
> GCC kept supporting for a while". We're discussing terminating that
> support. The "standard" part here is not about deference to the standard
> and claiming extensions can never be made, but rather that w
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 compat
dje@gmail.com (David Edelsohn) writes:
> This seems to be the core tension. If developers cared about these issues,
> they would enable appropriate warnings and -Werror.
>
> The code using these idioms is not safe and does create security
> vulnerabilities. And software security is increasin
jwakely@gmail.com (Jonathan Wakely) writes:
> This isn't "be like Clang", this is "diagnose things that have been
> invalid C since 1999".
Only if your definition of valid C is ``strictly conforming to the ISO
Standard''. I doubt there are many programs which fit such a
definition.
And anyw
39 matches
Mail list logo
