portability of function prototypes?
i am seeing constructs like this at
several locations of the XFree86 sources:
*.h:
extern char *Xpermalloc(
#if NeedFunctionPrototypes
unsingend int /* size */
#endif
);
*.c:
char *Xpermalloc(unsigned int length)
{ ... }
#if NeedFunctionPrototypes
XrmQuark XrmStringToQuark(
_Xconst char *name)
#else
XrmQuark XrmStringToQuark(name)
XrmString name;
#endif
{ ... }
for my impression the applied macro check
is obsolete nowadays and should not used
any longer for current coding. the phrase
inside the first #if #endif is a needed one.
i think for the second one the if-case is
probably the prefered coding style whilst
the else-case is the obsolete coding style.
am i right? this is a pure leftover?
or am i wrong and some targets do still
have some heavy dependencys on that?
are there some coding guidlines somewhere
in the tree that do outline on that subject?
i am personally targetting on compatible
coding and avoiding breakage of other codes.
-Alex.
PS: i am hoping for a response of some long term
XFree86 developer to answer this.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: portability of function prototypes?
Alexander Stohr wrote (in a message from Saturday 12)
i am seeing constructs like this at
several locations of the XFree86 sources:
*.h:
extern char *Xpermalloc(
#if NeedFunctionPrototypes
unsingend int /* size */
#endif
);
*.c:
char *Xpermalloc(unsigned int length)
{ ... }
#if NeedFunctionPrototypes
XrmQuark XrmStringToQuark(
_Xconst char *name)
#else
XrmQuark XrmStringToQuark(name)
XrmString name;
#endif
{ ... }
for my impression the applied macro check
is obsolete nowadays and should not used
any longer for current coding. the phrase
inside the first #if #endif is a needed one.
i think for the second one the if-case is
probably the prefered coding style whilst
the else-case is the obsolete coding style.
am i right? this is a pure leftover?
or am i wrong and some targets do still
have some heavy dependencys on that?
are there some coding guidlines somewhere
in the tree that do outline on that subject?
i am personally targetting on compatible
coding and avoiding breakage of other codes.
This is a leftover from the times where X could get compiled on
non-ansi compiler. Since X11R6.3 an ANSI C compiler is needed.
There's no reason to use this in new code.
We are removing them slowly, whenever a file that still use them
is edited.
Matthieu
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: portability of function prototypes?
Alexander Stohr wrote:
i am seeing constructs like this at
several locations of the XFree86 sources:
[Constructs deleted]
{ ... }
[sane rationale deleted]
-Alex.
PS: i am hoping for a response of some long term
XFree86 developer to answer this.
I shouldn't pose as an XFree86 developer, since I'm not one, but in a
previous life I've been a porting engineer, and I've come across this
sort of nonsense before. Commercial enterprises strive to ensure
backwards compatibility, yea unto the ancient compiler, and the dusty
video card. At some point you have to force the new. Code for ANSI,
and the compiler gremlins will quiet their chatter -- there are subtle
stack alignment errors written into the C standards -- there be dragons.
Tony.
--
quis custodiet ipsos custodes? -- Juvenal VI, 347-8
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] Advice on Learning X from the Developer Point of View
You'll probably get more advice of this sort on [EMAIL PROTECTED] than on [EMAIL PROTECTED] Randy Kramer wrote: I've found the documentation under /xdev/xc/doc/specs/Xserver. Some of the documents end in .doc (XprtIX.doc XprtTOC.doc). I've tried to open them in a Open Office 1.0.1 (oowriter), Word 97, and Word 6 (for Windows (the Word that came with what I call Office95, the predecessor of Office97). No luck, but the files do look vaguely like they might be word files. Anyone know what I can use to read them? They are probably FrameMaker documents. However, alternative versions (normally postscript) should be available in the tree, along with PDF versions posted at http://www.x-docs.org/ and printed versions sold by Digital Press. And I'm starting to read: * ddx.tbl.ms -- Definition of the Porting Layer for the X v11 Sample Server -- I think -- I'm reading it in nedit and see all the raw formatting codes like .TL (is that nroff or groff -- is there something better to read the stuff in?) nroff -ms or groff -ms should help produce formatted copies, or you can read the PDF's at the above mentioned site that already translated them. I also did some grepping through the code. One purpose was to try to find the main() representing the start of code for the X server. Can anybody tell me what file to start in? The Xserver itself is in xc/programs/Xserver main() is in dix/main.c under that. The dix directory is the OS-independent, device-independent code - most of the core protocol handling is in there. The OS-dependent, device independent code is in os - things like networking, the select() loop, etc. (OS in this case is generalized to any POSIX-ish/UNIX-ish OS.) The device dependent bits are under hw - all the video card input device drivers (actually user space modules, not kernel level drivers) are in there. Xext contains the code to most of the extensions to the server, except for those so large/complex or otherwise special enough to get their own subdirectory (xkb, render, lbx, etc.). I also grepped for files in the tree that contained kbd or keyboard -- the programs that I found (like kbd.c) seemed to be mainly for setting up the keyboard rather then actually doing anything with keyboard events -- I really wanted to find where the keyboard events are created and/or sent to the X client. xc/programs/Xserver/xkb is where much of that occurs. Are any tools like ctags, bonzai (whatever that is), Leo, or something similar used by X developers (and available to might be developers)? I find cscope very useful for tracking through the sources. (I normally use the version bundled with Sun's commerical compilers, but I understand SCO opensourced the original ATT version at http://cscope.sourceforge.net/ I haven't tried it, but it looks very similar from the web pages.) -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - Sun Software Group Quality, Integration, Customer Success (QICS) Platform Globalization Engin. - X11 Engineering ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
