Mail Archives: djgpp-workers/1998/02/11/17:46:18
On Tue, 10 Feb 1998, Nate Eldredge wrote:
> 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.
If it's too much work to do that initially, we could make a start by
classifying each function ANSI/POSIX/neither, and add more details later
on.
> 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?
I'm not sure, re: the comment about fork; this is a case of a function
which is not fully functional in djgpp. These docs are probably only used
by people developping under djgpp (is that a valid assumption?) and such
people are probably unlikely to use Unixy functions that djgpp only really
provides to simplify porting from Unix. OTOH, it might be wise to point
out that djgpp's behaviour in these cases is atypical -- but the docs
already do that IIRC.
> Ned Ulbricht wrote:
[about legality of using information from other documentation]
> 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?
I agree with Eli; I very much doubt that this would be a breach of
copyright. In addition, if it were illegal to identify functions as being
ANSI, POSIX, etc in the documentation then surely djgpp's header files
would be guilty here too?
> 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.
I think a sensible first move would be to parse the header files and
derive a list of functions in each category (ANSI, POSIX, neither) from
the header files.
> 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.
It's dangerous to label any system as a typical system. I think ANSI
functions should be labelled as such; in general no more needs to be said.
Functions which are POSIX but non-ANSI need DOS compatibility information
as Eli said. Non-POSIX functions should have their origin mentioned, as
well as information on portability to other DOS compilers and Unix
systems.
> George wrote:
> >There are a lot of functions in the docs though; perhaps they should
> >be `farmed out' to volunteers?
> Any volunteers? :)
I already volunteered to help.
> 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 think you/we should decide how to format the information, and how much
information to give. As Eli pointed out, the basic information
(ANSI/POSIX/neither) can be extracted from the header files, and a trained
monkey can add this to the docs in the required format. It's the
additional information that needs more thought.
I suggest we take the alphabetical listing and divide it up between the
volunteers. Each volunteer can add the basic information for each
function, to begin with. When that is done, make separate lists of
`POSIX' and `neither' functions. DOS compiler owners can then divide both
these lists up and add the DOS portability information to them; Unix
compiler owners probably need only check the functions in the `neither'
list (since all Unices are POSIX, aren't they?).
> 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.
If we can sort out the format before then, and partition the alphabetical
listing suitably, perhaps some of us could make a start while you're away.
--
george DOT foot AT merton DOT oxford DOT ac DOT uk
ko tavla fo la lojban
- Raw text -