Re: [avr-gcc-list] FAQ (was: strange behaviour with ceil())

[Joerg Wunsch]

"E. Weddington" <address@hidden> wrote:

> I agree that perhaps a FAQ is necessary. Interestingly though, the
> questions discussed below are in multiple domains; not only AVR GCC
> and Unix newbie, but C language and embedded programming.

Certainly.

> For example, as you mentioned, the typical question about a missing
> volatile' is more of a C language issue or an embedded programming
> issue.

Well, it depends. :)

Since the details of the "volatile" type qualifier are only described
by the C standard in a fairly generic way, and some issues of it are
implementation-defined, this topic should at least be mentioned with
some emphasis in the AVR-GCC FAQ.

(Distinction between space and tab in Makefiles)

> As a side note, I would put forth the argument that any program
> should not make a distinction between TABS and SPACES.

Sure, but that's a merely historical point with the Unix make utility.
It's a bit too late to really change this now. ;-) (Although GNU make
does its best to allow for both forms, but see my initial posting,
relying on this will make a Makefile artificially incompatible with
other versions of make.)

> Much less, I'm not used to a library being called an "archive" and
> having a .a file extension, I'm used to a library with a .lib
> extension.  An archive in my mind is a backup.

Well, things like ZIP files are usually also called `archive'.  A .a
file is nothing else than an (uncompressed) ZIP file, it allows for
archiving arbitrary files.  In the special case of archiving object
files, the archive will additionally get a symbol table that allows
the linker to quickly find whether a particular symbol is defined in
that library, so the respective .o file can be extracted from the
archive, and linked to the program.  Also, the make utility has
special knowledge about archive members, and in addition to follow
dependencies on file dates, it can handle dependencies on archive
members as well.  Thus, you can use make to e. g. also update a .a
archive containing all your sources as soon as one source is modified.
(Sure, the time to handle all of this is in the milliseconds area
these days, so you probably won't notice the difference between
re-creating the entire archive and just updating one archive member,
even for a huge library...)

The Unix fathers were a bit lazy in typing.  (Actually, their
typewriters were running at 100 Baud, so they could only type 10
characters per second.)  This made them chose short command names, and
short filenames.  Thus, many standard filename suffixes in Unix are
single-letter only.

> After talking with Sander Pool off-line, I understand the reason for
> seperate libraries: Unix history. But...is it still justified in
> having that seperation?

Probably not.

> What is the down side in combining them?

My guess is that the initial reason for having them in separated
libraries were rather the address space limitations of the PDP-11 Unix
originates from.  By splitting off the mathematical library from the
remainder of the C library, they could overcome the effects of the
small 64 KB data address space.

These days, it's IMHO not warranted to really have two separate
libraries.  I'm all for it to combine all the functions in a single
libc.a, and ship an empty libm.a for compatibility (to not break
Makefiles that already use "-lm".)

Marek and Ted, what do you think about it?

> So perhaps a general AVR GCC FAQ is needed.

I already volunteered to maintain it. ;-)

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/
avr-gcc-list at http://avr1.org