Re: Emacs-devel Digest, Vol 65, Issue 83

[Robert M. Goldman]

Thank you for helping me.


Robert M. Goldman




----- Original Message -----
From: address@hidden
To: address@hidden
Sent: Tuesday, July 14, 2009 4:10:01 PM GMT -05:00 US/Canada Eastern
Subject: Emacs-devel Digest, Vol 65, Issue 83

Send Emacs-devel mailing list submissions to
        address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.gnu.org/mailman/listinfo/emacs-devel
or, via email, send a message with subject or body 'help' to
        address@hidden

You can reach the person managing the list at
        address@hidden

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Emacs-devel digest..."


Today's Topics:

   1. Re: Sending attachments (Stefan Monnier)
   2. Re: "(setq name)": Is this a bug? (Stefan Monnier)
   3. Re: Willing to debug bug #3542 (23.0.94;  File access via UNC
      path slow again under Windows) (Eli Zaretskii)
   4. Re: Willing to debug bug #3542 (23.0.94; File access via UNC
      path slow again under Windows) (Davis Herring)
   5. Re: Blunderbuss ".dir-locals.el" raises everything in its
      path!! (Miles Bader)
   6. Re: Willing to debug bug #3542 (23.0.94;  File access via UNC
      path slow again under Windows) (Eli Zaretskii)
   7. Re: Willing to debug bug #3542 (23.0.94;  File access via UNC
      path slow again under Windows) (Eli Zaretskii)
   8. Patch: Blunderbuss ".dir-locals.el" raises everything in its
      path!! (Alan Mackenzie)


----------------------------------------------------------------------

Message: 1
Date: Tue, 14 Jul 2009 14:48:10 -0400
From: Stefan Monnier <address@hidden>
Subject: Re: Sending attachments
To: address@hidden
Cc: address@hidden, address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii

>> I may need to maintain Emacs again; past history shows other
>> maintainers come and go.  If that happens, I want to have Mail mode,
>> not depend on something that is part of Gnus.

>     Please explain why you consider "part of Gnus" to be
>     a negative attribute.

> There are two reasons.  First, its primary source is maintained
> outside of Emacs.  Second, the people who work on it do not hesitate
> to add dependencies between one part and another, with results that
> one quickly sees on studying files from Gnus.

I'm sure they'll appreciate help in reducing dependencies between modules.

> Another problem with Gnus maintenance is that, whenever they see the
> need for some other feature, they add it to Gnus, without discussing
> it with the Emacs maintainer, and without attempting to make the
> package independent of Gnus.

Actually, they originally did make a specific effort to make
message-mode independent from Gnus so that it can replace mail-mode.
And then mail-mode stayed and so message-mode evolved under the pressure
of nothing else than Gnus.

> Another problem is that a lot of the code is ugly and hard to
> understand.  While this CAN happen to any code, I think the separate
> maintenance of Gnus encourages it, since it discourages other people
> than the Gnus developers from working on the code at all.

I don't know about you, but I'm a lot more afraid of CC-mode's code than
of Gnus's.  If you agree with that and following your reasoning, we
should have kept the old c-mode.el.


        Stefan




------------------------------

Message: 2
Date: Tue, 14 Jul 2009 14:49:25 -0400
From: Stefan Monnier <address@hidden>
Subject: Re: "(setq name)": Is this a bug?
To: Alan Mackenzie <address@hidden>
Cc: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii

> Hi, Emacs,
> In .../lisp/files.el, function set-auto-mode, L2553, appears the strange
> invocation:

>     (setq name)

> .  One of my analysis tools tripped up on it.  According to setq's doc
> string, this is invalid.  In each [SYM VAL] in (setq [SYM VAL] ...), the
> VAL is not optional.  Surely?

> I think this is a bug.

It's accepted bny the interpreter and the compiler, AFAIK, but I do
consider it as a bug, so please fix it to (setq name nil).


        Stefan




------------------------------

Message: 3
Date: Tue, 14 Jul 2009 22:14:05 +0300
From: Eli Zaretskii <address@hidden>
Subject: Re: Willing to debug bug #3542 (23.0.94;       File access via UNC
        path slow again under Windows)
To: Miles Bader <address@hidden>
Cc: address@hidden
Message-ID: <address@hidden>

> From: Miles Bader <address@hidden>
> Cc: Stefan Monnier <address@hidden>, address@hidden,
>         address@hidden
> Date: Tue, 14 Jul 2009 13:28:19 +0900
> 
> >   d = opendir (SDATA (Fdirectory_file_name (encoded_dir)));
> 
> That's a limitation of opendir (and posix filenames in general), and
> there's absolutely nothing we can do it (so there's no point in worrying
> about that case)

