From: Peter S. <pe...@ja...> - 2003-02-24 09:06:05
|
So, I checked in a bunch of stuff in utils/d2c. It'd be a big help to me if folks on other platforms than Linux with gcc can try the conversion and see if CLISP still builds and checks (modulo the strings test that has been failing since before I started). If you have GNU make and perl on your machine you can do the conversion yourself: cd to utils/d2c and type 'make convert'. It should apply a few patches (in the d2c directory), run a few scripts, and leave you with a src/ directory containing no .d files. Or, if you don't have GNU make or perl, you can grab the tar file from <http://www.gigamonkeys.com/clisp-conversion-patch.tar.gz> and unpack it in the top level of your clisp tree. Note, it's not that small: ~1.5M. In either case, you can then do the normal build dance of ./configure, etc. from the top directory. Please let me know if it works or doesn't and what platform (OS and compiler) you used. All I know right now is it works with gcc 3.2.2. We expect that it will require a c99 compliant compiler. For instance, I know gcc 2.95.x won't work. But any datapoints are useful. WARNING: You'll almost certainly want to make a copy of your CLISP tree to try out this conversion in--for one, the .d files will be deleted as part of the converios (replaced by .c files) so if you have any changes in progress you'll have a hard time getting back to something that you can check in. The 'make convert' process will leave a bunch of intermedate phases of the conversion in src/. From the d2c directory you can type 'make clean-up' to get rid of them. Of particular interest are the *.indent-errors files. During the conversion I run all the source through GNU's indent program. But some of the files confuse it enough that we can't use the output. Any file that has a corresponding .indent-errors file after 'make convert' has this problem and will not be nicely indented. -Peter -- Peter Seibel pe...@ja... |
From: Arseny S. <am...@ic...> - 2003-02-24 13:38:15
|
Hello Peter, I have made conversion in cygwin enviroinment. There was a complain about unclosed '[' and a lot of ident-errors files all with the following message: 'indent: unknown option "-ppi2"'. The C files produced aren't compilable in MSVC - a lot of syntax errors appears, all of what I could check - about declarations in the middle of function body. Cygwin's gcc 3.2 compiles lisp.exe ok (but still get sigsegv making interpreted.mem). That's a piece of output about unclosed '[' patching file `src/configure.in' patching file `src/clisp-link.in' patching file `src/configure' cd ../../src; \ for f in *.d; do \ cp $f $f.PHASE-3; \ cat $f.PHASE-3 | /cygdrive/d/clisp-cvs/clisp2c/utils/d2c/ansidecl > `basename $f .d`.c; \ rm -f $f; \ done unclosed '[' in line 1974 unclosed '[' in line 1974 cd ../../src; \ for f in *.d.ORIG; do \ -- Best regards, Arseny |
From: Sam S. <sd...@gn...> - 2003-02-24 14:39:17
|
> * In message <483...@ic...> > * On the subject of "Re: Big .d -> .c checkin." > * Sent on Mon, 24 Feb 2003 23:40:59 +1000 > * Honorable Arseny Slobodjuck <am...@ic...> writes: > > The C files produced aren't compilable in MSVC - a lot of syntax > errors appears, all of what I could check - about declarations in the > middle of function body. does this mean that MSVC is not C99-compliant? maybe there is a switch that will tell MSVC to be C99-compliant? -- Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> UNIX is a way of thinking. Windows is a way of not thinking. |
From: Peter S. <pe...@ja...> - 2003-02-24 17:10:36
|
Arseny Slobodjuck <am...@ic...> writes: > Hello Peter, > > I have made conversion in cygwin enviroinment. There was a complain > about unclosed '[' That's normal--it's from ansidecl and I couldn't figure out what it was really about but it didn't seem to do any damage. > and a lot of ident-errors files all with the following message: > 'indent: unknown option "-ppi2"'. Hmmm. Sounds like maybe you have an older version of indent than me. Can you try grabbing 2.2.9 from <ftp://ftp.gnu.org/gnu/indent/> and seeing if that doesn't fix most of the indent problems. (Most of the errors that I get are about 'unmatched else' due to various complex CPP macros.) > The C files produced aren't compilable in MSVC - a lot of syntax > errors appears, all of what I could check - about declarations in > the middle of function body. So that definitely sounds like lack of c99 compliance. Maybe--as Sam suggested--there's some flag you need to pass to the compiler (or maybe try compiling as C++, if that's possible.) Thanks for giving it a whirl. -Peter -- Peter Seibel pe...@ja... |
From: Arseny S. <am...@ic...> - 2003-02-25 14:20:43
|
Hello Peter, Tuesday, February 25, 2003, 3:09:49 AM, you wrote: >> and a lot of ident-errors files all with the following message: >> 'indent: unknown option "-ppi2"'. > Hmmm. Sounds like maybe you have an older version of indent than me. > Can you try grabbing 2.2.9 from <ftp://ftp.gnu.org/gnu/indent/> and > seeing if that doesn't fix most of the indent problems. (Most of the > errors that I get are about 'unmatched else' due to various complex > CPP macros.) I had ver 2.2.7 then 2.2.8. Seems that only version 2.2.9 supports -ppi. Well, I have installed it, reconverted sources and you know, I like nonindented files more. >> The C files produced aren't compilable in MSVC - a lot of syntax >> errors appears, all of what I could check - about declarations in >> the middle of function body. > So that definitely sounds like lack of c99 compliance. Maybe--as Sam > suggested--there's some flag you need to pass to the compiler (or > maybe try compiling as C++, if that's possible.) Seems that there's no such flag. If 99 in c99 stands for 'year' then it's explanable - MSVC 6.0 released in 1998 AFAIK. I believe that if it's really necessary to compile by C99 compiler, sources can be changed to compile in C++ mode of VC. I'm not sure how much effort it will take however. -- Best regards, Arseny |
From: Peter S. <pe...@ja...> - 2003-02-25 18:42:40
|
Arseny Slobodjuck <am...@ic...> writes: > Hello Peter, > > Tuesday, February 25, 2003, 3:09:49 AM, you wrote: > > >> and a lot of ident-errors files all with the following message: > >> 'indent: unknown option "-ppi2"'. > > > Hmmm. Sounds like maybe you have an older version of indent than me. > > Can you try grabbing 2.2.9 from <ftp://ftp.gnu.org/gnu/indent/> and > > seeing if that doesn't fix most of the indent problems. (Most of the > > errors that I get are about 'unmatched else' due to various complex > > CPP macros.) > > I had ver 2.2.7 then 2.2.8. Seems that only version 2.2.9 supports > -ppi. Well, I have installed it, reconverted sources and you know, I > like nonindented files more. Heh. Well, Sam expressed a preference for having the source in K&R format so I guess you can take it up with him. (Unless indent is somehow doing things wrong--I took a quick look at the output but not a careful audit of all the source.) > >> The C files produced aren't compilable in MSVC - a lot of syntax > >> errors appears, all of what I could check - about declarations in > >> the middle of function body. > > > So that definitely sounds like lack of c99 compliance. Maybe--as > > Sam suggested--there's some flag you need to pass to the compiler > > (or maybe try compiling as C++, if that's possible.) > > Seems that there's no such flag. If 99 in c99 stands for 'year' then > it's explanable - MSVC 6.0 released in 1998 AFAIK. I believe that if > it's really necessary to compile by C99 compiler, sources can be > changed to compile in C++ mode of VC. I'm not sure how much effort > it will take however. Hmmm. Well, if you're bored and have some time to play around with it, let me know what you find out. I don't have access to MSVC so there's no way for me to figure it out (without spending X hundreds of dollars *and* hijacking my wife's windows machine.) -Peter -- Peter Seibel pe...@ja... |
From: Sam S. <sd...@gn...> - 2003-02-26 00:25:55
|
Peter, I am impressed with your work! > * In message <m3vfz8yzgx.fsf@localhost.localdomain> > * On the subject of "Re: Re[2]: Big .d -> .c checkin." > * Sent on 25 Feb 2003 10:41:50 -0800 > * Honorable Peter Seibel <pe...@ja...> writes: > > > Well, I have installed it, reconverted sources and you know, I > > like nonindented files more. Arseny, what did _you_ dislike? > Heh. Well, Sam expressed a preference for having the source in K&R > format so I guess you can take it up with him. (Unless indent is > somehow doing things wrong--I took a quick look at the output but not > a careful audit of all the source.) hmm... I looked at sequence.c and stream.c produced by "make convert". 1. the header for stream.c is not in the fancy /* * */ format (which is not surprising). Is it possible to treat the first comment in a file specially? 2. when the definition is a valid declaration, there is no point in keeping the declaration around, i.e., in static void copy_seqpart_into(void); static void copy_seqpart_into(void) { ... } the first line should go. 3. in #defines, comments are converted to #define pointer_fe_update(pointer,sequence,typdescr) \ { object updatefun = seq_fe_upd(typdescr); \ pushSTACK(sequence); /* sequence */\ pushSTACK(*(&(pointer) STACKop 1)); /* pointer */\ funcall(updatefun,2); /* (SEQ-FE-UPD sequence pointer) */\ pointer = value1; /* =: pointer */\ } while I would exopct to see #define pointer_fe_update(pointer,sequence,typdescr) \ { object updatefun = seq_fe_upd(typdescr); \ pushSTACK(sequence); /* sequence */ \ pushSTACK(*(&(pointer) STACKop 1)); /* pointer */ \ funcall(updatefun,2); /* (SEQ-FE-UPD sequence pointer) */ \ pointer = value1; /* =: pointer */ \ } 4. #ifdefs are not indented: if (!boundp(STACK_1) #ifdef X3J13_149 || nullp(STACK_1) #endif ) { /* end not supplied -> set end:=(length sequence ): */ should be if (!boundp(STACK_1) # ifdef X3J13_149 || nullp(STACK_1) # endif ) { /* end not supplied -> set end:=(length sequence ): */ 5. the following conversion: until (eq(STACK_2,Fixnum_0)) # count (ein Integer) = 0 -> Ende { # (SEQ-ACCESS seq pointer1) bilden: to while (!(eq(STACK_2, Fixnum_0))) { /* count (ein Integer) = 0 -> Ende *//* (SEQ-ACCESS seq pointer1) bilden: */ is not nice. it should be while (!(eq(STACK_2, Fixnum_0))) { /* count (ein Integer) = 0 -> Ende */ /* (SEQ-ACCESS seq pointer1) bilden: */ 6. there are some indentation violations: { uintL len = posfixnum_to_L(value1); /* len */ /* Grundidee: Um eine Sequence mit len Elementen umzudrehen, muessen der linke und der rechte Block mit je floor(len/2) Elementen vertauscht und dann einzeln umgedreht werden (rekursiv!); das mittlere Element (bei ungeradem len) bleibt unveraendert. Entrekursivierter Algorithmus: Fuer j=0,1,2,... sind 2^j mal zwei (fast) adjazente Bloecke der Laenge k2=floor(len/2^(j+1)) zu vertauschen. */ uintL j = 0; /* j := 0 */ uintL k = len; /* k = floor(len/2^j) := len */ there are probably more... > > >> The C files produced aren't compilable in MSVC - a lot of syntax > > >> errors appears, all of what I could check - about declarations in > > >> the middle of function body. > > > > > So that definitely sounds like lack of c99 compliance. Maybe--as > > > Sam suggested--there's some flag you need to pass to the compiler > > > (or maybe try compiling as C++, if that's possible.) > > > > Seems that there's no such flag. If 99 in c99 stands for 'year' then > > it's explanable - MSVC 6.0 released in 1998 AFAIK. I believe that if > > it's really necessary to compile by C99 compiler, sources can be > > changed to compile in C++ mode of VC. I'm not sure how much effort > > it will take however. > > Hmmm. Well, if you're bored and have some time to play around with it, > let me know what you find out. I don't have access to MSVC so there's > no way for me to figure it out (without spending X hundreds of dollars > *and* hijacking my wife's windows machine.) It is crucial that these changes do not break the woe32 build. Arseny, can you build CLISP with MSVC in C++ mode? what about mingw? does it come with gcc 3.2 now? -- Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> If it has syntax, it isn't user friendly. |
From: Peter S. <pe...@ja...> - 2003-02-26 01:14:30
|
Sam Steingold <sd...@gn...> writes: > Peter, I am impressed with your work! Thanks. > hmm... > I looked at sequence.c and stream.c produced by "make convert". > > 1. the header for stream.c is not in the fancy > /* > * > */ > format (which is not surprising). Is it possible to treat the first > comment in a file specially? Almost certainly. > > 2. when the definition is a valid declaration, there is no point in > keeping the declaration around, i.e., in > > static void copy_seqpart_into(void); > static void copy_seqpart_into(void) > { > ... > } > > the first line should go. Yeah. I was going to do some experiments with protoize/unprotoize to see if I can trick them into fixing this for us. > 3. in #defines, comments are converted to > > #define pointer_fe_update(pointer,sequence,typdescr) \ > { object updatefun = seq_fe_upd(typdescr); \ > pushSTACK(sequence); /* sequence */\ > pushSTACK(*(&(pointer) STACKop 1)); /* pointer */\ > funcall(updatefun,2); /* (SEQ-FE-UPD sequence pointer) */\ > pointer = value1; /* =: pointer */\ > } > > while I would exopct to see > > #define pointer_fe_update(pointer,sequence,typdescr) \ > { object updatefun = seq_fe_upd(typdescr); \ > pushSTACK(sequence); /* sequence */ \ > pushSTACK(*(&(pointer) STACKop 1)); /* pointer */ \ > funcall(updatefun,2); /* (SEQ-FE-UPD sequence pointer) */ \ > pointer = value1; /* =: pointer */ \ > } Hmmm. That's probably due to trailing white space in the original comment. Or maybe indent does that. Actually, if it were up to me, I'd format it like: #define pointer_fe_update(pointer,sequence,typdescr) \ { object updatefun = seq_fe_upd(typdescr); \ pushSTACK(sequence); /* sequence */ \ pushSTACK(*(&(pointer) STACKop 1)); /* pointer */ \ funcall(updatefun,2); /* (SEQ-FE-UPD sequence pointer) */ \ pointer = value1; /* =: pointer */ \ } or. #define pointer_fe_update(pointer,sequence,typdescr) \ { object updatefun = seq_fe_upd(typdescr); \ pushSTACK(sequence); /* sequence */ \ pushSTACK(*(&(pointer) STACKop 1)); /* pointer */ \ funcall(updatefun,2); /* (SEQ-FE-UPD sequence pointer) */ \ pointer = value1; /* =: pointer */ \ } But whatever. Tell me how you'd like to have it and I'll try to get it as near to there as possible. > 4. #ifdefs are not indented: > > if (!boundp(STACK_1) > #ifdef X3J13_149 > || nullp(STACK_1) > #endif > ) { /* end not supplied -> set end:=(length sequence > ): */ > > should be > > > if (!boundp(STACK_1) > # ifdef X3J13_149 > || nullp(STACK_1) > # endif > ) { /* end not supplied -> set end:=(length sequence > ): */ Yeah. I don't think GNU indent does that. It indents preprocessor foo relative to other preprocessor foo: #ifdef X # ifdef Y /* blah blah blah */ # endif #endif Given that the source already has the preprocessor directives indented with the code I should be able to move the '#' to the front of the line. Hopefully that won't get undone by indent. > 5. the following conversion: > > until (eq(STACK_2,Fixnum_0)) # count (ein Integer) = 0 -> Ende > { # (SEQ-ACCESS seq pointer1) bilden: > > to > > while (!(eq(STACK_2, Fixnum_0))) { /* count (ein Integer) = 0 -> Ende *//* (SEQ-ACCESS seq pointer1) bilden: */ > > is not nice. > it should be > > while (!(eq(STACK_2, Fixnum_0))) { /* count (ein Integer) = 0 -> Ende */ > /* (SEQ-ACCESS seq pointer1) bilden: */ I'll see where this is happening. I suspect that indent is the culprit. > 6. there are some indentation violations: > > { > uintL len = posfixnum_to_L(value1); /* len */ > /* Grundidee: Um eine Sequence mit len Elementen umzudrehen, muessen > der linke und der rechte Block mit je floor(len/2) Elementen > vertauscht und dann einzeln umgedreht werden (rekursiv!); das > mittlere Element (bei ungeradem len) bleibt unveraendert. > Entrekursivierter Algorithmus: > Fuer j=0,1,2,... sind 2^j mal zwei (fast) adjazente Bloecke > der Laenge k2=floor(len/2^(j+1)) zu vertauschen. */ > uintL j = 0; /* j := 0 */ > uintL k = len; /* k = floor(len/2^j) := len */ > > > there are probably more... Yeah. At some point I'm inclined to say, well, currently we have strangely formatted (in some cases) code in a C-like language that abuses (IMHO) the preprocssor in various ways; if we can convert it to mostly properly formatted, ANSI C by automatic means, let's check that in and then let folks continue to make hand edits as they go. I'll probably do a fair number of those edits myself--the reason I got into this in the first place was to have a reason to actually look at the code; I haven't done much of that yet. But all the hand edits required to get the code in exactly the format we want may take some time; if we don't check in some automatically converted source, then a) there's no way for anyone else to help out on the hand edits and b) I'll have an ever growing change-management problem as the source of the .d files changes out from under me while I'm trying to hand edit .c files that nobody else has. At some point my head *will* explode. I certainly don't want to regress the quality of the formatting but we also don't want to let the best be the enemy of the good. However, if there's any part of the automatic conversion, such as indent, that seems to be making things, on balance, worse--we can take it out. We can always run it by hand on files where it helps. You can compare the results of the various stages of the conversion by looking at the various files created in src/ during the d2c make. -Peter -- Peter Seibel pe...@ja... The intellectual level needed for system design is in general grossly underestimated. I am convinced more than ever that this type of work is very difficult and that every effort to do it with other than the best people is doomed to either failure or moderate success at enormous expense. --Edsger Dijkstra |
From: Sam S. <sd...@gn...> - 2003-02-26 14:39:57
|
> * In message <m3n0kjsv26.fsf@localhost.localdomain> > * On the subject of "Re: Re[2]: Big .d -> .c checkin." > * Sent on 25 Feb 2003 17:13:37 -0800 > * Honorable Peter Seibel <pe...@ja...> writes: > > > 3. in #defines, comments are converted to > > > > #define pointer_fe_update(pointer,sequence,typdescr) \ > > { object updatefun = seq_fe_upd(typdescr); \ > > pushSTACK(sequence); /* sequence */\ > > pushSTACK(*(&(pointer) STACKop 1)); /* pointer */\ > > funcall(updatefun,2); /* (SEQ-FE-UPD sequence pointer) */\ > > pointer = value1; /* =: pointer */\ > > } > > > > while I would exopct to see > > > > #define pointer_fe_update(pointer,sequence,typdescr) \ > > { object updatefun = seq_fe_upd(typdescr); \ > > pushSTACK(sequence); /* sequence */ \ > > pushSTACK(*(&(pointer) STACKop 1)); /* pointer */ \ > > funcall(updatefun,2); /* (SEQ-FE-UPD sequence pointer) */ \ > > pointer = value1; /* =: pointer */ \ > > } > > Hmmm. That's probably due to trailing white space in the original > comment. Or maybe indent does that. Actually, if it were up to me, I'd > format it like: > > #define pointer_fe_update(pointer,sequence,typdescr) \ > { object updatefun = seq_fe_upd(typdescr); \ > pushSTACK(sequence); /* sequence */ \ > pushSTACK(*(&(pointer) STACKop 1)); /* pointer */ \ > funcall(updatefun,2); /* (SEQ-FE-UPD sequence pointer) */ \ > pointer = value1; /* =: pointer */ \ > } > > or. > > #define pointer_fe_update(pointer,sequence,typdescr) \ > { object updatefun = seq_fe_upd(typdescr); \ > pushSTACK(sequence); /* sequence */ \ > pushSTACK(*(&(pointer) STACKop 1)); /* pointer */ \ > funcall(updatefun,2); /* (SEQ-FE-UPD sequence pointer) */ \ > pointer = value1; /* =: pointer */ \ > } > > But whatever. Tell me how you'd like to have it and I'll try to get it > as near to there as possible. the paramount consideration for me is that all lines are <=79 columns. the mantra is "fit as much code as possible into one Emacs screen full". > Yeah. I don't think GNU indent does that. It indents preprocessor foo > relative to other preprocessor foo: > > #ifdef X > # ifdef Y > /* blah blah blah */ > # endif > #endif > > Given that the source already has the preprocessor directives indented > with the code I should be able to move the '#' to the front of the > line. Hopefully that won't get undone by indent. OK. > > { > > uintL len = posfixnum_to_L(value1); /* len */ > > /* Grundidee: Um eine Sequence mit len Elementen umzudrehen, muessen > > der linke und der rechte Block mit je floor(len/2) Elementen > > vertauscht und dann einzeln umgedreht werden (rekursiv!); das > > mittlere Element (bei ungeradem len) bleibt unveraendert. > > Entrekursivierter Algorithmus: > > Fuer j=0,1,2,... sind 2^j mal zwei (fast) adjazente Bloecke > > der Laenge k2=floor(len/2^(j+1)) zu vertauschen. */ > > uintL j = 0; /* j := 0 */ > > uintL k = len; /* k = floor(len/2^j) := len */ > > > > > > there are probably more... > > Yeah. At some point I'm inclined to say, well, currently we have > strangely formatted (in some cases) code in a C-like language that > abuses (IMHO) the preprocssor in various ways; if we can convert it to > mostly properly formatted, ANSI C by automatic means, let's check that > in and then let folks continue to make hand edits as they go. I'll > probably do a fair number of those edits myself--the reason I got into > this in the first place was to have a reason to actually look at the > code; I haven't done much of that yet. But all the hand edits required > to get the code in exactly the format we want may take some time; if > we don't check in some automatically converted source, then a) there's > no way for anyone else to help out on the hand edits and b) I'll have > an ever growing change-management problem as the source of the .d > files changes out from under me while I'm trying to hand edit .c files > that nobody else has. At some point my head *will* explode. yes. > I certainly don't want to regress the quality of the formatting but we > also don't want to let the best be the enemy of the good. However, if > there's any part of the automatic conversion, such as indent, that > seems to be making things, on balance, worse--we can take it out. We > can always run it by hand on files where it helps. You can compare the > results of the various stages of the conversion by looking at the > various files created in src/ during the d2c make. yes. I would say that as soon as the the "new CLISP" compiles on linux and woe32 (and *BSD and Solaris :-), we should switch to it. -- Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> MS Windows vs IBM OS/2: Why marketing matters more than technology... |
From: Arseny S. <am...@ic...> - 2003-02-26 03:39:16
|
Hello Sam, Wednesday, February 26, 2003, 10:26:23 AM, you wrote: > Peter, I am impressed with your work! Yeah, me too. >> > Well, I have installed it, reconverted sources and you know, I >> > like nonindented files more. > Arseny, what did _you_ dislike? I didn't get what wrong with indentation in the original sources. Things like }) ? one-line structs ? I.e. ifdefs are still sticked with #s but carefully, space-by-space hand-indented code is reindented by robot. > It is crucial that these changes do not break the woe32 build. > Arseny, can you build CLISP with MSVC in C++ mode? Not yet. Now I'm stuck with handicraft alignof - it's not working with certain types. It works with one-word types such as int or char and fails for 'unsigned int' or 'int [16]' (jmp_buf). I made a small example and it works there. Somebody might enlighten me: this works ======== template <class type> struct alignof_helper { char slot1; type slot2; }; int main() { alignof_helper<unsigned int> aaa; ======== this doesn't (lispbibl.c) In both cases stddef's offsetof is used. ======== /* Determine the offset of a component 'ident' in a struct of the type 'type': See 0 as pointer to 'type', put a struct 'type' there and determine the address of its component 'ident' and return it as number: */ #if defined(HAVE_OFFSETOF) || defined(__MINGW32__) || (defined(BORLAND) && defined(WIN32)) || defined(MICROSOFT) #include <stddef.h> #else #undef offsetof #define offsetof(type,ident) ((ULONG)&(((type*)0)->ident)) #endif /* Determine the offset of an array 'ident' in a truct of the type 'type': */ #define offsetofa(type,ident) offsetof(type,ident[0]) /* alignof(type) is a constant expression, returning the alignment of type. */ #if defined (__cplusplus) #ifdef GNU #define alignof(type) __alignof__(type) #else template <class type> struct alignof_helper { char slot1; type slot2; }; #define alignof(type) offsetof(alignof_helper<type>, slot2) #endif #else #define alignof(type) offsetof(struct { char slot1; type slot2; }, slot2) #endif int xxzz = offsetof(alignof_helper<unsigned int>,slot2); ======== errors: lispbibl.c(1186) : error C2146: syntax error : missing ';' before identifier 'slot2' lispbibl.c(1193) : see reference to class template instantiation 'alignof_helper<unsigned int>' being compiled lispbibl.c(1186) : error C2501: 'type' : missing storage-class or type specifiers lispbibl.c(1193) : see reference to class template instantiation 'alignof_helper<unsigned int>' being compiled lispbibl.c(1186) : error C2501: 'slot2' : missing storage-class or type specifiers lispbibl.c(1193) : see reference to class template instantiation 'alignof_helper<unsigned int>' being compiled lispbibl.c(1193) : error C2065: 'slot2' : undeclared identifier lispbibl.c(7455) : error C2039: 'slot2' : is not a member of 'alignof_helper<unsigned int>' > what about mingw? does it come with gcc 3.2 now? I will check it. -- Best regards, Arseny |
From: Sam S. <sd...@gn...> - 2003-02-26 14:35:31
|
> * In message <106...@ic...> > * On the subject of "Re[4]: Big .d -> .c checkin." > * Sent on Wed, 26 Feb 2003 13:38:55 +1000 > * Honorable Arseny Slobodjuck <am...@ic...> writes: > > >> > Well, I have installed it, reconverted sources and you know, I > >> > like nonindented files more. > > Arseny, what did _you_ dislike? > I didn't get what wrong with indentation in the original sources. Things > like }) ? one-line structs ? I.e. ifdefs are still sticked with #s but > carefully, space-by-space hand-indented code is reindented by robot. many functions are written like this: int foo (int bar); int foo (bar) var int bar; { ...; } This is bad because Emacs expects to find the function start at "^{". (it also wastes a lot of valuable screen space) d-mode-convert-function translates the above to int foo (int bar) { ...; } Actually, indent(1) is not needed: just remove the fixed amount of leading whitespace. > > It is crucial that these changes do not break the woe32 build. > > Arseny, can you build CLISP with MSVC in C++ mode? > Not yet. Now I'm stuck with handicraft alignof - it's not working with > certain types. It works with one-word types such as int or char and fails > for 'unsigned int' or 'int [16]' (jmp_buf). I made a small example and it > works there. Somebody might enlighten me: I hope Bruno will answer this! > this works > > ======== > > > template <class type> struct alignof_helper { char slot1; type slot2; }; > > int main() { > alignof_helper<unsigned int> aaa; > > > ======== > > this doesn't (lispbibl.c) > In both cases stddef's offsetof is used. > > ======== > /* Determine the offset of a component 'ident' in a struct of the type 'type': > See 0 as pointer to 'type', put a struct 'type' there and determine the > address of its component 'ident' and return it as number: */ > #if defined(HAVE_OFFSETOF) || defined(__MINGW32__) || (defined(BORLAND) && defined(WIN32)) || defined(MICROSOFT) > #include <stddef.h> > #else > #undef offsetof > #define offsetof(type,ident) ((ULONG)&(((type*)0)->ident)) > #endif > /* Determine the offset of an array 'ident' in a truct of the type 'type': */ > #define offsetofa(type,ident) offsetof(type,ident[0]) > > /* alignof(type) is a constant expression, returning the alignment of type. */ > #if defined (__cplusplus) > #ifdef GNU > #define alignof(type) __alignof__(type) > #else > template <class type> struct alignof_helper { char slot1; type slot2; }; > #define alignof(type) offsetof(alignof_helper<type>, slot2) > #endif > #else > #define alignof(type) offsetof(struct { char slot1; type slot2; }, slot2) > #endif > > int xxzz = offsetof(alignof_helper<unsigned int>,slot2); > ======== > > errors: > > lispbibl.c(1186) : error C2146: syntax error : missing ';' before identifier 'slot2' > lispbibl.c(1193) : see reference to class template instantiation 'alignof_helper<unsigned int>' being compiled > lispbibl.c(1186) : error C2501: 'type' : missing storage-class or type specifiers > lispbibl.c(1193) : see reference to class template instantiation 'alignof_helper<unsigned int>' being compiled > lispbibl.c(1186) : error C2501: 'slot2' : missing storage-class or type specifiers > lispbibl.c(1193) : see reference to class template instantiation 'alignof_helper<unsigned int>' being compiled > lispbibl.c(1193) : error C2065: 'slot2' : undeclared identifier > lispbibl.c(7455) : error C2039: 'slot2' : is not a member of 'alignof_helper<unsigned int>' > > > > what about mingw? does it come with gcc 3.2 now? > I will check it. > > -- > Best regards, > Arseny > -- Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> In every non-trivial program there is at least one bug. |
From: Arseny S. <am...@ic...> - 2003-03-02 04:06:42
|
Hello Sam, Thursday, February 27, 2003, 12:40:46 AM, you wrote: > I would say that as soon as the the "new CLISP" compiles on linux and > woe32 (and *BSD and Solaris :-), we should switch to it. I was able to compile (but not link yet) with VC in c++ mode. A problem with alignof still persists, to compile I had to change it to trivial '#define alignof(x) 4' - just to see other errors. There are similar alignof macros defined in avcall.h and vacall_r.h. > MS Windows vs IBM OS/2: Why marketing matters more than technology... After 10 years of marketing MS was finally able to sell OS/2 have masked it under windows interface (XP)... -- Best regards, Arseny |