Re: OpenBSD C programming - getting started

From: jpd (read_the_sig_at_do.not.spam.it)
Date: 05/06/04 

Date: Thu, 6 May 2004 18:21:49 +0000 (UTC)

On 2004-05-06, Jesse Charbneau <groups@thecharbneaus.com> wrote:
> I have been using Linux/Unix for several years now and am familiar

Linux is not Unix[tm]. You also want to look up what `GNU' stands for.

[snip]
> 1.> When using gcc, how do I debug?

gdb? Maybe the old and trusted liberal use of printf()?

> I have tried to write some C
> (Kernigan and Richies C book, revised edition.) and found the book
> hard to follow,

I find that hard to believe. K&R is a classic on a programming language.
You are expected to know about programming language principles, though.

> and it didn't seem to cover gcc specifically.

The entirety of the gnu project didn't exist when K&R was written.
So that is entirely understandable.

> gdb has
> been mentioned to me before, but I haven't found a good tutorial/book
> on using it.

There's this site, and it's findable at

  http://www.gnu.org/software/gdb/documentation/

and it contains the official gdb documentation, including printable
manuals. Somewhere else on that site you can order printed documentation
as well. Further, one google for `gdb tutorial' provided at least six
interesting tutorials.

[insert snide commend about not finding caused by not searching here]

> 2.> I am specifically interested in using i386_iopl because I need to
> talk to an input ouput device.

You usually let the driver take care of that. If you'd know anything
about the architecture and philosophy of unix you'd know why. Heck,
even the newer windowses won't let you talk to hardware directly as
was commonplace in the dark ages of DOS.

If you want to write a driver (are you sure that is necessairy? can't
you use an existing and maybe generic driver?) you'll want to find out
how to do that for your ``linux/unix'' brand, whatever that may be.

> I found some code for use on freebsd
> but it talks directly to /dev/io, which obsd doesn't have (I have read
> that it was deprecated in favor of using i386_iopl()). What learning
> path should I be following to learn more towards this goal?

I'd start with writing programs that don't dig deep into hardware, first.
Pipe filters, maybe the odd (n)curses program, or something X if you feel
really masochistic. Later you can try communicating with devices, and
when you feel you've got the hang of that you can try something more
interesting. Starting with h/w-IO on a unix system is a bit early.

> I would
> also like to get to the point where I could possibly contribute to
> different projects (specifically openbsd and enlightenment).

You'll want to work on your code quality first. C is a language that
allows you to shoot yourself in the foot in various interesting ways,
but that doesn't mean that you then want to unleash that code on the
rest of the world. First see if you can get to the point where the
code does what you want it to do. After that, see how you can improve
so that it won't break in unexpected ways (for example, when it runs
on someone elses system). After that, see how you can improve so the
code is standards compliant, like C99 and POSIX and friends.

Don't get me wrong, writing programs is interesting, but getting it
right is far from trivial. Even in a ``simplified'' and ``fool proof''
language like java. C syntax is nicely simple, but writing code in it
is _not_ simplified or fool proof. 

-- 
  j p d (at) d s b (dot) t u d e l f t (dot) n l .