Hi, I'm working on one. It's a recent DSP with pretty massive processing power that's powering some really, really expensive machines (six figures a piece). A byte is 32 bits here. This is common on a lot of VLIW machines.

I guess uint8_t et co. appeared out of the plight of many systems programmer who needed to do things like "hand these precisely 8 bits to this peripheral". On this machine, getting only these specific 8 bits out of a char requires bit twiddling trickery (it doesn't support unaligned memory access), but if the peripheral you're talking to (e.g. a temperature sensor) calls 8 bits a byte, you're going to have to send it 8 bits, not teach it that a byte doesn't always mean 8 bits.

Prior to stdint.h (and on any platform without a C99-enable compiler, which are neither few nor unused), we used to work around this crap with a bunch of custom macros defined in hardware-specific header files. It was a mess and you needed to learn a lot more about every specific platform's compiler than you ever cared about. And it was particularly beautiful on bi-endian platforms, oh yes, those were so beautiful.

C99 came and said you know what, this is so platform-and-compiler-specific that the compiler should worry about it and that accounted for a massive relief of about 20% of my daily stress dose.

You should use it when you know that you need something to be exactly 8 bits long. Which may or may not be a byte (that's why it frickin' says int8_t and uint8_t, not byte and ubyte).

Edit: I'm going to piggyback on my comment and gently ask anyone to consider not blindly following the advice to inline the declaration of b in code like this:

    void test(uint8_t input) {
        uint32_t b;

        if (input > 3) {
            return;
        }

        b = input;
    }

In many (most?) cases, that's good advice, but declaring it (and any other local variables) in the beginning has the major advantage of allowing me to read the first line of the functions and tell how much space is being allocated on the stack when the function is called.

This is not only nice to know for performance reasons, it's also useful information for platforms that have limited stack size or -- my favourite! -- platforms that lack a MMU, so when your stack runs into useful data, your system doesn't crash, it just starts acting funny.

Just one counterexample: Texas instrument C28x core is 16-bit addressable. Each byte is 16 bits.

>The TMS320C28x byte is 16 Bits. By ANSI/ISO C definition, the sizeof operator yields the number of bytes required to store an object. ANSI/ISO further stipulates that when sizeof is applied to char, the result is 1. Since the TMS320C28x char is 16 bits (to make it separately addressable), a byte is also 16 bits.

http://processors.wiki.ti.com/index.php/Byte_Accesses_with_t...

C is the closest thing to universally portable assembler.

I fail to see how C is more portable than any other memory safe systems programming language, other than having the fortune that for 30 years OS and hardware vendors decided to only support C compilers.

But that's the most important thing, isn't it? Being able to compile and run your code? I mean, the English language sure isn't popular for its intrinsic merits either, but here we are.

Sure, but in a way C is the JavaScript of systems programming languages, in a deep need of a "The Good Parts" book as well.

I'm sorry, but is this comment a joke? Have you ever read "The C Programming Language", and seen how simple C is? These arguments that the two OPs are having are important, but only when faced with obscure architectures that nearly nothing but C will run on.

Conversely, JavaScript's failures are not because of the wide variety of architectures that it supports (a tiny fraction of C's), but instead on the monolithic and bad design of the language. If you read "The C Programming Language", you'll realize that in the ~240 pages of text, you know basically every feature of the language. It's small, and it's elegant, and it's portable. JavaScript is none of those.

It is not a joke, rather the conclusion of someone that was already dismayed with C back in the mid-90's.

> If you read "The C Programming Language", you'll realize that in the ~240 pages of text, you know basically every feature of the language.

Except for those little compiler specific little issues, it seems:

http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

http://blog.regehr.org/archives/213

http://blog.regehr.org/archives/226

http://blog.regehr.org/archives/232

> It's small, and it's elegant, and it's portable

Have you had the pleasure to port C code across multiple C compilers and OS in the mid-90's?

Agreed. (yes, did a lot of C in the mid/early 90s that ran on sundry unices, DOS, OS/2, Windows & VAX). Ouch.

