Description of problem:

The latest flex-2.5.4a version unconditionally defines _POSIX_SOURCE to 1
in the skeleton #defines of all flex generated code, with the new
flex-2.5.4a-posix.patch:

--- flex-2.5.4/skel.c   2006-07-14 15:30:18.000000000 +0200
+++ flex-2.5.4-pm/skel.c        2006-07-14 15:29:43.000000000 +0200
@@ -14,6 +14,8 @@ const char *skel[] = {
   "#define YY_FLEX_MINOR_VERSION 5",
   "",
   "%-",
+  "/* Use posix source, to silent c99 warnings about fileno. */",
+  "#define _POSIX_SOURCE 1",
   "#include <stdio.h>",
   "#include <unistd.h>",
   "%*",


I think this is a VERY bad idea, as it breaks builds that for instance 
use such constructs as 'u_long' ( if _POSIX_SOURCE is defined, then
_USE_BSD is undefined, and the 'u_long' typedef is not defined by 
sys/types.h ).

This has broken the dhcpv6 build so far (and possibly others) - I
now have to patch dhcpv6's flex code to '#undef _POSIX_SOURCE'
before including sys/types.h in order to get it to build.

I don't think avoiding any compiler warning warrants such a major
API change as defining _POSIX_SOURCE=1 by default - couldn't the code
be reworked so that the C99 compiler doesn't complain ?


Version-Release number of selected component (if applicable):
flex-2.5.4a

How reproducible:
100%

Steps to Reproduce:
Generate any flex code that uses the 'u_long' type

  
Actual results:
The code won't compile

Expected results:
Code should be able to use flex and u_long and still compile.