Using h_errno, errno etc Cygwin DLL globals [Re: Making wget]

[Mumit Khan]

On Wed, 26 Jan 2000, Chris Faylor wrote:

> Bug report:
> 
> When compiling using gcc 2.97.43 and the Cygwin snapshot from 1999-8-31
> I get an incorrect success when building code which contains both
> h_errno and netdb.h.  My program compiles and links perfectly rather
> than giving me the correct error!!!!

I don't know what 1999-08-31 did with h_errno, and how it exported it. If
it was a "statically linked" global variable, much like what sys_errlist
used to be, then it's expected to work.

  $ nm libcygwin.a | grep h_errno

If you see _h_errno (no sign of 'imp' in the name), it's case 1 below
and it's an application-space global variable; if you see both _h_errno 
and _imp_ versions, then it's case 2 below; if you see *only* the _imp_ 
versions, it's case 3 below.

> What the heck is the deal here???  This failed to compile perfectly on
> Ultrix 4.2!!!  Has anyone else seen this problem??

I don't see a problem ;-)

Note the the version of gcc is irrelevant here, the only relevant items
are (1) if h_errno came from the DLL or came from the "static" part of
libcygwin.a, and (2) if former, whether the DEF file used the DATA tag
or not when exporting h_errno. 

Here're the scenarios:
 
1. h_errno is in the static part of libcygwin.a: in this case, it's just
   like any other application-space global variable, and you can safely
   declare it in your code as `extern int h_errno', and it'll work as
   expected.

2. h_errno comes from DLL, *and* cygwin.def did not use a DATA tag.
   In this case, the following code is will link correctly, but in all 
   likelihood crash:
     
     int
     main ()
     {
       extern int h_errno;
       h_errno = 5;
     }

3. h_errno comes from DLL, *and* cygwin.def DID use a DATA tag. In this,
   the code above will not even link.

Regards,
Mumit



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com