[PATCH] Improve portability

[Mike Frysinger]

On Sunday 06 September 2009 01:01:30 Dan Fandrich wrote:
> 1) Empty struct initializers, e.g.
>
>  static const struct suffix_mult sfx[] = {
>     { "s", 1 },
>     { }	 		// <= should be { "", 0 }
>  };
>
> I'm unable to determine if this is actually allowed by ANSI C or not, but
> at least two compilers I've tried don't handle it.

gcc (with enough flags) agrees with you:
$ cat test.c
struct { char *a; int b; } f[] = { { } };
$ gcc -c test.c -ansi -pedantic
test.c:1: warning: ISO C forbids empty initializer braces

> 2) Automatic variables used as initializers, e.g.
>
>  char delim = 1;
>  const char delimiter[2] = { delim, 0 };
>
> C90 requires automatic struct variables to have initializers containing
> only constant expressions.

and we are already going for C99, so what older standards say doesnt really 
matter much.  so if this works under C99, then your compiler is too old, 
sorry.  as a consolation, gcc builds and runs on a variety of non-standard 
conforming systems ...

> 3) #include files added to satisfy dependencies required by system include
> files that are not self-contained, which happens in some non-glibc systems.
> Requiring <sys/socket.h> before <netinet/in.h> seems to be a relatively
> common one on pre-SuS systems.

if the busybox code needs those things, or POSIX says we should be doing this, 
then ok (i.e. we use socket() but dont pull in sys/socket.h for it).  but if 
the idea is to try and support broken C libraries where you have to kill a 
goat and read the entrails in order to get the right #include down, that isnt 
something we can possibly support in any sane manor.  we're going to be 
constantly changing code and not testing on these retarded C libraries which 
means your broken C library is going to be a constant problem.

> 4) Conditional operator missing the second expression, e.g.
>
>   getlogin() ? : getpwuid(cur_uid))

yes, that sure is a nice extension, but it is just that.  perhaps we should 
macro away the issue ?
#ifdef __GNUC__
# define alt_null_value(x, y) ((x) ? : (y))
#else
# define alt_null_value(x, y) ({ typeof(x) __x = (x); (__x) ? (__x) : (y); })
#endif

but maybe this version too uses gcc extensions ;)

> --- a/editors/awk.c
> +++ b/editors/awk.c
> @@ -114,7 +114,7 @@ typedef struct nvblock_s {
>  	var *pos;
>  	struct nvblock_s *prev;
>  	struct nvblock_s *next;
> -	var nv[0];
> +	var nv[];
>  } nvblock;
>
>  typedef struct tsplitter_s {
>
> Explicitly zero-length arrays seems to be allowed in C++ but not C, which
> uses an empty array size instead.

are we sure these two code snippets are the same thing ?  i never got around 
to wrapping my head around [] arrays at the end of structs.  "automatic 
arrays" or something ?

> --- a/libbb/login.c
> +++ b/libbb/login.c
> @@ -9,7 +9,7 @@
>   * Licensed under GPLv2 or later, see file LICENSE in this tarball for
> details. */
>
> -#include <sys/param.h>  /* s */
> +#include <sys/types.h>
>  #include <sys/utsname.h>
>  #include "libbb.h"
>
> MAXHOSTNAMELEN isn't referenced in this file, so I removed that include
> line. The sys/types.h file was included because sys/utsname.h isn't
> self-contained on Watcom C (I don't know how common this is compared to the
> netinet/in.h case).

MAXHOSTNAMELEN isnt in POSIX i dont believe.  we should be using HOST_NAME_MAX 
instead, and that comes from limits.h.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20090906/59045988/attachment-0001.pgp>