Subject: CVS domivogt: * Fixed FvwmIdent hang.

From: CVS <[email-masked]>
Date: Thu, 24 Jun 1999 20:34:30 -0500 (CDT)

CVSROOT:	/home/cvs/fvwm
Module name:	fvwm
Changes by:	domivogt	99/06/24 20:34:29

Modified files:
	.              : ChangeLog 
	fvwm           : builtins.c events.c focus.c fvwm.c gnome.c 
	                 icons.c misc.c move_resize.c placement.c 
	                 session.c stack.c 
	libs           : Module.c 
	modules        : ChangeLog 
	modules/FvwmIdent: FvwmIdent.c 
	modules/FvwmPager: .cvsignore x_pager.c 
	modules/FvwmWinList: FvwmWinList.c 

Log message:
* Fixed FvwmIdent hang.
* Fixed X error message when freeing NULL pixmap.
* Safety fix in InitGetConfigLine.
* Include virtual.h in several files.
* Fixed FvwmWinLists buggy size hints.

--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Fri, 25 Jun 1999 09:00:05 -0400

> * Safety fix in InitGetConfigLine.

I had  no worry at  all that InitGetConfigLine would  be called with a
matching string  that  would overflow   the  buffer, but   I think you
replaced working code with a memory leak:

fork> cvs diff -r 1.18 Module.c
Index: Module.c
===================================================================
RCS file: /home/cvs/fvwm/fvwm/libs/Module.c,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -B -b -r1.18 -r1.19
--- Module.c    1999/06/07 01:26:01     1.18
+++ Module.c    1999/06/25 01:34:24     1.19
@@ -129,7 +129,7 @@
 
 void InitGetConfigLine(int *fd,char *match) 
 {
-    char buffer[200];
+  char *buffer = (char *)safemalloc(strlen(match) + 32);
     first_pass = 0;                       /* make sure get wont do this */
     sprintf(buffer,"Send_ConfigInfo %s",match);
     SendText(fd,buffer,0);

There are situations  where  a module   would do  repetitive  calls to
InitGetConfigLine.

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 25 Jun 1999 15:22:36 +0200

> replaced working code with a memory leak:

Oops, I shouldn't make fixes at 3 AM :)

Bye

Dominik ^_^

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: [email-masked] (Paul D. Smith)
Date: 25 Jun 1999 09:56:49 -0400

%% Dominik Vogt <[email-masked]> writes:

  >> replaced working code with a memory leak:

  dv> Oops, I shouldn't make fixes at 3 AM :)

Remember, we've decided alloca() is OK for fvwm.  We're using it in some
places already so we might as well use it more often.

In general, anywhere you see an auto buffer variable it's best to
replace it with an alloca() call rather than a malloc() call; then the
scope is the same as the original variable, but you get to expand the
length of the buffer dynamically for more robust behavior.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 26 Jun 1999 02:21:50 +0200

> places already so we might as well use it more often.

Duh, I forgot about this. We should definitely have a 'safealloca' function
in the style of safemalloc.

Bye

Dominik ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: [email-masked] (Paul D. Smith)
Date: 26 Jun 1999 22:59:30 -0400

>> places already so we might as well use it more often.

  dv> Duh, I forgot about this. We should definitely have a 'safealloca'
  dv> function in the style of safemalloc.

Well, of course you can't do that.  Any memory alloca()'d is
automatically "freed" when the function that invoked alloca() exits.
That's the whole point, after all.

Alloca() allocates memory from the stack, so the only way it could fail
is if you blew the stack size.

I suppose you could make a "safealloca()" _macro_.  Not sure it's really
worth it, though.

PS. Note that most GNU/etc. programs use the functions "xmalloc()",
    etc. instead of "safemalloc()" (the "x" means "exit"; as in the
    function won't return if the allocation fails).

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 27 Jun 1999 15:51:04 +0200

> That's the whole point, after all.

Yes, I understood so much, but why do you think alloca will never
return a NULL pointer? Excerpt from the man page on my Linux:

       The  alloca function returns a pointer to the beginning of
       the allocated space.  If the  allocation  failed,  a  NULL
       pointer is returned.

> is if you blew the stack size.

And why should this be less likely than that safemalloc fails?

Bye

Dominik ^_^

---

From: [email-masked] (Paul D. Smith)
Date: 27 Jun 1999 20:48:58 -0400

>> That's the whole point, after all.

  dv> Yes, I understood so much, but why do you think alloca will never
  dv> return a NULL pointer? Excerpt from the man page on my Linux:

I never said it couldn't fail, I said you can't make a safealloca()
function.

Because, any memory you "alloca()" in the safealloca() function
disappears as soon as the function returns.

You could, as I mentioned, make a safealloca() macro.  But of course
when it's a macro any code there is duplicated however many times you
invoke it.

  >> Alloca() allocates memory from the stack, so the only way it could
  >> fail is if you blew the stack size.

  dv> And why should this be less likely than that safemalloc fails?

Because typically people don't put that much stuff on the stack, I
guess.  I don't have any idea how much more or less likely it is,
statistically, but I _do_ know that a large percentageof GNU projects
use alloca() and I've never yet seen one test the return value.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 28 Jun 1999 20:58:51 +0200

> when it's a macro any code there is duplicated however many times you

Oh, now you have made me feel really dumb. So *that* was your point
in talking about the memory being automatically freed. How embarassing 8-)
I guess there is no xalloca function commonly available?

Bye

Dominik ^_^

---

From: [email-masked] (Paul D. Smith)
Date: 29 Jun 1999 01:11:50 -0400

>> I never said it couldn't fail, I said you can't make a safealloca()

  dv> Oh, now you have made me feel really dumb. So *that* was your
  dv> point in talking about the memory being automatically freed. How
  dv> embarassing 8-)

:)

  dv> I guess there is no xalloca function commonly available?

Nope.  Everyone just seems to assume it will always work.  I guess they
figure if you're so low on stack space that alloca() fails, your program
is due for a very rocky landing soon anyway (maybe you couldn't even
call the proper perror()/exit()/etc. functions!)

I would suspect a more likely cause is a bogus parameter to alloca()
than _really_ blowing the stack, but again, no one seems to check it
*shrug*.  Typically you wouldn't invoke alloca() unless you were pretty
sure that the value was fairly small (even if you have a decent stack
you can suck it up pretty fast with alloca() if you're not careful, or
use it in deep recursion, or whatever).  Whenever folks get data where
the size could be significant they use traditional malloc/heap storage.