"The C Programming Language" isn't that great of a book, either. I had FAR better luck making sense of C (after having been in school for almost 4 years, and working part time on another language for almost 2 years) with the book "C, An Advanced Introduction" (1st version, not "ANSI Edition"), by Narain Gehani. For somebody transitioning from real high level languages, the array/pointer/string swamp was a real source of anti-productivity fun and games until explained by somebody other than its creators.

When you're done with The C Programming Language, read Expert C Programming, C Traps and Pitfalls, and The C Puzzle Book. Then tell me how simple C is.

Have you read "Expert C Programming: Deep C Secrets"? That book will show you that a simple language does not mean that programming in it is simple.

On a related note, I believe "The C Programming Language" is not a good book for the realities of 2016.

There's two recommendations here for "Expert C Programming".

I read it cover to cover fairly recently; I don't think there was really anything I disagreed with, but there also wasn't anything I didn't already know and wasn't already practicing. While I've been programming C a while now, that surprised me. I've decided that the book isn't bad but is probably more "help get you from beginner to intermediate" than "help get you from intermediate to expert", much less something of use to an expert (sadly, in my position).

An alternative interpretation would have it that there is just not enough to say about C that an expert-level book is likely to say things a C expert would not already know. That would argue against your point about the complexity of C. As I say, though, this has not been my conclusion.

[1] Except that Eliza was named after the character from Pygmalion - I'd somehow never put that together!

C is not simple.

There are tons of such books.

Compilers. Compilers for everything.

You can hype your favorite systems language all you want, but if there is no compiler, it wont compile.

>OS and hardware vendors decided to only support C compilers.

If you want your favorite language X to work everywhere C does. Just make X-to-C compiler.

X-to-C compiler isn't as nice as it could be, because you're writing code for some weird chip and need to twiddle some bits for IO using a macro defined in a header somewhere, and that doesn't play nicely with your pet X-to-C compiler.

Not an ideal situation, for sure, but a real one.

It's possible for translator understand headers and macros and generate bindings for them. Even for function macros. For example, GNAT has macro binding although it's not complete.

Btw. There is nothing "pet" in X to C translators. You pay good money for a good Ada to C compiler.

Or an RPG II to C translator/compiler :-)

A job I had in the early 90s, maintaining and extending such...

Of course, but that is an issue of implementation availability not language quality.

I remember the days when using C meant getting an account to the university (or work) UNIX system.

Every TI DSP I've worked with uses 16-bit bytes

c6x has 8-bit bytes.

>Bytes and octets are the same today. I never came across a system where this wasn't true.

The fact that all modern systems use eight bit bytes is no reason to assume that a byte is eight bits. The fact is that a byte is not eight bits large.

People may wish to run code on "historical" systems, and someone may wish to create a 9-bit byte system for fun.

To write C code with an assumption that things are one way, when the standard does not define this assumption, screams of unportable code. You might as well use GCC extensions - after all, for a long time, what would it matter? Everyone used GCC, right?

By the same argument we shouldn't assume that bits have only two values - what, you mean I can't write C for my ternary logic computer?

You need to make a decision about which simplifying assumptions you make - C has decided not to assume there are 8 bits to the byte. I think it's arguable that in 2016 this is not the best decision, and they could get rid of some cognitive overhead by making the simplifying assumption.

Unfortunately, there are real world systems with C compilers that do not have 8 bit bytes. It's easy to forget the embedded world.

C is one of the very, very few languages that you can reasonably expect to run on your weird embedded microprocessor, microcontroller, DSP, or whatever.

Bit, however, means "binary digit". That's the literal definition of the word. Historical usage of the word "byte" has varied.

> C is one of the very, very few languages that you can reasonably expect to run on your weird embedded microprocessor, microcontroller, DSP, or whatever.

I'm not an expert on DSP processing in any way, but I'd argue that if the environment is so peculiar that it doesn't have 8-bit bytes, you won't be able to use so many of the (formally optional) parts of C that you might as well call your code "weirdC" and do without char. It's not like you're going to use normal C libraries, and you are most probably relying on a specific compiler implementation and a lot of platform specific weirdnesses.

