Mail Archives: djgpp-workers/1998/02/11/21:41:43
George Foot wrote:
>
>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.
That's a good idea.
>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.
They do, but on the *other* other hand, Unix is also missing some
functionality that DJGPP provides. For instance, in the `fork' example. The
standard way on DOS of running another program is with `spawn', but Unix
doesn't have that. One has to use `fork' and `exec' instead. Saying that
"DJGPP's `fork' doesn't really work", and saying "On Unix, `fork' does work
and here is what it does" are two different things. But going with the
second alternative is rather outside the scope of DJGPP.
Perhaps the solution is to try to confine ourselves to mentioning other
platforms where the behavior is "less than" DJGPP's, like DOS `stat's not
reporting the inode number. When we describe additional things done by other
implementations, we start documenting them instead of DJGPP, and that is
really the other platform's job. It is a fine line, though.
I like Eli's suggestion of using that space in the docs to mention specific
porting problems encountered before. I suspect most of the theoretical flood
of overly detailed info on other systems will not materialize, due to being
too much work.
>It's dangerous to label any system as a typical system.
You're right. I shouldn't have implied Linux as being typical. I think it
will be useful though, since its documentation is freely available and it's
not too weird of a Unix-alike.
> 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.
That sounds really good.
>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.
It might be easier still to divide it by header, since that way people don't
have to grep the entire batch of headers for each function. It's a little
harder to divide "equally" that way, but that may not be too important.
> 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
I wonder how should we coordinate all this. Do we swamp djgpp-workers with
passing these lists back and forth? Is that a problem?
>(since all Unices are POSIX, aren't they?).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In a perfect world, yes. In real life, no. But I suspect as far as a C
library goes, most Unices will be close.
>I think you/we should decide how to format the information, and how much
>information to give.
Okay, here's an imaginary example of how an entry might look. I'll have to
look over how the Texinfo formatting would work, but I believe it's simple.
It's off the top of my head, but I hope it gives the basic idea.
`frob'
#include <foobar.h>
int frob();
...
Portability
POSIX. Provided by other DOS compilers, in <mumble.h>.
Most DOS compilers don't twiddle the frobozzicator when calling this
function. Borland C does.
Other ideas welcome.
>> 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.
Incidentally, I do plan to stay subscribed to djgpp-workers.
>
>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.
As I mentioned above, it might be easier to do it per-header, and that could
be done on a volunteer basis. Any help would be wonderful.
Oh, another thought. Should this be worked on relative to the 2.02 alpha, or
just to 2.01? I think 2.02 adds some documentation. If we do, can somebody
do me a favor and give me a complete pointer to the alpha? I can only ftp
through an ftp-email server, and searching for things that way is very
tedious. (Yes, I do plan to get better Internet service Real Soon Now...)
I really appreciate all this constructive criticism. Thanks, everyone!
Nate Eldredge
eldredge AT ap DOT net
- Raw text -