6 ms·
I would say use C. Interfacing C with Java is simple JNI. Interfacing C with Swift is very simple, too.
by ww520 7y ago
I would say use C. Interfacing C with Java is simple JNI. Interfacing C with Swift is very simple, too.
- saagarjha 7y agoI'd push for Rust/C++ with C linkage.
- hsaliak 7y agoToolchain integration matters. Just use c++.
- pjmlp 7y agoC is also very simple to add security exploits to your app. I would never advise C unless the platform is lacking of a C++ compiler. Just use extern "C" at the boundaries.
- rijoja 7y agoA super thin layer made of C between say Objective-C or Swift and C++ is quite convenient though and doesn't add much of an security risk. See it as the lowest common denominator.
- TheSoftwareGuy 7y agoThat’s what the extern “C” does
- scarface74 7y agoWhat’s the threat of a security vulnerability in a 3rd party mobile app that tightly sandboxes your app - especially for a none financial app? I would think that if even a vulnerable app could affect other running processes or the OS itself, you’ve found a vulnerability in the underlying OS.
- tedunangst 7y agoPresumably the user of the app cares about their own data...
- scarface74 7y agoAnd only their data in the app in question or any data that the user allowed the app to have would be vulnerable. If not, that’s an issue with the sandbox on the mobile OS.
- FpUser 7y agoIf users care about their own data the best thing they could do is to stop using smart phones and signing up to google, facebook, saas providers etc. etc. They would leak your data with the efficiency any pirate will be jealous of.
- pjmlp 7y agoThe threat depends on what the app is used for. If nothing else it can be used for piracy. Software Engineering should strive for quality and best practices.
- scarface74 7y agoHow do you propose that an security vulnerability in an iOS app that doesn’t result in a jailbreak will allow someone to copy the app from an iOS device on to another device? Also, are you claiming that using C == “not striving for quality” or that it is not “best practice” to use C? And on a side note, most corporations don’t care about “quality” or “best practice”, they care about shipping and selling software. Two decades in the industry has shown that those two things aren’t as highly correlated as you wish.
- pjmlp 7y agoIndustry is young, but thankfully returning goods on app stores and suing companies for delivering bad software is starting to happen. I am claiming both when using a language whose security reports from Google, Apple, Microsoft, ARM, Linux kernel just increase in size every year with the amount of memory corruption and UB induced security exploits. Like those reports advise, usage of C should be constrained to environments where no other safer alternative is made available, or due to constraints on already deployed software.
- rkachowski 7y agoWhat vulnerabilities does C introduce that C++ doesn't?
- millstone 7y agoFor example it is easier to avoid buffer overflows with std::string than with C-style strings.
- scarface74 7y agoIt’s also easier to avoid buffer overflows in C by using the “n” variants of C string library functions.
- xmprt 7y agoWhy subject yourself to that risk when you can just use C++ and make everyone's lives easier? Is there a benefit to using C?
- scarface74 7y agoWhat “risk” is there in an overflow from using strncmp, strncpy, etc? C++ still isn’t as easy to interop with other languages as C and the low level APIs built into operating systems are not going to use C++/STL and you still end up converting to standard C strings and arrays.
- naniwaduni 7y agostrncpy notoriously doesn't necessarily 0-terminate. (It also always pads the full length with zeroes if necessary, so it's almost never what you actually want to do.) The C standard library is full of these footguns. I won't say C++ doesn't have its bad parts, and I certainly wouldn't say that it's impossible to avoid the bad parts of C (some would), but you probably aren't going to manage.
- 7y ago
- izacus 7y agoC is pretty rudimentary for more complex logic - not having nice containers, things like std::thread or smart pointers can mean a lot of pain when trying to write code portable across platforms. I don't think it's worth staying there - especially since C++ is a first party supported language on pretty much all platforms.