Is WINAVR crap or what?

The original C language wasn't particularly well designed for portability, or for dealing with asynchrony (interrupts and threads). There are just too many areas in which the behavior of the code is less than fully defined... it's up to the compiler or runtime implementor. Code which works on one system can fail on another, because the two systems' compilers have slightly different behavior... and *both* behaviors are legal C.

Dealing with those issues (via language extensions, and the liberal use of standardized APIs and #include files) has probably been the biggest area of work and progress in C in the years since it was invented.

Achieving true code portability is harder than you might expect, and if you want your code to be portable, it's important to take advantage of the more rigorous features and coding standards of versions of C which are rather newer than K&R. It's also important that you code up everything in ways which *explicitly* result in a well-defined behavior, rather than depending on side effects.

Near-worse-case example: C says that the value 0, in source code, is the language representation of a NULL pointer. However, it does *not* say that the actual representation of NULL in memory (or in registers) consists of zero bits! There are a few oddball machine architectures on which an address register containing the numeric value 0 is an explicitly legal and useful pointer... and NULL has an internal representation different than zero bits (e.g. on Honeywell L66 systems, NULL is represented by the hardware as 06014).

On these architectures, if you initialize a block of memory to all zero bits, and then expect that this action has successfully initialized pointers within this block to NULL, you'll be wrong! You must *explicitly* assign a NULL or zero value to each pointer (and the compiler will "see" that you're assigning zero, and convert to the local representation of NULL).

ings

might

s a

ns the

ated).

vious

Arlet Ottens expounded in news:4d0be95b$0$81476$ snipped-for-privacy@news.xsall.nl:

The main problem is that with winavr you're working in a hostile development environment. It's not winavr's fault if you work in the "DOS box". Linux would give a better experience, but you'd still be using a make file.

As a compromise, I use Cygwin to give me a Unix like environment under Windows. However, that alone won't make winavr happy, because it is native windows and cygwin is not (but with some scripting you can work around it).

The recommended way (aside from GUI IDE solutions) seems to be either to run from MSYS or to use and install the windows native suggested make command. But you don't like makefiles, so that isn't going to help you much.

If you're in a hurry, you'll want one of the IDE suggested solutions instead.

Even MS Visual Studio (or whatever it is called today) uses their brand of makefile underneath the hood.

The only other alternative is to go with the Arduino environment, which hides the makefile from you. But that has its own disadvantages. ;-)

Warren

Nico Coesel expounded in news: snipped-for-privacy@news.kpnplanet.nl:

If it deleted my work, it really would be The F'n Manual (in RTFM).

On acronyms: I love the recent Wiki[leaks] Task Force (WTF) acronym.

Warren