all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: schwab@suse.de, dmantipov@yandex.ru, emacs-devel@gnu.org,
	eggert@cs.ucla.edu
Subject: Re: Warnings/errors related to possibly clobbered variables
Date: Tue, 13 Jan 2015 15:55:12 -0500	[thread overview]
Message-ID: <jwva91m2yum.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <83egqy4f36.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 13 Jan 2015 22:10:05 +0200")

>> > Why not declare the offending variables 'volatile' and forget about
>> > all this stuff?
>> FWIW, `volatile' might not necessarily give us the behavior we
>> want/need.
> How so?  Are you saying that qualifying an automatic variable as
> 'volatile' might change the semantics of the program?

GCC's warning basically points out that the semantics of the program is
unclear, because when we come back from a longjmp we could either see
the latest value of the variable, or a value it had earlier when we did
the setjmp.

So using `volatile' chooses one of the two behaviors, and it might not
be the one we need.

> IME, adding 'volatile' is generally TRT in these cases.  Plus, it's
> very simple, and goes "by the book" (a.k.a. the C Standard).

FWIW, the last time I had to fight with this kind of interaction between
longjmp and local variables, I ended up installing the patch below to
fix the random crashes I was seeing: the problem is more subtle than
just "add `volatile'".


        Stefan


diff --git a/src/bytecode.c b/src/bytecode.c
index 0ea646a..f1bdfd9 100644
--- a/src/bytecode.c
+++ b/src/bytecode.c
@@ -501,7 +501,6 @@ exec_byte_code (Lisp_Object bytestr, Lisp_Object vector, Lisp_Object maxdepth,
 		Lisp_Object args_template, ptrdiff_t nargs, Lisp_Object *args)
 {
   ptrdiff_t count = SPECPDL_INDEX ();
-  ptrdiff_t volatile count_volatile;
 #ifdef BYTE_CODE_METER
   int volatile this_op = 0;
   int prev_op;
@@ -509,14 +508,12 @@ exec_byte_code (Lisp_Object bytestr, Lisp_Object vector, Lisp_Object maxdepth,
   int op;
   /* Lisp_Object v1, v2; */
   Lisp_Object *vectorp;
-  Lisp_Object *volatile vectorp_volatile;
 #ifdef BYTE_CODE_SAFE
-  ptrdiff_t volatile const_length;
-  Lisp_Object *volatile stacke;
-  ptrdiff_t volatile bytestr_length;
+  ptrdiff_t const_length;
+  Lisp_Object *stacke;
+  ptrdiff_t bytestr_length;
 #endif
   struct byte_stack stack;
-  struct byte_stack volatile stack_volatile;
   Lisp_Object *top;
   Lisp_Object result;
   enum handlertype type;
@@ -1122,9 +1119,6 @@ exec_byte_code (Lisp_Object bytestr, Lisp_Object vector, Lisp_Object maxdepth,
 	    PUSH_HANDLER (c, tag, type);
 	    c->bytecode_dest = dest;
 	    c->bytecode_top = top;
-	    count_volatile = count;
-	    stack_volatile = stack;
-	    vectorp_volatile = vectorp;
 
 	    if (sys_setjmp (c->jmp))
 	      {
@@ -1135,12 +1129,11 @@ exec_byte_code (Lisp_Object bytestr, Lisp_Object vector, Lisp_Object maxdepth,
 		handlerlist = c->next;
 		PUSH (c->val);
 		CHECK_RANGE (dest);
-		stack = stack_volatile;
+		/* Might have been re-set by longjmp!  */
+		stack.byte_string_start = SDATA (stack.byte_string);
 		stack.pc = stack.byte_string_start + dest;
 	      }
 
-	    count = count_volatile;
-	    vectorp = vectorp_volatile;
 	    NEXT;
 	  }
 



  reply	other threads:[~2015-01-13 20:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-13 11:32 Warnings/errors related to possibly clobbered variables Dmitry Antipov
2015-01-13 11:51 ` Andreas Schwab
2015-01-13 12:12   ` Dmitry Antipov
2015-01-13 16:21     ` Eli Zaretskii
2015-01-13 17:07       ` Paul Eggert
2015-01-13 19:43       ` Stefan Monnier
2015-01-13 20:10         ` Eli Zaretskii
2015-01-13 20:55           ` Stefan Monnier [this message]
2015-01-13 21:31           ` Paul Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwva91m2yum.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=dmantipov@yandex.ru \
    --cc=eggert@cs.ucla.edu \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=schwab@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.