Date: Tue, 10 Feb 1998 21:33:32 -0800 (PST) Message-Id: <199802110533.VAA06002@adit.ap.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: djgpp AT delorie DOT com From: Nate Eldredge Subject: Re: Suggestion: Portability section for libc docs Cc: , , , Precedence: bulk Wow, I'm overwhelmed by the response. I'll try to cover everyone's ideas here. Eli Zaretskii wrote: > 1) Since most DOS-based compiler don't have POSIX-compliant > headers such as unistd.h, I suggest that the Portability > section would also include the headers where the > functions/variables are declared in the other DOS compilers. This is a good idea; however it requires that we look at all the other DOS compilers. If people are around who have Microsoft, Borland, Watcom, Zortech, etc, that's fine, but I personally don't. I'd need help on this one. George Foot wrote: >: 2) Sometimes functions which exist on other platforms have >: slightly different functionality. In such cases, the >: differences should be mentioned. > >I partially disagree; I think it would be useful to point out which >functions are portable and to what extent, certainly, and since djgpp >compiles for DOS it would make sense to include portability >information to MS and Borland; but I don't think the libc docs are the >place to describe exactly how certain functions work on *other* >compilers. This is a bit of a dilemma. It does seem out of place to describe other platforms in DJGPP documentation. Also, actually finding all these differences is a nightmare. It would be helpful to know how things work elsewhere, but IMHO people should consult the platform itself for specifics. Otherwise, we end up saying things like "Watcom's `stat' doesn't fill in the `st_link' field" ad nauseum, bloating the docs, and then Watcom changes their behavior and our documentation is wrong. Major, general differences should be noted, yes. Like for `fork', it would IMHO not be inappropriate to say, "On Unix systems, this function actually works". How does that sound? Ned Ulbricht wrote: >Obviously there's not a problem with relying on public domain >references when they're relevent and available. And certain functions >can just be declared non-portable (djgpp only or gcc only) by fiat. But >to list something as portable will usually require relying on sources >which are not in the public domain--unless we test it ourselves. Are you saying there is a legal problem with saying "Microsoft C supports `int86'" if we have gleaned that from reading Microsoft documentation? That seems hard to believe, but I suppose it's possible. Perhaps we could avoid specifically mentioning the competition and say, "`int86' is available on other DOS compilers"? Any other thoughts here? Eli wrote: >You don't need the standards, it is enough to look into the DJGPP >headers. Thanks, I hadn't thought of that. Of course, those were made by people who knew what standards supported what features, so I can avoid doing all that work again. Various people wrote: [offers of access to Unix systems, man pages, etc] Thanks for the offers! I have a Linux system here with all the info and man pages, so I can use that as a reference. I believe Linux is a fairly good mix of the characteristics of various Unices, If someone has information about a specific system, that would of course be helpful. George wrote: >There are a lot of functions in the docs though; perhaps they should >be `farmed out' to volunteers? Any volunteers? :) I'm not sure what would be the best way to divide it: per-function, per-platform, ?? In any case, any help would be greatly appreciated. I will be on vacation next week, and will have to unsubscribe from the djgpp list to avoid overflowing my inbox. :( So if anybody sends something then, please cc: to me if possible to make sure I get it (my e-mail address is for real ;-). I probably won't be able to start work until after I get back. One other question: Would it be better to move this discussion/project to `djgpp-workers'? Thanks, everybody, for your really helpful comments!! Nate Eldredge eldredge AT ap DOT net