Keep libtool's -version-info arguments for the three libraries
(libwraster, libWINGs and libWUtil) centralized in configure.ac
instead of in the specific Makefile.am.
The code was added in 2001 in commit acdc0e3d6b for
"backwards compat". This motivation no longer exists in 2010,
so there is no reason to keep a private implementation of
a standard function from the C library.
Instead of using the --disable-verbose-compile hack, let's
use the standard option --enable-silent-rules (or 'make V=0' directly)
available with autoconf 1.11 and higher.
This is enabled in autoconf by using 'silent-rules' in AM_INIT_AUTOMAKE.
The verbosity of compilation is reduced in a similar manner as using
the --disable-verbose-compile option, so we can remove all that ugly
hackery.
WUtil.h:212: warning: function declaration isn’t a prototype
WUtil.h:259: warning: function declaration isn’t a prototype
WUtil.h:300: warning: function declaration isn’t a prototype
WINGsP.h:593: warning: function declaration isn’t a prototype
WINGsP.h:599: warning: function declaration isn’t a prototype
WINGs.h:616: warning: function declaration isn’t a prototype
raster.c:295: warning: no previous prototype for ‘calculateCombineArea’
libWINGs is using mathematical functions (atan, sqrt, etc.). Check
whether we need to lik against libm to use these and link libWINGs
against it if necessary.
libWINGs is using libwraster functions (e.g. RScaleImage) and therefore
needs to be linked against it.
ametzler@argenau:/tmp/WMAKER/wmaker-crm$ env LD_LIBRARY_PATH=debian/wmaker/usr/lib ldd -r debian/wmaker/usr/lib/libWINGs.so.2.0.1 2>&1 | grep RScaleIma
undefined symbol: RScaleImage (debian/wmaker/usr/lib/libWINGs.so.2.0.1)
libWINGs is using libWUtil functions (e.g. WMAddIdleHandler). Reorder
lib_LTLIBRARIES to build libWUtil before libWINGs. Link libWINGs against
libWUtil.
The "make dist" command can be used to generate the release tarball, but
only if the Makefile.am correctly specifies EXTRA_DIST, specifies
headers in foo_SOURCES, and so on.
- Does away with the O_BINARY abomination
- as a byproduct, plugs an fd leak in wcolorpanel.c:fetchFile()
- sprinkle some fsync()s to files that have been written to (this
needs to be done everywhere)
+ fix brown paper bag thinko in configure.ac
As the README used to say, it was a unfinished work. If someone
wants to finish it after all these years it can be recovered
from the logs. But meanwhile let's not carry dead code around.
- add new wglobaldefaultspathfordomain() to wings (replaces several
hand-rolled individual implementations in utils/)
- make all of 'em handle -h|--help, -v|--version
- try making them not to nothing silently
- change various ways of knowing thyselves to using __progname
- generally try to make them feel similar (NOT right, similar --
right is a completely different matter)
- make it use wings functions, remove duplicated code from getstyle
- de-static necessary functions in wings
- add new wrmdirhier to wings
- rename WMMkDirHier to wmkdirhier (fits better)
- remove calling shell from getstyle (what were they thinking?)
i couldn't quite test getstyle (no idea about themes), but it still
basically works.
do back your ~/G dir up... wrmdirhier might eat it!
definitely needs testing, especially by people who have any idea
how themes work.
Some more getstyle
- missed a shell invocation
- maybe copyFile should be in wutils too...?
[crmafra: Folded second patch into the first]
make wtrimspace() use wings' own function for a task
semantics change: it used to segfault given null, now it returns null.
this doesn't affect any current use (there's exactly one..), and i see
no harm in this behaviour, and perceive this to be more natural.
The result is not much more convoluted than the original was, but much shorter.
Several vararg macros were added -- no idea what !gcc compilers make of this.
The messages sent to these functions are inconsistent across the source tree.
I have now decided that the logging function will add the final newline -
messages will need to be modified accordingly.
I have no idea why the original implementation was as complicated and ugly as
it was. My guess is that it was anticipated that these are be called from
sighandlers, but why no snprintf when they are all stuffed up with vsnprintf...
Still, the result is not worse in this regard either.
It addresses this warning
dialog.c: In function ‘LoadHistory’:
dialog.c:209: warning: passing argument 2 of ‘WMFindInArray’ from incompatible pointer type
../WINGs/WINGs/WUtil.h:455: note: expected ‘int (*)(void *, void *)’ but argument is of type ‘int (*)(const void *, const void *)’
but induces others in other places. One of them was this one
window.c: In function ‘wManageWindow’:
window.c:782: warning: passing argument 2 of ‘WMFindInArray’ from incompatible pointer type
../WINGs/WINGs/WUtil.h:455: note: expected ‘int (*)(const void *, const void *)’ but argument is of type ‘int (*)(void *, void *)’
which is fixed by constifying the arguments of matchIdentifier(). The other warnings are
fixed similarly.
remove the choice of atomic/non-atomic writes. firstly, the only users
of non-atomic writes were getstyle and geticonset; secondly, who in their
right minds would ever want non-atomic writes; thirdly, the file system
will screw you anyway *G*.
...which creates directory hierarchies under $GNUSTEP_USER_ROOT
- make WMWritePropListToFile() use this
readily solves the "run dialog history vs nonexistent state dir" case.
if other consumers are found for this, just de-static and move the
prototype to WUtil.h or some other appropriate place.
This patch modifies the linking of the WINGs libraries
to create a shared library. wmaker used to do this, but
it was dropped around wmaker-0.90/0.91.
The shared .so library is needed when compiling and running
the wdm display manager and any other programs which link
to libWINGs.
Submitted by: Gilbert Ashley
Origin: ALT/Sisyphus Linux
The man page of XChangeProperty() says:
"If the specified format is 32, the property data must be a
long array."
And as we call it with format 32, the type of 'data' must
be 'long'. It happens to work nowadays in 32-bit architectures
because sizeof(CARD32) = sizeof(long), but that is no longer
true in 64-bit mode.
This patch was downloaded from
www.openbsd.org/cgi-bin/cvsweb/ports/x11/windowmaker/patches/patch-WINGs_wwindow_c
and I thank Alexey I. Frolov and Vladimir Nadvornik for helping me
to understand it on a wmaker-dev thread.
This patch adds history to some dialog boxes. To use it replace %a with
%A in menu file (like in "Run..." menu item). You can specify third
parameter to %A to use different histories for differen dialogs.
All history files is kept in ~/GNUstep/.AppInfo/WindowMaker/ and the number of
history lines controlled by DialogHistoryLines parameter (one for
all dialogs) defaults to 500 lines.
It also adds Tab completion.
Origin: ALT/Sisyphus Linux, Alexey Voinov <voins@altlinux.ru>
These are some of the fixes sent to the wmaker-dev list by
Vladimir Nadvornik, with minor modifications to address Dan
Pascu's concerns.
Original-post: http://lists.windowmaker.info/dev/msg00293.html
wtokenfree() does not free the first entry of an array.
If count is 1 then
while (--count)
will be
while (0)
and the inner body of that while-loop will not be entered.
Therefore a memory leak happens every time wtokenfree() is called.
Retrieved-from: http://paldium.homeunix.org/tobias/wmaker/patches/
[crmafra: This patch, altough correct, breaks WPrefs.app, which will be
fixed by the next patch. ]
Problems:
1.
During expansion of path, the resulting path can overflow the supplied
area of PATH_MAX+2 (buffer as well as buffer2). A tampered environment
variable can be used to modify program flow.
Proof:
[note: wmaker has been compiled with propolice]
$ export A="[tested with 4096x A]"
$ GNUSTEP_USER_ROOT="\$A\$A/\$A/\$A/" wmaker --for-real
*** stack smashing detected ***: wmaker terminated
Aborted
2.
Way too many functions handle a return value of NULL for wexpandpath
improperly, resulting in segfaults (and maybe other problems). To
prove the existance of these issues:
Proof:
$ GNUSTEP_USER_ROOT=~nouser wmaker --for-real
wmaker error: could not get password entry for user nouser: Success
Segmentation fault
Solution:
hard exit with error message about what is going on.
3.
The improper parsing of environment variables can lead to expansion
of path names that were not intended to be expanded.
(a) If a string like "$(var" is found, Window Maker tries to expand "var"
(environment variable) although the syntax is wrong.
Proof:
$ export PROOF=foo
$ GNUSTEP_USER_ROOT=/\$\(PROOF wmaker --for-real
wmaker warning: could not find user GNUstep directory (/foo/Defaults/WindowMaker).
(b) If the variable out of a) cannot be resolved, a closing bracket will be
added.
Proof:
$ unset PROOF
$ GNUSTEP_USER_ROOT=/\$\(PROOF wmaker --for-real
./wmaker warning: could not find user GNUstep directory ($(PROOF)/Defaults/WindowMaker).
Author: Tobias Stoeckmann
Retrieved-from: http://paldium.homeunix.org/tobias/wmaker/
Submitted-by: Gilbert Ashley <amigo@ibiblio.org>
for arq in `git ls-files *.c`; do
echo $arq;
indent -linux -l115 $arq;
done
The different line break at 115 columns is because
I use a widescreen monitor :-)
This patch addresses this warning of gcc:
wfontpanel.c: In function 'listFamilies':
wfontpanel.c:588: warning: missing sentinel in function call
Fix it by using the 'NULL' pointer instead of 0 (zero) as the
sentinel.
For more information, see
http://www.linuxonly.nl/docs/2/2_GCC_4_warnings_about_sentinels.html
in particular,
"On most systems, there is no difference between 0 and (char *)0.
On 64 bit systems, however, the integer 0 is 32 bits and the
pointer 0 is 64 bits. The compiler does not know whether it is
an integer or a pointer, and defaults for the integer. This will
not clear the upper 32 bits and the function will not stop
scanning its parameters."
Note that here in my 64-bit Mandriva I don't need to cast (char *)NULL.
There may be issues with running applications in 64-bit mode when
they were written with tacit assumptions about 32-bit platforms.
For example,
* Assuming that a pointer can be cast back and forth to an integer
The reason is that the size of the integer and pointer may be different.
See the description of "[PATCH] Warn when casting a pointer (constant)
to an integer of different size." in the gcc mailing list
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01881.html
where it was also suggested the use of casts to uintptr_t. This is
what this patch does.
As a result the following warnings are fixed, leaving us with an
almost warning-free compilation in 64-bit platforms:
defaults.c:1446: warning: cast to pointer from integer of different size
defaults.c:1457: warning: cast to pointer from integer of different size
defaults.c:1471: warning: cast to pointer from integer of different size
defaults.c:1486: warning: cast to pointer from integer of different size
icon.c:67: warning: cast from pointer to integer of different size
menu.c:112: warning: cast from pointer to integer of different size
switchmenu.c:452: warning: cast from pointer to integer of different size
window.c:140: warning: cast from pointer to integer of different size
window.c:2217: warning: cast to pointer from integer of different size
workspace.c:135: warning: cast to pointer from integer of different size
workspace.c:214: warning: cast to pointer from integer of different size
workspace.c:634: warning: cast to pointer from integer of different size
workspace.c:1330: warning: cast to pointer from integer of different size
workspace.c:1514: warning: cast to pointer from integer of different size
wfilepanel.c:135: warning: cast from pointer to integer of different size
wfilepanel.c:171: warning: cast from pointer to integer of different size
wfontpanel.c:499: warning: cast to pointer from integer of different size
wfontpanel.c:500: warning: cast to pointer from integer of different size
wfontpanel.c:505: warning: cast to pointer from integer of different size
wfontpanel.c:506: warning: cast to pointer from integer of different size
wfontpanel.c:776: warning: cast from pointer to integer of different size
wfontpanel.c:777: warning: cast from pointer to integer of different size
wfontpanel.c:877: warning: cast from pointer to integer of different size
wfontpanel.c:878: warning: cast from pointer to integer of different size
wpanel.c:363: warning: cast from pointer to integer of different size
fontl.c:42: warning: cast from pointer to integer of different size
fontl.c:42: warning: cast from pointer to integer of different size
fontl.c:42: warning: cast from pointer to integer of different size
fontl.c:90: warning: cast to pointer from integer of different size
puzzle.c:138: warning: cast from pointer to integer of different size
puzzle.c:225: warning: cast to pointer from integer of different size
wtableview.c:1031: warning: cast to pointer from integer of different size
wtableview.c:1067: warning: cast to pointer from integer of different size
wtableview.c:1069: warning: cast to pointer from integer of different size
wtableview.c:1074: warning: cast to pointer from integer of different size
wtabledelegates.c:234: warning: cast from pointer to integer of different size
wtabledelegates.c:250: warning: cast from pointer to integer of different size
wtabledelegates.c:265: warning: cast from pointer to integer of different size
wtabledelegates.c:287: warning: cast to pointer from integer of different size
wtabledelegates.c:351: warning: cast from pointer to integer of different size
wtabledelegates.c:372: warning: cast from pointer to integer of different size
wtabledelegates.c:393: warning: cast from pointer to integer of different size
wtabledelegates.c:410: warning: cast to pointer from integer of different size
test.c:44: warning: cast from pointer to integer of different size
test.c:47: warning: cast to pointer from integer of different size
test.c:55: warning: cast from pointer to integer of different size
test.c:58: warning: cast from pointer to integer of different size
This patch adds the --disable-verbose-compile switch to the
configure script.
When this option is used it reduces the verbosity of compilation
messages to the essential. However compiler warnings are not affected
and thus gain visibility by not standing in the middle of a storm
of other messages.
In summary, the compilation messages are reduced to a stream of
CC array.o
CC bagtree.o
CC configuration.o
CC connection.o
CC data.o
[...]
instead of a mind-boggling flux of
gcc -DHAVE_CONFIG_H -I. -I../src -I../WINGs/WINGs -I../wrlib -I../src
-I/usr/include/freetype2 -I/usr/local/include
-DLOCALEDIR=\"/usr/local/lib/loca\"/usr/local/share/WINGs\"
-DDEBUG -fno-strict-aliasing -g -O2 -c array.c
gcc -DHAVE_CONFIG_H -I. -I../src -I../WINGs/WINGs
-I../wrlib -I../src -I/usr/include/freetype2 -I/usr/local/include
-DLOCALEDIR=\"/usr/local/lib/loca\"/usr/local/share/WINGs\"
-DDEBUG -fno-strict-aliasing -g -O2 -c bagtree.c
[...]
