Time to run source through indent?
Tim, Before I start on anything, how do we want to handle running the source through indent? Jonathan
Jonathan asked,
Before I start on anything, how do we want to handle running the source through indent?
Sorry for the slow response. The dhcp server at swbell was down all day. But wonder of wonders, when it came back I still had the same IP. It's almost like a static IP <grin!> This bodes well in case I need to host a fractint CVS on my own machine. Back to your question. We just need to decide some default settings, and set up indent that way. Someone (Rich?) suggested that there is a GNU style guide somewhere we could follow. I'm not religious about it, but I sure do like consistency. I suggest we throw the floor open for nominations for a set of indent settings, all have a quick looksee, and then adopt them as a standard. Also I'm slowly getting better at using CVS, so may well carry out my long-standing threat to actually set this up. BTW, thanks for all your hard work on the last patch. Tim
In article <3E875190.24724.133BC1@localhost>, "Tim Wegner" <twegner@swbell.net> writes:
Back to your question. We just need to decide some default settings, and set up indent that way. Someone (Rich?) suggested that there is a GNU style guide somewhere we could follow.
See <http://www.gnu.org/prep/standards_23.html#SEC23> The default settings of gnu indent are set to follow the recommendations in that document. -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> izfree: Open source tools for Windows Installer <http://izfree.sourceforge.net>
Rich wrote:
See <http://www.gnu.org/prep/standards_23.html#SEC23>
The default settings of gnu indent are set to follow the recommendations in that document.
Geesh this is too easy! :-) Ok, everybody please check out the default settings of indent. Run some code through it and see if we should adopt that style. If anyone wants a non-default tweak, just suggest it and make a case for it. Tim
On Sunday 30 March 2003 09:42 pm, Tim Wegner wrote:
Geesh this is too easy! :-)
Ok, everybody please check out the default settings of indent. Run some code through it and see if we should adopt that style. If anyone wants a non-default tweak, just suggest it and make a case for it.
I believe the only option I would add is -nut, to force the use of spaces instead of tabs. Jonathan
In article <200303311915.09465.osuchj@avalon.net>, Jonathan Osuch <osuchj@avalon.net> writes:
I believe the only option I would add is -nut, to force the use of spaces= =20 instead of tabs.
Yeah, that's a good idea. -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> izfree: Open source tools for Windows Installer <http://izfree.sourceforge.net>
Has anyone tried to compile with OpenWatcom lately? I'm trying to compile the allegro branch, and I'm having trouble with type conflicts in parser.c, especially with the array 'FnctList' and its function pointers. It compiles under VS 6.0, but does not with OpenWatcom (32 Bit DOS/4GW-Target, -DDOS -DBIG_ANSI_C). Can anyone comment on this? Thanks, Florian The code that's causing trouble is (gathered from various places, boiled down to show the relevant parts): typedef void _cdecl funct_t(void); funct_t *isfunct(char *Str, int Len); struct FNCT_LIST { char far *s; /* TIW 03-31-91 added far */ /* void (**ptr)(void); */ funct_t** ptr; }; void dStkSin(void) { double sinx, cosx, sinhy, coshy; FPUsincos(&Arg1->d.x, &sinx, &cosx); FPUsinhcosh(&Arg1->d.y, &sinhy, &coshy); Arg1->d.x = sinx*coshy; Arg1->d.y = cosx*sinhy; } void (*StkSin)(void) = dStkSin; struct FNCT_LIST far FnctList[] = { /* TIW 03-31-91 added far */ {s_sin, &StkSin}, ---> above line gives type mismatch
On Sunday 06 April 2003 06:09 am, Florian Kolbe wrote:
typedef void _cdecl funct_t(void);
funct_t *isfunct(char *Str, int Len);
struct FNCT_LIST { char far *s; /* TIW 03-31-91 added far */ /* void (**ptr)(void); */ funct_t** ptr; };
void dStkSin(void) { double sinx, cosx, sinhy, coshy;
FPUsincos(&Arg1->d.x, &sinx, &cosx); FPUsinhcosh(&Arg1->d.y, &sinhy, &coshy); Arg1->d.x = sinx*coshy; Arg1->d.y = cosx*sinhy; }
void (*StkSin)(void) = dStkSin;
struct FNCT_LIST far FnctList[] = { /* TIW 03-31-91 added far */ {s_sin, &StkSin}, ---> above line gives type mismatch
I would have to guess that it is choking on the _cdecl in the typedef of funct_t. In the brief time I've spent trying to compile the source with the djgpp compiler I found that I needed to undefine _cdecl. Jonathan
participants (4)
-
Florian Kolbe -
Jonathan Osuch -
Rich -
Tim Wegner