[OpenBIOS] ANSI

[Stefan Reinauer]

* Segher Boessenkool <segher at 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

-- 
The x86 isn't all that complex - it just doesn't make a lot of
sense.          -- Mike Johnson, Leader of 80x86 Design at AMD
	                          Microprocessor Report (1994)
-
To unsubscribe: send mail to majordomo at freiburg.linux.de
with 'unsubscribe openbios' in the body of the message
http://www.freiburg.linux.de/OpenBIOS/ - free your system..