From: Jody Bruchon <jody@jodybruchon.com>
To: ELKS <linux-8086@vger.kernel.org>
Subject: Cleaning up elkscmd and adding help text...any volunteers?
Date: Wed, 18 Mar 2015 08:43:34 -0400 [thread overview]
Message-ID: <550972F6.5000309@jodybruchon.com> (raw)
Hello all,
I'm currently spending time cleaning up the elkscmd code base. There's a
lot that needs to be done. A recent example is that the 'dd' command had
the infrastructure in place that would get the 'count=xxx' value from
the argument list, then simply did NOTHING with the specified count. I
have already fixed this bug but it is probably just one of many in the
elkscmd software collection.
Most of the code in elkscmd components is still K&R C. We've got a
compiler that is a K&R C compiler but it has an ANSI prototype handler
that we already use everywhere, so I'd like to see all of the K&R style
cleared out. You'll probably notice in the recent commit history that
I've been cleaning up ugly K&R C prototypes and modernizing the overall
code style. I'm building elkscmd programs with 'gcc -Wall -pedantic' to
find potential problems to fix and ANSI-fying the code makes GCC happier
(and looks better!)
One of my current goals is to introduce some simple help text into
elkscmd applications. I've already written usage help for 'dd' which
(somewhat tersely) gives the user information on what options are
available and what the expected command arguments are. The ELKS kernel
is reasonably stable, but basic commands are a pain to use.
We especially need help text because GNU and/or BusyBox commands is what
anyone trying ELKS will currently be used to. Users won't know how to
use the commands if they don't explain themselves. One example is how
the 'dd' ELKS command doesn't support 'conv=' or 'oflag=' while the
other two do.
If anyone wants to add help text to elkscmd components, feel free to do
so and send me some patches. My expectations are as follows:
* If main() doesn't have a return or exit() at the end, add one, and be
sure that the main() function is specified as 'int main' rather than
'void main' (all programs should return zero on success, so main() must
never be a void function.)
* If argument parsing is done in main() I expect the use of 'goto usage'
for all points where the help text should be displayed. A 'usage:' label
should be placed AFTER the return or exit() statement at the end of
main() instead of creating a separate usage() function when possible.
Every added function and function call increases binary size, so avoid
adding functions unless they introduce a net decrease in size or overall
complexity. See my changes to elkscmd/file_utils/dd.c if you need an
example.
* Regarding use of 'goto' statements in general: they may only be
forward-jumping. Don't write a usage section somewhere near (for
example) the top of main() and have future code 'goto' that place.
* If usage needs to be shown from places other than main(), write a
usage() function that does exit(1) at the end and call that...but see if
you can have the function(s) propagate error codes back to the
originating code in main() instead, which is usually a better choice and
avoids adding a new function.
* You don't have to clean up the K&R C prototyping since removing it
sometimes requires shuffling functions around; I'll clean it out
eventually. If you DO want to clean up prototypes, make sure they
compile correctly before sending me a patch.
* You can use GCC to error check most of the simpler programs and build
a native binary that'll run on your own system by running i.e. 'gcc
-Wall -pedantic dd.c -o dd' GCC has way better diagnostics than bcc,
especially the GCC 5 snapshots which have colorized diagnostic output.
Many problems that are missed by bcc get caught by GCC and make a lot of
noise. (GCC can't be used for ELKS-only programs like ktcp though.)
-Jody
next reply other threads:[~2015-03-18 12:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-18 12:43 Jody Bruchon [this message]
2015-03-18 13:24 ` Cleaning up elkscmd and adding help text...any volunteers? Alan Cox
-- strict thread matches above, loose matches on Subject: below --
2015-03-18 20:52 Juan Perez-Sanchez
2015-03-19 13:41 LM
2015-03-19 14:07 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=550972F6.5000309@jodybruchon.com \
--to=jody@jodybruchon.com \
--cc=linux-8086@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).