GNU bug report logs - #29450
26.0.90; No check for nil in some filenotify functions

Previous Next

Package: emacs;

Reported by: "John Wiegley" <johnw <at> gnu.org>

Date: Sun, 26 Nov 2017 06:19:01 UTC

Severity: minor

Tags: moreinfo, wontfix

Found in version 26.0.90

Done: Michael Albinus <michael.albinus <at> gmx.de>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: "John Wiegley" <johnw <at> gnu.org>
Cc: 29450 <at> debbugs.gnu.org
Subject: bug#29450: 26.0.90; No check for nil in some filenotify functions
Date: Sun, 26 Nov 2017 17:39:31 +0200
> From: "John Wiegley" <johnw <at> gnu.org>
> Date: Sat, 25 Nov 2017 22:18:07 -0800
> 
> The documentation for find-file-name-handler says:
> 
>     find-file-name-handler is a built-in function in ‘C source code’.
>     
>     (find-file-name-handler FILENAME OPERATION)
>     
>     Return FILENAME’s handler function for OPERATION, if it has one.
>     Otherwise, return nil.
> 
> However, several of the functions in filenotify use the return value of this
> function without checking if it's nil or not:

Maybe I'm blind, but I cannot find any place in filenotify where the
handler is used without checking, including in the case you show:

>     (defun file-notify-rm-watch (descriptor)
>       "Remove an existing watch specified by its DESCRIPTOR.
>     DESCRIPTOR should be an object returned by `file-notify-add-watch'."
>       (when-let* ((watch (gethash descriptor file-notify-descriptors)))
>         (let ((handler (find-file-name-handler
>                         (file-notify--watch-directory watch)
>                         'file-notify-rm-watch)))
>           (condition-case nil
>               (if handler <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>                   ;; A file name handler could exist even if there is no
>                   ;; local file notification support.
>                   (funcall handler 'file-notify-rm-watch descriptor)

What am I missing?

> I've been getting several errors with a backtrace like nil(48). This is likely
> because some package has done something wrong, but even still, filenotify
> should be more defensive.

Can you show a full backtrace like that?




This bug report was last modified 7 years and 109 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.