RE: ansifying xwininfo.c
This is the minimum work to get this program into ansi shape. This patch is ready for inclusion. If their are no objections to the patch, it would be very nice to get this in ASAP. It will make some other projects I am working on go smoother. Thanks, Warren Turkal i have no reason to object to such patches. it was done in 100 kB sized tarballs for the XFree86 tree in the past and worked well that way. having such extern statements in a single header file is a major point of getting interfaces verfied on any platform at compile time (if the compiler is not tuned to react like dead beef). compilers like the intel c for linux do even provide switches to make functions either static or requiering an extern prototype thus giving you no choice to miss any indecisive variant. go on with such things, you will be suprised how many points for improvment you can find even without any big sense for the project as a whole. thise could be a simple entry point for future dri coders. -Alex. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: ansifying xwininfo.c
Alexander Stohr wrote: i have no reason to object to such patches. it was done in 100 kB sized tarballs for the XFree86 tree in the past and worked well that way. So who applies these patches then? I don't have CVS write, nor do I want it at this point. Warren Turkal -- President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ansifying xwininfo.c
Warren Turkal wrote: Here is a patch ansifying xwininfo.c. I diffed the executable after the changes to the executable from before the changes, and they were the same. I have opened a bug report at http://bugzilla.xfree86.org/show_bug.cgi?id=677 Warren Turkal -- President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ansifying xwininfo.c
On Tue, 9 Sep 2003, Warren Turkal wrote: Thomas Dickey wrote: while I'm perfectly aware that extern is redundant, there are two things to be said in favor of keeping it: a) it's easy to grep for sure b) some compilers silently ignore conflicts with a static definition of the prototype, but can be persuaded to warn if the extern is explicit. (gcc does this, making it unsuitable as the only compiler to use for testing). also - extern prototypes really should be moved to a header file, otherwise they're not effective at flagging mismatches between different files.. All of the extern functions were defined in the file. These appear to be functions only useful to xwininfo. Why make a header for a one *.c program? I was offering general advice - most of the files in the X tree have a' mixture of extern/static prototypes. If a function's not used outside a given file, there's no reason to mark it extern... -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ansifying xwininfo.c
Thomas Dickey wrote (in a message from Tuesday 9) On Tue, 9 Sep 2003, Warren Turkal wrote: -#if NeedFunctionPrototypes -extern void scale_init(void); -extern char *nscale(int, int, int, char *); while I'm perfectly aware that extern is redundant, there are two things to be said in favor of keeping it: a) it's easy to grep for b) some compilers silently ignore conflicts with a static definition of the prototype, but can be persuaded to warn if the extern is explicit. (gcc does this, making it unsuitable as the only compiler to use for testing). ... and a 3rd reason is that 'extern' is not optional for variables. Most traditional Unix linkers will allow the same variable to be declared without 'extern' in multiple object files and merge them into only one, but this behaviour is not a feature one should rely on. And it fact, at least the Darwin linker treats this as an error. Doing the same for functions is more consistent. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ansifying xwininfo.c
On Tue, 9 Sep 2003, Matthieu Herrb wrote: ... and a 3rd reason is that 'extern' is not optional for variables. Most traditional Unix linkers will allow the same variable to be declared without 'extern' in multiple object files and merge them into only one, but this behaviour is not a feature one should rely on. And it fact, at least the Darwin linker treats this as an error. true - most do, though the nicer ones warn about it (IRIX64 and Tru64, iirc). I've been burned occasionally by code that relies on the common linkage, and have used one of gcc's options to warn about it (-Xlink -warn-common). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ansifying xwininfo.c
On Tue, 9 Sep 2003 21:57:23 +0200, Matthieu Herrb wrote:
Thomas Dickey wrote (in a message from Tuesday 9)
On Tue, 9 Sep 2003, Warren Turkal wrote:
-#if NeedFunctionPrototypes
-extern void scale_init(void);
-extern char *nscale(int, int, int, char *);
while I'm perfectly aware that extern is redundant, there are two
things to be said in favor of keeping it:
a) it's easy to grep for
b) some compilers silently ignore conflicts with a static definition of
the prototype, but can be persuaded to warn if the extern is explicit.
(gcc does this, making it unsuitable as the only compiler to use for
testing).
... and a 3rd reason is that 'extern' is not optional for
variables.
Wrong.
Most traditional Unix linkers will allow the same variable
to be declared without 'extern' in multiple object files and merge
them into only one, but this behaviour is not a feature one should
rely on. And it fact, at least the Darwin linker treats this as an
error.
If so, then the Darwin linker is defective. ISO Standard C variables do NOT
require the extern modifier in order to have external linkage. A variable
at file scope without an initializer is automatically extern.
file_1.c
#include stdio.h
int xxx;
int main()
{
printf( xxx is %d\n, xxx );
return 0;
}
file_2.c
int xxx = 8;
Those two files comprise an ANSI/ISO compliant C program which produces a
well-defined result. A compiler which fails to compile this is not ISO
compliant.
--
- Tim Roberts, [EMAIL PROTECTED]
Providenza Boekelheide, Inc.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: ansifying xwininfo.c
Thomas Dickey wrote: If a function's not used outside a given file, there's no reason to mark it extern... This is the minimum work to get this program into ansi shape. This patch is ready for inclusion. If their are no objections to the patch, it would be very nice to get this in ASAP. It will make some other projects I am working on go smoother. Thanks, Warren Turkal -- President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
