Integer types in embedded systems

[=?ISO-8859-1?Q?Tom=E1s_=D3_h=C9ilidhe?=]

Let's say we had a simple function for returning the amount of days in
a month:

unsigned DaysInMonth(unsigned const month)
{
switch (month)
{
case 8:
case 3:
case 5:
case 10: return 30;

case 1: return 28;

default: return 31;
}
}

Notice the integer type I've used, i.e. "unsigned int" rather than
"unsigned char" or "unsigned short".

Many of the microcontrollers (i.e. a small chip that has a CPU and
RAM, basically it's a tiny little computer) in use nowadays do
arithmetic on 8-Bit numbers.

An example of a prevalent microcontroller nowadays would be the
PIC16F684. It's only got about 35 different CPU instructions. All of
the arithmetic instructions work on 8-Bit registers.

In my little code snippet above, the biggest number used is 31, which
of course would fit inside an "unsigned char".

In C, the plain "int" type is described as the "natural" type for the
system. I think a lot of people agree that this is the type you use
when you "just want to store a number", and I think a lot of people
expect it to be the fastest integer type.

The only problem with int, however, is that it must be at least 16-
Bit.

On an 8-Bit microcontroller such as the PIC16F684, this of course
means that int will NOT be the most efficient type. The problem with
this however is that we have code snippets like the one above that
think they're using the best integer types for the job. If we were to
re-write the code for an embedded system, we'd probably have:

char unsigned DaysInMonth(char unsigned const month)
{
switch (month)
{
case 8:
case 3:
case 5:
case 10: return 30;

case 1: return 28;

default: return 31;
}
}

I'd like now to bring up the topic of portable programming. In my own
code, I've begun to use types such as:

uint_fast8_t

Basically I'm saying "I want the fastest integer type whose range is
at least up to 255".

In this way, I can write code that will peform optimally on both
embedded systems and PC's.

To people out there who are enthusiastic about writing portable code,
do you think it's time we started using types like uint_fast8_t
instead of "unsigned int"?

Of course, even if our target platform doesn't supply an stdint.h, we
can always have a default version of it, e.g.:

typedef char unsigned uint_fast8_t;
or:
typedef unsigned uint_fast8_t;

[pete]

Tomás Ó hÉilidhe wrote:

PIC16F684. It's only got about 35 different CPU instructions.

I program that in assembly,
*because* it's only got about 35 different CPU instructions.
I've never felt any desire to use C on that chip.

do {
/*
** This whole loop is a single opcode on a PIC16F684
*/
} while (--n != 0);

To people out there who are enthusiastic about writing portable code,
do you think it's time we started using types like uint_fast8_t
instead of "unsigned int"?

--
pete

[Jack Klein]

On Fri, 2 May 2008 13:42:23 -0700 (PDT), Tomás Ó hÉilidhe
<to*@lavabit.comwrote in comp.lang.c:

>
Let's say we had a simple function for returning the amount of days in
a month:

unsigned DaysInMonth(unsigned const month)

First, omitting the "int", even if legal, is sloppy and would not
survive a code inspection in a professional organization.

Second, applying a const qualifier to a value parameter might pass a
code inspection, but is considered by many to be just plain prissy.

{
switch (month)
{
case 8:
case 3:
case 5:
case 10: return 30;

case 1: return 28;

default: return 31;
}
}

Notice the integer type I've used, i.e. "unsigned int" rather than
"unsigned char" or "unsigned short".

Many of the microcontrollers (i.e. a small chip that has a CPU and
RAM, basically it's a tiny little computer) in use nowadays do
arithmetic on 8-Bit numbers.

An example of a prevalent microcontroller nowadays would be the
PIC16F684. It's only got about 35 different CPU instructions. All of
the arithmetic instructions work on 8-Bit registers.

We won't get into many people's opinions about PICs, it would be
off-topic here.

In my little code snippet above, the biggest number used is 31, which
of course would fit inside an "unsigned char".

Which would, in C, immediately be promoted to either signed or
unsigned int. So you'd gain nothing. Some, perhaps many, embedded
compilers for 8-bit micros have an option for telling the compiler not
to promote 8-bit values. Once you do that, it's not really C anymore.

In C, the plain "int" type is described as the "natural" type for the
system. I think a lot of people agree that this is the type you use
when you "just want to store a number", and I think a lot of people
expect it to be the fastest integer type.

You seem to be a beginning embedded programmer, particularly based on
some of the posts you've made on comp.arch.embedded. On the other
hand, you make these opinionated statements like "a lot of people
expect". Who are these people? How do you know what they expect?

I think that no experienced embedded programmer would expect that. I
think anyone who hasn't learned not to expect that does not have the
experience to professionally program embedded systems. And on
anything outside the embedded arena these days, they can get away with
expecting that.

Most C programmers these days are woefully ignorant, and they expect
many things, such as...

--a char is signed and has a range of [-128,127]

--an int is four bytes

--a pointer is four bytes

--a float is four bytes

--there is a stack

....an I could go on and on.

The only problem with int, however, is that it must be at least 16-
Bit.

Actually, that's not a problem. That's a guarantee and a good one.

On an 8-Bit microcontroller such as the PIC16F684, this of course
means that int will NOT be the most efficient type. The problem with

Actually, it generally is the most efficient type if you need a type
that can hold an object in either of the ranges [-32767,32767] or
[0,65535].

this however is that we have code snippets like the one above that
think they're using the best integer types for the job. If we were to

Your assumption is that they think that. Have you asked "they" what
they think, or are you just assuming?

re-write the code for an embedded system, we'd probably have:

Actually, speaking for more than 25 years of embedded system
development, I'd say they would most likely not rewrite the code,
Knuth being absolutely correct about premature optimization. Once the
program was finished and meeting its requirements, but needed a
performance boost, then it might possible be rewritten as you suggest
below. But only after a profiler or other hard measurement tool
proved that it was a bottleneck.

char unsigned DaysInMonth(char unsigned const month)
{

Really, lose the const, it just makes you look silly.

As does your insistence on putting the base type before the unsigned
qualifier. At least as important as portability, and more important
in many cases in the real world, is maintainability. While your code
might be perfectly valid and legal to the compiler, not one C
programmer in a 1000 writes code like that.

Your writing code contrary to the common idiom just because you like
the way it looks is nothing but a cause for confusion, causing others
to take longer to read and understand your code for inspection or
maintenance. If it survived code inspection, which I think not likely
in most quality shops, embedded or otherwise.

switch (month)

But remember, at this point, C requires that the unsigned char be
promoted to either an int or unsigned int anyway.

{
case 8:

And the type of the 8, and the rest of the constants in your cases
already have type int.

case 3:
case 5:
case 10: return 30;

case 1: return 28;

default: return 31;
}
}

I'd like now to bring up the topic of portable programming. In my own
code, I've begun to use types such as:

uint_fast8_t

Does that mean that you don't use 'char', 'int', 'long', etc.?

Basically I'm saying "I want the fastest integer type whose range is
at least up to 255".

Basically, you are fooling yourself if you are feeding this code to a
conforming C compiler, because it must perform the standard
promotions. If you are operating something that is not quite a
conforming C compiler, perhaps by using certain invocation options,
that's a different story, but also rather off-topic here.

In this way, I can write code that will peform optimally on both
embedded systems and PC's.

Again, if the compiler you feed this to is instructed to compile in
conforming mode, this code will be basically the same as the original
version.

To people out there who are enthusiastic about writing portable code,
do you think it's time we started using types like uint_fast8_t
instead of "unsigned int"?

Actually, I haven't had a use for the fast types yet. I have used the
(u)int_leastx_t types, for portability between DSPs where CHAR_BIT is
larger than 8, and "ordinary" platforms where CHAR_BIT is exactly 8.
In fact I've successfully written code that had to pack and unpack
binary communications packets using unit_least8_t that compiles
unchanged on CHAR_BIT 8 and CHAR_BIT 16 implementations.

Of course, even if our target platform doesn't supply an stdint.h, we
can always have a default version of it, e.g.:

typedef char unsigned uint_fast8_t;
or:
typedef unsigned uint_fast8_t;

There have been plenty of examples on the web of stdint.h files for
compilers that do not supply them. At least one was written by a
member of the C standard committee. I've written quite a few myself
for older embedded compilers. And I've written one for Visual C++ 6,
which I often use for testing algorithms.

The real issue here is premature micro optimization. The majority of
the posters and readers in this group, as opposed to
comp.arch.embedded, are not embedded system programmers. They have,
and probably will never have, a need to port their code to anything
smaller than a 32-bit processor. Your advice is not relevant to them.

In my opinion, you are worrying about efficiency under the guise of
portability. If you are really concerned with portability, understand
that portability to other programmers is as important as portability
to other implementations and platforms.

Get rid of "char unsigned const" and write "const unsigned char" like
all the other C programmers do. Save your creativity for clever
algorithms, and write the simplest and clearest code to implement the
algorithm correctly.

And at the very end, when your program works and meets all of its
requirements, then you can look at optimizations like this. But only
if this is the code causing one of the bottle necks.

For example, if this code is executed once per day when the clock
rolls over from 23:59:50 to 0:00:00, to decide whether to change the
month and date, or just the date, on a display, what have you gained
by saving 5 or 50 clock cycles out every 24 hours?

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

[Thad Smith]

Jack Klein wrote:

On Fri, 2 May 2008 13:42:23 -0700 (PDT), Tomás Ó hÉilidhe
<to*@lavabit.comwrote in comp.lang.c:

>Let's say we had a simple function for returning the amount of days in
a month:

unsigned DaysInMonth(unsigned const month)
{
switch (month)
{
case 8:
case 3:
case 5:
case 10: return 30;

case 1: return 28;

default: return 31;
}
}

....

>In my little code snippet above, the biggest number used is 31, which
of course would fit inside an "unsigned char".

Which would, in C, immediately be promoted to either signed or
unsigned int. So you'd gain nothing. Some, perhaps many, embedded
compilers for 8-bit micros have an option for telling the compiler not
to promote 8-bit values. Once you do that, it's not really C anymore.

For parameters and return values if they are declared as 8-bit types, you
will save instructions on an 8-bit processor. Promotion doesn't happen on
those.

> switch (month)

But remember, at this point, C requires that the unsigned char be
promoted to either an int or unsigned int anyway.

Yes, month is promoted to an int, but my compiler is clever -- it knows
that the operand is 8 bits and doesn't needlessly generate a leading zero
byte before performing the switch evaluation.

Good compilers do that kind of optimization. a = b + 5; can be done with
single byte operations for single byte operands. So can many other
expressions.

>

> {
case 8:

And the type of the 8, and the rest of the constants in your cases
already have type int.

So what? These are constants. The clever compiler knows that the 8-bit
unsigned value can be contained in a single byte.

>I'd like now to bring up the topic of portable programming. In my own
code, I've begun to use types such as:

uint_fast8_t

Does that mean that you don't use 'char', 'int', 'long', etc.?

>Basically I'm saying "I want the fastest integer type whose range is
at least up to 255".

Basically, you are fooling yourself if you are feeding this code to a
conforming C compiler, because it must perform the standard
promotions. If you are operating something that is not quite a
conforming C compiler, perhaps by using certain invocation options,
that's a different story, but also rather off-topic here.

I disagree. I am familiar with my compiler. It does take advantage of
smaller operand size. Any yes, it is conforming in regards to integer
promotion.

>In this way, I can write code that will peform optimally on both
embedded systems and PC's.

Again, if the compiler you feed this to is instructed to compile in
conforming mode, this code will be basically the same as the original
version.

Not the one I use.

--
Thad

[=?ISO-8859-1?Q?Tom=E1s_=D3_h=C9ilidhe?=]

On May 3, 4:53*am, Jack Klein <[e-mail]:

unsigned DaysInMonth(unsigned const month)

First, omitting the "int", even if legal, is sloppy and would not
survive a code inspection in a professional organization.

I don't know whether that's a good sign or a bad sign, especially
considering I'd aspire to be better than any "professional"
programmer.

Second, applying a const qualifier to a value parameter might pass a
code inspection, but is considered by many to be just plain prissy.

Who's talking about code inspections? I write code for myself. I write
it clear, efficient and proper. I used const wherever possible unless
it's redundant.

Which would, in C, immediately be promoted to either signed or
unsigned int. *So you'd gain nothing. *Some, perhaps many, embedded
compilers for 8-bit micros have an option for telling the compiler not
to promote 8-bit values. *Once you do that, it's not really C anymore.

Don't forget about the "as if" rule. I compiler doesn't have to do
something, it just has to act as if it does seomthing.

If you do:

char unsigned a = 5, b = 6;

char unsigned c = a + b;

Compile it and check the assembler. You'll see that only 8-Bit
registers are used.

In C, the plain "int" type is described as the "natural" type for the
system. I think a lot of people agree that this is the type you use
when you "just want to store a number", and I think a lot of people
expect it to be the fastest integer type.

You seem to be a beginning embedded programmer, particularly based on
some of the posts you've made on comp.arch.embedded. *On the other
hand, you make these opinionated statements like "a lot of people
expect". *Who are these people? *How do you know what they expect?

Firstly, yes I'm new to embedded systems, but I consider myself to be
an experienced programmer. I've been programming in C and C++ for
about 6 or 7 years now and I have for a long time considered "int" to
be the "fast type".

I think that no experienced embedded programmer would expect that.

I realise that, and this is why they're distinct from more generic
programmers. (By generic programmers, I mean someone who writes an
algorithm and doesn't know what their platform is.)

*

I think anyone who hasn't learned not to expect that does not have the
experience to professionally program embedded systems.

Obviously, since I wrote the original post in this thread, I realise
that "int" is slow on an 8-Bit micrcontroller.

I'm talking about more generic programming, e.g. just being a C
programmer. A good C programmer should be able to write portable code
that will perform well on everything. Since the portable programmer
will assume that "int" is the best type for the job, this will have
negative consequences when the code is brought to an embedded system.

The solution: Use things like uint_fast8_t instead of int.

Most C programmers these days are woefully ignorant, and they expect
many things, such as...

--a char is signed and has a range of [-128,127]

--an int is four bytes

--a pointer is four bytes

--a float is four bytes

--there is a stack

...an I could go on and on.

Yes, the majority of programmers are bad programmers. Kind of like ice
skaters.

Any half-decent C programmer will know what freedom and restrictions
the Standard provides.

The only problem with int, however, is that it must be at least 16-
Bit.

Actually, that's not a problem. *That's a guarantee and a good one.

Are you paying attention? It's bad for 8-Bit microcontrollers. It's
fine for 16-Bit microcontrollers and upwards.

On an 8-Bit microcontroller such as the PIC16F684, this of course
means that int will NOT be the most efficient type. The problem with

Actually, it generally is the most efficient type if you need a type
that can hold an object in either of the ranges [-32767,32767] or
[0,65535].

I'm now talking about that specific range, I'm talking about storing
"just a number", even like small numbers that don't go above 200.

this however is that we have code snippets like the one above that
think they're using the best integer types for the job. If we were to

Your assumption is that they think that. *Have you asked "they" what
they think, or are you just assuming?

I've had many discussions about portability on various different
newsgroups. Do a google search of comp.lang.c for my name and
"portable portability". I never shut up about it.

Actually, speaking for more than 25 years of embedded system
development, I'd say they would most likely not rewrite the code,
Knuth being absolutely correct about premature optimization. *Once the
program was finished and meeting its requirements, but needed a
performance boost, then it might possible be rewritten as you suggest
below. *But only after a profiler or other hard measurement tool
proved that it was a bottleneck.

You'd have to have the intelligence of a squid not to realise that the
micrcontroller can work with 8-Bit numbers with a single instruction,
and that it needs mutliple instructions (and multiple bytes in memory)
to work with 16-Bit numbers.

char unsigned DaysInMonth(char unsigned const month)
{

Really, lose the const, it just makes you look silly.

I'm beginning to think that I should probably be glad if you think I'm
silly.

That const serves a purpose; I put it there for a reason.

As does your insistence on putting the base type before the unsigned
qualifier. *At least as important as portability, and more important
in many cases in the real world, is maintainability. *While your code
might be perfectly valid and legal to the compiler, not one C
programmer in a 1000 writes code like that.

Oh the woes of being a good programmer.

Your writing code contrary to the common idiom just because you like
the way it looks is nothing but a cause for confusion, causing others
to take longer to read and understand your code for inspection or
maintenance. *If it survived code inspection, which I think not likely
in most quality shops, embedded or otherwise.

I'm not a professional programmer. If I was, I'd make sure I'm working
with good, competant programmers. If my colleague can't get his head
around "short unsigned" then we'd be better off not working together.
I'm not prejudiced against stupid people, I just don't like working
with them.

* * switch (month)

But remember, at this point, C requires that the unsigned char be
promoted to either an int or unsigned int anyway.

Again, the assembler produced will work with a single 8-Bit register.

* * {
* * case 8:

And the type of the 8, and the rest of the constants in your cases
already have type int.

Single 8-Bit register again.

In my own
code, I've begun to use types such as:

* * uint_fast8_t

Does that mean that you don't use 'char', 'int', 'long', etc.?

Not entirely.

Basically I'm saying "I want the fastest integer type whose range is
at least up to 255".

Basically, you are fooling yourself if you are feeding this code to a
conforming C compiler, because it must perform the standard
promotions.

Against your argument is invalid. The compiler knows when the
promotion will have no effect.

>*If you are operating something that is not quite a
conforming C compiler, perhaps by using certain invocation options,
that's a different story, but also rather off-topic here.

You'll find that these smart compilers conform to the standard in
terms of integer promotion.

In this way, I can write code that will peform optimally on both
embedded systems and PC's.

Again, if the compiler you feed this to is instructed to compile in
conforming mode, this code will be basically the same as the original
version.

Again, a single 8-Bit register.

The real issue here is premature micro optimization. *The majority of
the posters and readers in this group, as opposed to
comp.arch.embedded, are not embedded system programmers.

White coats not mixing with blue blazers?

A programmer is a programmer. I programmed in C on PC's for years
before I started doing embedded systems programming... and guess what
there was no difference.

If you have a fully-portable algorithm in compliance to the C89
standard, then it should run on everything from your microwave's
interface to your PC. The only problem with algorithm is that it might
be inefficient on the microwave if it's using "int" as its everyday
integer type. If the algorithm instead used uint_fast8_t, then the
code would be fast on every kind of system.

>*They have,
and probably will never have, a need to port their code to anything
smaller than a 32-bit processor. *Your advice is not relevant to them.

Where are you getting this distinction between a C programmer and an
embedded systems programmer. You can program an embedded system in C,
and I do it.

In my opinion, you are worrying about efficiency under the guise of
portability. *If you are really concerned with portability, understand
that portability to other programmers is as important as portability
to other implementations and platforms.

Get rid of "char unsigned const" and write "const unsigned char" like
all the other C programmers do.

Again, I've not interest to accomodate lact-lustre programmers. If
they can't get their head around a simple re-ordering of words, then
they haven't a snowball's chance in hell of understanding my more
complex algorithms.

>*Save your creativity for clever
algorithms, and write the simplest and clearest code to implement the
algorithm correctly.

And would you believe that I think my own code is simple and clear.

And at the very end, when your program works and meets all of its
requirements, then you can look at optimizations like this. *But only
if this is the code causing one of the bottle necks.

For example, if this code is executed once per day when the clock
rolls over from 23:59:50 to 0:00:00, to decide whether to change the
month and date, or just the date, on a display, what have you gained
by saving 5 or 50 clock cycles out every 24 hours?

What if the code is run in an eternal loop on a microcontroller that's
running at 4 MHz. If the microcontroller is also flashing an LED
display, then the decrease in speed will result in display flicker.
And I *have* seen this in my very own college project this year.

[Jack Klein]

On Sat, 3 May 2008 04:53:12 -0700 (PDT), Tomás Ó hÉilidhe
<to*@lavabit.comwrote in comp.lang.c:

On May 3, 4:53*am, Jack Klein <[e-mail]:

unsigned DaysInMonth(unsigned const month)

First, omitting the "int", even if legal, is sloppy and would not
survive a code inspection in a professional organization.

I don't know whether that's a good sign or a bad sign, especially
considering I'd aspire to be better than any "professional"
programmer.

Oh, my, I had no idea that you were the ultimate programmer, better
than all the rest, better than the best. I'll make a note of that.

Second, applying a const qualifier to a value parameter might pass a
code inspection, but is considered by many to be just plain prissy.

Who's talking about code inspections? I write code for myself. I write
it clear, efficient and proper. I used const wherever possible unless
it's redundant.

In that case, why are you bothering to waste your time bestowing your
wisdom on other, lesser, programmers? Our opinion is meaningless to
you.

Which would, in C, immediately be promoted to either signed or
unsigned int. *So you'd gain nothing. *Some, perhaps many, embedded
compilers for 8-bit micros have an option for telling the compiler not
to promote 8-bit values. *Once you do that, it's not really C anymore.

Don't forget about the "as if" rule. I compiler doesn't have to do
something, it just has to act as if it does seomthing.

If you do:

char unsigned a = 5, b = 6;

char unsigned c = a + b;

Compile it and check the assembler. You'll see that only 8-Bit
registers are used.

Sadly, I have to disagree with you there. Take ARM for example, in
the majority of the world's cell phones. I guarantee you it will use
a 32-bit register. Regardless of any compiler, past, present, or
future, regardless of options used when invoking the compiler.

In C, the plain "int" type is described as the "natural" type for the
system. I think a lot of people agree that this is the type you use
when you "just want to store a number", and I think a lot of people
expect it to be the fastest integer type.

You seem to be a beginning embedded programmer, particularly based on
some of the posts you've made on comp.arch.embedded. *On the other
hand, you make these opinionated statements like "a lot of people
expect". *Who are these people? *How do you know what they expect?

Firstly, yes I'm new to embedded systems, but I consider myself to be
an experienced programmer. I've been programming in C and C++ for
about 6 or 7 years now and I have for a long time considered "int" to
be the "fast type".

That is one of the many assumptions you will need to rid yourself of
if you expect to become an expert embedded programmer.

I think that no experienced embedded programmer would expect that.

I realise that, and this is why they're distinct from more generic
programmers. (By generic programmers, I mean someone who writes an
algorithm and doesn't know what their platform is.)

*

I think anyone who hasn't learned not to expect that does not have the
experience to professionally program embedded systems.

Obviously, since I wrote the original post in this thread, I realise
that "int" is slow on an 8-Bit micrcontroller.

I'm talking about more generic programming, e.g. just being a C
programmer. A good C programmer should be able to write portable code
that will perform well on everything. Since the portable programmer
will assume that "int" is the best type for the job, this will have
negative consequences when the code is brought to an embedded system.

Actually, I couldn't disagree more. Most professional programmers are
concerned, as they should be, with producing error free (or as error
free as possible) programs that meet their requirements. Suggesting
that programmers for desk top environments such as *nix or Windows
should worry about their code being ported to an eight-bit micro is
inefficient and not cost effective.

The solution: Use things like uint_fast8_t instead of int.

Most C programmers these days are woefully ignorant, and they expect
many things, such as...

--a char is signed and has a range of [-128,127]

--an int is four bytes

--a pointer is four bytes

--a float is four bytes

--there is a stack

...an I could go on and on.

Yes, the majority of programmers are bad programmers. Kind of like ice
skaters.

Any half-decent C programmer will know what freedom and restrictions
the Standard provides.

The only problem with int, however, is that it must be at least 16-
Bit.

Actually, that's not a problem. *That's a guarantee and a good one.

Are you paying attention? It's bad for 8-Bit microcontrollers. It's
fine for 16-Bit microcontrollers and upwards.

My attention skills are quite adequate, thank you. You said, and
quite specifically, "The only problem with int, however, is that is
must be at least 16-Bit(sic)." In fact, it's still just a few lines
above where I am typing this, quoted several times from your original
post.

And that is absolutely, positively, not a problem, but an extremely
useful guarantee provided by the C language.

The problem you are expressing is that you think that an int is not
the most efficient type for you to use in one particular code snippet,
on one particular hardware architecture, with one particular compiler.

That is a problem with your expectations or wants, not a problem with
the C language requirement for the type int.

On an 8-Bit microcontroller such as the PIC16F684, this of course
means that int will NOT be the most efficient type. The problem with

Actually, it generally is the most efficient type if you need a type
that can hold an object in either of the ranges [-32767,32767] or
[0,65535].

I'm now talking about that specific range, I'm talking about storing
"just a number", even like small numbers that don't go above 200.

this however is that we have code snippets like the one above that
think they're using the best integer types for the job. If we were to

Your assumption is that they think that. *Have you asked "they" what
they think, or are you just assuming?

I've had many discussions about portability on various different
newsgroups. Do a google search of comp.lang.c for my name and
"portable portability". I never shut up about it.

Actually, speaking for more than 25 years of embedded system
development, I'd say they would most likely not rewrite the code,
Knuth being absolutely correct about premature optimization. *Once the
program was finished and meeting its requirements, but needed a
performance boost, then it might possible be rewritten as you suggest
below. *But only after a profiler or other hard measurement tool
proved that it was a bottleneck.

You'd have to have the intelligence of a squid not to realise that the

Oops, now your getting insulting. I don't recall casting any
aspersions on your intelligence.

micrcontroller can work with 8-Bit numbers with a single instruction,
and that it needs mutliple instructions (and multiple bytes in memory)
to work with 16-Bit numbers.

I was making a living designing, building, and selling embedded
systems with various 8-bit microprocessors and microcontrollers for at
least ten years before Microchip released the first PIC. There is
little you can teach me about 8-bit architectures.

char unsigned DaysInMonth(char unsigned const month)
{

Really, lose the const, it just makes you look silly.

I'm beginning to think that I should probably be glad if you think I'm
silly.

That const serves a purpose; I put it there for a reason.

As does your insistence on putting the base type before the unsigned
qualifier. *At least as important as portability, and more important
in many cases in the real world, is maintainability. *While your code
might be perfectly valid and legal to the compiler, not one C
programmer in a 1000 writes code like that.

Oh the woes of being a good programmer.

Oh, woe is you! Or should that be "are you"? Now you have ventured
into a completely subjective area, your definition of "good".

Indulge me, tell me how your insistence on writing "char unsigned
const" "good", as opposed to "const unsigned char", which is what the
vast majority of C programmers would write.

What makes that "good", and, by definition, the way (almost) everybody
else would write it not "good", or at least not as "good" as your way?

Your writing code contrary to the common idiom just because you like
the way it looks is nothing but a cause for confusion, causing others
to take longer to read and understand your code for inspection or
maintenance. *If it survived code inspection, which I think not likely
in most quality shops, embedded or otherwise.

I'm not a professional programmer. If I was, I'd make sure I'm working
with good, competant programmers. If my colleague can't get his head
around "short unsigned" then we'd be better off not working together.
I'm not prejudiced against stupid people, I just don't like working
with them.

Oh, now anyone who writes "const unsigned char" is "stupid", unless
they cheerfully adapt to your idiosyncrasies?

You can actually make a point about putting the const keyword after
the type. The C grammar basically wants it there, and only allows it
at the beginning of a declaration as a special case.

It would be quite a bit harder to provide a justification for "char
unsigned" or "long unsigned", since an unsigned char is neither an
unsigned nor a char, it is a unique type on it's own. The unsigned
keyword is not a cv qualifier, it is an integral part of the type
name.

* * switch (month)

But remember, at this point, C requires that the unsigned char be
promoted to either an int or unsigned int anyway.

Again, the assembler produced will work with a single 8-Bit register.

The assembler produced by one particular compiler.

* * {
* * case 8:

And the type of the 8, and the rest of the constants in your cases
already have type int.

Single 8-Bit register again.

In my own
code, I've begun to use types such as:

* * uint_fast8_t

Does that mean that you don't use 'char', 'int', 'long', etc.?

Not entirely.

Haven't yet attained perfection.

Basically I'm saying "I want the fastest integer type whose range is
at least up to 255".

Basically, you are fooling yourself if you are feeding this code to a
conforming C compiler, because it must perform the standard
promotions.

Against your argument is invalid. The compiler knows when the
promotion will have no effect.

*If you are operating something that is not quite a
conforming C compiler, perhaps by using certain invocation options,
that's a different story, but also rather off-topic here.

You'll find that these smart compilers conform to the standard in
terms of integer promotion.

In this way, I can write code that will peform optimally on both
embedded systems and PC's.

Again, if the compiler you feed this to is instructed to compile in
conforming mode, this code will be basically the same as the original
version.

Again, a single 8-Bit register.

The real issue here is premature micro optimization. *The majority of
the posters and readers in this group, as opposed to
comp.arch.embedded, are not embedded system programmers.

White coats not mixing with blue blazers?

A programmer is a programmer. I programmed in C on PC's for years
before I started doing embedded systems programming... and guess what
there was no difference.

Actually, you are quite wrong about that. Does your PIC compiler
provide a double that meets the C specifications?

If you have a fully-portable algorithm in compliance to the C89
standard, then it should run on everything from your microwave's
interface to your PC. The only problem with algorithm is that it might
be inefficient on the microwave if it's using "int" as its everyday
integer type. If the algorithm instead used uint_fast8_t, then the
code would be fast on every kind of system.

*They have,
and probably will never have, a need to port their code to anything
smaller than a 32-bit processor. *Your advice is not relevant to them.

Where are you getting this distinction between a C programmer and an
embedded systems programmer. You can program an embedded system in C,
and I do it.

Because embedded programmers in C might need to worry about choosing
the best data type on some micros and DSPs, and C programmers working
in 32-bit or larger hosted environments do not.

In my opinion, you are worrying about efficiency under the guise of
portability. *If you are really concerned with portability, understand
that portability to other programmers is as important as portability
to other implementations and platforms.

Get rid of "char unsigned const" and write "const unsigned char" like
all the other C programmers do.

Again, I've not interest to accomodate lact-lustre programmers. If

"Accomodate(sic)". So everybody else who has been writing C for forty
years should accommodate you. Including Brian Kernighan and Dennis
Ritchie, including the authors of the various versions of ANSI and ISO
C standards. Obviously lack-luster programmers, the lot of them.

they can't get their head around a simple re-ordering of words, then
they haven't a snowball's chance in hell of understanding my more
complex algorithms.

You're absolutely right, I'm sure that none of people I alluded to
above could understand your clever algorithms.

*Save your creativity for clever
algorithms, and write the simplest and clearest code to implement the
algorithm correctly.

And would you believe that I think my own code is simple and clear.

But you persist in posting your code to a public forum read almost
exclusively by C programmers who conclusively demonstrate that they
don't think your way of writing code is appropriate by not writing
code the way that you do.

And at the very end, when your program works and meets all of its
requirements, then you can look at optimizations like this. *But only
if this is the code causing one of the bottle necks.

For example, if this code is executed once per day when the clock
rolls over from 23:59:50 to 0:00:00, to decide whether to change the
month and date, or just the date, on a display, what have you gained
by saving 5 or 50 clock cycles out every 24 hours?

What if the code is run in an eternal loop on a microcontroller that's
running at 4 MHz. If the microcontroller is also flashing an LED
display, then the decrease in speed will result in display flicker.
And I *have* seen this in my very own college project this year.

I will repeat, since you seem to have missed it, this paragraph of my
response:

"And at the very end, when your program works and meets all of its
requirements, then you can look at optimizations like this. *But only
if this is the code causing one of the bottle necks."

So you have correctly discovered that there were performance issues in
your program, and found optimizations that improved them. Excellent.

As I've said to you in at least one previous post, it is important for
embedded programmers working on "unusual" architectures to be aware
not only of the features and limitations of the underlying hardware,
but also of the details of their compiler.

Where you take the great and unjustified, in my opinion, leap, is in
deciding that you have uncovered a great truth and every C programmer
working on any kind of code anywhere should analyze every integer
object used in their code and use the stdint.h code for the fastest
possible type.

Quite frankly, for many programmers, that would be an absolutely
unjustified use of time and resources. They would expend extra
effort, and therefore produce working, tested code more slowly, on an
activity that would not improve the correctness or efficiency of their
code by even the tiniest amount.

Perhaps you should conduct a survey, to determine the percentage of C
programmers who are currently coding for Windows or Linux or OSX and
are planning a future port to PIC or 8051 or AVR.

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

[Anand Hariharan]

On Sat, 03 May 2008 04:53:12 -0700, Tomás Ó hÉilidhe wrote:

On May 3, 4:53*am, Jack Klein <[e-mail]:

unsigned DaysInMonth(unsigned const month)

(...)

>Second, applying a const qualifier to a value parameter might pass a
code inspection, but is considered by many to be just plain prissy.

Who's talking about code inspections? I write code for myself. I write
it clear, efficient and proper. I used const wherever possible unless
it's redundant.

(...)

>

char unsigned DaysInMonth(char unsigned const month)
{

Really, lose the const, it just makes you look silly.

I'm beginning to think that I should probably be glad if you think I'm
silly.

That const serves a purpose; I put it there for a reason.

Am guessing your reason is to tell yourself as the function's
/implementer/ that you are not going to modify the function
argument. However, most functions are written for the caller.

As a programmer who is going to call your function, if I were to
look at your function declaration, I see that it has a value
parameter (i.e., a copy of my argument is passed to your function).
So, the const there is indeed redundant to the caller.
--
ROT-13 email address to reply

[Ian Collins]

Tomás Ó hÉilidhe wrote:

On May 3, 4:53 am, Jack Klein <[e-mail]:

>Get rid of "char unsigned const" and write "const unsigned char" like
all the other C programmers do.

Again, I've not interest to accomodate lact-lustre programmers. If
they can't get their head around a simple re-ordering of words, then
they haven't a snowball's chance in hell of understanding my more
complex algorithms.

Are we witnessing the return of Frederick Gotham?

--
Ian Collins.

[=?ISO-8859-1?Q?Tom=E1s_=D3_h=C9ilidhe?=]

On May 4, 7:05*am, Jack Klein <[e-mail]:

I don't know whether that's a good sign or a bad sign, especially
considering I'd aspire to be better than any "professional"
programmer.

Oh, my, I had no idea that you were the ultimate programmer, better
than all the rest, better than the best. *I'll make a note of that.

You'll notice I said "aspire to". There are many C programmers in the
world. Many of them are not very good, and a very small proportion of
them are excellent. You spoke of "code inspection" which is why I
assumed you were talking about professional programmers. The vast
majority of professional programmers are not very good, which is why I
expressed the view that I'd aspire to be better than a professional
programmer.

How you took arrogance from my statement, I don't know.

In that case, why are you bothering to waste your time bestowing your
wisdom on other, lesser, programmers? *Our opinion is meaningless to
you.

Again, I think your arrogance sensor is dodgy.

If you do:

* * char unsigned a = 5, b = 6;

* * char unsigned c = a + b;

Compile it and check the assembler. You'll see that only 8-Bit
registers are used.

Sadly, I have to disagree with you there. *Take ARM for example, in
the majority of the world's cell phones. *I guarantee you it will use
a 32-bit register. *Regardless of any compiler, past, present, or
future, regardless of options used when invoking the compiler.

That's unfortunate. The only embedded compiler I've worked with is the
PIC C compiler, and thankfully it will only use an 8-Bit register for
the code above.

Firstly, yes I'm new to embedded systems, but I consider myself to be
an experienced programmer. I've been programming in C and C++ for
about 6 or 7 years now and I have for a long time considered "int" to
be the "fast type".

That is one of the many assumptions you will need to rid yourself of
if you expect to become an expert embedded programmer.

The idea of "int" in the C programming language was that it would be
the main integer type to use. I myself take this to mean that it will
be the fastest type. (I can't think of any more suitable meaning of
"natural type" as worded in the Standard).

Actually, I couldn't disagree more. *Most professional programmers are
concerned, as they should be, with producing error free (or as error
free as possible) programs that meet their requirements. *Suggesting
that programmers for desk top environments such as *nix or Windows
should worry about their code being ported to an eight-bit micro is
inefficient and not cost effective.

I'm trying to devise a strategy that will take away the need to worry.

When writing a simple algorithm in C, you can sit there with a smile
on your face knowing that it will run on Solaris, Redhat, Windows XP,
Playstation 3, XBox 360. Here's an example algorithm for instance:

void SetToFive(int *p,int const *const pend)
{
do *p++ = 5;
while (pend != p);
}

You can also be happy that it will run on an embedded system... but
then it might be too slow for the embedded system because of the use
of int instead of char.

My attention skills are quite adequate, thank you. *You said, and
quite specifically, "The only problem with int, however, is that is
must be at least 16-Bit(sic)." *In fact, it's still just a few lines
above where I am typing this, quoted several times from your original
post.

And that is absolutely, positively, not a problem, but an extremely
useful guarantee provided by the C language.

To accomodate 8-Bit systems, it would have been better to decree that
the "natural type" only be at least 8-Bit, instead of 16-Bit as the
Standard decrees. (Of course this would require a reorganisation of
the types).

The problem you are expressing is that you think that an int is not
the most efficient type for you to use in one particular code snippet,
on one particular hardware architecture, with one particular compiler.

Only the hardware architecture. In my most recent embedded systems
project, I didn't need int at all because I had no need for a number
greater than 255, so this thing of not opting for int isn't a "once
off". The compiler hasn't got much power in deciding int type lengths
if it has to work with an 8-Bit microcontroller.

That is a problem with your expectations or wants, not a problem with
the C language requirement for the type int.

I disagree. Int is the "natural type", but the problem is that it
simply cannot be the natural type for an 8-Bit system by virtue of the
fact that int must be at least 16-Bit. That's the problem.

I was making a living designing, building, and selling embedded
systems with various 8-bit microprocessors and microcontrollers for at
least ten years before Microchip released the first PIC. *There is
little you can teach me about 8-bit architectures.

Then I would expect you to realise, even far better than myself, the
detrimental effect of using int in embedded systems code.

Oh the woes of being a good programmer.

Oh, woe is you! *Or should that be "are you"? *Now you have ventured
into a completely subjective area, your definition of "good".

Indulge me, tell me how your insistence on writing "char unsigned
const" "good", as opposed to "const unsigned char", which is what the
vast majority of C programmers would write.

It's just personal preference. I find it more intuitive to see the
most basic type information first.

What makes that "good", and, by definition, the way (almost) everybody
else would write it not "good", or at least not as "good" as your way?

I was referring to my const correctness, not my word ordering.

Oh, now anyone who writes "const unsigned char" is "stupid", unless
they cheerfully adapt to your idiosyncrasies?

No at all. I've seen more than one excellent programmer write like
that. Another thing I do is write "++i" instead of "i++", but of
course a lot of excellent programmers write "i++" (this of course only
applies to a context where the resultant expression is discarded).

You can actually make a point about putting the const keyword after
the type. *The C grammar basically wants it there, and only allows it
at the beginning of a declaration as a special case.

It would be quite a bit harder to provide a justification for "char
unsigned" or "long unsigned", since an unsigned char is neither an
unsigned nor a char, it is a

It mirrors C's syntax for printf, e.g. "%lu".

[=?ISO-8859-1?Q?Tom=E1s_=D3_h=C9ilidhe?=]

On May 4, 8:09*am, Ian Collins <[e-mail]:

Are we witnessing the return of Frederick Gotham?

I am not sock puppeting. The most recent post I can find of Frederick
Gotham dates back to Dec 4th 2006, and quite ironically the first
thing Google found when I did a search was a thread in which he was
accused of sock puppeting; less ironically, you yourself made quite a
contribution to that thread.

I have my real e-mail address attached to my posts and I only post
under one name (on all kinds of fora across the internet), so I'd
appreciate if you'd abandon that accusation.

[CBFalconer]

Tomás Ó hÉilidhe wrote:

>

.... snip ...

>
I have my real e-mail address attached to my posts and I only post
under one name (on all kinds of fora across the internet), so I'd
appreciate if you'd abandon that accusation.

That is not a good idea, because of the ease with which the
spammers can access it. I suggest putting the real address in the
'Reply-To' header, which is much less accessible, but is
automatically used for email replies. My from address is also
real, but does nothing but collect spam.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

[Eligiusz Narutowicz]

CBFalconer <cb********@yahoo.comwrites:

Tomás Ó hÉilidhe wrote:

>>

... snip ...

>>
I have my real e-mail address attached to my posts and I only post
under one name (on all kinds of fora across the internet), so I'd
appreciate if you'd abandon that accusation.

That is not a good idea, because of the ease with which the
spammers can access it. I suggest putting the real address in the
'Reply-To' header, which is much less accessible, but is

Do not be so stupid.

automatically used for email replies. My from address is also
real, but does nothing but collect spam.

Why you make it then? How you know which is used to collate emails
addresses?

[CBFalconer]

Eligiusz Narutowicz wrote:

CBFalconer <cb********@yahoo.comwrites:

>Tomás Ó hÉilidhe wrote:

>>>

... snip ...

>>>
I have my real e-mail address attached to my posts and I only post
under one name (on all kinds of fora across the internet), so I'd
appreciate if you'd abandon that accusation.

That is not a good idea, because of the ease with which the
spammers can access it. I suggest putting the real address in the
'Reply-To' header, which is much less accessible, but is

Do not be so stupid.

You are not very smart, nor knowledgeable, are you?

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

[Eligiusz Narutowicz]

CBFalconer <cb********@yahoo.comwrites:

Eligiusz Narutowicz wrote:

>CBFalconer <cb********@yahoo.comwrites:

>>Tomás Ó hÉilidhe wrote:

... snip ...

I have my real e-mail address attached to my posts and I only post
under one name (on all kinds of fora across the internet), so I'd
appreciate if you'd abandon that accusation.

That is not a good idea, because of the ease with which the
spammers can access it. I suggest putting the real address in the
'Reply-To' header, which is much less accessible, but is

Do not be so stupid.

You are not very smart, nor knowledgeable, are you?

Please justify your claim. It makes no sense to me. Or you always
make these claims with no proof or background in the subject?

[rio]

"Tomás Ó hÉilidhe" <to*@lavabit.comha scritto nel messaggio
news:e5**********************************@z72g2000 hsb.googlegroups.com...
On May 4, 7:05 am, Jack Klein <[e-mail]:

>Oh, my, I had no idea that you were the ultimate programmer, better
than all the rest, better than the best. I'll make a note of that.

each one say about himself to be a programmer imagine to be that one

>Again, I think your arrogance sensor is dodgy.

If you do:

char unsigned a = 5, b = 6;

char unsigned c = a + b;

Compile it and check the assembler. You'll see that only 8-Bit
registers are used.

Sadly, I have to disagree with you there. Take ARM for example, in
the majority of the world's cell phones. I guarantee you it will use
a 32-bit register. Regardless of any compiler, past, present, or
future, regardless of options used when invoking the compiler.

you for gain the speed lose the portability. the future will
be of true portable languages (the part has to need to be fast
will be rewritten in assembly of each cpu of port)

>That's unfortunate. The only embedded compiler I've worked with is the
PIC C compiler, and thankfully it will only use an 8-Bit register for
the code above.

i agree that the code has to be portable;
one time i write something for a cpu it will go well for all
something like
uns32 a=5, b=6, c=a+b;

something without any interpretation from one machine to some other
with no Undefinite Beaviour

Firstly, yes I'm new to embedded systems, but I consider myself to be
an experienced programmer. I've been programming in C and C++ for
about 6 or 7 years now and I have for a long time considered "int" to
be the "fast type".

That is one of the many assumptions you will need to rid yourself of
if you expect to become an expert embedded programmer.

>The idea of "int" in the C programming language was that it would be
the main integer type to use. I myself take this to mean that it will
be the fastest type. (I can't think of any more suitable meaning of
"natural type" as worded in the Standard).

for me the above is not the right way to go

>Actually, I couldn't disagree more. Most professional programmers are
concerned, as they should be, with producing error free (or as error
free as possible) programs that meet their requirements. Suggesting
that programmers for desk top environments such as *nix or Windows
should worry about their code being ported to an eight-bit micro is
inefficient and not cost effective.

>I'm trying to devise a strategy that will take away the need to worry.

>When writing a simple algorithm in C, you can sit there with a smile
on your face knowing that it will run on Solaris, Redhat, Windows XP,
Playstation 3, XBox 360. Here's an example algorithm for instance:

>void SetToFive(int *p,int const *const pend)
{
do *p++ = 5;
while (pend != p);
}

>You can also be happy that it will run on an embedded system... but
then it might be too slow for the embedded system because of the use
of int instead of char.

the problem with the fast cpu that are in production is not that
are slow.
the problem is rewrite each program for each cpu or OS
Buon Giorno

[Antoninus Twink]

On 4 May 2008 at 17:57, Eligiusz Narutowicz wrote:

CBFalconer <cb********@yahoo.comwrites:

>You are not very smart, nor knowledgeable, are you?

Please justify your claim. It makes no sense to me. Or you always
make these claims with no proof or background in the subject?

Falconer is an idiot with no discernible technical knowledge or ability.
No one takes him seriously - even Heathfield and Collins have recently
turned on him. There's no point arguing with him - he's a boring old
granddad sitting in the corner in a pool of his own piss and moaning at
anyone who doesn't have the common sense to ignore him.

[Eligiusz Narutowicz]

Antoninus Twink <no****@nospam.invalidwrites:

On 4 May 2008 at 17:57, Eligiusz Narutowicz wrote:

>CBFalconer <cb********@yahoo.comwrites:

>>You are not very smart, nor knowledgeable, are you?

Please justify your claim. It makes no sense to me. Or you always
make these claims with no proof or background in the subject?

Falconer is an idiot with no discernible technical knowledge or ability.
No one takes him seriously - even Heathfield and Collins have recently
turned on him. There's no point arguing with him - he's a boring old
granddad sitting in the corner in a pool of his own piss and moaning at
anyone who doesn't have the common sense to ignore him.

It did seem to be the case from seeing his other posts. He is always
complaining a lots of times and seems to know not too much of C but more
about being rude of posting.

[santosh]

Eligiusz Narutowicz wrote:

CBFalconer <cb********@yahoo.comwrites:

>Eligiusz Narutowicz wrote:

>>CBFalconer <cb********@yahoo.comwrites:
Tomás � h�ilidhe wrote:
>
... snip ...
>
I have my real e-mail address attached to my posts and I only post
under one name (on all kinds of fora across the internet), so I'd
appreciate if you'd abandon that accusation.

That is not a good idea, because of the ease with which the
spammers can access it. I suggest putting the real address in the
'Reply-To' header, which is much less accessible, but is

Do not be so stupid.

You are not very smart, nor knowledgeable, are you?

Please justify your claim. It makes no sense to me. Or you always
make these claims with no proof or background in the subject?

The alleged justification for putting a valuable email address in the
Reply-To field and a disposable address, or an invalid address in the
Sender field is that most email address harvesters collect only the
address in the Sender field, as the Reply-To field is not often
present.

Personally, my experience indicates that at least a few bots _do_ pickup
the address in a Reply-To field too, though the spam received at that
address in significantly lesser than at the address included in the
Sender field. Bots these days are getting smarter and smarter.

My Sender address is a real one and gets large amounts of spam but
GMail's spam filter is very good and almost all spam is delivered to
the Junk folder which I empty periodically.

PS. I'm sure you'll agree from the evidence in the Google archives that
CBFalconer has contributed vastly to this group over a long period of
time. Antoninus Twink was a pure troll up until recently. Now he's a
pure off-topic contributor. :-)

[Ian Collins]

Tomás Ó hÉilidhe wrote:

On May 4, 8:09 am, Ian Collins <[e-mail]:

>Are we witnessing the return of Frederick Gotham?

I am not sock puppeting.

I didn't say you were. It's the similarities in tone and content that
reminded my of that poster. The same arrogance and negativity towards
professional programmers. The same insistence on and justification of
arse about face declarations.

You could be twins.

--
Ian Collins.

[Eligiusz Narutowicz]

santosh <sa*********@gmail.comwrites:

Eligiusz Narutowicz wrote:

>CBFalconer <cb********@yahoo.comwrites:

>>Eligiusz Narutowicz wrote:
CBFalconer <cb********@yahoo.comwrites:
Tomás � h�ilidhe wrote:
>>
... snip ...
>>
>I have my real e-mail address attached to my posts and I only post
>under one name (on all kinds of fora across the internet), so I'd
>appreciate if you'd abandon that accusation.
>
That is not a good idea, because of the ease with which the
spammers can access it. I suggest putting the real address in the
'Reply-To' header, which is much less accessible, but is

Do not be so stupid.

You are not very smart, nor knowledgeable, are you?

Please justify your claim. It makes no sense to me. Or you always
make these claims with no proof or background in the subject?

The alleged justification for putting a valuable email address in the
Reply-To field and a disposable address, or an invalid address in the
Sender field is that most email address harvesters collect only the
address in the Sender field, as the Reply-To field is not often
present.

Personally, my experience indicates that at least a few bots _do_ pickup
the address in a Reply-To field too, though the spam received at that
address in significantly lesser than at the address included in the
Sender field. Bots these days are getting smarter and smarter.

Exactly. And when one has it they all have it.

It is nonsense to say that reply.to keeps you safe.

The point is it is JUST AS ACCESSIBLE.

[Flash Gordon]

Eligiusz Narutowicz wrote, On 04/05/08 18:57:

CBFalconer <cb********@yahoo.comwrites:

>Eligiusz Narutowicz wrote:

>>CBFalconer <cb********@yahoo.comwrites:
Tomás Ó hÉilidhe wrote:
... snip ...
I have my real e-mail address attached to my posts and I only post
under one name (on all kinds of fora across the internet), so I'd
appreciate if you'd abandon that accusation.
That is not a good idea, because of the ease with which the
spammers can access it. I suggest putting the real address in the
'Reply-To' header, which is much less accessible, but is
Do not be so stupid.

You are not very smart, nor knowledgeable, are you?

Please justify your claim. It makes no sense to me. Or you always
make these claims with no proof or background in the subject?

The NNTP protocol allows fetching the From header without fetching the
entire post. There is no such mechanism to retrieve the Reply-To header.
Thus economically it makes more sense to simply pull the From headers
and harvest the email addresses from those. Peoples experience bares out
that this is what occurs.
--
Flash Gordon

[Richard Heathfield]

Eligiusz Narutowicz said:

santosh <sa*********@gmail.comwrites:

<snip>

>>
Personally, my experience indicates that at least a few bots _do_ pickup
the address in a Reply-To field too, though the spam received at that
address in significantly lesser than at the address included in the
Sender field. Bots these days are getting smarter and smarter.

Exactly. And when one has it they all have it.

It is nonsense to say that reply.to keeps you safe.

The point is it is JUST AS ACCESSIBLE.

Um, no, not really. As has already been explained, you have to work harder
to get at it - that is, you have to download and sift through more data to
get the Reply-To than to get the From. Of course you can still get it
easily (after all, our newsreaders manage just fine), but it isn't quite
as easy as the From - in fact, it's significantly more trouble, to the
point where many email address harvesters don't bother.

Like you, however, I don't place a huge amount of confidence in the
difference, which is why I put my email address in my sig, munged in a
form that is apparently too difficult to be understood by some humans, let
alone harvest programs. (No great loss - any Usenet stranger who has
difficulty extracting my email address from my sig is probably someone I
don't want to talk to anyway!)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[CBFalconer]

Eligiusz Narutowicz wrote:

CBFalconer <cb********@yahoo.comwrites:

>Eligiusz Narutowicz wrote:

>>CBFalconer <cb********@yahoo.comwrites:
Tomás Ó hÉilidhe wrote:
>
... snip ...
>
I have my real e-mail address attached to my posts and I only post
under one name (on all kinds of fora across the internet), so I'd
appreciate if you'd abandon that accusation.

That is not a good idea, because of the ease with which the
spammers can access it. I suggest putting the real address in the
'Reply-To' header, which is much less accessible, but is

Do not be so stupid.

You are not very smart, nor knowledgeable, are you?

Please justify your claim. It makes no sense to me. Or you always
make these claims with no proof or background in the subject?

This is a somewhat better response than your last. The point is
that the default protocols transmit the 'from' address. That
protocol is used to select what messages to download, transfer,
etc. The full message is much larger than just the headers, and
the spammers don't want to bother with all that, so they just get
the header to scrape off addresses. This is all covered by the
'less accessible' in my original message.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

[rio]

"rio" <[e-mail] scritto nel messaggio
news:48***********************@reader3.news.tin.it ...

the problem with the fast cpu that are in production is not that
are slow.
the problem is rewrite each program for each cpu or OS

IMO the problem
in language area is not that "the cpu are not fast enought"
but it is "to rewrite each program for each cpu and OS"

Buon Giorno

[Nick Keighley]

On 3 May, 04:53, Jack Klein <[e-mail]:

On Fri, 2 May 2008 13:42:23 -0700 (PDT), Tomás Ó hÉilidhe
<[e-mail] in comp.lang.c:

Let's say we had a simple function for returning the amount of days in a month:

unsigned DaysInMonth(unsigned const month)

First, omitting the "int", even if legal, is sloppy and would not
survive a code inspection in a professional organization.

it would in mine. I find "unsigned" perfectly clear.
Do use auto?

<snip>

--
Nick Keighley

[Nick Keighley]

On 4 May, 13:32, Tomás Ó hÉilidhe <[e-mail]:

On May 4, 7:05*am, Jack Klein <[e-mail]:

I don't know whether that's a good sign or a bad sign, especially
considering I'd aspire to be better than any "professional"
programmer.

Oh, my, I had no idea that you were the ultimate programmer, better
than all the rest, better than the best. *I'll make a note of that.

You'll notice I said "aspire to".

you aspire to be better than any professional programmer.
You are aware that these paople are doing it as a full time job?
So to be better than most programmers is a worthy if tough job.
But to be better thah *any* PP implies you think you are a genius.

There are many C programmers in the
world. Many of them are not very good, and a very small proportion of
them are excellent.

fair enough

You spoke of "code inspection" which is why I
assumed you were talking about professional programmers.

they are probalby more likely yo do code inspections.
Though I bet some of the Free stuff is viewed pretty
critically. The Linux kernal for instance.

The vast
majority of professional programmers are not very good,

and you know this how? Interestingly, The last time I was told
this it was by an estate agent.

which is why I
expressed the view that I'd aspire to be better than a professional
programmer.

How you took arrogance from my statement, I don't know.

imagine...

In that case, why are you bothering to waste your time bestowing your
wisdom on other, lesser, programmers? *Our opinion is meaningless to
you.

Again, I think your arrogance sensor is dodgy.

it isn't

<snip>

--
Nick Keighley

[=?ISO-8859-1?Q?Tom=E1s_=D3_h=C9ilidhe?=]

On May 6, 1:21*pm, Nick Keighley <[e-mail]>
wrote:

you aspire to be better than any professional programmer.
You are aware that these paople are doing it as a full time job?

Yes, I'm aware.

So to be better than most programmers is a worthy if tough job.

Not exactly a tough job, especially if you enjoy it.

But to be better thah *any* PP implies you think you are a genius.

I can say right now that I'm better than a hell of a lot of
professional programmers. I've seen code written by professional
programmers and also by the likes of programming lecturers, and I've
very often immediately seen ways of improving it. This is a more a
reflection on their lack of ability rather than my surplus. Also I've
seen many cases of professional programmers using non-portable
techniques in places where not only was there a perfectly suitable
portable technique, but also where the portable technique was faster.
E.g.:

double arr[32];
memset(arr,0,sizeof arr);

versus:

double arr[32] = {0};

You spoke of "code inspection" which is why I
assumed you were talking about professional programmers.

they are probalby more likely yo do code inspections.
Though I bet some of the Free stuff is viewed pretty
critically. The Linux kernal for instance.

I bet the people working on the Linux kernel are way way WAY better
than the people working on Vista's new widget system. You only have to
take one glance at the Win32 API to realise just how crap Windows
programmers are.

The vast
majority of professional programmers are not very good,

and you know this how? Interestingly, The last time I was told
this it was by an estate agent.

From looking at their code. And interestingly, I'm a programmer as
opposed to an estate agent.

[huib188]

On 4 mei, 22:18, Flash Gordon <[e-mail]:

The NNTP protocol allows fetching the From header without fetching the
entire post. There is no such mechanism to retrieve the Reply-To header.

Not really,

telnet textnews.cambrium.nl nntp
201 news.cambrium.nl NNRP Service Ready (no posting).
GROUP comp.lang.c
211 85516 123425 208940 comp.lang.c
XHDR reply-to 208533
221 reply-to data follows
208533 cb********@maineline.net
..

- Huibert

[=?ISO-8859-1?Q?Tom=E1s_=D3_h=C9ilidhe?=]

On May 6, 6:16*pm, [e-mail] wrote:

telnet textnews.cambrium.nl nntp
201 news.cambrium.nl NNRP Service Ready (no posting).
GROUP comp.lang.c
211 85516 123425 208940 comp.lang.c
XHDR reply-to 208533
221 reply-to data follows
208533 [e-mail]

You're my hero! Is there a forum or anything where people play around
with stuff like this? I sent e-mails using telnet a few years ago but
I'd love to try out all different stuff.

[Flash Gordon]

hu*****@gmail.com wrote, On 06/05/08 18:16:

On 4 mei, 22:18, Flash Gordon <[e-mail]:

>The NNTP protocol allows fetching the From header without fetching the
entire post. There is no such mechanism to retrieve the Reply-To header.

Not really,

Well, not always.

telnet textnews.cambrium.nl nntp
201 news.cambrium.nl NNRP Service Ready (no posting).
GROUP comp.lang.c
211 85516 123425 208940 comp.lang.c
XHDR reply-to 208533

XHDR is an extension that may not be supported by all news servers. The
standardised HDR command is not required to work for all header fields
(and may not be implemented by all news servers).

Anyway, this has gone somewhat off topic.
--
Flash Gordon

[Flash Gordon]

Tomás Ó hÉilidhe wrote, On 06/05/08 13:41:

On May 6, 1:21 pm, Nick Keighley <[e-mail]>
wrote:

>you aspire to be better than any professional programmer.
You are aware that these paople are doing it as a full time job?

Yes, I'm aware.

>So to be better than most programmers is a worthy if tough job.

Not exactly a tough job, especially if you enjoy it.

Tough often means difficult and being better than most programmers is
certainly difficult to achieve.

>But to be better thah *any* PP implies you think you are a genius.

I can say right now that I'm better than a hell of a lot of
professional programmers.

I suspect you are as yet nowhere near the standard of other professional
programmers.

Both comments could be applied equally well to non-professional programmers.

I've seen code written by professional
programmers

Only a small amount of it. I doubt that you have seen much written for
the avionics or automotive industries.

and also by the likes of programming lecturers,

Which may not be the best for a number of reasons.

and I've
very often immediately seen ways of improving it.

So have I and I have spent a number of years as a professional
programmer. I've also seen stuff that I could not improve and seen stuff
written faster than I could write it.

This is a more a
reflection on their lack of ability rather than my surplus. Also I've
seen many cases of professional programmers using non-portable
techniques in places where not only was there a perfectly suitable
portable technique, but also where the portable technique was faster.
E.g.:

double arr[32];
memset(arr,0,sizeof arr);

versus:

double arr[32] = {0};

So they have more to learn. Now see if you can write a 50,000 line
program. The big test is not if you can do a small amount but if you can
write a program of significant size and complexity. Oh, 50,000 lines is
not large.

>>You spoke of "code inspection" which is why I
assumed you were talking about professional programmers.

they are probalby more likely yo do code inspections.
Though I bet some of the Free stuff is viewed pretty
critically. The Linux kernal for instance.

I bet the people working on the Linux kernel are way way WAY better
than the people working on Vista's new widget system.

You are comparing apples with green grocers.

You only have to
take one glance at the Win32 API to realise just how crap Windows
programmers are.

Possibly if you mean people who originally designed the Win32 API, not
if you mean people who write SW for Windows.

>>The vast
majority of professional programmers are not very good,

and you know this how? Interestingly, The last time I was told
this it was by an estate agent.

From looking at their code.

Probably (in my opinion) most professional programmers are working in
areas where you would have no chance of seeing their code.

And interestingly, I'm a programmer as
opposed to an estate agent.

So? How much output of professional programmers have you seen? Have you
reviewed a moderate sized project?
--
Flash Gordon