Re: [ctwm] Compiler warning fixes for review
On Mon, Oct 29, 2007 at 08:45:04PM -0500 I heard the voice of
Matthew D. Fuller, and lo! it spake thus:
See attached patch.
Well, hearing no objections, I've reread the patch enough to convince
myself that it's right (or at least, where wrong, the old code was at
least as wrong). So, this is pushed. At least one actual bug (var
used before defined) is fixed, as well as some potential latent ones
on platforms where sizeof(int) != sizeof(long), and some general
warning-petting beyond that. The most likely source of problems will
come from lex/yacc output code.
There remain a large hunk of warnings when strict-aliasing is enabled,
mostly around X{Find,Save}Context(). A large number can also be found
with -Wsign-compare that I didn't have the heart to get into. Maybe
next round...
--
Matthew Fuller (MF4839) | [EMAIL PROTECTED]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
[ctwm] Crash fix for when WorkSpaces not defined
When no WorkSpaces {} are defined in your .ctwmrc, parts of the
structure used to track them aren't initialized properly in the code.
This can lead to crashes when those pointers are dereferenced; I came
across it in the TwmWindows menu. I've pushed up a fix for this;
see attached patch.
I have a sneaky suspicion there are more such land mines scattered
through the code :|
--
Matthew Fuller (MF4839) | [EMAIL PROTECTED]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
#
#
# patch workmgr.c
# from [cbbb225102a852d23956bec573e7e10b61620c54]
#to [2d59af82aea7cee7cc29bb3db7f77be30fcb3fed]
#
--- workmgr.c cbbb225102a852d23956bec573e7e10b61620c54
+++ workmgr.c 2d59af82aea7cee7cc29bb3db7f77be30fcb3fed
@@ -168,8 +168,14 @@ void ConfigureWorkSpaceManager (void) {
virtualScreen *vs;
for (vs = Scr-vScreenList; vs != NULL; vs = vs-next) {
- WorkSpaceWindow *wsw = (WorkSpaceWindow*) malloc (sizeof
(WorkSpaceWindow));
- wsw-twm_win = (TwmWindow*) 0;
+ /*
+* Make sure this is all properly initialized to nothing. Otherwise
+* bad and undefined behavior can show up in certain cases (e.g.,
+* with no Workspaces {} defined in .ctwmrc, the only defined
+* workspace will be random memory bytes, which can causes crashes on
+* e.g. f.menu TwmWindows.)
+*/
+ WorkSpaceWindow *wsw = (WorkSpaceWindow*) calloc (1, sizeof
(WorkSpaceWindow));
wsw-state = Scr-workSpaceMgr.initialstate; /* BUTTONSSTATE */
vs-wsw = wsw;
}
Re: [ctwm] Crash fix for when WorkSpaces not defined
In message [EMAIL PROTECTED] on Thu, 22 Nov 2007 13:28:25 -0600, Matthew D.
Fuller [EMAIL PROTECTED] said:
fullermd When no WorkSpaces {} are defined in your .ctwmrc, parts of
fullermd the structure used to track them aren't initialized properly
fullermd in the code. This can lead to crashes when those pointers
fullermd are dereferenced; I came across it in the TwmWindows menu.
fullermd I've pushed up a fix for this; see attached patch.
fullermd
fullermd I have a sneaky suspicion there are more such land mines
fullermd scattered through the code :|
Good job. Yeah, I wouldn't be surprised if there are more things like
that...
Ehummm, I think it's time we take a look in the bugs database and try
to fix some of the things (or dismiss it).
Cheers,
Richard
--
Richard Levitte [EMAIL PROTECTED]
http://richard.levitte.org/
When I became a man I put away childish things, including
the fear of childishness and the desire to be very grown up.
-- C.S. Lewis
Re: [ctwm] Crash fix for when WorkSpaces not defined
On Thu, Nov 22, 2007 at 08:44:27PM +0100 I heard the voice of Richard Levitte, and lo! it spake thus: Ehummm, I think it's time we take a look in the bugs database and try to fix some of the things (or dismiss it). Yeah, I was doing a little looking back over bugs and unresolved list posts when I got sidetracked by my Xnest-ed test ctwm blowing up every time I scrolled past my TWM Windows menu entry. Funny how that throws you off your stride. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
[ctwm] Signal handler messes
We've got problems in the signal handlers. Signal handlers seem to be set in 3 files. The good news: - util.c is all safe - menus.c is safe ctwm.c, however, is a different story. - SIGCHLD handler is safe, yay. - SIGHUP handler is doing a fprintf() which isn't async-signal-safe. Fortunately, that's merely cosmetic and can be pretty easily yanked. - SIGSEGV/BUS (Crash()) catcher is doing a lot of fprintf()'s, which aren't safe (but are merely informative and could be dropped). However, it's also calling out both indirectly and directly to Xlib functions(!!!) which have to be about the LEAST async-signal-safe functions you could find in the wild. - SIGINT/QUIT/TERM handler (Done()) commits all the above atrocities, and heaps on top the potential of calling out to *SOUND* playing functions. Caramba! The SIGHUP handler can be trivially made safe. The Crash() handler, I think, should just be removed; the clean cleanup stuff can't be done in the signal handler, and can't possibly be safely done at that point anyway since we're already in an ill-defined state. The begging of the user to send a stack trace can't be done safely in the signal handler, and the trace is likely corrupted already by jumping around the signal handlers. Done() probably needs to be switched to just calling _exit(2) (not exit(3)). A somewhat more involved possibility would be to set a flag we can check to do the more clean-like shutdown off in the main loop (which is probably the better choice, but is more work). Thoughts? -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ctwm] Ctrl-Return lost w/ ctwm 3.8a
On Tue, May 01, 2007 at 05:17:30PM -0400 I heard the voice of [EMAIL PROTECTED], and lo! it spake thus: I just tried 3.8a (XPM USEM4 GNOME I18N) and the Ctrl-Return isn't recognized anymore and isn't caught by ctwm for the altkeymap. It's just taken as a regular Return character. [months later] I'm unable to reproduce this in a little testing here. Mapping Return or Ctrl-Return to pulling up a menu works just fine with the current head in 'root' context or in 'all'. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
[ctwm] Special window-manager modifier not working
I have setup a WM modifier, more specifically I use my lower-left corner ctrl key for it. The way I do it is to remap it via xmodmap to Hyper_L and then set it (via xmodmap again) to mod5. Then I have in my .ctwmrc some bindings such as: Button1 = m5 : window|icon|title|frame : f.function ResizeOrRaiseOrLower Button2 = m5 : window|icon|title|frame : f.movepack Button3 = m5 : window|icon|title|frame : f.menu WindowMenu This has been working fine for many years, but recently I've been encoutering machines where it doesn't work. This shows up on newly installed machines and on some of them the problem has finally disappeared for no apparent reason, while for some (in particular for my main laptop) it doesn't want to go away. The way the problem manifests itself is that all the above special bindings in my .ctwmrc seem to be ignored. If I right-click in an Emacs frame with the special m5 modifier pressed, instead of getting my ctwm WindowMenu, I get a message from Emacs saying that H-mouse-3 is unbound. `xev' indicates that the key is properly xmodmapped. I have a strong suspicion that this is linked to some nasty Gnome or XKBsomething intrusion, but since I know nothing about that, I'm at a loss. Does someone here have an idea where I might want to start looking for a solution? Stefan
Re: [ctwm] Special window-manager modifier not working
In message [EMAIL PROTECTED] on Thu, 22 Nov 2007 16:19:09 -0500, Stefan Monnier [EMAIL PROTECTED] said: monnier I have a strong suspicion that this is linked to some nasty Gnome or monnier XKBsomething intrusion, but since I know nothing about that, I'm at monnier a loss. monnier monnier Does someone here have an idea where I might want to start looking for monnier a solution? How about a test account where you run ctwm raw, without Gnome or any other desktop environment? That could be a way to narrow the scope of the problem... Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis
Re: [ctwm] [rt.lp.se #133] Sticky NumLock for the pointer but not the keyboard
On Sun, Jul 01, 2007 at 07:25:27PM +0200 I heard the voice of Jens Schweikhardt via RT, and lo! it spake thus: Clicking the left button on the root window makes root/button m2 appear, even though NumLock is off (as per NumLock LED and per keyboard symbols). Is this a bug in ctwm? I wouldn't expect it to be; that info would all be getting passed through the X server to get to ctwm. In some quick testing here, I can't reproduce it; works just as expected for me. I'm using Pause remapped to Num Lock: % grep -A2 Pause ~/.xmodmap ! Pause - numlock keycode 0x6E = Num_LockBreak addmod2= Num_Lock -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ctwm] [rt.lp.se #134] ctwm crashed by ClickToFocus function turning on
On Sun, Aug 12, 2007 at 08:23:20PM +0200 I heard the voice of
佐藤 純弘 via RT, and lo! it spake thus:
to reproduce this,
1. run ctwmrc with attched .ctwmrc
2. then get no-title bar window popup
easiest way is using Firefox, go basic authenticated page
then enable to get password popup
3. click button to close popup (OK / Cancel /etc/)
4. ... then ctwm crash, get core.
I get a slightly different trace. Whether that's due to code changes,
or corruption from signal handlers, I don't know.
Mine is bombing out in events.c:2681, which is:
XTranslateCoordinates(dpy, Tmp_win-vs-window, [...]
Examination of the core in gdb shows that Tmp_win-vs is NULL, hence
the SEGV. The attached patch seems to prevent the crash here, but I
have no idea whether it's a correct fix, or just invalid in a
non-crashing way; it's very much shotgunned. Olaf may know better?
--
Matthew Fuller (MF4839) | [EMAIL PROTECTED]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
#
# old_revision [1dfd5be037e9fb09f9aee3d938dcca2848aa7744]
#
# patch events.c
# from [39f3358ff082d672b599845150ceab6806a03603]
#to [faecee097f0d8826210e043688de7642c4b3814d]
#
--- events.c39f3358ff082d672b599845150ceab6806a03603
+++ events.cfaecee097f0d8826210e043688de7642c4b3814d
@@ -2675,10 +2675,14 @@ void HandleButtonRelease(void)
if(xl 0 || yt 0 || xl Scr-rootw || yt Scr-rooth) {
int odestx, odesty;
int destx, desty;
- Window cr;
+ Window cr, tsrc;
virtualScreen *newvs;
- XTranslateCoordinates(dpy, Tmp_win-vs-window,
+ if(Tmp_win-vs!=NULL)
+ tsrc = Tmp_win-vs-window;
+ else
+ tsrc = Scr-Root;
+ XTranslateCoordinates(dpy, tsrc,
Scr-XineramaRoot, xl, yt, odestx, odesty, cr);
newvs = findIfVScreenOf(odestx, odesty);
Re: [ctwm] Depth-arrangement of windows is not preserved?
In message [EMAIL PROTECTED] on Thu, 22 Nov 2007 17:13:26 -0600, Matthew D.
Fuller [EMAIL PROTECTED] said:
fullermd On Fri, Dec 22, 2006 at 11:44:02PM +0100 I heard the voice of
fullermd Rhialto, and lo! it spake thus:
fullermd
fullermd Once we settle on some layout, [...]
fullermd
fullermd Which we should move toward. The present situation is
fullermd downright painful. The style is inconsistent in every way.
fullermd The amount of cruft is staggering; what variables we declare
fullermd where and in what scope, what functions are prototypes where
fullermd (or at all)...
I generally agree. There's a lot of baggage, and I suspect some of it
comes all the way from twm itself.
fullermd The following, I think, should not be contentious:
fullermd
fullermd - Tabs should not be used for alignment. See e.g. #define's
fullermd and comments after lines in structure definitions in twm.h
fullermd and other .h's. This goes all wonky with any tabstop
fullermd except that of the person writing it. The only thing a
fullermd tab is the same size as is a tab, so unless they happen at
fullermd the beginning of the line in equal numbers, you can be
fullermd assured that tabs will misalign somewhere.
I agree. To make it easy, we could add something similar to this (but
with C instead of C++ style comments) at the end of each file:
// Local Variables:
// mode: C++
// fill-column: 76
// c-file-style: gnu
// indent-tabs-mode: nil
// End:
// vim: et:sw=2:sts=2:ts=2:cino=2s,{s,\:s,+s,t0,g0,^-2,e-2,n-2,p2s,(0,=s:
Now, there's no need for the GNU style specifically, although I happen
to like it, but I hope you catch my drift...
fullermd - Single-line if()'s are the devil. I've used 'em in code
fullermd before, but almost always for bad reasons.
Agreed.
fullermd Similarly, cramming two statements on one line like
fullermd i = 0; j = 0; is usually more hinderance than help.
Not sure I agree in all cases.
fullermd - We have way too many lines that are way too long. Sub-80
fullermd char! Going with that, comments at EOL are probably
fullermd usually best put elsewhere.
I try to keep lines at sub-80, but there are cases where doing so
becomes butt ugly. Those are often better kept long.
fullermd - Speaking of comments, we need a lot more of 'em. Except
fullermd in the places where there are long comments embedded in
fullermd the middle of statements, like in the if() a dozen lines
fullermd into ChangeOccupation(). I'm hot on comments and vertical
fullermd whitespace.
Yes, more well placed comments good! Anyone feeling like documenting
a piece of code somewhere with comments? By all the mighty gods,
don't let anything stop you!
fullermd - We have too damn many global variables.
True, but they do serve a purpose.
fullermd These are probably more so:
fullermd
fullermd - Indent with either 1 tab per level, or some number (2? 4?
fullermd 3 maybe, to really mess with people mixing in tabs?) of
fullermd spaces per level. No number of spaces should ever turn
fullermd into a tab (see ci and pi flags in vim). That part at
fullermd least shouldn't be too argumentative; it's which of the
fullermd two that gets rough.
My preference is the GNU style or BSD KNF style with 4 spaces for
indentation.
For those wondering about the different styles, see
http://en.wikipedia.org/wiki/Indent_style
fullermd - Spaces before args. if (x) and foofunc (x). I don't
fullermd like 'em.
Well, I'd like to differenciate between statements (such as if) and
functions. The former gets a space, the latter not. That goes along
with the BSD KNF style.
fullermd - Braces. It seems like a majority (but not a large one) of
fullermd the code KR's it. I prefer Allman; I especially dislike
fullermd the cuddled up else if's you end up with in KR...
I dunno, Allman's style always made me cringe... Now, what exactly is
wrong with else if? Can you show an example of what's so horrible
and how you would write it instead?
fullermd Other random bits:
fullermd
fullermd - Multi-line alignment. I tend to align later lines where
fullermd they 'belong' logically; up to the ( of function calls,
fullermd and sometimes layers deeper on long many-parenthesized
fullermd if()'s, except when that is too far over (where too
fullermd far is interpreted on a variety of criteria), in which
fullermd case I push them over 2 indentation levels (which
fullermd distinguishes them well from inner blocks).
Agreed.
fullermd - Underscores good. CamelCase bad.
I generally agree, except CamelCase seems to be the general X11
style. I've no problem adapting to that.
fullermd - Defining functions with a newline before the function name
fullermd sure does make finding stuff easier.
fullermd
fullermd void
fullermd foobar(blah)
fullermd
fullermd not
fullermd
fullermd void foobar(blah)
The former is yet one of those things that make me cringe. I can't
see how it's hard to search the
Re: [ctwm] Crash fix for when WorkSpaces not defined
Actually, it's less weird than you might think. I assume that Matthew did some hacking in a branch of his own, but since that branch is most probably not among those he's allowed to write to, the revisions themselves come over, but the branch certs do not. So basically, the edge between e07ab7de496e218dc324fe3a9cb66d85dde116d8 and a97d0dcc8eaf6e94ce9190d98913789d9dbbd37f represent the move from the ctwm branch to Matthew's private hackng branch, and the edge between 6eb1af5f822cafe715c4e46f37ea3bc808e7a5f5 and 4da54949171b2cc1c5f467318daf87b683a77d9b represent the move back into the ctwm branch. Cheers, Richard In message [EMAIL PROTECTED] on Fri, 23 Nov 2007 02:00:33 +0100, Rhialto [EMAIL PROTECTED] said: rhialto I pulled a new monotone repository and looked at it with monotone-viz, rhialto and something weird is going on. Maybe it's a monotone bug, or it may be rhialto with monotone-viz. rhialto rhialto There is a Revision: a97d0dcc8eaf6e94ce9190d98913789d9dbbd37f (Add in a rhialto prototype for yyparse() to quiet compiler warnings.) which goes rhialto nowhere (it has a blocked instead of a solid box) and even stranger a rhialto Revision: 6eb1af5f822cafe715c4e46f37ea3bc808e7a5f5 (Move another rhialto twmrc_error_prefix() extern to global scope.) which comes from nowhere. rhialto rhialto Normally the blocked boxes mean that there are connections, but they are rhialto just not shown in the current view. However I think I'm viewing rhialto everything but there is still no link. I suspect there is a link between rhialto these two (maybe even with some intermediary revision) but some bug rhialto prevents me from seeing it. rhialto rhialto My versions are monotone 0.36 (base revision: rhialto e4bc808d89e029ce623f9e8f2b10c84006b83fb5) and monotone-viz 0.15 (base rhialto revision: ) - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis
