Topics

Compiler warnings

Jack Purdum
 

All:

Several people have asked about compiler warnings they are getting, like:

        warning: ISO C++ forbids converting a string constant to 'char*'

A variation on this are the "deprecated" warnings issued by the compiler. Even more confusing is the fact that the warnings they now see were not there before. Usually, this is because of a compiler update. As a general rule, compiler warnings do not prevent the compile from finishing or performing an upload. However, warnings mean something is bending the rules. For anyone who might be interested, this was my answer to one of those people.


Steve:

I think everyone understands what a syntax error is: Not following the rules of the language. Semantic errors are more difficult because the rules are followed, but the context is wrong. For example, we know an English sentence needs a noun and a verb...those are the rules. However, if I say: "The dog meowed.", it obeys the syntax rules, but the semantics are out of context. I'm not sure how far back, but around version 1.65 the GCC compiler started performing some syntax and semantic checking at the "lint" level. My company produced a C compiler back in the '80's and we had a "picky flag" that could be set from 0 to 10. It performed syntax and semantic checks at increasing stringent levels. I never saw any published C code that passed our Picky Level 10. Indeed, that level was so intrusive that we never used it. Most work was done at Picky Level 4. When we were ready for distribution, we cranked it up to level 10. Truth be told, we still didn't bother to fix some of the warnings. Somewhere between 1.65 and 1.85 they kicked the GCC compiler's equivalent of our Picky Flag up a notch, hence warnings now where none existed before. That's a good thing.

However, the bad thing is that there are now a lot of warnings that unnecessarily cause people concern. Even worse, a lot of it comes from libraries, which is NOT your responsibility to fix. The library writer should fix those. When I first compiled the µBITX code, I had probably a hundred such warnings, mainly because I insisted on using only one INO file, making all the other CPP files (plus a header). True, it was a pain in the butt to fix all the warnings, but it was worth it. Why? First, by not using multiple INO files, the compiler cannot perform data type checking. You'd be surprised by how many bugs hide under the blanket of missing type checking. Second, because the compiler no longer has to glom all the source files into one huge file to compile it, it allows the GCC to perform incremental compiles. This is a HUGE win. When I compile the JackAl code for the first time in the morning, it must recompile all files. In the process, it clears the "dirty flag" for each source file. Even with my 8-core, 3.7GHz machine with a mega-munch of memory, the JackAl code takes almost 2 minutes to compile. If I used all INO files, it would always take 2 minutes to compile the source code regardless of how many file changes I made. With incremental compiles, it sets the dirty flag and recompiles only those files that have changed since the last compile. This drops my compile time (on a single-file change) to about 5 seconds. Given that I might do 30-50 compiles a day, you do the math

Kind of a long answer, but it's important that you understand what's going on "under the hood" from time-to-time. Usually, compiler warnings can be ignored, but always keep in mind it still means the compiler saw something it didn't like.

Jack, W8TEE

On Thursday, June 28, 2018, 7:13:32 PM EDT, Steve Smith <steve@...> wrote:


thanks - I erased the EPROM and then calibrated and I am getting real results. These were new part so I am not sure how the EPROM would have had values, but the first few times we loaded the software we did not have an SD card in. Could that have affected it?

Also, thanks for the explanation of the warnings, Jack. I am running version 1.85 of the Arduino IDE on Windows 10. Is there a reason some folks get the warnings and others don't? Is it a setting in the IDE?

73s

Steve

Tom, wb6b
 

Good rundown on warnings.

Fortunately we haven't had a new idealistic programmer decide to set the -Werror complier flag yet. That was great fun unleashed at the worst possible moment.

Tom, wb6b

ajparent1/KB1GMX
 

I take them seriously as it impacts future upgrades of the compiler which may
not accept it at all.  That and its a basic fix.

I'm an old Pascal user and wild type changes were not permitted.  

Also old assembler writer where you can do terrible things and
maybe survive.... ouch!


Allison

AA9GG
 

C++ and micro-controllers do not really play well together.  That is why I use strictly ANSI C.

On Sat, Jun 30, 2018 at 2:11 PM, ajparent1/KB1GMX <kb1gmx@...> wrote:
I take them seriously as it impacts future upgrades of the compiler which may
not accept it at all.  That and its a basic fix.

I'm an old Pascal user and wild type changes were not permitted.  

Also old assembler writer where you can do terrible things and
maybe survive.... ouch!


Allison




--
Paul Mateer, AA9GG
Elan Engineering Corp.
www.elanengr.com
NAQCC 3123, SKCC 4628

Jack Purdum
 

Really? Why do you say that? I find the OOP benefits to be well worth the effort to use them, especially encapsulation.

Jack, W8TEE

On Sunday, July 1, 2018, 10:59:38 PM EDT, AA9GG <paul.aa9gg@...> wrote:


C++ and micro-controllers do not really play well together.  That is why I use strictly ANSI C.

On Sat, Jun 30, 2018 at 2:11 PM, ajparent1/KB1GMX <kb1gmx@...> wrote:
I take them seriously as it impacts future upgrades of the compiler which may
not accept it at all.  That and its a basic fix.

I'm an old Pascal user and wild type changes were not permitted.  

Also old assembler writer where you can do terrible things and
maybe survive.... ouch!


Allison




--
Paul Mateer, AA9GG
Elan Engineering Corp.
www.elanengr.com
NAQCC 3123, SKCC 4628

ajparent1/KB1GMX
 

I wondered on that too.

Some of C++ features are bulky but for Arduino you don't use them. But it makes building reusable code far easier.
Encapsulation is a useful one and I don't see any cost for it in the code size.

OF course if your that concerned about space....  A good macro assembler for the target machine works.

Allison

AA9GG
 

Google "oop and microcontrollers" or "C++ and microcontrollers" .  The main reason is the code bloat OOP generates

On Mon, Jul 2, 2018 at 10:16 AM, ajparent1/KB1GMX <kb1gmx@...> wrote:
I wondered on that too.

Some of C++ features are bulky but for Arduino you don't use them. But it makes building reusable code far easier.
Encapsulation is a useful one and I don't see any cost for it in the code size.

OF course if your that concerned about space....  A good macro assembler for the target machine works.

Allison




--
Paul Mateer, AA9GG
Elan Engineering Corp.
www.elanengr.com
NAQCC 3123, SKCC 4628

ajparent1/KB1GMX
 

As someone that cut their teeth is the '70s with K&R C the biggest thing I see is poor programming
not poor programming languages.  I also grew up in systems where resources are scarce and 
adding them was expensive.  So pardon me if I think 32K of code space, 1k of eeprom and 2K
of ram is a lot of space.  Sure beats 8749 with 2K of program Eprom, 128byts of ram and a timer.

OOP is not a bad word but it may be very stupid in a machine with maybe 2K of ram, code
accordingly.  The problem is coders (not programmers) that figure if it doesn't fit use a bigger
chip.  Then again if the objects are small it can be useful.  For example a Arduino Mega2650
running a two axis (elevation and azimuth) antenna control that serves out position and
tracking as a web page.  No it isn't full and it even gets the TLEs for the Sat to track via
the web page.  One of these days I need GPS and a electronic compass so it knows
where it is and what way is north so I can move it with out calibrating it afterwards.
Writing that in plain ansi C is just more error prone work than it needs to be.


Allison

Jack Purdum
 

Writing that in plain ansi C is just more error prone work than it needs to be.

What is your suggestion to fix that?

There are elements of C++ that I don't like and tend to be misused (e.g., multiple inheritance). However, one can practice the OOP concept of encapsulation even within the confines of ANSI C, and that's a very good thing. Perhaps the two biggest mistakes I see made by beginning programmers are 1) the reliance on globally-scoped variables and 2) trying to write functions that do too much (i.e., they are not "cohesive"). A globally defined variable means that every single statement in the program has the ability to change that variable. It's like placing a hooker at the top of the program and giving every statement in the program a $50 bill and, after something goes wrong, trying to find out who the father of the error is. Encapsulation at least lessens the scope of the error search.

If you can't tell someone what a function does in two sentences or less, it is not cohesive. Another tip off is a function that has a bunch of variables passed to it, especially variables that are little more than flag variables. Writing Swiss Army knife functions may seem like a good idea, but they are almost always too complex for the task at hand and, because they try to do too much, they are rarely reusable.

Just paying attention to those two things as you write code will make the code less error-prone. Personally, I've used a lot of different languages over the years and I still think C is the best. There must be some agreement, otherwise it wouldn't be the first language most companies resurrect on a new processor and it wouldn't have lasted over 40 years.

Jack, W8TEE

On Monday, July 2, 2018, 12:08:58 PM EDT, ajparent1/KB1GMX <kb1gmx@...> wrote:


As someone that cut their teeth is the '70s with K&R C the biggest thing I see is poor programming
not poor programming languages.  I also grew up in systems where resources are scarce and 
adding them was expensive.  So pardon me if I think 32K of code space, 1k of eeprom and 2K
of ram is a lot of space.  Sure beats 8749 with 2K of program Eprom, 128byts of ram and a timer.

OOP is not a bad word but it may be very stupid in a machine with maybe 2K of ram, code
accordingly.  The problem is coders (not programmers) that figure if it doesn't fit use a bigger
chip.  Then again if the objects are small it can be useful.  For example a Arduino Mega2650
running a two axis (elevation and azimuth) antenna control that serves out position and
tracking as a web page.  No it isn't full and it even gets the TLEs for the Sat to track via
the web page.  One of these days I need GPS and a electronic compass so it knows
where it is and what way is north so I can move it with out calibrating it afterwards.
Writing that in plain ansi C is just more error prone work than it needs to be.


Allison

Steven Read
 

Nice explanation Jack! People who write standards need to realize there are are many programs they break with changes like this. Myself, I go "tweak" the source when I get something like this but I am a bit obsessive about getting a clean compile. Inflicting things like this on the average Joe is a lousy way to run a railroad!

On Thu, Jun 28, 2018 at 10:53 PM, Jack Purdum via Groups.Io <jjpurdum@...> wrote:
All:

Several people have asked about compiler warnings they are getting, like:

        warning: ISO C++ forbids converting a string constant to 'char*'

A variation on this are the "deprecated" warnings issued by the compiler. Even more confusing is the fact that the warnings they now see were not there before. Usually, this is because of a compiler update. As a general rule, compiler warnings do not prevent the compile from finishing or performing an upload. However, warnings mean something is bending the rules. For anyone who might be interested, this was my answer to one of those people.
 
--
Steven Read - ab9ol - Dublin, Indiana (em79jt)

ajparent1/KB1GMX
 

I like your rules Jack.

My standard for a function or any subroutine is simple do one thing.
I guess that matches your no swiss knives.  I call them overloaded functions.

I think the best example of that is the SD library as it drags in FAT.  Its huge 
and if all you want to do is read or write blocks FAT is not needed or even
a file system.  Or you can just do tag and bag directory and teach the PC 
to use a simpler system to talk to a block device.  That is only one example.
Took me a while to tear the whole thing down to block_Write(blockNum, Buffer)
and block_read(blockNum, Buffer)  Where buffer is a 512 byte area, and
blockNum is a 32bit int.  The difference is more than 10K of code!

Global variables are ok if used for that only.  Not be cause the tuning math
needed a variable to store and intermediate result.

The offense i've seen is long ints when the counter never exceeds maybe 10
and floats when the value is going to be an integer.   Its remarkable that
people forget the iron they are programing is basically a 8 bit byte machine.

C and for that fact C++ is a small language, the libraries are where people
get their shorts eaten.  You don't need a full string library for a little 8bitter.

C seems to be there when others have come and gone.  Just about all the
others are easy (Ruby, Python, Java) if you know C.

