Questions and a RFC [was Re: Assignment from Nicholas Wourms arrived]

Nicholas Wourms nwourms@netscape.net
Wed Aug 13 15:44:00 GMT 2003


cygwin-patches@cygwin.com wrote:

> On Tue, Aug 12, 2003 at 06:55:11PM -0400, Nicholas Wourms wrote:
> 
>>1)Did my MUA strip the tabs from the patch?  The only reason I ask is 
> 
> 
> Yes.  The patch already contained spaces.  I see you're using Mozilla/NS7
> so I'm wondering how this happened.  AFAIK, Mozilla doesn't touch
> attachments.

Alas, I fear that NS7.1(aka Moz 1.4) is having the same problem folks 
were having on the LKML with 1.4...  I think the work around was to send 
formatted attachments as .txt so that Moz would get the mime-type right. 
  I'll send a clean up patch with a clarifying comment for NBBY to test 
this theory.

> 
> No :-)
> 
> Long answer:  You don't need any assignment for newlib due to the relaxed
> licensing of newlib.

Excellent.

> 
>>3)I'm still trying to figure out how to use lstat in newlib source code, 
> 
> 
> What are you trying to implement?  If you need lstat, you're perhaps better
> off implementing this in Cygwin instead of newlib.

ftw/nftw.  Per Gerrit's suggestion on the list, I looked at OpenBSD's 
version of ftw/nftw they did for the US DOD.  IMHO, it looks the be the 
most robust compared to the other Non-GPL'ed versions floating around. 
I suppose one could write it from scratch, but if a reasonable 
implementation exists, why bother?  Of course to the next point...

Perhaps it doesn't belong in newlib, as it isn't terribly portable in 
it's current state.  I basically had to disgorge a bunch of extra code 
code which was targeted at platforms with a more robust(mature?) 
opendir().  However, I suppose I could just #if 0 it, and leave it to 
the linux/ELIX people to fix up the parts which apply to them [1].

> 
>> since apparently the function declaration is hidden when building 
>>newlib/cygwin.  So far, any attempt to use it results in undefined 
>>references to _lstat when linking the dll.  I tried adding a definition 
>>to _syslist.h, but that didn't work.  I hate to sound clueless, but if 
>>someone could nudge me toward the right header or magic, that would be 
>>great.
> 
> 
> cd winsup/cygwin
> ctags -R .
> vi -t cygwin_lstat
> 
> However, thinking about this situation, I'm sure it wasn't really clever
> to rename lstat to cygwin_lstat.  Your problem to link against it stems
> from that fact and other declaration problems has been easilier solved by
> just adding a bunch of defines at the top of syscalls.cc.

*Doh*  I didn't connect the dots on that one, thanks for the 
clarification :-).  Speaking of aliases, about this time last year, 
Conrad and I were debating the reasoning behind the underscore aliases 
in cygwin.din.  I speculated that they might be a work around for 
elf-centric configuration programs which look for weak versions of the 
symbols (which indeed seems to be the case for argz & the configure 
found in binutils/gcc/gdb).  He thought that it had something to do with 
MSVC compatibility.  However, it seems that people have since stopped 
doing this.  Out of curiosity, what was the history behind doing this? 
For future contributions, what is the official policy on doing it now?

> [...time passes...]
> 
> Ok, I've tested to revert the function name from cygwin_lstat to lstat
> in syscalls.cc and applied the appropriate patch.  This is transparent
> to all applications and should allow to use lstat from newlib as in
> libc/sys/linux.
> 

Thank you, I will submit some code later on for review.  At that time, I 
suppose you can be the judge of where it belongs :-D.  I think, though, 
that I'll wait until post-1.5.x to do this, as it seems to be the 
consensus that we are in a feature "freeze".

>>4)Corinna, I've been working on porting some of the missing 
>>SUSv3/c99/bsd functions from the *bsd libc.  I noticed that the libutil 
>>which you distribute with inetutils contains some of the functions I 
>>thought belonged in libc, or at least the headers of newlib would have 
>>me believe this.  Specifically, I was wanted to work on adding instances of:
>>endusershell()
>>setusershell()
>>getusershell()
>>ruserok()
>>iruserok()
> 
> 
> Don't do this(TM).  The reason is that, first, I have already code for
> this in the loop and, second, I have to coordinate this with changing
> my inetutils package not to contain the libutil.a anymore at one point.
> I appreciate your effort but I'd like to keep these functions in my
> hand, even though it might take a bit longer.

No problem, I didn't know what the story was, which is why I was testing 
the waters before investing any more effort/time.  By all means, I'll 
look at other things to work on, no worries.

Speaking of things in the loop, has any further thought been given to 
David Euresti's patch from last year which enables passing of file 
descriptors between processes via Unix Domain Sockets?  It'd be a shame 
not to use it but, alas, David has expressed no further interest in 
working on it and Conrad (who had intended to pick up the torch) seems 
to have fallen off the face of the earth.  At one point you said you'd 
like to see it go in, but it was dependent on David's cooperation.  Is 
this in the loop or has it been dropped altogether?

> Especially I will not do this for 1.5.2 (or 3, whatever will be the first
> gold version).  At this point, we should only apply bug fixes and very
> obvious stuff.  New functionality should wait for later Cygwin versions.
> 

Right, I think this is sound advice, so I'll hold off on any new stuff 
until post-1.5.

>>5)This is meant as a general RFC based on something I noticed while 
>>researching the freebsd libc.
> 
> 
> Sorry, but I agree with Charles and I'm pretty sure Chris will have the
> same opinion.

Yes, I regret having even suggested it at this point in time.  Sorry for 
the noise.

Cheers,
Nicholas

<OFF-TOPIC>
[1] My opinion on this:
To be clear, when I started on fts, I really had no intention of trying 
to make it work on any other platform besides Cygwin.  Perhaps I'm still 
a bit bitter from the embedded linux people "cheating" by importing big 
chunks of glibc, which effectively stymies their contributions to the 
global newlib.  However, instead of just being angry, I'm going to try 
to do something about it.  My hope is that, in a small way, I can help 
bring some parity between ELIX IV and Cygwin.  The current state of 
newlib just seems terribly unfair, but then again, life is unfair and 
people are mean :-D.
</OFF-TOPIC>



More information about the Cygwin-patches mailing list