<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Daniel Dunbar wrote:
<blockquote
cite="mid:6a8523d60911041548g2fdc4bdq4e9a6c8c257735d3@mail.gmail.com"
type="cite">
<pre wrap="">On Wed, Nov 4, 2009 at 2:08 PM, John McCall <a class="moz-txt-link-rfc2396E" href="mailto:rjmccall@apple.com"><rjmccall@apple.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Daniel Dunbar wrote:
On Tue, Nov 3, 2009 at 7:36 PM, John McCall <a class="moz-txt-link-rfc2396E" href="mailto:rjmccall@apple.com"><rjmccall@apple.com></a> wrote:
+def err_cconv_knr : Error<
+ "function with no prototype cannot use '%0' calling convention">;
I'm not sure if we already have a canonical way of referring to this,
but IIRC we already use "K&R" in other places, which may be more
meaningful than "function with no prototype".
I disagree. I think very few people know what K&R syntax is, outside of a
vague memory that they should (but usually don't) remember to write "(void)"
instead of "()" when declaring a nullary function. ANSI C programmers
should at least be more familiar with the concept of a prototype. The vast
majority of people encountering this error are going to be people who've
accidentally written their nullary function without void.
</pre>
</blockquote>
<pre wrap=""><!---->
I'm arguing more for normalizing the diagnostics than one particular
spelling, I'm also not sure which one is best.
</pre>
</blockquote>
<br>
Okay.<br>
<br>
<blockquote
cite="mid:6a8523d60911041548g2fdc4bdq4e9a6c8c257735d3@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">...not that there's really any point to declaring a nullary function
fastcall, at least not in any of the conventions calling themselves
'fastcall' that I know about.
</pre>
</blockquote>
<pre wrap=""><!---->
FWIW, this is also an argument that anyone who did this would not, in
fact, have a nullary function.
</pre>
</blockquote>
<br>
You'd be surprised; a lot of novice programmers learn about calling
conventions for the first time and start slapping 'fastcall' on
everything, because obviously it makes things faster, right?<br>
<br>
<blockquote
cite="mid:6a8523d60911041548g2fdc4bdq4e9a6c8c257735d3@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">That said, maybe we should say "K&R" and just provide a fixit to put 'void'
in the argument list.
</pre>
</blockquote>
<pre wrap=""><!---->
We don't want to fixit things unless we know the fixit is correct,
that wouldn't apply here.
</pre>
</blockquote>
<br>
I have two responses to this.<br>
<br>
The first is that we obviously wouldn't suggest this fixit on
definitions with non-trivial K&R arguments.<br>
<br>
The second is that I think this policy about fixits is both (1)
misguided and (2) not really being followed with any consistency. I
mean, the parser has a fixit which inserts semicolons at the end of
declarations; there's no way that that's 100% correct, but it's still
the most likely solution, so it's still really useful. -Wparentheses
has a fixit which inserts the parentheses; that's useful because it
tells the user how to suppress the diagnostic, but if we really think
it's 100% correct, we shouldn't bother emitting the diagnostic in the
first place.<br>
<br>
The truth is that users should never blindly apply fixits, and any tool
which lets them do so is probably really dangerous. Once you accept
that, fixits become just another axis of communication, suggesting the
likely source of errors and how they might be resolved.<br>
<br>
John.
</body>
</html>