[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Nonsensical byte compiler warning.

From: David Kastrup
Subject: Re: Nonsensical byte compiler warning.
Date: Wed, 04 Apr 2007 12:17:52 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Markus Triska <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>> I reported this warning without being able to figure out where it
>> came from, remember?
> Yes, I remember. I also remember that at least 3 other people figured
> it out.

So I am not anyone, after all.

> One of them submitted a patch. Another one couldn't see the problem
> despite having pinpointed the exact location of the call (as you
> suggest that the optimiser report), believing in a "bug in the byte
> compiler".

Probably not anyone, either.

> While the error text can be improved, I find it unjustified to call
> the current behaviour "nonsensical", "plain useless" or "a compiler
> bug". It's a reasonable choice to point to the enclosing defun,

Not regarding the line number.  I disagree strongly.  The name of the
enclosing function is useful.  The line number isn't, except for
verifying that one is not looking at the wrong file.

But not even for that the reported number is really helpful since it
does not return the line number of the start or end of the defun
(which would give the user the clue that the line number is not
related to the point of error, but rather the function definition),
but rather a line in the function body that is somewhat close to the
actual beginning of the defun.

And that is worse than useless since it suggests that the line number
tries pinpointing some location inside of the function.  Which it

> and if your function has dozens of calls to char-before, there are
> probably graver problems to worry about.

So you are of the opinion that a function that calls any other
function from more than one place is a grave problem, and the byte
compiler is not supposed to be helpful with grave problems?

Sorry, but I can't see how one could consider your points and
conclusions here even remotely tenable.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]