Planned coverage of CookBook/Matrix, mySituation (was months ago: Requesting advice how to clean up C code for validating string represents integer)

From: Flash Gordon <s...@xxxxxxxxxxxxxxxxxx>
Anyway, of course there is lot of system-specific functions
which do lot of good. Do you not agree this guy should not
put those in his cooksomething?
I'd still be interesting to see *vast* number of functions
like that which do something of interest in that cookthing.
Functions for networking (getting MACs for NICs is very useful
but IIRC you need to go beyond POSIX on nix boxes to do it),

I intend eventually to include networking (sockets, streams, etc.)
eventually after I finish the more basic stuff (and maybe some
stuff rather soon if I feel like it), and I already have stubs for
those future sections of my CookBook/Matrix:
<http://www.rawbw.com/~rem/HelloPlus/CookBook/Matrix.html>
Input/Output:
...
* [Local interprocess streams]
* [InterNet TCP streams]
* [InterNet datagrams]
<http://www.rawbw.com/~rem/HelloPlus/CookBook/ConPara.html>
Table of contents:
...
* [RPC (remote procedure call), RMI (remote method invocation)]

If POSIX is incompatible with all those topics, I may need to
include it in a separate chapter. Please let me know if in your
opinion that's the case.

To my knowledge, "NIC" means Network Information Center, such as
APNIC, JPNIC, KRNIC, etc. If you're using it to mean something
else, please explain.

functions for graphics,

I have no access to any computer where I would be able to test
graphics in even one of those six languages, much less in all six,
so I won't be including anything whatsoever about graphics in *my*
document. But if you would be willing to write your own chapter on
graphics in all six languages, multiple specific implementations on
multiple specific platforms (Unix/FreeBSD/Solaris/SunOS/etc.,
Linux/RedHat/etc., Mac System 6.0.x, Mac System 7.5.x, Mac System
10.x, and a whole slew of various MS-Windows versions
NT/2000/whatever), I'd be glad to give a cursory browse of it to
verify that it conforms to my basic CookBook/Matrix idea, then
include it virtually in my document as an external chapter-link.

functions for threads etc.

That's already planned, but only in a limited way, because while
it's built into the standard Java port, it's only a vendor-add-on
in the other languages so I'd be able to test it only in a very
limited way, basically only java version 1.2.2 and CMUCL version
18b, AFAIKATM. Hmm, I don't yet have a stub for that section,
adding it now ... done:
<http://www.rawbw.com/~rem/HelloPlus/CookBook/ConPara.html>
Table of contents:
...
* [multi-processing, threads]
If you volunteer to write sub-sections for threads on other
platforms, I'd be glad to link it in if it meets my standards.

If a "CookBook" is going to cover such things, which is not
unreasonable,

Agreed (with caveat that graphics isn't possible for me to
personally cover).

then it will need to cover system specifics.

Not for threads in java, and some other features in various
languages that are portable, but yes to completely cover any one of
those topics for all six languages will require system-specific
coverage for at least one of the languages. In the short run I'll
simply say that in such-and-such language there is no portable way
to accomplish the task, and describe how-to only for the few
languages where it *is* portable. Later, I haven't decided whether
to *ever* include the system-specific info.

Of course, it should clearly mark what is system specific.

Yes, agreed, if I ever include anything like that.

There's also the matter of standard-version-specific, such as
strtoll which is in C1999 but not C1990 (I'm fed up with being
non-y2k-safe in such jargon!! <OT>I'm getting shitloads of spam
that says it was sent in the year 37 or 38, which Yahoo! Mail
treats as if it were sent from the future year 2037 or 3038
respectively, when IMO Yahoo! Mail should blanket reject all such
grossly-mis-dated e-mail</OT>).

If you tell them it is only in the latest standard and they find
it is not in the latest and greatest from <insert provider of
dislike> then they will not only learn that provider as not kept
up but also what it is the provider is not doing.

I agree. Furthermore, if *every* function/operator/method per some
older standard *is* in that particular implementation, and it's
only the newly-standardized stuff that's not present, then the user
knows the company *was* up to date before the standard changed out
from under them, so they should be given some slack, like ten years
to finally finish upgrading their product for the new standard, so
give them two more years slack on the issue of C1999. On the other
hand, if not even the 17-year-old standard (C1989/C1990) is fully
implemented, it's seriously time to find a new vendor who respects
portability issues even a teensy bit.

Providing random information about system specific stuff is bad
for one set of reasons (although non-random clearly marked system
specifics is not). Sticking to C99 only is bad for different
reasons.

Agreed. I'm currently leaning toward treating all ten-or-more-year-old
standard as given fact, and flagging all within-past-ten-years
changes specially to alert users that even a good implementation
(such as GNU C) might not yet have all that new stuff.

This chap has given the impression that he is using some form of
remote system which he probably does not own or control.

That's correct. I use a commercial ISP which is running FreeBSD
Unix, and which is accessible from home only via VT100 dialup.
I have no control whatsoever, and extremely little influence, on
what man pages or upgrades to java etc. the admin chooses to
install or not. Witness only java 1.2.2 installed to date.
Even my laptop (that I got for free, with modem that died so I
can't produce any content there for upload) has java 1.3 something.
As for gcc, man pages don't tell any way to learn which version
number it is, so I have no idea which version I'm using.

Dear newbie reading this stuff and thinking I am right: no way,
forget and ignore all I say.
Is this better now?
Currently that warning belongs on Robert's site!

Not at all. I actually need eager newbies with lots of energy to
try various methods (*) I suggest in my CookBook/Matrix and tell me
whether some text was confusing or unacceptably incomplete or
outright wrong. My instant-alert Web service can be used to report
short errata, or to alert me that longer errata have been e-mailed
so I know to search for it among tes of thousands of spam it's
mixed with. (If you think looking for needle in haystack is hard!!)

* (not OOP sense, more general sense: operator/[generic]function/OOPmethod)

<meta>Hmm, I think in the future when I use the word "method" in
that original general sense, I'll just use SGML/XML markup:
<general>method</general>, and when I use the word in the OOP sense
I'll mark it <oop>method</oop> instead. Would that be clearly
understood by everyone here?</meta>
.

Quantcast