Linked by Thom Holwerda on Wed 22nd Feb 2012 15:24 UTC, submitted by Ajeet
Multimedia, AV On my mark... Get set... Start not caring! Adobe has announced it plans to discontinue the stand-alone Flash Player for Linux, instead focussing all its effort on the version available through the Pepper API - which, besides Chrome, no one else is going to support.
Thread beginning with comment 508239
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: No surprise
by rafaelnp on Thu 23rd Feb 2012 13:48 UTC in reply to "RE: No surprise"
rafaelnp
Member since:
2009-06-03

No stardard is perfect, e.g. posix has some open dark corners. With C, if you use a C99 compliant compiler you rarely have a problem. Of course if you develop for windows and want to port to Linux, *BSDs (or vice-versa), you have a nightmare ahead.

As far as i know microsoft's C compiler doe not support C99.I say again, open standards is the best option. Look at IPv4, HTML, JTAG, Ethernet and so on. Imagine the world we leave today wihtouy these standards...

Reply Parent Score: 2

RE[3]: No surprise
by evangs on Thu 23rd Feb 2012 15:23 in reply to "RE[2]: No surprise"
evangs Member since:
2005-07-07

With C, if you use a C99 compliant compiler you rarely have a problem.
*snip*
As far as i know microsoft's C compiler doe not support C99.
*snip*


None of the commonly used compilers are C99 compliant. See http://en.wikipedia.org/wiki/C99. GCC which is widely used has only implemented 43 features, 6 are missing, 1 is broken and 12 suffer from "library issues". 12 years after the C99 standard is ratified, the fact that the majority of compilers do not support the standard shows how irrelevant that standard is to the real world. In fact, given the broken support of C99 among the popular compilers (i.e. GCC, Visual C++, Intel C++, Clang) you'd have to be stupid to use C99 features if portability is your goal.

Having said that, the biggest hurdles to portability have little to do with language standard compliance unless that code is written by some diva developer who wants to show how uber-1337 they are. Having ported code to across operating systems and architectures, the biggest issues to be aware off were bitness and endianess issues, and subtle difference in API routines. One that bit me before is how the POSIX function fsync() has different semantics on different supposedly "POSIX compliant" platforms. http://rhaas.blogspot.com/2010/10/wal-reliability.html

Standards are only valuable if they're adhered to.

Reply Parent Score: 4

RE[4]: No surprise
by moondevil on Thu 23rd Feb 2012 15:50 in reply to "RE[3]: No surprise"
moondevil Member since:
2005-07-08

There are many language features like how overflow behaves, numeric type size, and a few other things that are not specified in the C standard. It is quite funny to see how even "expert" C developers fall in those traps.

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

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

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

Reply Parent Score: 2

RE[4]: No surprise
by Neolander on Thu 23rd Feb 2012 18:18 in reply to "RE[3]: No surprise"
Neolander Member since:
2010-03-08

And yet that standard DOES bring a bunch of useful stuff, such as Unicode support and standard integer types that do not suck.

I really don't understand how people managed to write low-level code that is relatively compiler-agnostic before stdint.h.

Reply Parent Score: 1