Slashdot Mirror
Is IoT a Reason To Learn C? (cio.com)
itwbennett writes: Whether or not beginning programmers should learn C is a question that has been roundly debated on Slashdot and elsewhere. The general consensus seems to be that learning it will make you a better programmer -- and it looks good on your resume. But now there might be another reason to learn C: the rapid growth of the internet of things (IoT) could cause a spike in demand for C skills, according to Gartner analyst Mark Driver. "For traditional workloads there is no need to be counting the bytes like there used to be. But when it comes to IoT applications there is that need once again..."
Someone create a IOT language!
Ceci n'est pas une Signature !
IoT == massive surveillance bots + massive zombie botnet
The premise of this question is evil.
Choose to learn or not learn C for whatever the reason. But it is disingenuous to ask this loaded question pre-laden with an evil assumption.
and I not sure learning C will help much with that.
Pain is merely failure leaving the body
Why bother with learning C when "learning" Java or other managed-runtime-based languages can get you employed based upon your interviewing skills with "design pattern" knowledge? From experience, candidates which focus on design-pattern knowledge are actually the least competent....
IoT is not confined to something as low level as C.
I heard this said before about phones, but eventually technology developed enough to allow mobile devices to have a strong enough processor. People are already too used to program higher-level and I see no reason why the same environments we have in our phones can't run on our fridges or boilers or ovens, therefore I do not think that people will use C.
Avantgarde Hebrew science fiction
MIPS ASM or GTFO
IoT is a reason to learn a few things about IT security. Whether you plan to develop in the field or go into consulting, IoT means total job security in the IT-Security field for the foreseeable future.
Quite frankly, if you thought Microsoft is keeping security busy, just wait 'til IoT makes it big into the office space. You're looking at security holes and blunders you can't even imagine today! And every single of them are a sweet, sweet, 4 to 5 digit consulting gig!
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Android Things uses Java, and I'm sure other devices will use different languages (python, or something else that comes along). C is a nice to understand kind of language if you want to move libraries for Arduino to other platforms, but understanding any similar language will make that trivial.
The language that pretty much invented to buffer overflow? Yeeeah, I think you might be right.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
If its imported as a product what code is going to be done? Branding over some device ready GUI?
Thats more an art skill for a web app?
Making your own IoT device in the USA? Whats trendy in 2017 for low level design work?
A US design team with the needed skills will work on that.
If the kit is sold, most of the work has been done.
If your making your own kit, you have the skills or paying a very smart person with the skills.
Domestic spying is now "Benign Information Gathering"
... that is the question.
It little behooves the best of us to comment on the rest of us.
... use BASIC:
10 get foxnews.com
20 refresh
30 goto 10
It little behooves the best of us to comment on the rest of us.
Swift is a language well-suited to byte counting, if that is a need - at this point because of the tremendous pressure to increase security on iOT devices I really think Swift could have massive uptake.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Or another reason to learn Rust?
It seems to be the best positioned alternative systems language at the moment.
In an ideal world, developers of this newly emerging industry would try to avoid the mistakes of the past. They would gravitate towards one of the "safer" low-level languages such as Rust or Ada instead of C.
Of course, from the news headlines it seems that IoT developers are already intent on recreating every bad security practice that's been described since the Morris Worm. So I'm not holding my breath.
Rust does anything in any space C can, but more safely.
Light IoT will always need languages that are very power cautious, but I see that bringing a rise of CUDA IoT, or even FPGA skills.
Heavy IoT will always be flavor-of-the-month.
Science & open-source build trust from peer review. Learn systems you can trust.
C was invented as portable assembly IIRC. If you cant sort out a buffer overflow then dont call yourself a programmer.
Real programmers see their job as making the computers job easy, not the other way around.
Career network security programmer here.
Absolutely of you're programming a device that connects to the internet, you should understand a bit about security and have a security mindset. If your device won't get regular updates, this is even more true.
Where does C fit in? It's unnecessary, if you just want to learn basic security best practices.
If you want to really understand how exploits work, and some advanced protections, you need to understand how your program and your data are arranged in memory, what actually happens in the hardware to when your asynchronous timer goes off, etc. For that, C is the language to learn. Java programmers know how to use Java. C programmers know how Java works, internally. The bad guys writing exploits are (typically) C programmers, they can defeat your PHP or Python program because they know how PHP and Python work internally.
You've always used languages with automatic garbage collection, so you mostly don't have to worry about freeing memory after you use it? Great. You don't know how and when memory is freed, and what happens when a hacker exploits a "use after free" to execute code that he's put into the variable you think no longer exists.
To be clear, I'm not saying that people need to *use* C to write secure software. I'm saying that if you *learn* C, you'll learn a lot that applies to advanced security knowledge in any language. Higher level languages are most commonly written in C; if you know how things are done in C you'll understand what your high-level language is doing behind the scenes. You'll understand your Ruby software much better if you understand how the same program works in C.
Just C on your resume without C++ will pigeonhole you as a code monkey. Learn C++ and you will also know C, which is essentially just C++ with subtractions. These days, it would be rare to encounter an embedded tool chain that does not support both C and C++, usually with the same compiler.
When all you have is a hammer, every problem starts to look like a thumb.
Have we fallen so far that we need a reason such as "IoT" to learn C?
Sad day.
Yeah, I don't think any modern IoT device has any programmer "counting the bytes". I used to count bytes, back when I had 4KB of memory, or 8MB of memory, or 20MB of disk space. I think you'll be hard-pressed to find any IoT device with less than a gig of virtual memory. Considering zero or near-zero graphics output, I think you'll be just fine with any language ever inventing.
My vote goes to turing, which I haven't seen in twe decades, but for which I have a school-age nostalgia -- I made a street-fighter-style game for high school, with stick-figure graphics!
Computers (and machines in general) were created to make the life of humans easier. Imho, a real programmer also remembers that fact.
Avantgarde Hebrew science fiction
Yes, you should know C well enough to be able to read somebody else's code. At least. You may even switch to it for good, unexpectedly.
No, IoT-devices are a poor reason to start learning the language. By the time you are done, Moore's Law will make this devices powerful enough to run Ruby, Perl, and PHP, and you'll be able to go back to those...
In Soviet Washington the swamp drains you.
Real programmers? As compared to the untrue Scotsman?
Look around you and see what doubles as "programmer" today. Ask them how a stack overflow happens and why that is a problem. If I get a buck from you every time you get a blank stare and you get ten from me every time you get a sensible answer, your house belongs to me before the week is out.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
If your skin isn't brown, don't learn anything, because your chance of finding work is zero.
"If you cant sort out a buffer overflow then dont call yourself a programmer"
Several decades of severe network exploits show that a huge amount of software, commercial, free, open source, obscure, commonplace, whatever was written by people who can't call themselves programmers and used by those who don't have the 1st clue how to use it securely.
When I first got serious about computing, 2 decades gone, the common wisdom was that we had not choice but to keep on using the old (mostly very insecure) software because so much depended on it, it would be too costly to rewrite in more secure languages and in time it would all get fixed by better programming practices.
We are also only 2 weeks away from the 15th anniversary of Bill Gates' "Security is Job 1" e-mail
https://www.cnet.com/news/gate...
If we knew then what we knew now, how much damage would be caused by exploits, what it would cost to fix, remediate, the secrets exposed, the privacy intrusions, would that advice still hold or would we have been better off to say damn the torpedoes and rewrite all of it?
Pain is merely failure leaving the body
IoT stuff is probably the worst reason to learn C. Internet exposed services written in C without some knowledge of secure coding practices, is just asking for disaster. Even with large amounts of experience, C will still let you shoot yourself in the foot just fine.
Now if you want to learn C because you ENJOY working at such a low level, then please do. Learning C is much like BDSM, it's not for everyone. People will think you are weird, but the people in the know, well..they get it ;)
Most mods will probably flag this as trolling. But I believe JavaScript is a great language for IoT. There are a few advantages of using JavaScript, it's actually very easy to get networking to work well and reliably. A programmer will be able to write front-end, server-side/less back-end and IoT back-end all in one language. The code will be portable across all these bases (not always needed, but some functions will be universal). There are now a proliferation of embedded devices that support JavaScript "natively" (ESP32, RedBear Duo, and many more). It might not be as fast as C, but it's fast enough. Here is a project I created using JavaScript at every level: https://www.hackster.io/anemoi...
if you are a programmer. How can you be a programmer if you don't know C?
Because https://www.youtube.com/watch?...
Buffer overflows can be very useful constructs when you handle them very carefully and properly. They can be used as the GOTO for very limited microprocessor's code.
Custom electronics and digital signage for your business: www.evcircuits.com
C or C++, coded appropriately, can best fit technical concerns with business concerns.
--
Marc A. Lepage
Software Developer
It seems likely that most IoT devices will rely on a central hub which leaves the devices as relatively dumb. The hub (or the cloud) side will likely be a less constrained environment so will use a higher level language.
The other factor is that the thing side has a manufacturing component so will probably be commoditized by Chinese manufacturers and relatively few jobs will exist outside.
You do not RC. C was not intended to be portable, according to Dennis Ritchie. Interest in portability came many years later.
Real workmen wear safety goggles and use table saws which drop the blade when it detects flesh. Why should programming be different? You can work a lot faster if you don't have to worry about slicing your hand off. It's 2017, buffer overflows shouldn't exist. Programming language developers and/or compiler developers are really slacking off.
RISC-V is the new MIPS.
At this point there is no point to having any other general purpose computing instruction sets. Time for POWER, MIPS, SPARC, ARM, AARCH64, x86, x86-64, Tensilica (ESP8266), AVR, Blackfin, Lattice, etc to die.
If you need a stronger microprocessor for a task use one. The notion that using buffer overflow or stack smashing or jumping into data segments with 'dynamic' code is something you should ever do is simply ridiculous.
Yeah... to get a 60Hz 1970s microprocessor to do something useful in 512 bytes of RAM you had to be creative... and it was expensive to go upmarket for a better CPU. But in the 21st century if you are using a buffer overflow to write code on purpose, the time you spend building and documenting and maintianing that... you should have just spent another nickle and got a more capable processor with more ram.
I've written code that popped the default return location and pushed a value that took me anywhere in the program I cared to go. https://www.youtube.com/watch?...
Just about any language can have a compiler written for it that writes code that meets the low-memory requirements. It helps if the programmer is intimate with the details of what language elements map to which machine code.
I do embedded C programming. With this said, I don't think that improvements to the tools are impossible - sure, I have to prevent buffer overflows myself at the present time - but it doesn't have to be this way. The key thing about embedded programming is that hardware designers are lazy. They want to do the least amount of work possible. So instead of making their hardware easy to program, they like to make it in a way that is easiest to them. So every data sheet contains all kinds of special exceptions to the rules that you the programmer have to take into account. And instead of supporting some fancy, easy to program in language, they do the minimum amount of work to make a C compiler work. (it's really minimal - you only need to map a few base instructions to opcodes on the hardware and you can bootstrap the C compiler).
One major issue is while every microcontroller or DSP generally has roughly the same stuff - various ports that do the same thing, the MAC instruction, usually a von Neuman architecture, usually interrupts and DMA - you basically have to scrape the datasheet for weeks to do something you've done before on a different microcontroller.
No. If that's your concern, simply PUSH the target address and RETurn to it. At least if your processor doesn't simply let you MOVe raw data into the IP.
There is exactly no reason to ever smash the stack to redirect the program flow UNLESS of course you do not have control over the program code, i.e. when you have to do pretty much what those who use that kind of exploit do. But then we're leaving the area of development and enter the realm of ... let's say repurposing.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
knowing how to program in C and how C works under the hood makes you a better programmer. Even if you don't program in C. That is reason enough.
Non sequitur: Your facts are uncoordinated.
Like it or not, C is still the defacto standard for embedded programming. If you're working in any where near bare metal your going to be using it. That may change but for now, if you dev for Internet of things and you don't know it, you're basically a script kiddie. Source: I'm an electrical engineer.
Am I the only one who has never heard of IoT?? Is that really a real thing? I gotta spend more time on the twitter or something to learn the cool stuff.
There's nothing BASIC can't do.. while that is generally true for programming languages in general, BASIC has a long tradition of bringing in house what for other languages are external libraries and turning them into commands that are intrinsics in the language. Take a look at all the modern flavors of BASIC and their built-in commands. If you can code it into a compiler it can be BASIC, baby!
Well, most systems use third party C compilers, gcc or keil or whatever. C is low level enough that the CPU doesn't have to know it's C anyway, it could be Fortran, Pascal, Ada, or whatever as long as it has a basic stack model. They're not supporting any language. Von Neuman isn't even required, there are many embedded systems that are Harvard architecture (separate regions for code and data) which C supports just fine.
Most buffer overflows weren't necessarily because of being sloppy in the original code, but because the code was copied so readily. Someone has a simple routine without all the necessary checks because it's not being used for anything very important, software that doesn't need to be secure, it's a one-off utility (maybe it converts postscript to PCL). Then someone copies that routine into another program, makes that a set-uid program, and poof you've got a security hole. First programmer says "it was not intended to be re-used", second programmer says "re-inventing the wheel is foolish!", and they blame each other.
Reducing compute times/memory usage by 0.1% in big data centers reduces the cost of electricity and cooling by millions.
Reducing compute times/memory usage in battery powered devices increases battery lifetime.
I view C++ as a better choice then C though, who can code a linked list from scratch more efficient then what they do? You get more abstraction power.
Computers (and machines in general) were created to make the life of humans easier. Imho, a real programmer also remembers that fact.
There are no technical reason a programmer cant create code that is good for humans (usable), and for machines (efficient).
The problem is when a programmer decides, or is forced to compromise on quality. That is the lesser programmer.
Because the current crop of IoT programmers clearly don't know a thing about it, or just don't care, which is why IoTs are the largest DDoS attack army in history.
What's being discussed here are platforms that need features SWIFT simply doesn't have, like inline assembler to manipulate hardware specific features
That's not so; the assembly language of Swift is bitcode - which you can embed in Swift code for customized performance.
manual allocation schemes for shared memory (EG reserved blocks that are processed by hardware interrupts)
Although the link is not exactly that case you can use UnsafeMutablePointers for that purpose. Swift is not a garbage collected language, it uses ARC which is already deterministic as to when memory is allocated and released - but you can disable that for code and manually manage memory used.
To use SWIFT you'd need to develop entirely different custom libraries for each platform
Ask Apple how they support various ARM architectures...
No not everything is quite there, but Swift is moving rapidly and the underpinnings were built with the explicit goal that Swift COULD replace C as a language for any purpose, not just another higher level language that really can't apply for low level development. At this point the language is basically locked in but more features will be added over time, including stronger device programming support. That's why taking the time to learn it now means that by the time you understood it well you could probably start doing some hardware development with it... pretty sure LLVM at least and possibly Swift will be involved in some way at Tesla for example. When you are writing code that MUST be stable, like code that controls a car, C is just not going to cut it long term.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
But when it comes to IoT applications there is that need once again.
Yeah, for five or ten minutes, then it'll be like, "Oh, hey, the new Samsung Toast-X is out! Peak bread-toasting power 750 watts, comes standard with Bluetooth and WiFi, the basic entry-level toaster can do 6 slices at a time, AND it has 4GB or RAM, so it'll run Windows 10, (2018 IOT Edition)!
I just bought a wristwatch that runs apps, and basically a full-blown OS in miniature... I'm pretty sure that capability will be BAKED into ovens and the like before long at all, pun TOTALLY intended.
A real programmed wont use a sawed off shotgun to hammer in a nail, unless there is no reasonable alternative. The issue with C is not that you have to sort out buffer overflows, nearly every language has that - most modern high overhead languages just throw an exception. The issue with C is that you get a buffer overflow by default nearly every time you copy a string or resize an array ( a real C programmer uses doubly linked lists of course ) and that is both anoying to deal with and horribly brittle.
Sure. And if somebody has bothered to do the porting work and write a third party tool that uses a different compiler - and your project has the budget for such a tool - it's better. But it still isn't easy. You still end up reinventing many things.
Swift itself is also open source.
It also can be used as a full replacement for C in a way Rust cannot; see my response to someone saying Swift can't be used for device programming for examples. Rust is a nice language but it's just not as architected as Swift is for use across the space of devices like C is already.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Worth mentioning that a half-way decent string and buffer library will solve basically all buffer overflow issues. If you're using strcpy(), gets(), or even strncpy() (without knowing the pitfalls), then you're in trouble.
"First they came for the slanderers and i said nothing."
Security is about mitigating risk and security requires defense in depth. The language of the embedded device should NOT be C. C is a bottom less pit of memory corruption issues: see ANY operating system.
The programming language of any device should be a type-safe memory-safe interpreted language: .net, java, scheme, you name it. There was a .net research operating system from microsoft that looked interesting. Maybe a core version of that open sourced would make a great foundation for not screwing shit up through buffer overflows or any other memory/type corruption issues.
There is a stereotype and anachronistic idea that embedded devices lack CPU power. CPU power is bought in spades for trivial pennies to dollars.
That will leave all the other hundreds of logical security issues to address.
Standardized components for those would be great.
When someone is solid in C, it's a great indicator that they care about their craft. The curious and passionate will inevitably dive into it. I find that it becomes a great litmus test for hiring.
I'll dare say this potentially unpopular statement: If you have no interest in C, then you're in this for money and not love. How can you not love the foundation that your entire career is based upon??
lot is a reason not to own a lot device...wtf does a heater need to be hooked up to the web for?? Or some other dire device, the whole concept of lot is stupid beyond belief....
C is programming lingua franca. Anybody calling himself a programmer and not knowing C is not a programmer.
Before the mainstream software programming turned to be web programming, C was taught in every computer science university programme.
Not knowing C limits your competence to a small pond called web programming.
Ada is actively developed and has way more features than C++ without resorting to the OOP overhead, but its not hip, and crammed down our throats like Java et. all swift and go so who cares.... people want easy and like the "feel good" of making a C app or two
If you are working faster because your table saw is a SawStop or is a Bosch with the "Active Response" response feature, you are NOT a good workman. You are being careless and relying on what is meant as a backup safety device to save your fingers/hands. If you ever trigger one of these devices with your flesh (vs., for example, a hot dog, wet wood, or radiant barrier sheathing), at a minimum you should be horribly embarrassed at how careless you were and hopefully it causes you to seek retraining.
Correct me if I'm wrong, but I think the bad name IoT got in security is mostly due to routers and camera's on the market shipped with old linux installs and backdoors and default passwords set.
If we're talking C, it's probably about programming microcontrollers. There are no root exploits on microcontrollers. A stack overflow will probably get you a crashed device and in the very best case access to functions you shouldn't have.
... Embedded is a reason to learn C though. And embedded and IoT do have some intersection/overlap. But I IoT itself is mostly a fad involving the slapping together of unsafe preconfection microlinuxes with unsafe overkill websevers/port 80 stuff and adding that to toasters and stuff that really don't need it and won't be used more than ~3 times unless by some bored teenagers wgo wants to screw up your homes heating or AC by surfing on shodan for some lonb forgotten default access to said IoT trinkets.
Bottom line:
You shouldn't do anything because of IoT unless it,s avoiding it like the plague (unless you're a hacker that is). OTOH If you want to learn embedded, C with assembler for the basics is the way to go.
Good luck.
We suffer more in our imagination than in reality. - Seneca
Hell, ask them what the stack is first, most won't have a clue. I used to ask developers (for C# positions) what the difference between a value and a reference type was. Still have not got a correct answer, eventually stopped asking the question. The problem is only going to get worse as they force more and more people to "learn to code" when they actually don't have the inclination. Cut and paste coders, the lot of them.
There are three kinds of falsehood: the first is a 'fib,' the second is a downright lie, and the third is statistics.
Actually the ISO C library have plenty of tools to prevent buffer overflows, but there is a performance tradeoff.
Since you have buffer overflows you likely have a buffer with a fixed size.
The idea is to never handle pointers to the end of the data in the buffer or even keep track of how much data is in it.
If you want to append data at the end you use strncat with you buffer address and a sizeof(buffer).
Yes, the processor will have to scan through the buffer every time you use so you don't get the performance you might want, but the source will be very clean and you will not have to worry about buffer overflows.
Many of the string functions also returns the start of the buffer so that you can chain multiple operations together in a oneliner if that is your thing.
Unless you're going to sell tens of millions of cheap devices, or more, it's not going to be financially worth it to hire some good programmers to make a nice, tight piece of C code, that will squeeze onto a puny microcontroller. It's probably going to be some mediocre device, interfacing via a web browser, with logic in... JavaScript. So, just make the mediocre device, also in JavaScript. There are a lot of moderately priced JavaScript programmers out there, and it is a more productive language than C, and spend more money on the hardware. I guess if the IoT device is not some cheap pos device, you could put on a full blown Linux or BSD distro. Use the Theo Deraadt!
One of the microcontrollers I use run at 20MHz and has 256 bytes of RAM and it is less than 10 years old.
Also, for embedded stuff you can't dump the extra memory cost on the end user. It will cut into your profit.
That nickle adds up pretty quickly in the quantities that embedded stuff is produced in.
Two of the reasons for learning C are:
1. It is a good, general programming language that can allow you to produce efficient code.
2. You want to be a good programmer with a good understanding og the HW and the OS
I'm not convinced the growth in IoT thingies is other than an ephemeral fad. There will be a period with a lot of innovation, then it will settle down on the relatively minor subset of gadgets that are actually useful and wanted, and there will no longer be a lot of need for programming skills in that area. But the C language has already demonstrated its staying power (as have certain other languages like FORTRAN and COBOL to the surprise of many), and it will be relevant to know for years to come, no doubt.
K&R C could be considered portable assembly at one time (but a bloated one). Those days are long gone. Abstraction is for humans; abstraction is bloat for microprocessors.
There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon
Indeed indeed.
Or you can just use enough pokes until it does what you want.
While most of my work is for chips that are vastly more powerful than what is found in IoT devices I work on bootloaders and bare-metal programming. In some cases memory is a premium. With only a couple of exceptions, all of the work I have done has always been with C. Most small micros are programmed in C almost exclusively with a sprinkling of assembly.
C is very good for working closely with the hardware and in memory constrained environments. C code does exactly what it says. There is no hidden overhead. The runtime needed to run C code is pretty minimal. All it really needs to get going is often a few registers initialized and a stack and it's ready to go.
It works beautifully with memory mapped registers and data structures which are extremely common in this environment. There's even a keyword designed for this, volatile, that is not present in most other languages (or it does not do the same thing).
I can use a bitfield to define hardware registers and just map a pointer to the address of that register and use it. Mixing in assembly code is easy if it's needed, though generally I find that assembly code isn't needed very often.
It's also easy to generate a binary blob using C, a linker script and a tool like objcopy.
My experience has mostly been with 64-bit MIPS and some ARMV8 but it applies to most embedded processors. The output of the C compiler when optimizing for size (with the right options set) is pretty close to hand optimized assembly and often even better because the compiler does things that would make the code otherwise hard to read or maintain. The runtime overhead of C is minimal.
C's flexibility with pointers is also a huge plus. I can easily convert between a pointer and an unsigned long (or unsigned long long) and back as needed, or typecast to a different data type and pointer arithmetic is trivial. There is no hidden bounds checking or pointer checking to worry about. Many people say that's a bad thing, but when you're working close to the metal it can really turn into a major pain in the you know what. Master pointers and know how and when to typecast them. I've seen too many times where people screw up pointer arithmetic. I once spent several weeks tracking down a bug that showed up in one of my large data structures where I saw corruption. It turned out that some totally unrelated code written by somebody else in a totally different module was written by someone who didn't understand pointer arithmetic and was spewing data all over the place other than where it should be. He also didn't realize that when you get data from a TCP stream you don't always get the amount of data you ask for, it could be less.
I have been writing low-level device drivers and bootloaders for over 20 years and while programming has changed significantly for more powerful systems in userspace, for low level programming it has changed very little. My advice is to learn C and learn it well. Know what some of those keywords mean like static and volatile. Anyone who interviews in my group damned well better know what volatile means and how to use it.
C isn't a very complicated language but it takes time to properly master. It also doesn't hold your hand like many modern languages, which is why you often hear it is easy to have things like buffer overflows or stack overflows and it's also easy to shoot yourself in the foot. It doesn't have many of the modern conveniences, but those conveniences often come at a cost in terms of memory and performance.
The best book I've seen on the language was written by the authors of the language. It's not very long but it is concise and well written.
The C Programming Language by Brian W. Kernighan and Dennis M. Richie.
I have also worked on C++ device drivers. While the overhead of C++ itself is generally minimal, it depends that you use only a subset of C++ and you have to know what C++ is doing behind the sce
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
There is a practical reason, programmer efficency. If that programmer compromises, he can do more work.
Avantgarde Hebrew science fiction
The nice thing about C is that is as close to portable assembler as a language can get. It forces you to understand how computers and OSs work in order to become proficient, and in time your code will become better because of it - even when using other languages.
Of course, the ugly thing about C is that is as close to portable assembler as a language can get.
So what is "the stack"? A core concept of C? Something the standard mentions in passing?
CLI paste? paste.pr0.tips!
You should only use C if your program has at least one of the following properties:
- It has extreme CPU efficiency demands; for example, it needs to use SIMD wherever possible and do so efficiently;
- It has strong realtime demands. E.g. you're rendering video or audio live with very low latency or are reading sensors and controlling something mechanical and therefore cannot have a garbage collector stopping the world even for a millisecond;
- It has extreme cross-platform requirements; you want to be able compile on many architectures.
Each of these can be a reason to pick C. However, IoT in general is not. Whenever you can, please pick a language with proper memory management. And if you must absolutely use C, consider writing only the parts of your application that absolutely need it in C.
When it came to selecting a programming language for writing a software synthesizer/sequencer, after extensive testing, there really wasn't any serious competition to C/C++/gcc w.r.t. auto-vectorization support and realtime characteristics. So I chose C++. And it is a world of pain. However, it is insanely mind-boggingly fast and even under heavy load will respond with sub-millisecond response times.
So FFS please don't pick C(++) unless you absolutely must.
0x or or snor perron?!
Using strncat() has so many corner cases, I would recommend never using it. Too easy to make a mistake.
"First they came for the slanderers and i said nothing."
This SO answer is a pretty good attempt at explaining it:
https://stackoverflow.com/ques...
And you will see why C/C++ is important for IoT. What's the purpose of IoT? To make hardware available in the cloud. What are the pieces of the "stack"? You have some sort of SoC, an OS, your hardware(fridge, slow cooker, camera, scanner, etc), likely a web server and your app that runs on the web server. On the software components you have two main pieces: talking to the hardware and the app that runs on the web server. Those are two very distinctly different pieces of software and are best suited to be developed via certain languages. Would you use PHP or JS to talk to hardware? Heavens no, you use C, C++ to do that work. Conversely, would you write your web app in C? Heavens no. PHP, JS or another scripting language would do that job. And those two apps need to talk to each other so you also need to understand how both sides work.
Same old axiom: use the right tool for the job; screwdriver to drive a screw, hammer to pound in the nail. Speaks to why we all have to have a wide range of skills and cannot squat on a single language or technology.
"Security best practices" would be to shitcan the entire idea of the internet of things as stupid and stop listening to marketing drones whose only motivation is to sell you some thing from which they can forever after farm data-demographic income.
-Styopa
If that programmer compromises, he can do more work.
In that case it doesnt matter what language the programmer uses, no language is idiot proof.
It was actually a rhetorical question. Standard C does neither specify nor require a stack or a heap, and memory allocation isn't specified in terms of those.
I'm only pointing it out because of the GP implying that knowing about "the stack" implies competence at C, which is far from true.
Or to put it differently:
$ grep -iEc 'stack|heap' c11std.txt
0
$
CLI paste? paste.pr0.tips!
Yes, you should learn C. If you don't know C, you are NOT a programmer. You are a hipster wannabe.
I think we define compromise differently. If someone decides to give up on the quality of something, willingly, not because he can't, but because he has better things to do for the project, why is he an idiot?
Avantgarde Hebrew science fiction
Yeah sure. Blame the programmer for being forced to compromise by bad management or hardware practices.
If you have no clue about how the computer works, have no idea how large local variables and large global variables differ even if you have only a main() function (for which you NEED to know about stack vs. heap, even though you wouldn't need to know it by those names) I claim you pretty much CANNOT be competent at practical use of C.
Most people don't care if you could write C programs that would work great on a Turing machine, you absolutely need to know how to write a program that will work well on the actual machine IN FRONT OF YOU, and you can't do that without knowing about stacks, heaps etc.
The Java serialization issue shows pretty much that those "more secure" languages don't help a bit if there is a cargo-cult mentality of insecure programming.
In fact, Java made it even easier: Instead of fiddling around with stacks, things that might crash if the program was compiled with a different compiler etc, you nowadays just politely ASK the program to execute whatever code you want, and it just goes ahead and does it.
You don't even need to have a clue about the CPU, OS, compiler etc.
There is no point in choosing a language that makes sure all the cracks are nicely filled if your programmers are going to leave the front door wide open anyway. Or worse, your shiny new programming language by default leaves the frontdoor wide open via core language features and expects every programmer to know the obscure magic needed to close them - whether it's Java's deserialization, Windows' SetDllDirectory/SafeDllSearchMode etc.
If you cant sort out a buffer overflow then dont call yourself a programmer.
If you can't see that std::string is a better choice then don't call yourself a programmer.
No sig today...
A value is the contents of a memory address. A reference type, in C#, is a type that is derived from System.Object and is allowed to be null.
Or were you asking the difference between a value type and a reference type? Syntax errors suck, even in English.
BTW, it's worth noting that .Net's value types are still derived from System.Object, but aren't allowed to be null. Every variable in .Net is what C would define as a void**. A handle to an unknown. Yes, that includes both value types and reference types. They're a stack-allocated pointer to a heap-allocated pointer to a heap allocation. Every. Single. Time. Even System.IntPtr. In the reference implementation (Microsoft's .Net, as opposed to Mono or some other implementation of the spec), the only thing preventing value types from holding a null reference is some validation (C programmers just think "overhead") in the CLR.
Or you have a different opinion than you have.
I wrote a program a couple weeks ago that flashes a red light that alerts of a new Twitter post. Uses a RPi 3 and the program was written in Java.
Java has the ability to run threaded tasks easily which I wanted for polling the Twitter website. I could of used cron I suppose.
I assume C has something similar but I know Java and Raspbian has Java.
Sig. Sig. Sputnik
C was invented as portable assembly IIRC. If you cant sort out a buffer overflow then dont call yourself a programmer.
Real programmers see their job as making the computers job easy, not the other way around.
And one way a real programmer makes the computers job easy is making sure there code is as easy to work with for those who make updates after they are gone.
to really use it safely and properly you simply have to understand how computers work at the lowest levels.
I've done a lot of assembly myself (in the past, not so much these days!). That has been really helpful over the years as I can understand performance issues a lot better than someone who does not have that background...
I think though the computer industry has shown that even when someone truly understands the lowest levels of how computers work, they can easily write code that is not safe. I don't think there's any way past that other than an inherently safer language that still lets you access very low level parts of the system... Swift (and LLVM) is the first language/system I have seen that I think can take over for C.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
> Standard C does neither specify nor require a stack or a heap
This is why I laugh when people call C a 'portable assembler.'
Assemblers are dependent on machine architecture. C isn't even dependent on a Von Neumann architecture.
C is awesome - that is reason enough to learn it
Please just stay a script kiddie. Stay ignorant of how the system works. Just relax and believe the folks who tell you that you can do anything you need with Java, Rust, Go, and Swift. Learning the metal is for old guys and non-social weenies who don't even have Facebook, Twitter, and Instagram accounts. You don't need to know that stuff, honest. Slasdhot is right. Nobody hires C coders, uhh, yeah, it's dead and stuff like that.
Those people who tell you that C is the most portable language in the world are just old greybeards. Ignore them. C is just old and krufty and C coders are just butthurt that they don't know Python & PHP. Yeah, that's the ticket.
You can totally just learn "security" and not learn how things work. Just listen to the folks who got their CISSP recently, they can tell you. It's all about certs and the public perception of what languages you code in. Once you learn how to run a few metasploit hacks, you're set to get an elite job at a pen-test firm were the other cool kids hang out.
Let my life be a cautionary tale. I spent all that time learning C and a few dialects of ASM, alas, just to be surpassed by script kiddies. I'm now broke, friendless, bitchmade, and homeless. It's terrible. All because I learned C instead of the cool languages.
Been writing security focused C code for over 10 years. We do code reviews and use tools to find problems in the code. I hardly ever see a buffer overflow. You really are either a poor programmer or a really poor company if you let buffer overflows into your code in this day and age.
Having said that, there are several other problems with using C, but the other option is C++ and C++ has overlap with some of the issues C has and has some of its own problems as well.
Having said that, sometimes I really wish C had length checking on arrays built in, even though I understand why it doesn't...
C is the reason to learn C. If you don't understand this, you need to go back and get better at C.
You've got it backwards. Yes, I do know x86 and the pertinent C implementations rather well. But no, since C abstracts those concepts away, there is a) no need to and b) it actually makes things less portable if you have implicit assumptions about what the machine has and does WHEN C ALLOWS YOU TO NOT CARE ABOUT IT.
So please tell me, given the code
int a, *b = malloc(sizeof *b);
What exactly is the advantage of thinking about `a` and `b` as "on the stack" and `*b` "on the heap"? I truly don't get it.
What is the problem with thinking about `a` and `b` as having automatic storage duration+block scope, and `*b` having allocated storage duration? It's THOSE TERMS that have well-defined semantics that EVERY C implementation (including those that put things "on the stack"/"on the heap") *has* to comply with. (That is apart from the fact that something you think is "on the stack" might well be NOT on the stack because it's "in a register", or got opimized out entirely, rendering your stack/heap categorization as a heuristic at best).
Learn some C. Make your programs more portable. You'll end up a better C programmer.
CLI paste? paste.pr0.tips!
I program on ST micro's Cube, Silicon Lab's Simplicity Studio, NXP's Kinesis and ARM's mbed-os.
The first three are C, the last is C++.
It is all very very simple C syntax (compared to advanced techniques used in the GNU source).
The language is not the barrier. The insane complexity of the stacks is the barrier. I've been programming in C since 1986, but understanding how to code the subtle issues of the BLE implementations for all four stacks took fucking FOREVER.
If the programmer is willing to compromise on usability and quality because there are better things to do, then how do you maintain quality control ?
Its just a matter of time until that 'better thing' he has to do is add another feature rather the bug check existing features.
Right now I am playing a game called OpenRA. The game crashes for me sometimes when on the main menu and never crashes during gameplay. The game also suffers from a gameplay imbalance. Currently more effort is invested in adding these new balance feautres than in main menu ui stability. The balance is, imho, the "better thing". If the bug was fixed then we'd have a slightly more stable program on account of a crucial feature.
Ideally both things (ui bug + balance) should be fixed. Practically, time is limited.
Avantgarde Hebrew science fiction
C is arguably the most important programming language in history. If you don't already have some working knowledge of C you're not a serious programmer to begin with and will reap little benefit from some IoT boom.
For the users, not the programmers.
I own a company that does hardware and firmware, mostly for projects in the IoT space. We've had clients hire us to connect all sorts of dumb stuff to the internet. Many times you're using a chip that has a framework or stack that already exists; be it BLE, or Wi-Fi, or even Sub-1GHz (my personal favorite, it's the Denny's of wireless protocols). These frameworks are usually written in C. So while it's possible to incorporate them into a C++ project, usually it's just not worth the time or risk; it's easier just to leave it in C. The key to writing in C is to make it as human readable as possible. Code is written once, but read many times. So don't just use shitty variable names like "count"; use something that makes sense like associatedDevicesCount. That being said, for tight loops, i is just fine. It's also interesting how little customers care about security, even when our team brings it up. We're always trying to strike a balance. More security generally means more time during manufacturing (loading keys, etc.) or making the product harder to use. With manufacturing time going for (in US) about $1 per minute, we want to keep things moving. And clients hate dealing with customer support calls because the user can't get his miniblind controller to talk to his iPhone. C is also very popular for lonely devices - things that have to sit out there and just transmit information periodically, and are difficult to reset if the firmware goes haywire. I'd bet that 99% of iBeacons are implemented in C. Certainly the ones we've made are in C. All that being said, I'd like to try C++ on a new project; if nothing else for fun.
DSPs are usually Harvard architecture, not von Neumann.
It's really easy to right things quickly in scripting languages but the bloat there is phenomenal. I needed a little minimal command line script to call a glibc function and output the result. It's easier in a scripting language unless it doesn't give access to the underlying calls needed.
Anyway this is only one example case but point is that if I do it the easiest way in each, C gives me a few KB program that runs quickly, takes only a few KB of memory where as achieving the same in a scripting language means reading MBs of libs, engine from the HDD,. big engine bootstrap, loading into memory, etc and basically makes a big nasty memory spike to get something really simple.
Modern embedded hardware is still often beefy enough to now run a lot of stuff on interpreted but despite that there's still a benefit to using an amount of C and will be for a long time.
> I have to prevent buffer overflows myself at the present time
You should have to even in a high level language. When you get an out of range exception because the language caught it for you, that's not a mechanism you're meant to rely on, instead it's a safety net. There might also be some higher level conveniences for such checks which isn't quite the same as a safety net.
If you're a seasoned programmer you should find yourself saying instead that C doesn't have your back as much as it could because ultimately no one is flawless, even seasoned developers and it's better the compiler reminds them of this if they can rather than a hacker. Word of warning as we can get back into the dependency trap with that. Ultimately when programming, you have to program which means staying alert as to what you're doing.
This why when I write with Python I call it a script. I'm a scripter, not a programmer. Not sure about the use of "coder" though?
Python can be used as a scripting language (i.e. a language that targets other programs), but it is a full-fledged "real" programming language.
I don't know where people get the idea that any interpreted language must be a scripting language?
> how a stack overflow happens
Ooh! Ooh! I know this one! How it happens is, first you log in, then you create a question and paste in the code from your assignment. (Be sure to paste in only a little snippet, leaving out silly things like import statements and function signatures, and change variable names to things like "a" for anonymity). Then you wait a while until some grumpy old-timer posts a link to an identical three-year-old Stack Overflow question. Then you click on that link, copy the code from the highest-rated answer, and paste it back into your assignment. When it compiles, you're all set! Simple!