Some issues wrt compilation on Windows using VS.NET

[Tim Van Holder]

Steps taken so far:

- created a win32/msvc.net subdir (please advise as to
  what a preferred location would be for portability
  cruft like this)
- manually created a config.h from config.in and put in
  win32/msvc.net
- added GNU Regex (regex.[hc]) to win32/msvc.net
- created solution and vc++ win32 console project; added
  all sources & headers, using default settings
- added scan.l, parser.y, and mkskel.sh (+ flex.skl) to
  the project as well, in preparation for custom build
  rules.
- (attempted to) compile the project

Issues encountered so far:
[note: MSVC is notoriously verbose with warnings - there are
 surprisingly few in flex, which is why even warnings get a
 mention here]

- existence of a POSIX regex is never tested for, and used
  unconditionally
  -> GNU regex included in project

- (minor) size_t vs. flex_uint32_t
  -> VS.NET is a 64-bit ready environment, and by
  default warns about 64-bit portability issues.
  size_t is marked as potentially 64-bit in size; this
  makes it unfortunate that size_t values are assigned
  to flex_uint32_t fields (in table structures).  Since
  those fields are in fact sizes, it would make more
  sense to have them as size_t instead of flex_uint32_t.
  This only causes a bunch of (easily disabled) warnings
  though, so it's not that big a deal.

- (minor) signed vs unsigned
  -> newsz in yytbl_data_compress() should be a size_t
  (or at the very least a flex_uint32_t) instead of a
  flex_int32_t.

- yytbl_write32() uses htonl() unconditionally and
  yytbl_write16() uses htons() unconditionally.
  The netinet/in.h header is checked for but the functions
  are used regardless.
  -> On Windows these functions are in winsock.h or winsock2.h, so
  this was easily solved by adding an #include to tables.c
  (an include in flexdef.h was not possible due to a clash
  between the CHAR type from the windows headers and the CHAR
  token used in parser.c), and an #undef for Char, as Char is
  also a typedef used by the windows headers

- scan.c uses unistd.h unconditionally (even though configure
  is set up to test for its existence).  This is VERY
  unfortunate, as it introduces a kind of chicken-and-egg
  problem as a win32 flex is required to regenerate it.
  -> However, unistd.h seems completely unneeded in this case,
  so adding an '#ifndef WIN32' around it was sufficient.

- filter.c unconditionally uses dup(), dup2() and execvp()
  -> On Windows these are in io.h and process.h, so easily
  fixed with two #includes in flexdef.h

- filter.c assigns to stdin and stdout
  -> this is not possible on windows (stdin is a #define for
  &_iob[0], so not an l-value) - since the C++ standard (and I
  assume the C standard too, but I don't have that handy)
  explicitly states stdin/stdout/stderr are macros, so that
  many systems happen to support this seems more an accident.
  Even POSIX only requires them to be macros that are
  pointer-to-FILE, not that they refer to assignable pointers.
  Perhaps this code could/should be based around libiberty's
  pexecute()?

- filter.c uses pipe()
  -> Windows has _pipe(), but that has a different calling
  interface.  This would also go away if pexecute was used as
  base (as this has implementations for various systems including
  msdos, windows, and os/2)

This only leaves the main issue, the use of fork()/wait() in
filter.c (and wait() in main.c, but I assume the two are related).
At first glance it seems as it's all for that pipe, so I'll try to
make an alternate implementation using popen() (which IS supported
on DJGPP and Windows).

If a patch for MSVC.NET support is welcome, please tell me
what subdir to put the windows-specific stuff in and I'll
send a patch once I get flex fully compiled & working.

Oh, and since I initially downloaded the sources to see if I
could embed a full flex lexer (even a C style one, as I think that
would be easier to hook up to a bison parser) inside a
C++ namespace, is that possible yet?  Perhaps through a (set of)
"%namespace foo" or "%option namespace foo" directives?