Mail Archives: djgpp-workers/2003/03/19/08:23:26
Hello.
Charles Sandmann wrote:
>
> > > I have no objections to these, but they seem less critical than other
> > > things.
> >
> > Hmmm, I though C99 compliance was a goal of 2.04? In which case isnan,
> > strto* are important. fchdir less so, since that's POSIXy.
>
> Does this make the library fully C99 compliant? If so, great. I was under
> the impression there were other things were still needed.
If you ignore the new maths functions and the wide-character functions, then
we're pretty close to C99 compliance. Use of restrict and the updates to
strto* are the only things left for the non-maths and non-wide-character
functions AFAIK.
> > Apparently stat doesn't return the same inode each time on Win2k/XP.
>
> OK.
I don't think this will be difficult to fix. It would be similar to the
proposed fix for fstat.
The fstat fix uses the stored file name from fd_props, which is the true name
of the original file name, then uses _invent_inode on that. There is a problem
that hasn't been solved yet, where we need to do something about UNC drive
letters, if we have a mapping for the drive.
I can't remember if we can distinguish Win2k & XP from everything else. If
not, we could always use this code for directories.
> > AFAICT the main reason for new DXE is to support NLS without eating up
> > disk space. Is NLS a killer feature for 2.04?
>
> It's actually much more than NLS - that's just one example. But right now
> there isn't a standard toolkit for building shared modules which everyone
> has - so noone is doing it. You have to get the toolkit into a release
> before it will be used.
OK. I'll update the 2.04 status page.
> > I guess it comes down to: What do we (or the users) want from DJGPP 2.04?
> > (Has anyone asked them?) What do we have time to do?
>
> Smaller images seems to be a common FAQ on the newsgroup/mailing list.
I've added that to the issues on the 2.04 status page.
> > > How about considering making all djdev executables link to a dynamic
> > > libc, and having libc have it's own version/releases?
> >
> > Blimey. That sounds like a DJGPP 3.x thing to me.
>
> Actually we are about there in a test version. One new call to crt0 which
> is stubbed in the standard libc and loads dynamic libc if so required. If
> the new crt0 is in V2.04 - then it can be layered.
OK, that sounds a lot safer than it did at first!
> > My concern is that it's going to take another year or so to get it out. We
> > haven't even got an alpha release to Simtel.NET for testing yet. I expect
> > it has got a fair bit of testing, based on Andrew's builds on clio.
>
> DXE's not that much work - and the only thing in the library which uses it
> is the FPU emulation loader. So getting it in, even buggy, is low risk.
> We are struggling with compatiblity issues and things you might not want
> to live with long term that aren't standards ...
[snip]
Perhaps we could just dump backwards compatibility on DXEs. How many people
actually use DXEs as they stand?
Bye, Rich =]
--
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]
- Raw text -