A a long time PDP11 user (I have Unix V2.11 and Ultrix V6(BSD flavor).
ITs funny to thing the 11 is a near native C machine (very CISIC) and
the origin point for C and typically 128K bytes was a big machine. 
It teaches one brevity, modularity, and with care clarity.  

I still use Small-c on many micros because it is C (more K&R than ansi but hey
it was the 70s and ANSI was over a decade later) and small.    I like it because
it allows me to get as close to the irn as I care to and yet hide the iron when I
need to. 

Allison

Howard Fidel
 

Allison:
PDP11, wow that goes back quite a while. We used one in the first commercial product I was involved in designing from the ground up, way back in 1975.

Howard

On 7/2/2018 10:46 PM, ajparent1/KB1GMX wrote:
I like your rules Jack.

My standard for a function or any subroutine is simple do one thing.
I guess that matches your no swiss knives.  I call them overloaded functions.

I think the best example of that is the SD library as it drags in FAT.  Its huge 
and if all you want to do is read or write blocks FAT is not needed or even
a file system.  Or you can just do tag and bag directory and teach the PC 
to use a simpler system to talk to a block device.  That is only one example.
Took me a while to tear the whole thing down to block_Write(blockNum, Buffer)
and block_read(blockNum, Buffer)  Where buffer is a 512 byte area, and
blockNum is a 32bit int.  The difference is more than 10K of code!

Global variables are ok if used for that only.  Not be cause the tuning math
needed a variable to store and intermediate result.

The offense i've seen is long ints when the counter never exceeds maybe 10
and floats when the value is going to be an integer.   Its remarkable that
people forget the iron they are programing is basically a 8 bit byte machine.

C and for that fact C++ is a small language, the libraries are where people
get their shorts eaten.  You don't need a full string library for a little 8bitter.

C seems to be there when others have come and gone.  Just about all the
others are easy (Ruby, Python, Java) if you know C.

A a long time PDP11 user (I have Unix V2.11 and Ultrix V6(BSD flavor).
ITs funny to thing the 11 is a near native C machine (very CISIC) and
the origin point for C and typically 128K bytes was a big machine. 
It teaches one brevity, modularity, and with care clarity.  

I still use Small-c on many micros because it is C (more K&R than ansi but hey
it was the 70s and ANSI was over a decade later) and small.    I like it because
it allows me to get as close to the irn as I care to and yet hide the iron when I
need to. 

Allison


Jack Purdum
 

Yep, I think we think alike on this. I think Ron Cain was the inventor of Small C and I remember using that on my 8080/CP/M machine. Then I found Zeor Zollman's BDS C and I tried to get him to add floating point and structs to it...even met with him in Boston while he was at MIT...but couldn't convince him to do it. My company ended up writing our own C compiler, Eco C-88: the first with a complete IDE...even before Turbo C. (We needed the floating point because we developed and sold an advanced statistics package.)

You're right, there's a lot of what I call RDC (Really Dumb Code), and not all of it's by beginning programmers. I was hired as a consultant by a company that wrote banking software. One piece of commercial code had a 31 level if-else block, where one routine ran each day and all the others were ignored. Some banks using the code had over two million customers. Given that, on average there would be 15 failed comparisons for millions customers each day, we figured some banks were throwing away over 30 minutes of CPU time each day versus using a switch statement. I pointed this out in a code walk through stating it was a really stupid piece of code. I was fired that afternoon. Turns out, the person who hired me wrote the code and everyone in the room knew it!

As far as the Arduino environment, I do like it and think it's a great way to a lot of people to experience what programming's all about, yet have some fun at the same time. I do wish, however, that people who write libraries for the IDE would stay on top of their libraries and fix the warnings that keep popping up as the compiler checks get tighter.

It seems like most knowledgeable EE types, like yourself, are also accomplished programmers. Alas, I'm living proof that it doesn't go the other way. I enjoy reading your comments and I know all of us have benefited from them.

Jack, W8TEE

On Monday, July 2, 2018, 10:46:16 PM EDT, ajparent1/KB1GMX <kb1gmx@...> wrote:


I like your rules Jack.

My standard for a function or any subroutine is simple do one thing.
I guess that matches your no swiss knives.  I call them overloaded functions.

I think the best example of that is the SD library as it drags in FAT.  Its huge 
and if all you want to do is read or write blocks FAT is not needed or even
a file system.  Or you can just do tag and bag directory and teach the PC 
to use a simpler system to talk to a block device.  That is only one example.
Took me a while to tear the whole thing down to block_Write(blockNum, Buffer)
and block_read(blockNum, Buffer)  Where buffer is a 512 byte area, and
blockNum is a 32bit int.  The difference is more than 10K of code!

Global variables are ok if used for that only.  Not be cause the tuning math
needed a variable to store and intermediate result.

The offense i've seen is long ints when the counter never exceeds maybe 10
and floats when the value is going to be an integer.   Its remarkable that
people forget the iron they are programing is basically a 8 bit byte machine.

C and for that fact C++ is a small language, the libraries are where people
get their shorts eaten.  You don't need a full string library for a little 8bitter.

C seems to be there when others have come and gone.  Just about all the
others are easy (Ruby, Python, Java) if you know C.

A a long time PDP11 user (I have Unix V2.11 and Ultrix V6(BSD flavor).
ITs funny to thing the 11 is a near native C machine (very CISIC) and
the origin point for C and typically 128K bytes was a big machine. 
It teaches one brevity, modularity, and with care clarity.  

I still use Small-c on many micros because it is C (more K&R than ansi but hey
it was the 70s and ANSI was over a decade later) and small.    I like it because
it allows me to get as close to the irn as I care to and yet hide the iron when I
need to. 

Allison

w7hd.rh
 

How this brings back memories.  I learned C on a Unix V7 machine (PDP-11/45) using the original Bell Labs code.  I was working for Pacific Northwest Bell at the time and wrote most of the automated data-gathering code in C for remote sites all over Oregon, Washington and Idaho.  Since the code ran in the wee hours of the morning, it had to be fast to gather and compile all the data for all those sites, so brevity was key there.
Then I went on to learn Pascal at Oregon Heath & Sciences center.  When I finally got my own personal computer in 1977, I used Whitesmiths C compiler on a Z80 based MP/M system.  Wrote a satellite-tracking program for our ham club and had great fun re-learning Solid Geometry.

Ron W7HD


On 07/02/2018 07:46 PM, ajparent1/KB1GMX wrote:
I like your rules Jack.

My standard for a function or any subroutine is simple do one thing.
I guess that matches your no swiss knives.  I call them overloaded functions.

I think the best example of that is the SD library as it drags in FAT.  Its huge 
and if all you want to do is read or write blocks FAT is not needed or even
a file system.  Or you can just do tag and bag directory and teach the PC 
to use a simpler system to talk to a block device.  That is only one example.
Took me a while to tear the whole thing down to block_Write(blockNum, Buffer)
and block_read(blockNum, Buffer)  Where buffer is a 512 byte area, and
blockNum is a 32bit int.  The difference is more than 10K of code!

Global variables are ok if used for that only.  Not be cause the tuning math
needed a variable to store and intermediate result.

The offense i've seen is long ints when the counter never exceeds maybe 10
and floats when the value is going to be an integer.   Its remarkable that
people forget the iron they are programing is basically a 8 bit byte machine.

C and for that fact C++ is a small language, the libraries are where people
get their shorts eaten.  You don't need a full string library for a little 8bitter.

C seems to be there when others have come and gone.  Just about all the
others are easy (Ruby, Python, Java) if you know C.

A a long time PDP11 user (I have Unix V2.11 and Ultrix V6(BSD flavor).
ITs funny to thing the 11 is a near native C machine (very CISIC) and
the origin point for C and typically 128K bytes was a big machine. 
It teaches one brevity, modularity, and with care clarity.  

I still use Small-c on many micros because it is C (more K&R than ansi but hey
it was the 70s and ANSI was over a decade later) and small.    I like it because
it allows me to get as close to the irn as I care to and yet hide the iron when I
need to. 

Allison


-- 
Ron W7HD - NAQCC#7587 OMISS#9898 KX3#6966 LinuxUser#415320
Editor OVARC newsletter

Jack Purdum
 

Ron:

We tried the Whitesmith's C compiler, and tested its floating point with:

   for (int i = 0; i < 10000; i++) {
      printf("%f", (double) i);
   }

it literally took about a second to print out each number! It was a port from a PDP-11 and it was a dog.

Jack, W8TEE

On Monday, July 2, 2018, 11:27:06 PM EDT, w7hd.rh <w7hd.rh@...> wrote:


How this brings back memories.  I learned C on a Unix V7 machine (PDP-11/45) using the original Bell Labs code.  I was working for Pacific Northwest Bell at the time and wrote most of the automated data-gathering code in C for remote sites all over Oregon, Washington and Idaho.  Since the code ran in the wee hours of the morning, it had to be fast to gather and compile all the data for all those sites, so brevity was key there.
Then I went on to learn Pascal at Oregon Heath & Sciences center.  When I finally got my own personal computer in 1977, I used Whitesmiths C compiler on a Z80 based MP/M system.  Wrote a satellite-tracking program for our ham club and had great fun re-learning Solid Geometry.

Ron W7HD


On 07/02/2018 07:46 PM, ajparent1/KB1GMX wrote:
I like your rules Jack.

My standard for a function or any subroutine is simple do one thing.
I guess that matches your no swiss knives.  I call them overloaded functions.

I think the best example of that is the SD library as it drags in FAT.  Its huge 
and if all you want to do is read or write blocks FAT is not needed or even
a file system.  Or you can just do tag and bag directory and teach the PC 
to use a simpler system to talk to a block device.  That is only one example.
Took me a while to tear the whole thing down to block_Write(blockNum, Buffer)
and block_read(blockNum, Buffer)  Where buffer is a 512 byte area, and
blockNum is a 32bit int.  The difference is more than 10K of code!

Global variables are ok if used for that only.  Not be cause the tuning math
needed a variable to store and intermediate result.

The offense i've seen is long ints when the counter never exceeds maybe 10
and floats when the value is going to be an integer.   Its remarkable that
people forget the iron they are programing is basically a 8 bit byte machine.

C and for that fact C++ is a small language, the libraries are where people
get their shorts eaten.  You don't need a full string library for a little 8bitter.

C seems to be there when others have come and gone.  Just about all the
others are easy (Ruby, Python, Java) if you know C.

A a long time PDP11 user (I have Unix V2.11 and Ultrix V6(BSD flavor).
ITs funny to thing the 11 is a near native C machine (very CISIC) and
the origin point for C and typically 128K bytes was a big machine. 
It teaches one brevity, modularity, and with care clarity.  

I still use Small-c on many micros because it is C (more K&R than ansi but hey
it was the 70s and ANSI was over a decade later) and small.    I like it because
it allows me to get as close to the irn as I care to and yet hide the iron when I
need to. 

Allison


-- 
Ron W7HD - NAQCC#7587 OMISS#9898 KX3#6966 LinuxUser#415320
Editor OVARC newsletter

Brian Bowling
 

Turns out, the person who hired me wrote the code and everyone in the room knew it!

Well, almost everyone anyway. :)

On Mon, Jul 2, 2018 at 11:14 PM, Jack Purdum via Groups.Io <jjpurdum@...> wrote:
Yep, I think we think alike on this. I think Ron Cain was the inventor of Small C and I remember using that on my 8080/CP/M machine. Then I found Zeor Zollman's BDS C and I tried to get him to add floating point and structs to it...even met with him in Boston while he was at MIT...but couldn't convince him to do it. My company ended up writing our own C compiler, Eco C-88: the first with a complete IDE...even before Turbo C. (We needed the floating point because we developed and sold an advanced statistics package.)

You're right, there's a lot of what I call RDC (Really Dumb Code), and not all of it's by beginning programmers. I was hired as a consultant by a company that wrote banking software. One piece of commercial code had a 31 level if-else block, where one routine ran each day and all the others were ignored. Some banks using the code had over two million customers. Given that, on average there would be 15 failed comparisons for millions customers each day, we figured some banks were throwing away over 30 minutes of CPU time each day versus using a switch statement. I pointed this out in a code walk through stating it was a really stupid piece of code. I was fired that afternoon. Turns out, the person who hired me wrote the code and everyone in the room knew it!

As far as the Arduino environment, I do like it and think it's a great way to a lot of people to experience what programming's all about, yet have some fun at the same time. I do wish, however, that people who write libraries for the IDE would stay on top of their libraries and fix the warnings that keep popping up as the compiler checks get tighter.

It seems like most knowledgeable EE types, like yourself, are also accomplished programmers. Alas, I'm living proof that it doesn't go the other way. I enjoy reading your comments and I know all of us have benefited from them.

Jack, W8TEE

On Monday, July 2, 2018, 10:46:16 PM EDT, ajparent1/KB1GMX <kb1gmx@...> wrote:


I like your rules Jack.

My standard for a function or any subroutine is simple do one thing.
I guess that matches your no swiss knives.  I call them overloaded functions.

I think the best example of that is the SD library as it drags in FAT.  Its huge 
and if all you want to do is read or write blocks FAT is not needed or even
a file system.  Or you can just do tag and bag directory and teach the PC 
to use a simpler system to talk to a block device.  That is only one example.
Took me a while to tear the whole thing down to block_Write(blockNum, Buffer)
and block_read(blockNum, Buffer)  Where buffer is a 512 byte area, and
blockNum is a 32bit int.  The difference is more than 10K of code!

Global variables are ok if used for that only.  Not be cause the tuning math
needed a variable to store and intermediate result.

The offense i've seen is long ints when the counter never exceeds maybe 10
and floats when the value is going to be an integer.   Its remarkable that
people forget the iron they are programing is basically a 8 bit byte machine.

C and for that fact C++ is a small language, the libraries are where people
get their shorts eaten.  You don't need a full string library for a little 8bitter.

C seems to be there when others have come and gone.  Just about all the
others are easy (Ruby, Python, Java) if you know C.

A a long time PDP11 user (I have Unix V2.11 and Ultrix V6(BSD flavor).
ITs funny to thing the 11 is a near native C machine (very CISIC) and
the origin point for C and typically 128K bytes was a big machine. 
It teaches one brevity, modularity, and with care clarity.  

I still use Small-c on many micros because it is C (more K&R than ansi but hey
it was the 70s and ANSI was over a decade later) and small.    I like it because
it allows me to get as close to the irn as I care to and yet hide the iron when I
need to. 

Allison




--
“si vis pacem, para bellum”