You can use char, and for the most part you won't notice any difference, until you start looking at the memory display in your IDE and have a short-lived WTF moment. A c-string looks strange in the memory view because there's a NULL octet between each character but that's an implementation detail that you don't really notice 99% of the time, because everything on the processor is designed to use 16-bit words. If you write a buffer of chars to the UART tx register, it will only put the half of the word with the character data onto the wire, just like with any other microcontroller, just like with PySerial, and just like with JS and websockets. That's why the C standard doesn't say a char is 8-bits, it just says that sizeof(char) is 1. I would argue that any code doing anything under the assumption that a char variable occupies 8 bits in memory and that the next char in an array is physically adjacent to it with no wasted space in between is just poorly-written and inherently not portable.

As for why this is the case, Generally DSPs are designed to do a few tasks very well (multiply-accumulate being the most obvious example, simultaneous reads from X and y memory, etc.) and are generally optimized for a specific word size. If you really need to access an octet on E.g. A 16-bit TI DSP you can, you just need to shift and mask. That's obviously not very efficient, because that's not really what it's optimized for. If that's what you really need, you picked the wrong part. You're gonna be filter-/FFT-/DCT-/whatever-ing way more 12 or 16-bit ADC samples per second, per dollar, and per milliWatt on that 16-bit DSP than you would be on your octet-addressable MSP430.

Regarding "Normal" c libraries, If they're valid C they should work just fine for the most part, With some obvious exceptions: you're not going to have a fun time with your "floats" on a processor without FP HW. That's why there's a standard, if you're not relying on undefined or implementation-defined behavior, you'll be fine(ish)

> I would argue that any code doing anything under the assumption that a char variable occupies 8 bits in memory and that the next char in an array is physically adjacent to it with no wasted space in between is just poorly-written and inherently not portable

I don't think that's fair at all. It's well written and perfectly portable, under that assumption. If that assumption happens to hold for all the systems that could is meant to run on, why shouldn't you make it? Why assuming that unsigned integers overflow to 0 is fair, and assuming 8 bit bytes is not? They are both pragmatic choices. I think arguing that the C standard didn't make the best choice is at the least a reasonable position. Saying that people who disagree with you on this are writing bad code is not the right way to approach the subject, IMO.

> If they're valid C they should work just fine for the most part

I've yet to find a library that is valid C, in the strictest sense of the term - i.e., no floats or doubles, no 8-bit char, no uint8_t, etc. I'm sure there are, among libraries meant to run on DSPs. Does it make sense for them and libraries meant to run on bigger processors to adhere to the same exact standard? I'm not sure.

> If that assumption happens to hold for all the systems that could is meant to run on, why shouldn't you make it?

Because what's going to happen two years down the road when you need to get that code working on a different platform.

(In the old days, they called that thinking "all the world's a VAX", which became "all the world's linux" in the not-quite-as-old days)

> Because what's going to happen two years down the road when you need to get that code working on a different platform.

And what happens when the different platform handles overflow differently? Or has non-IEEE floats? Or breaks whatever assumption the C standard already makes?

Here's the thing: C is already built on assumptions, which might or might not hold for a specific platform.

Choosing which assumptions we hold true is a pragmatic choice that must be done. C does it, and does it consciously - but it doesn't mean that it nails every choice.

If you're in a situation where you need specific implementation details of floating point arithmetic, then may the devil have mercy on your soul, because god certainly won't.

Wouldn't debugging / testability imply this is a fairly large proportion of programs? Having a calculation give different results on different hardware would make testing difficult: http://yosefk.com/blog/consistency-how-to-defeat-the-purpose...

Your own link explains how easy it is to get different results even on the same hardware depending on compiler flags.

Maybe "poorly-written" was a bit strong, but if you're making that assumption, you are by definition relying on un- or implementation-defined behavior.

The fact that a char is stored on silicon in the lowest 8 bits of the smallest addressable memory space really makes no difference. char arrays act just like they do on any other platform.

