Integer types in embedded systems

[Tomás Ó hÉilidhe]

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;

 

[Thad Smith]

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.

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.

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.

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


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.

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.

 

[Tomás Ó hÉilidhe]

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.

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.

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.

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.

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.

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.

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

Single 8-Bit register again.

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

Not entirely.

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.

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.

 

[Anand Hariharan]

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.
(...)


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.

 

[Ian Collins]

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?

 

[Tomás Ó hÉilidhe]

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.

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.

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, 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".

 

[Tomás Ó hÉilidhe]

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.

 

[Flash Gordon]

Tomás Ó hÉilidhe wrote, On 04/05/08 13:32:

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.

I've been in SW development professionally since 1985 (although I was
obviously very low on the ladder back at the start and a lot was not in
C) and most of the professional SW developers I have worked with have
been good or better than good in the areas of SW development they worked
in. I've met some who were not very good, but in the areas I have worked
they were in the minority.

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

Well, you do seem to think your opinions are worth more than the
opinions of people with vastly more experience. Personally I would put
Jack's opinions on C in an embedded environment ahead of mine.

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.

All the embedded world is not PICs.

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).

The fastest integer type for one purpose is not always the fastest for
another. I've worked on a processor where the way to get maximum speed
would generally be to use 16 bit inputs, 32 bit intermediates and then
drop down to 16 bits for the results. So what size should int be? On the
C compiler for this processor int was 16 bits (the size of the data bus)
and the accumulator was 32 bits and the C compiler provided you with
some nice additional guarantees about how it would treat certain
constructs when mixing ints and longs so you new that with the following
int a=20000;
int b=30000;
int c = ((long)a * b) >> 16;
The compiler would use the most efficient assembler possible (at most 3
instructions taking at most 3 clock cycles excluding wait time on
external RAM). However no such guarantee applied if you did not widen to
long for the multiply.

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.

Personally I have no problem with using the new fast types, however they
will not always produce the fastest code. For instance, it might be a 32
bit type which is fast normally but because you have a large array it
does not fit in the cache and so is slower than a smaller and otherwise
slower type.

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).

This would have made int a lot less useful for a lot of cases. The need
for integer types larger than 8 bits is so common that even on 8 bit
processors in the 80s it was common for the processor to provide good
support for working with wider types. I know I used register pairs a lot
on the old Z80!

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".

So that makes it "one project, on..."

The compiler hasn't got much power in deciding int type lengths
if it has to work with an 8-Bit microcontroller.

Well, it has, but making it other than 16 bits would be a little foolish.

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.

Well, my experience is that 8 bits is commonly too small and 8 bit
processors can to 16 bit arithmetic reasonably efficiently (add with
carry instructions and/or register pairs etc). Although I will admit to
not knowing the PIC.

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

Jack probably realises all of the tradoffs better than either you or me.

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

Some people consider whether it is signed or unsigned to be more basic.
I any case, you are going against years of common practice, and from
personal experience consistency is generally more important than that
the style be the best possible style.

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

Putting const on a parameter does not really do you much good and means
that either you have a redundant const in your declaration in the header
file or the declaration and definition look different, neither of which
are things I would consider good.

No at all. I've seen more than one excellent programmer write like
that.

Probably at least an order of magnitude more than you have seen do it
your way.

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).

Ah well, here the balance is probably closer to even especially with
people who are also practised in C++.

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

That gives you one point, but in my opinion it is a point worth a lot
less than consistency with by far the majority of other programmers.

 

[Eligiusz Narutowicz]

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?

 

[Eligiusz Narutowicz]

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?

 

[Antoninus Twink]

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]

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.

 

[Flash Gordon]

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

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.

 

[santosh]

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]

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.

 

[Eligiusz Narutowicz]

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.

 

[Nick Keighley]

On Fri, 2 May 2008 13:42:23 -0700 (PDT), Tomás Ó hÉilidhe



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]

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...



Again, I think your arrogance sensor is dodgy.

it isn't

<snip>

 

[Tomás Ó hÉilidhe]

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};

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.

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]

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 (e-mail address removed)
..

- Huibert