* Segher Boessenkool segher@chello.nl [020623 15:47]:
There was some discussion on this list on probing compiler features before actually using them instead of making vague assumptions on what version supports which feature.
I still prefer just requiring gcc-3 (although it currently works "fine" with 2.95 as well) (except on some 64-bit targets).
Agreed. Though it does not hurt to start looking into portability early especially as Paflof is close to complete now.
Instead of using a vast amount of autoconf/automake magic, I wrote a small perl script that calls the compiler with simple code fragments and analyzes these afterwards using nm.
Good :) The autoevil suite is, well, evil ;)
Just a practical issue - we need perl anyways and it's a lot easier to read than either the same amount of code in configure.in or 5k lines of configure script.
This way it is also usable when cross compiling. Basically the patch removes types.h as it will be autogenerated plus the already known ANSI fixes (mostly applying a regexp to change comment style)
Please keep types.h intact, and have it include an auto-types.h or something like that. Much easier if you want to bypass the automatic stuff for whatever reason.
It's enough to touch types.h before doing a "make". Another idea would be to give a parameter to conf.pl to create a default config. keeping 2 instances of the same file seems a bit unclean.
Walkthrough :) :
-CFLAGS = -Wall -W -std=gnu9x -g -O2 # -pg +CFLAGS = -Wall -std=gnu9x -g -O2 # -pg
Why remove -W ? It's soooo useful :)
ah.. confused it with -w. sorry.
+CC = gcc
I removed this for a reason ;) Just CC=gcc make if you need it...
+NM = nm -t bsd
Not all nm's are GNU nm. Different nm's outputs are similar enough to be parseable with a simple regexp.
there's 3 output formats with gnu nm - sysv, posix and bsd. To be clean we have to check which output format is available and use an according regexp for that (hoping that other systems use one of these output formats) For now this should be ok, because, as you said, we're still GNU cc specific in many other positions.
+$CC="gcc -std=gnu9x"; +$NM="nm";
Better just use sh's already-set variables for this.
this forbids using conf.pl on the command line, as they're set by make, not sh.
+# Check for restrict keyword. +my $answer="no"; +print("\nChecking whether we can use the restrict keyword (C99)... "); +print(I "\n#define __RESTRICT__ ");
The C compiler already defines __STDC_VERSION__ to 199901L or greater if C99 features are supported.
I know. I just thought of a theoretical compiler that knows about restrict without supporting other C99 features. It seemed wiser to check for the used features themselfes, not the standards that say "this feature belongs here"
-//#define DEBUG_STACKS
Don't remove this, please ;) #undef it, if you want, but keep all compile-time flags at the top op file :)
I just moved it down to the other #defines
#include <stdio.h> #include <stdlib.h> +#define __USE_XOPEN_EXTENDED #include <unistd.h> -#include <string.h> +#define __USE_MISC #include <sys/mman.h> +#include <string.h> #include <termios.h> +#define __USE_POSIX +#define __USE_POSIX199309 #include <signal.h> #include <fcntl.h>
This isn't exactly making stuff more portable, now is it?
It does not hurt it either. It's needed to compile with -ansi -pedantic, but is changed in the newer release of my patch.
struct interpreter {
cell *restrict data_stack;cell *restrict return_stack;cell *restrict dictionary;char *restrict tib;char *restrict pockets;
cell * __RESTRICT__ data_stack;cell * __RESTRICT__ return_stack;cell * __RESTRICT__ dictionary;char * __RESTRICT__ tib;char * __RESTRICT__ pockets; void *here;};
It would have been simpler had you done #define restrict if restrict isn't supported...
Uh.. nulling out reserved words... well.. i don't really care... we should just solve the case where it's not existant.
+#if 0
free(i->data_stack);free(i->return_stack);free(i->dictionary);+#endif
#if 0 for commenting out code is evil, imho.
Better than C++ style comments in pure C code ;) And it's the only way of doing it "portable" ;) But as John already mentioned, we should decide whether we want that code or not and drop it completely in the later case.
Stefan