There aren't a lot of libraries floating around that you'd be using on a DSP, aside from vendor-supplied ones. Generally you're using a DSP because you have specific signal processing needs and power and cost requirements, which are pretty orthogonal to the requirements of most desktop development. As such, there probably isn't a huge amount of overlap between the libraries you'd be using.

Another reason for that being that quite a bit of the time you're not running an OS. There is no transparent abstraction layer that magically maps an ADC IC connected via SPI to an arbitrary group of remappable peripheral pins to /dev/adc0. I think that's kind of the big disconnect between desktop and embedded, so much of the code is specific to the processor/DSP and the arbitrary external hardware connected to it. You can't take code written for a DsPIC that uses the internal ADC and run it on an MSP430 with an internal ADC for the same reason. There isn't necessarily a POSIX layer, so it's a very different beast than writing code that works on UNIX, Linux, and OSX. Look at the Linux source and see how many architecture-specific files there are in each architecture's folder. That's what you need to get a consistant interface across different processors. Without all that non-portable abstraction code running below yours, posix- and standard-compliant code still wouldn't be portable.

As far as using the same standard, I think it's a good thing that there is agreement on what the effect of a given construct is. I think the issue comes when you expect that code written for one platform to just work(TM) on another.

ehmmmm standard C has floats and doubles. so they are valid C

>Why assuming that unsigned integers overflow to 0 is fair

because the standard says so

In your other posts I noticed some more misunderstanding of the C standard, so I suggest not to talk about things you are not aware about.

> ehmmmm standard C has floats and doubles. so they are valid C

Sure, but the standard says hardly anything about their behaviour, making it practically impossible to write code that actually does anything with floats and doubles that will behave correctly on any standards-compliant C implementation.

I suggest you refrain from personal attacks, especially based on your own misreadings of the comment you're replying to.

>but the standard says hardly anything about their behaviour, making it practically impossible to write code that actually does anything with floats and doubles that will behave correctly on any standards-compliant C implementation.

No, not really. This reminds me the common "you can't write anything serious in C without undefined behaviour" bs.

However, if you DO have a real need of IEEE-compatible floats for whatever reason, then there is nothing wrong with checking __STDC_IEC_559__ and reporting an error if it is not defined. In fact, if you are using a system that doesn't have an IEEE float implementation, using another language won't save you.

>I suggest you refrain from personal attacks, especially based on your own misreadings of the comment you're replying to.

Feel free to show me what I misread. I would also suggest that you try to read the nonsensical bullshit he has been spreading in this thread.

> However, if you DO have a real need of IEEE-compatible floats for whatever reason, then there is nothing wrong with checking __STDC_IEC_559__ and reporting an error if it is not defined.

Sure - but in that case why not do the same thing for insisting that char be 8 bits?

Except than the fact that it does not limit you except in some very specific cases, unlike the IEEE incompatible floats thing.

If it does limit you somehow and you really need char be 8 bits, then sure.

I think you're underestimating the amount of legacy code that people have. We're not talking about "I have a new processor, let's write code for it." That's unrealistic. It's more like, "I have a new processor, let's get our existing code base working on it, because if we don't, we're going to lose millions of dollars."

That doesn't touch my argument. If you're code is meant to run on DSPs it will already enforce all the relevant rules; if not, you'll have to port it anyway. It's not like your compiler backend that outputs code for DSPs will just compile standard C.

All the code using non-optional c constructs will compile. If you're doing something that uses floating point math and expecting to run it on a 16-bit DSP, you're probably doing something wrong. The biggest hurdle isn't compiler support, rather converting all the floating point operations to fixed-point and ensuring that you have enough resolution such that rounding errors don't make your IIR filter unstable for example. That's really outside the scope of the discussion though, as that is just an aspect of practical DSP using fixed point math.

As a male human of questionable maturity, I'd just like to say that I am really looking forward to working with ternary digits!

As a matter of fact, GCC extensions are de facto standards at this point. Clang had to copy most of them.

Same with bytes not being 8 bits. Nobody will ever make a system where that's not the case anymore. You'd break de facto compatibility with almost all C code for no reason. Market realities trump making systems "for fun".