That's not what I meant.  What I meant is the problem that could
happen if encoded_dir's value was address@hidden, and there was also a
directory called "foo".  Won't we then opendir "foo"?

And what if opendir was replaced by unlink?




------------------------------

Message: 4
Date: Tue, 14 Jul 2009 12:32:18 -0700 (PDT)
From: "Davis Herring" <address@hidden>
Subject: Re: Willing to debug bug #3542 (23.0.94; File access via UNC
        path slow again under Windows)
To: "Eli Zaretskii" <address@hidden>
Cc: address@hidden, Miles Bader <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain;charset=iso-8859-1

> That's not what I meant.  What I meant is the problem that could
> happen if encoded_dir's value was address@hidden, and there was also a
> directory called "foo".  Won't we then opendir "foo"?

Of course.  But is the equivalence between "foo" and "address@hidden"
fundamentally worse than the (almost: consider symlinks) equivalence
between "foo" and "foo/"?  Maybe it just doesn't matter much.

> And what if opendir was replaced by unlink?

Nothing.  You can't unlink directories.  ;)

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.




------------------------------

Message: 5
Date: Wed, 15 Jul 2009 04:47:05 +0900
From: Miles Bader <address@hidden>
Subject: Re: Blunderbuss ".dir-locals.el" raises everything in its
        path!!
To: address@hidden
Cc: Alan Mackenzie <address@hidden>, Chong Yidong <address@hidden>,
        Jan Dj?rv <address@hidden>,     Stefan Monnier
        <address@hidden>, address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii

"Davis Herring" <address@hidden> writes:
> My understanding is that people don't want _automatic_ cleanup forced on
> them (so that they can edit as they're used to without having it change
> things unexpectedly) even though they will follow the convention
> eventually.

If I understand the documentation, c-cleanup-list doesn't apply anyway
unless you have electric mode enabled -- and if you have that enabled,
all sorts of stuff starts to happen "automatically".  So it seems a bit
of a stretch to say it "forces" anything.

-Miles

-- 
Arrest, v. Formally to detain one accused of unusualness.




------------------------------

Message: 6
Date: Tue, 14 Jul 2009 22:57:35 +0300
From: Eli Zaretskii <address@hidden>
Subject: Re: Willing to debug bug #3542 (23.0.94;       File access via UNC
        path slow again under Windows)
To: Stefan Monnier <address@hidden>
Cc: address@hidden
Message-ID: <address@hidden>

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Tue, 14 Jul 2009 14:18:53 -0400
> 
> >   directory_nbytes = SBYTES (directory);
> >   if (directory_nbytes == 0
> >       || !IS_ANY_SEP (SREF (directory, directory_nbytes - 1)))
> >     needsep = 1;
> >   [...]
> >               int nbytes = len + directory_nbytes + needsep;
> >               fullname = make_uninit_multibyte_string (nbytes, nbytes);
> >               bcopy (SDATA (directory), SDATA (fullname),
> >                      directory_nbytes);
> 
> make_uninit_multibyte_string calls allocate_string_data which does
> 
>   STRING_DATA (s)[nbytes] = '\0';
> 
> so the destination of the `bcopy' already has the terminating NUL.

Perhaps most of the places where we use these paradigms are okay due
to all these subtle corners that together make everything work.  But
IMHO it's inherently unsafe to use character arrays that are not true
C strings as if they were C strings.  For one, it violates the mental
model each C programmer has about strings, and that can easily lead to
misunderstanding, confusion, and bugs.  For example (from dbusbind.c):

  char x[DBUS_MAXIMUM_SIGNATURE_LENGTH];
  [...]
        strcpy (x, SDATA (CAR_SAFE (XD_NEXT_VALUE (elt))));
  [...]
      sprintf (signature, "%c%s", dtype, x);

or

      case DBUS_TYPE_SIGNATURE:
        {
          char *val = SDATA (Fstring_make_unibyte (object));
          XD_DEBUG_MESSAGE ("%c %s", dtype, val);

How can one convince herself that this code is safe without knowing
too much about the Lisp strings whose data gets handled here as C
strings?  Can they have embedded nulls or cannot they?

Same here (editfns.c):

      if (SBYTES (val) > message_length)
        {
          message_length = SBYTES (val);
          message_text = (char *)xrealloc (message_text, message_length);
        }
      bcopy (SDATA (val), message_text, SBYTES (val));
      message2 (message_text, SBYTES (val),
                STRING_MULTIBYTE (val));

message_text[] is not a C string here, because it's not
null-terminated (and doesn't have enough space to be terminated).
Without looking at the implementation of message2, whose 1st arg is a
`char *', how can one know that there's no bug here?

