bug in avr-gcc (WinAVR User Manual - 20050214)?

Comments:

1) Don't say bug, it won't make you any friends around here. 2) Did you switch on all warnings? -Wall 3) What assembler does it generate?

Peter

Did I say, "bug"? I meant to say, "perceived non-conformance with expected behaviour" ;-)

I looked at the .lst file that was generated and it seems to be the same even if it has the 'rouge' line in it - so, it's silently dropped (on my setup), even though I'd never be able to get something like this past MS Developer Studio.

yes, -Wall is on, but I may not be getting any warnings (my development environment is a bit broken) - it was inherited, but I've 'upgraded' to support a newer Atmel Processor (ATmega8535) and something's not quite right - I can build to the point where I get the flash hex file that can successfully be downloaded and confirmed as working on the hardware, but the make file (avr_freaks version) bombs out somewhere after step 8 (I changed the format from 'avrobj' to 'coff-avr' (sort of at random) to get it past stage 8).

The only reason that even got this far was by using a file monitor to see what gcc, et al. files were coming up as 'not found' during the build - is gcc always this hard on the user?

(From my experience if IAR Workbench on a previous project, I'd easily pay the money for that (if it could be budgeted) rather than have all this hassle with gcc.)

Thanks.

On Sat, 12 Mar 2005 14:59:58 -0000, "Joe" wrote in comp.arch.embedded:

What version of gcc is involved? And what is "... stuff"?

Even assuming that "... stuff" contains executable statements, the last line is a function prototype declaration. Prior to the 1999 version of the C language standard, declarations are not allowed after executable statements in a block. But since 1999 they are, so the code is quite legal if you are compiling with the current C standard.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

Okay, that explains it - I'm just behind the times.

Why would someone want to put a function prototype at the end of a function like this (I suppose it's to reduce the scope of the prototype - but it seems clumsy - it's certanly not elegant.).

Thanks.

easily pay

this

cost of IAR merely for a guarantee I would never have to use it (IAR) ever again. Bugs, oddities, HUGE COSTS every time you discover a bug, dongle protection, HUGE COSTS for upgrades that should be free to fix bugs, ineffectual tech support, and did I mention HUGE COSTS every time you report a bug and request what ought to be a free fix for noncompliance with advertised capabilities?

gcc delivers exactly what it promises, for the advertised price.

There was a bit of discussion regarding this on the avr-gcc list I think. It was mentioned that this functions within functions support by gcc could be very usefull if one had to port a large pascal application to C.

Regards Anton Erasmus

... except that nested functions is not what the case at hand is about.

It's about a function *declaration* found inside some other functions. That's bad style, you should generally never do that, but it's allowed. And as of C99, it's even allowed anywhere inside an statement block, instead of only in its beginning.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

I think it is the wrong question. The standard allows prototypes (and AFAIK variable declarations) anywhere in the function. The compiler cares (not much) about sense and nonsense of what the programmer writes.

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use @monlynx.de instead !