libDtHelp is unable to read SDL help files
with -ftree-store-ccp optimization which
is enabled by -O2 on gcc 4.2.1.
GifUtils.c and decompress.c didn't work
properly with -ftree-store-ccp enabled.
GifUtils.c was repaired by fixing
those warnings:
GifUtils.c: In function 'create_pixmap':
GifUtils.c:1093: warning: return makes integer from pointer without a cast
GifUtils.c:1110: warning: return makes integer from pointer without a cast
GifUtils.c:1215: warning: return makes integer from pointer without a cast
GifUtils.c: In function 'gif_to_pixmap':
GifUtils.c:1242: warning: return makes integer from pointer without a cast
decompress.c didn't generate warnings, but the
only effect of the -ftree-store-cpp was to introduce
this change:
addq $1, %rax
movq %rax, (%rbx)
.L90:
- cmpl $157, %edx
+ cmpl $-99, %edx
jne .L86
movl 8(%rbx), %eax
subl $1, %eax
Which corresponds to this source code:
bufioI.h
57 #define BufFileGet(f) ((f)->left-- ? *(f)->bufp++ : (*(f)->io) (f))
42 int (*io)(/* BufFilePtr f */);
decompress.c
53 #ifdef NO_UCHAR
54 typedef char char_type;
55 #else
56 typedef unsigned char char_type;
57 #endif /* UCHAR */
58
59 static char_type magic_header[] = { "\037\235" }; /* 1F 9D */
131 if ((BufFileGet(f) != (magic_header[0] & 0xFF)) ||
132 (BufFileGet(f) != (magic_header[1] & 0xFF)))
133 {
134 return 0;
135 }
BufFileGet() returns (int), so the (unsigned char) constants
got promoted to (int) with sign extension; therefore constant
157 decimal (0x9D) became -99 decimal, sign extended
(0xffffff9D), and the comparison was always false.
Tested using:
$ gcc -v
Using built-in specs.
Target: amd64-undermydesk-freebsd
Configured with: FreeBSD/amd64 system compiler
Thread model: posix
gcc version 4.2.1 20070831 patched [FreeBSD]
Running on:
FreeBSD 10.0-CURRENT (r240948M)
built Wed Sep 26 23:33:08 CEST 2012
dtcreate crashed on 64-bit system when clicking
"Find Set.." button.
Crash happens in libXm:
new_w=0x805db4300, args=0x7fffffffb430, num_args=0x7fffffffb3dc)
at Form.c:1955
$1 = {att = {{type = 4 '\004', w = 0x805db3700, percent = 0, offset = 0,
value = 0, tempValue = 0}, {type = 1 '\001', w = 0x0, percent = 0,
offset = 10, value = 0, tempValue = 0}, {type = 3 '\003',
w = 0x805db3700, percent = 0, offset = 0, value = 0, tempValue = 0}, {
type = 3 '\003', w = 0x800000000, percent = 0, offset = 10, value = 0,
tempValue = 0}}, next_sibling = 0x0, sorted = 0 '\0',
resizable = 1 '\001', preferred_width = 0, preferred_height = 0}
(...)
at icon_selection_dialog.c:1768
1767 /* Creation of icon_scrolled_win */
1768 icon_scrolled_win = XtVaCreateManagedWidget( "icon_scrolled_win",
1769 xmScrolledWindowWidgetClass,
1770 icon_selection_dialog,
1771 XmNscrollingPolicy, XmAUTOMATIC,
1772 /* XmNnavigationType, XmTAB_GROUP, */
1773 XmNx, 282,
1774 XmNy, 84,
1775 XmNscrollBarDisplayPolicy, XmAS_NEEDED,
1776 XmNrightOffset, 10,
1777 XmNrightAttachment, XmATTACH_FORM,
1778 XmNtopOffset, 0,
1779 XmNtopWidget, icon_container_label,
1780 XmNtopAttachment, XmATTACH_WIDGET,
1781 XmNleftOffset, 0,
1782 XmNleftWidget, icon_container_label,
1783 XmNleftAttachment, XmATTACH_OPPOSITE_WIDGET,
1784 XmNbottomOffset, 10,
1785 XmNbottomWidget, XmATTACH_NONE,
1786 XmNbottomAttachment, XmATTACH_WIDGET,
1787 NULL );
What happens here is that ConstraintInitialize receives
four constraints, the last one is this:
{ type = 3 '\003', /* XmATTACH_WIDGET */
w = 0x800000000, /* malformed XmATTACH_NONE ???
percent = 0,
offset = 10, /* specified as XmNbottomOffset */
value = 0,
tempValue = 0}
XmATTACH_* values are defined in <Xm/Xm.h> as follows:
505 enum{ XmATTACH_NONE, XmATTACH_FORM,
506 XmATTACH_OPPOSITE_FORM, XmATTACH_WIDGET,
507 XmATTACH_OPPOSITE_WIDGET, XmATTACH_POSITION,
508 XmATTACH_SELF
509 } ;
What is not clear to why XmATTACH_NONE - which should be (int)0 -
becomes 0x800000000 - looks like a 64 bit bug somewhere.
Providing a long value on None (0L) as in this change fixes the
problem.
I understand is that it possible to use such an "empty" widget
is to create additional space at the bottom of the newly created
"icon_scrolled_win".
What needs to be clarified - shouldn't be such an (int) value be
automatically promoted to (long) (or XtArgVal, XtPointer, ...)
and preserve the value 0? Lots of parameters seem to be
passed as ints (for example dimensions) and they do not
appear to cause any trouble.
XmPrivate must be generated manually. For this you work, you must
have a freshly compiled openmotif tree, and MLIBSRC must be pointing
to it.
Otherwise, it's possible during the includes phase for an attempt to
be made to regenerate this file, which will fail on the vast majority
of systems out there.
So, to regenerate,
cd include/Xm
rm XmPrivate.h
make XmPrivate.h
- Fix missing prototypes
- Fix some 64-bit related problems (XtVaGetValues)
- Fix crash on dtcreate startup in create_applicationShell1()
- Add XmeFlushIconFileCache() prototype from <Xm/IconFileP.h>
When applying a patch, "git am" strips
trailing whitespace, although they are
present in the git formatted-patch.
This way the committed file will be
slightly different than the file re-generated
by extractprototype.h
It shouldn't hurt, but next run of
extractprototype.h will add trailing spaces
again and the resulting diff on XmPrivate.h
will include more changes than actually
needed.
This may break some viscious circle after
applying the patch, so enabling regeneration
on LinuxArchitecture again.
This patch does not add XmeFlushIconFileCache()
needed by dtcreate.
__rpc_xdr is no longer available on FreeBSD 10.
(XDR is typedef'd as "struct XDR" and not "struct __rpc_xdr").
By the way, why did we ever need this? Probably
it should be removed. Leaving for __OpenBSD__ for now.
This is required by recent changes to the stack protector code in gcc,
generating references to __guard_local instead of __guard, defined in
crtbeginS.o.
This is a temporary solution; strictly speaking, we shouldn't invoke ld
directly at all but use cc instead.
Install black and white and 128-color custom logos for FreeBSD.
The FreeBSD logo based on the artwork provided by The FreeBSD Foundation:
http://www.freebsd.org/logo/logo-basic.png
The mark FreeBSD is a registered trademark of The FreeBSD Foundation
is are used by Common Desktop Enviroment (CDE) with
the permission of The FreeBSD Foundation.
The FreeBSD Logo is a trademark of The FreeBSD Foundation and is used
by Common Desktop Environment (CDE) with the permission of
The FreeBSD Foundation.
Use of logo subject to Trademark Usage Terms and Conditions:
http://www.freebsdfoundation.org/documents/Guidelines.shtml
The following patch gets the Lucida Sans font working on my FreeBSD system. Before applying this, title bars and menu bars are displayed in the "-misc-fixed" font. This is on FreeBSD 9.0-RELEASE-p3.
On Mon, 24 Sep 2012, Jon Trulson wrote:
> On Tue, 25 Sep 2012, Marcin Cieslak wrote:
>
> Applied.
I'm sorry - it turns out this one does not fully
work as expected.
This one is better (it's relative to the old master)
- so it might cause a conflict:
Fixes the following warning:
In file included from ../../../imports/x11/include/X11/Xutil.h:54,
from ../../../imports/x11/include/X11/Intrinsic.h:54,
from Action.c:64:
../../../imports/x11/include/X11/keysym.h:49:1: warning: "XK_MISCELLANY" redefined
<command-line>: warning: this is the location of the previous definition
<keysym.h> which includes all key symbols and loads <keysymdef.h>
is automaticlly included by the X Toolkit.
This patch removes #include <keysymdef.h> whenever not needed,
and adds #define XK_MISCALLANY in the source code where required.
Fix this warning:
RFCTransport.C: In function 'long unsigned int writeToFileDesc(const char*, int,
__va_list_tag*)':
RFCTransport.C:91: warning: 'DtMailBoolean' is promoted to 'int' when passed thr
ough '...'
RFCTransport.C:91: warning: (so you should pass 'int' not 'DtMailBoolean' to 'va
_arg')
RFCTransport.C:91: note: if this code is reached, the program will abort
Having a difficult choice between unplasant
cast to get a void * into an enumeration type
and "Something's wrong here" double cast
I decided for the latter.
At least it does not crash when the legal
value of zero is passed as the argument.
Avoid overwrite of local variables when using
short (int, etc.) types with XtVaGetValues().
Cast XtPointer using (XtArgVal) without
the need to use C99 <stdint.h> and friends.
Fix SIGSEGV because of implicit declaration
of _XmStringUngenerate.
The error message reported to the user was:
TT_ERR_PROCID The process id passed is not valid.
XtArgVal should be a type that encompasses XtPointer
and long integer types. In the X.org implementation
it is currently defined as (long).
Don't use (unsigned int *) instead of (Window *).
Use /usr/local/bin/lpq from CUPS for FreeBSD
for now; this prevents immediate dtprintinfo
crash.
In the future we should handle both built-in
/usr/bin/lpq as well as CUPS /usr/local/bin/lpq
output in separate functions.
Code to support CUPS should probably shared between
other operating systems.
When asking for data using XtVaGetValue()
make sure that there is enough place for
the return value (which is sometimes XtPointer).
Providing pointer to (int) is not enough.
Cast XtPointer into requested int types
directly, which unfortunately introduces
compilation warning:
cast from pointer to integer of different size
Add missing prototypes and header files to the dtfile
code in order to move closer towards 64-bit compatibility.
Extract the following functions from Motif internal headers:
_XmGetWidgetExtData
_XmRecordEvent
_XmStringUngenerate
_XmTextFieldSetDestination
_XmGetActiveTopLevelMenu
Extract manually prototypes of the obsolete Motif interface:
_XmHighlightBorder
_XmUnhighlightBorder
Remove XmPrivate.h if extractprototype.awk fails
Make the following header files available via -I:
codelibs/boolean.h
codelibs/pathutils.h
codelibs/shellutils.h
and remove shellutils.h from dtwm directory.