Or here (search.c):

          raw_pattern_size = SCHARS (string);
          raw_pattern_size_byte = SCHARS (string);
          raw_pattern = (unsigned char *) alloca (raw_pattern_size + 1);
          copy_text (SDATA (string), raw_pattern,
                     SBYTES (string), 1, 0);

raw_pattern[] is not null-terminated, and we then use it, directly and
indirectly, in many places.  Without studying each use, there's no way
you can determine that there cannot be a bug here.

Etc., etc. -- I see other places where maybe it works, maybe it
doesn't.  One needs to study the code very carefully and look at many
functions up and down the call stack, just to determine if a few lines
don't constitute a bug.




------------------------------

Message: 7
Date: Tue, 14 Jul 2009 23:03:24 +0300
From: Eli Zaretskii <address@hidden>
Subject: Re: Willing to debug bug #3542 (23.0.94;       File access via UNC
        path slow again under Windows)
To: address@hidden
Cc: address@hidden, address@hidden
Message-ID: <address@hidden>

> Date: Tue, 14 Jul 2009 12:32:18 -0700 (PDT)
> From: "Davis Herring" <address@hidden>
> Cc: "Miles Bader" <address@hidden>, address@hidden
> 
> > That's not what I meant.  What I meant is the problem that could
> > happen if encoded_dir's value was address@hidden, and there was also a
> > directory called "foo".  Won't we then opendir "foo"?
> 
> Of course.  But is the equivalence between "foo" and "address@hidden"
> fundamentally worse than the (almost: consider symlinks) equivalence
> between "foo" and "foo/"?

Yes, it is (IMO): directory "address@hidden" does not exist, so you should
have got an error.  Instead, you silently open a directory by another
name, as if "address@hidden" existed.




------------------------------

Message: 8
Date: Tue, 14 Jul 2009 20:11:50 +0000
From: Alan Mackenzie <address@hidden>
Subject: Patch: Blunderbuss ".dir-locals.el" raises everything in its
        path!!
To: Jan Dj?rv <address@hidden>, Jason Rumney <address@hidden>
Cc: Chong Yidong <address@hidden>,      Stefan Monnier
        <address@hidden>, address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii

Hi, Jan, Jason, Stefan!

On Tue, Jul 14, 2009 at 04:22:06PM +0000, Alan Mackenzie wrote:
> Hi, Jason, Jan, Stefan!

> On Mon, Jul 13, 2009 at 01:09:24PM +0800, Jason Rumney wrote:

> > I think it points to a bug in the handling of c-file-style.  The
> > documentation of c-cleanup-list (which is the variable that Jan was
> > surprised about) says that it should only be affected by the style
> > when it is set to set-from-style.

> I think you're right here, and that the bug is that the function
> handling c-file-style forgets to check that its value is
> 'set-from-style.

Here's a preliminary patch which I think fixes the code, though I've only
tested it briefly.  It seems to work for the case you (Jan) were hit by.

Now, any CC Mode style set by `c-file-style' will leave unchanged those
style variables (e.g. `c-cleanup-list') which have already been given
real values.

I expect and intend that if the `c-file-style' mechanism is used twice,
the second one (in the file's Local Variable section) will prevail over
the first one (in some .dir-locals.el), whilst respecting the non-default
value of `c-cleanup-list'.

Jan, please try it out!

Thanks!


Index: cc-mode.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/progmodes/cc-mode.el,v
retrieving revision 1.84
diff -c -r1.84 cc-mode.el
*** cc-mode.el  19 May 2009 22:35:07 -0000      1.84
--- cc-mode.el  14 Jul 2009 19:53:20 -0000
***************
*** 670,676 ****
          (offsets (cdr (assq 'c-file-offsets file-local-variables-alist))))
        (when stile
        (or (stringp stile) (error "c-file-style is not a string"))
!       (c-set-style stile))
        (when offsets
        (mapc
         (lambda (langentry)
--- 670,676 ----
          (offsets (cdr (assq 'c-file-offsets file-local-variables-alist))))
        (when stile
        (or (stringp stile) (error "c-file-style is not a string"))
!       (c-set-style stile 'respect-defaults))
        (when offsets
        (mapc
         (lambda (langentry)
***************
*** 741,747 ****
      (when c-file-style
        (or (stringp c-file-style)
          (error "c-file-style is not a string"))
!       (c-set-style c-file-style))
  
      (and c-file-offsets
         (mapc
--- 741,747 ----
      (when c-file-style
        (or (stringp c-file-style)
          (error "c-file-style is not a string"))
!       (c-set-style c-file-style 'respect-defaults))
  
      (and c-file-offsets
         (mapc

-- 
Alan Mackenzie (Nuremberg, Germany).




------------------------------

_______________________________________________
Emacs-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/emacs-devel

End of Emacs-devel Digest, Vol 65, Issue 83
*******************************************