From owner-freebsd-hackers  Sat Oct 14 07:12:24 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id HAA07846
          for hackers-outgoing; Sat, 14 Oct 1995 07:12:24 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA07837
          for <freebsd-hackers@freebsd.org>; Sat, 14 Oct 1995 07:12:16 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id AAA17454; Sun, 15 Oct 1995 00:07:57 +1000
Date: Sun, 15 Oct 1995 00:07:57 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199510141407.AAA17454@godzilla.zeta.org.au>
To: freebsd-hackers@freebsd.org, j@uriah.heep.sax.de
Subject: Re: lint
Sender: owner-hackers@freebsd.org
Precedence: bulk

>The following things are in my way:

>. The inconsistent handling of _BSD_WCHAR_T in <stdlib.h>, <stddef.h>,
>  and <runetype.h>.  Is there any particular reason to protect the
>  rune_t declaration from Posix and ANSI sources?

Yes, it isn't legal in ANSI to declare it in an ANSI header.  It is legal
in POSIX iff it is declared in <sys/types.h>.  I didn't know that it was
broken in <stddef.h>.  <stddef.h> should handle it the same as <stdlib.h>.

There is a more serious conflict between <ctype.h> and both <stddef.h>
and <stdlib.h>.  The following doesn't compile if either _ANSI_SOURCE or
_POSIX_SOURCE is defined:

	#include <stddef.h>
	#include <stdlib.h>

All these bugs should be fixed by using a different ifdef guard for
wchar_t and rune_t.

>. The ANSI-violating definitions for fgets() (second parameter must be
>  int, not size_t) and ftell() (parameter is not const); i'm about to
>  change them.

It's interesting that these bugs have been around for so long.  The
first but not the second is fixed in 4.4lite2.

Bruce