>You'd break de facto compatibility with almost all C code for no reason.

The authors of that code should have written portable code if they didn't want it to break.

If a few people write unportable code in your language, they're bad programmers. But if everyone writes unportable code in your language, it's a bad language.

Texhnically, they did. The go to compiler for years was GCC, with all the GNU extensions turned on. The problem is that those extensions were classically on by default, so it was very easy to just use them without thinking too much about it.

On GNU/Linux, yes.

Outside world, there are tons of C compilers to chose from.

If you're designing a new ISA, it's extremely difficult to succeed in the market no matter what you do. But one excellent way to guarantee you won't succeed is to have that attitude toward your developers.

> People may wish to run code on "historical" systems, and someone may wish to create a 9-bit byte system for fun.

I bet there will be then bigger problems with porting the code than assuming byte is 8 bit long if someone is creating a 9-bit system "for fun".

I would be very surprised if some non-trivial C code written for x86 compiles and runs unmodified on exotic platforms. Besides, I don't want to be hold back by people wishing to run code on historical or experimental systems.

> Bytes and octets are the same today.

Not in DSPs. Today.

The XAP processor architecture use in CSR Bluetooth Chips (design orginally from Cambridge Consultants) is one such processor.

On it: A 'byte' is 16 bits. A word is 16 bits (so sizeof(int) == 1) A function ptr is 24 bits (so sizeof(Fx) == 2)

CSR have sold well over a billions chips. There is a strong argument that this is the 3rd most popular architecture family after ARM and X86/64.

Things that x86 programmers do that won't work because they make assumptions the C standard doesn't specify: Cast a uint16_t* to uint8_t* to extract the upper and lower octets of the uint16 (a uint8_t array is actually in memory a uint16_t array using only the lower 8 bits) Store a function pointer in a void* (throws away upper 8 bits of the 24 bit func pointer).

Would you port x86 code, like say the Apache web server, to this chip? Or is it basically a memory constrained little device that you are writing a driver for, from scratch?

Seems like you would learn the rules, even though they are a bit odd, easily enough while writing something from scratch, or maintaining an existing (somewhat) small driver program.

Agreed, though, be aware (or just beware?) that this chip is quite different, and new skills MUST be learned.

char is apparently still not always 8-bit on current DSP chips, where everything is 32-bit. Historically, PDP-8's used 12-bit bytes and Crays also used 32-bit bytes.

(EDIT: fixed PDP-11 -> PDP-8, thanks kabdib!)

PDP-11s always used 8-bit bytes, you're probably thinking of the PDP-8.

I don't remember what the popular sizes for the PDP-10 were. A 36-bit machine, none of the choices were really great. (I know that CLU on the PDP-10 used 36 bits).

Yeah at least since the 80s bytes has been taught as "8 bits" for as long as I've ever heard it.

That said, uint8_t is more explicit (and less to write).

What was the original distinction between bytes and octets? Byte = word vs octet = 8-bits, i.e. a byte is not necessarily 8-bits long?

A byte is the smallest addressable unit. An octet is a unit of 8 bits, which is a common size for a byte.

A byte is the smallest individually-addressable unit.

Oh, well, if you haven't seen something then it must not exist.

"I wasn't even told that there once were systems where this wasn't true until fairly recently."

Wait, so someone filled in a piece of your ignorance and your response is still "Bytes and octets are the same"?

To be fair, what they actually said was, "Bytes and octets are the same today". It's a little disingenuous, I think, to quote everything but the last word, especially since the qualifier "today" was kind of their entire point.

In the words of SLJ, allow me to retort. Bytes and octets are the same today on the hardware the OP is used to working with; I'm guessing whatever the latest generation of commodity x86 derivatives is.

The real crime here isn't lack of knowledge; it's thinking that one's own narrow experience is all-encompassing and that what's true in one part of the programming world is true everywhere.

I'm not disputing your last statement. I'm saying that, if you are going to quote someone, quote the whole sentence, at least, and don't leave out words that are substantial to the point they are making.