C++ problem

That's the way the C language works. You can laugh about it (or indeed cry about it, when it leads to wailing and gnashing of teeth), but that's what C does. Before any sort of arithmetic operation or comparison, any types that are smaller than "int" get promoted to "int" (that's a simplification, but good enough for now). So on a 32-bit system, uint16_t types get turned into int32_t types with the same value, and then the operation is carried out.

You can force unsigned behaviour by simply casting one of the parts to uint32_t, as in "(uint32_t) a * b", which will also ensure that b is converted to an uint32_t (it passes through "int" on the way, but that makes no difference).

I expect you will consider this one of the reasons you prefer assembly to C, and there are many (myself included) who think the rules of C are a bit weird here. But we have to live with it.

The OP has responded at least once, but no code. Funny...

God, I wish. I write C, -Wall, -Wextra. No warnings, all is good. I write perfectly good VHDL and I'll often wind up with a THOUSAND warnings.

At one point I tried going through with an Awk script after the fact to look for known warnings and suppress them from the output, but managing the list of "known warnings" just got to be too much lift.

My projects tend to be on the small side so I can usually focus on the more important parts of the project earlier and deal with the warnings toward the end. I do make sure I have vetted every warning before I release any design to a customer. There are pitfalls in FPGA design and if the tools are telling me of any of them I want to utilize that.

Most of the warnings have to do with optimizing away logic that was added as part of a vendor supplied and utilized module that has functions which are unneeded. When the unneeded outputs are optimized away a warning is reported. Silly vendors.

I dunno

But I've only ever come across the rule to do it this way in C++

No C shop I have ever worked in has said "never used defines for constant (numeric) values", all of the C++ ones have

tim

I don't need "help".

I have solved it now.

I just wanted to know if it was my mistake, or the compliers. As I said, my C++ experience is limited - and all self taught (for that matter the second part apples to my C experience)

But in 25 years of C programming I have never come across this issue before.

That could be because I have never tried to do the same thing (as I said earlier, if I was writing the exact same solution in C my zero cionstant comparison value would have been a define - and in upper case.) But that still leaves the possibility that I might have used a comparison between a signed and an unsigned variable.

tim

I am not disagreeing with you (as I don't know.)

But the point is, the first mistake makes me an idiot, the second just lacking in knowledge

tim

cos I access usenet at home and the code is at work

(I'm on GMT, so I'm now at home)

:-(

tim

So was it your mistake or the compiler's? I still don't know what you did so the type cast didn't work.

I worked at a place that wouldn't let me access usenet and it was an issue. I liked getting advice from the many which included company representatives at that time. My bosses attitude was, "ask people here" which was his typical short sightedness.

OK

I'll try that again tomorrow.

I'll try the C++ cast as well

and if it still doesn't work I'll cut a copy of the code for you

It's not really forbidden (as far as I can tell), just that I haven't taken the time to set up a newsreader

the last place that I worked it was normal to put queries on stackoverflow.com

tim

The first step to progress is to question conventional wisdom!

A good many "rules" for C, or coding standards, have a long heritage - stretching back to when ANSI C was new, and "const" was a strange, newfangled concept with poor compiler support. And for a long time, many embedded C compilers have been rather limited or inefficient - if you made your fixed values as "static const int" the compiler would put that value into flash (or even ram) and read it from there, rather than optimising the value at compile time. Needless to say, this could be very inefficient. While most compilers these days are better than that, the myth lives on.

There is also the issue that in C, unlike in C++, a "static const" is not a constant expression - you can't use it as a switch label, or for giving the size of an array.

So while I fully agree with you that C++ guidelines commonly emphasis const's over #define's, and C guidelines commonly do not, I recommend using static const in C code too.

We are only looking for a snippet that demonstrates the problem. At work tomorrow, figure out a minimal code example that shows the issue, using fake names to protect the innocent (and guilty), then copy it to a post-it note and smuggle it home and post it here tomorrow night. We should be able to figure out where the misunderstanding lies - escalating to comp.lang.c or compiler mailing lists if necessary.

Isn't this group accessible by Google groups? Certainly that would work ok to make one post of the code from work. Or you can do like was done with the DeCSS program and print it on a tshirt and wear it home. lol

Is there a word for searching on the Internet for one thing and 15 minutes later coming up with a dozen other interesting topics? I know that was featured in an XKCD cartoon. Seems like there should be a word... I was looking for the name of the group that spread the word about the DeCSS program and ended up learning about Martha Payne, a 9 year old who started a blog about the school lunches and ended up

I have:

I like the "C" rule. I like that fact that consts are identified by them being in Caps, it is useful.

I hate the fact that in C++ they look like normal variables, so I questioned the C++ rule, and because I am less experienced in C++ than the person who oversees the rules I get told to "take a hike".

You may think that the stronger typing helps you get to working code. My experience is different. In 35 years of (mostly) embedded development, a type mismatch has never ever caused a problem which (once discovered) took more than a little thought to find the source and fix.

OTOH there have been multiple occasions when some different type of error that the compiler didn't spot has taken weeks to resolve.

I shall feel free to ignore that advice

tim

The 21st century version of taking an hour to look up a word in a dictionary... But I don't know of a word for it.

Firstly.

I stupidly forgot that it is Friday today [1], and I am not at work, so it will have to wait until Monday.

and secondly I don't need clever ways to smuggle it home. I don't work in a place that has any rules about taking code home (that's not to say that they "like" it, just that they trust staff to be "professional" - which in the main, they are!). I can simply email it from my work email to my home email

tim

I should try to look that up...

Since you clearly don't know how C works, I suggest you stop responding. Funny how you were advising someone to stop digging earlier.

Nothing stops you from naming consts in caps: static const uint32_t XYZZY = 3; works just fine.

Well, that's not very good manners on the other person's part, but C++ has such a wide range of possible styles that (more than in other languages IMHO) project leadership has to enforce a level of uniformity. They should at least be nice about it though.

Yes, the idea is that it's better to prevent the problem in the first place than require you to discover it (often at the worst possble time) after the code is already running.

I do have the impression that C static analyzers have gotten a lot better lately, but it's been a while since I wrote very much C.