Author Topic: Commercial product source code  (Read 33704 times)

0 Members and 1 Guest are viewing this topic.

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: Commercial product source code
« Reply #50 on: April 16, 2014, 09:50:59 am »
Quote
compilers shouldn't care about libraries that are not part of the actual programming language
I'll have to admit a certain sinking feeling when compilers started checking argument types for printf() (and we had our own printf, where %e output an ethernet address, and etc.)  I always figured that C owed a fair portion of its success to the fact that the libraries were NOT part of the language definition, especially when you look at how much of prior languages effort DID go into defining various IO primitives (and not-so-primitives.)  That gave C an agility and portability that the bigger languages just didn't have.

But I think it's a lost battle :-(  And I won't be implementing an "zippy" functions that have the same names as nearly-identical standard C functions.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Commercial product source code
« Reply #51 on: April 16, 2014, 09:58:13 am »
Quote
compilers are crap on what they do

You would have come cross as a credible participant if you don't make crazy arguments, like the one above.

If that's really what you think, it would be difficult for anyone, including yourself, to have a rationale conversation with you.
================================
https://dannyelectronics.wordpress.com/
 

Offline grumpydoc

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: Commercial product source code
« Reply #52 on: April 16, 2014, 10:02:21 am »
Quote
No, what I said is that compilers shouldn't care about libraries that are not part of the actual programming language as per the thread you are talking about. I can make my own strcpy and I don't want the compiler to police me. So big NO to kcc.

Also what I said also is that if I know the instruction set of the targeted processor, and it can do overlapping memory copies with expected behavior and I would take advantage of that on small MCU.

Also what I said is that I rather program in Assembly because C does a poor job on MCU's.

While I don't disagree with writing your own routine where which behaves in a particular way which the standard library routine doesn't guarantee please don't call it strcpy - call it my_strcpy or lthmntbmov (low to high memory nul terminated block move) or anything except strcpy.

Calling it strcpy just asks for some bright spark in the future to not understand why you've got a custom strcpy and remove it - giving a 50% chance things will go pear shaped.

It's especially embarassing when you're the bright spark that does the removal. Been there, seen it happen :)
 

Offline Rufus

  • Super Contributor
  • ***
  • Posts: 2095
Re: Commercial product source code
« Reply #53 on: April 16, 2014, 12:59:48 pm »
Cpu's these days are fast enough that this will be unnoticable.

Open SSL runs on tens of millions of computers processing probably trillions of requests per second. Using a language which automatically checks for things which can't possibly happen in 95% of cases for such software will require extra power stations to be built which is noticeable.

The problem was not a stupid memcpy error it was failure to validate information in a request before processing it. 
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5550
  • Country: us
Re: Commercial product source code
« Reply #54 on: April 16, 2014, 04:13:54 pm »
Quote
compilers are crap on what they do

You would have come cross as a credible participant if you don't make crazy arguments, like the one above.

If that's really what you think, it would be difficult for anyone, including yourself, to have a rationale conversation with you.

I stand corrected, let me say it a different way, gcc produces crap code:


Quote
Looking at the results for the two compilers we see that GCC has not learned anything over the last five years (this is for how long we have been comparing compilers in terms of OpenMP barrier overhead): The barrier takes roughly a factor of 20 longer with gcc than with the Intel compiler.

http://blogs.fau.de/hager/archives/6883

Don't get me wrong, there are good compilers out there but they are still increasing efficiency by 10% each year, and that tells me they have not plateau yet.

Now throw in 8 cores dual processors, you tell me what compiler uses it all?
None, you might get lucky and scrape 5% of what the CPU can do.

"The way the processor industry is going, is to add more and more cores, but nobody knows how to program those things. I mean, two, yeah; four, not really; eight, forget it." Steve Jobs, Apple.

Then again, he is not a programmer and didn't know anything about computers.
 

Offline tjaeger

  • Regular Contributor
  • *
  • Posts: 101
Re: Commercial product source code
« Reply #55 on: April 17, 2014, 08:13:29 am »
No, what I said is that compilers shouldn't care about libraries that are not part of the actual programming language as per the thread you are talking about. I can make my own strcpy and I don't want the compiler to police me. So big NO to kcc.
And "big NO" to gcc and clang, which will both be happy to "inline" standard library function where the only guarantees are the ones given in the C standard (which you should really have a look at), as explained ad nauseam in the other thread.  What I don't understand is, if you're such a genius, how come you've never thought of the obvious solution to this: just define your own function and don't call it strcpy.  I promise that the compiler won't touch it.

Quote
If I know that for a particular MCU the memcpy listing behaves like I want it to behave then I might use the memcpy function, but most likely I would use assembly and if I have to support other micros then I will use macros. But only when a program doesn't fit the chip.
Don't use memcpy with overlapping memory areas: It's undefined (== bad).  You can certainly hand-code a memory copy routine in assembler if that's your thing, but it sounds like a waste of time in all but the most limited circumstances.  Use memmove instead.  It does exactly what you want.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Commercial product source code
« Reply #56 on: April 17, 2014, 11:24:50 am »
Quote
you tell me what compiler uses it all?

You may consider a few things:

1) why do you need to use it all?
2) why should a compiler use it all?
3) what makes a compiler use it all?
================================
https://dannyelectronics.wordpress.com/
 

Offline Wilksey

  • Super Contributor
  • ***
  • Posts: 1329
Re: Commercial product source code
« Reply #57 on: April 17, 2014, 11:29:54 am »
Referring to the original question,a lot of smaller "commercial" projects are born from other peoples hobby projects, just added protection circuitry and perhaps better rated components and the change to SMT.

The code, well, they will very rarely release this as source files as it would have taken someone time to write, and time is money, I have seen a couple which have been open sourced after years of selling, but the older the product the safer they can release it due to technological advances, i.e. you wouldn't use the same part from 10 years ago today if it was for example, a GSM module, as better, more power efficient chipsets are now available.

If you are interested in a particular industry, your best bet is to get a job working in that sector in a position that you can perhaps have a peek at the code in the repository, you would have to be very careful if you started producing products of similar nature though!
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Commercial product source code
« Reply #58 on: April 17, 2014, 12:01:08 pm »
From a programming logic perspective, you wouldn't see much difference between commercial software and open source - if anything, commercial software tends to lag behind, for reasons like legacy, life cycle management, reliability / liability and / or bureaucracy - I am sure the list goes on.

The biggest differences between the two lie in two or three categories:

1) general architecture: many pieces of hobbyist software are written to perform a specific task, with little thought of what has been done before it and what will be done after it. So they look like hacks rather than modules that can fit into a bigger piece.

I can give you a highly simplistic example. Writing to a spi transmission is quite simple on most mcus: you simply load your data into a transmission register or a buffer and the spi hardware does its magic. That's how most hobbyist spi routines are done: line after line of loading data into the spi registers.

You will rarely see that in a commercial software. What you are likely see are generic functional calls to a spi transmission routine that does some parametric check and then load up the transmission register. At first glance, this may look high inefficient and even redundant. But in a corporate environment, it is far more efficient and / or reliable: the actual spi transmission routines likely come from a proven library that has passed QC; it will be maintained on different mcus that the library supports; .... Once you load the spi library, you know with high degree of confidence that it will work; and if it doesn't, you know precisely where to fix the issues.

Approaches like that allow for fast debugging, low development cost and fast development cycles.

So something that looks highly inefficient / redundant may actually turn out to be highly efficient.

2) documentation: most decent shops do a good job insisting on documentation so the next person handling your code knows how you did it and why you did what you did. and if additional features are to be added, how it can be done efficient.

3) incrementalism vs. grand vision: hobbyist projects tend to start with a grand goal that is too big for anyone person, let alone an underskilled person, to tackle. Commercial projects tend to start small: with a limited set of features and functionality and frequent reuse of early modules / code base. and additional features are built on to it gradually. The emphasis on code modularity and reusing of older pieces is generally not present in a hobbyist project.

4) utilitarian vs. fancy code: you will notice that many hobbyists spend hours trying to make their code go faster, often at the cost of readability, or reliability. Coding in assembly in obscure fashions for example is proudly proclaimed as the status symbol. Those guys are either experts coding for NASA or DoD, or they have never taken on a project slightly more complicated than blinking one led.

As my driving coach told me, the difference between a pro-driver and a street racer is that the pro driver knows when to drive slow in order to drive fast.
================================
https://dannyelectronics.wordpress.com/
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Commercial product source code
« Reply #59 on: April 17, 2014, 12:16:09 pm »
As to code quality: I would say that 99.99% of the hobbyist code is fairly bad. But since the volume of it released is gigantic, you can indeed find gems from time to time.

Quality of open source software is hard to assess, since it is more often than not written by people with varying degree of competence, and as the heartbleed incident shows, with minimum QC too. But you are dealing with people who love what they do, so passion can indeed win out from time to time.

Commercial software in my view tends to be unexceptional but predictably so - I think it is by design (risk aversion) and due to QC.

So if you value cutting edge, go with open source or even a good hobbyist piece (good luck finding it);

if you value reliability (getting the job done), go with commercial software.

If you value getting the job done right, write your own.
================================
https://dannyelectronics.wordpress.com/
 

Offline Dielectric

  • Regular Contributor
  • *
  • Posts: 127
  • Country: 00
Re: Commercial product source code
« Reply #60 on: April 17, 2014, 03:14:21 pm »
Wow, derail...

Micrium's uC/OS-II RTOS is some very nice commercial code.  People that I respect hold it up as an example.

http://micrium.com/certification/unequaled-code-quality/
(grab their coding standards doc, good reading)

You can download the source after registering:
http://micrium.com/downloadcenter/micrium-source-code/

There are even a couple of textbooks to go with it.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Commercial product source code
« Reply #61 on: April 17, 2014, 04:23:56 pm »
Yeah. For learning, those older books on ucos are really nice.

Unfortunately, most hobbyists approach coding from a "writing" perspective, not from a (software) engineering perspective.
================================
https://dannyelectronics.wordpress.com/
 

Offline GiskardReventlov

  • Frequent Contributor
  • **
  • Posts: 598
  • Country: 00
  • How many pseudonyms do you have?
Re: Commercial product source code
« Reply #62 on: April 17, 2014, 04:47:06 pm »
Wow, derail...
Ha!  It's very common here.

Quote
Micrium's uC/OS-II RTOS is some very nice commercial code.  People that I respect hold it up as an example.

Will have to look at this.

Not exactly answering the initial question, but Windows NT source is publicly available.
 

Offline Q-Kernel

  • Contributor
  • Posts: 13
Re: Commercial product source code
« Reply #63 on: April 17, 2014, 05:12:31 pm »
Micrium's uC/OS-II RTOS is some very nice commercial code.  People that I respect hold it up as an example.

High quality software requires lots of development effort and time to mature and uC/OS is high quality commercial code.

High quality commercial code is not cheap so there must be a reason for the owner to make it open source. The main reason to make it open source is to get more exposure of the product and sell a version with a different licence model.

We made our RTOS Q-Kernel open source and everybody can use it for free in a non commercial setting like hobby, education, etc. Q-kernel was developed 7 year ago and has matured over the years. We made it zero latency, tick-less, included power management, included publish/subscribe, etc, so we put a lot of money in over the time.

The existing customers financed all this work but hobbyist and the educational world can now use it for free. They have access to commercial quality software including professional documentation which is often missing in non-commercial software.

I think that open source products with a dual licencing model (free license and commercial license) have a great future.

 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Commercial product source code
« Reply #64 on: April 19, 2014, 12:28:48 am »
I mentioned earlier that ST has some bugs in its code base. I was asked if I could mention a few examples. So here goes a short list:

1) HSE_VALUE in device header files.

HSE_VALUE specifies the external crystal / oscillator frequency, and is typically defined in device header files, like stm32fl1xx.h for L1xx devices. It usually takes this form:

Code: [Select]
/**
 * @brief In the following line adjust the value of External High Speed oscillator (HSE)
   used in your application
   
   Tip: To avoid modifying this file each time you need to use different HSE, you
        can define the HSE value in your toolchain compiler preprocessor.
  */ 
#define HSE_VALUE    ((uint32_t)8000000) /*!< Value of the External oscillator in Hz*/

How retarded a programmer has to be to write code like that?

To their credit, most of those types of defines have been fixed in later releases but it is simply embarrassing to have written something like that.

2) peripheral library 3.6.1 for stm32f10x devices.

The official stdperiph lib is 3.5.0. However, a newer version (3.6.1) is actually available, in stsw-stm32121.

It contains two errors, one of them would have presented their compilation (in _flash.c) - where is ST's QC on that? :)

Another, in _tim.c, is simply wrong:

Code: [Select]
static void TI4_Config(TIM_TypeDef* TIMx, uint16_t TIM_ICPolarity, uint16_t TIM_ICSelection,
                       uint16_t TIM_ICFilter)
{
...
  {
    /* Select the Polarity and set the CC4E Bit */
    tmpccer &= (uint16_t)~((uint16_t)(TIM_CCER_CC3P | TIM_CCER_CC4NP));
    tmpccer |= (uint16_t)(TIM_ICPolarity | (uint16_t)TIM_CCER_CC4E);
  }

Easy to spot too.

The point? Don't blindly trust anything - open source is fallable, as is commercial software.
================================
https://dannyelectronics.wordpress.com/
 

Offline HackedFridgeMagnet

  • Super Contributor
  • ***
  • Posts: 2028
  • Country: au
Re: Commercial product source code
« Reply #65 on: April 19, 2014, 01:18:44 am »

1) HSE_VALUE in device header files.

HSE_VALUE specifies the external crystal / oscillator frequency, and is typically defined in device header files, like stm32fl1xx.h for L1xx devices. It usually takes this form:

Code: [Select]
/**
 * @brief In the following line adjust the value of External High Speed oscillator (HSE)
   used in your application
   
   Tip: To avoid modifying this file each time you need to use different HSE, you
        can define the HSE value in your toolchain compiler preprocessor.
  */ 
#define HSE_VALUE    ((uint32_t)8000000) /*!< Value of the External oscillator in Hz*/

How retarded a programmer has to be to write code like that?

To their credit, most of those types of defines have been fixed in later releases but it is simply embarrassing to have written something like that.


Ok, I'll bite. What is retarded about the code?
 

Offline Mechatrommer

  • Super Contributor
  • ***
  • Posts: 11534
  • Country: my
  • reassessing directives...
Re: Commercial product source code
« Reply #66 on: April 26, 2014, 01:21:01 pm »

1) HSE_VALUE in device header files.

HSE_VALUE specifies the external crystal / oscillator frequency, and is typically defined in device header files, like stm32fl1xx.h for L1xx devices. It usually takes this form:

Code: [Select]
/**
 * @brief In the following line adjust the value of External High Speed oscillator (HSE)
   used in your application
   
   Tip: To avoid modifying this file each time you need to use different HSE, you
        can define the HSE value in your toolchain compiler preprocessor.
  */ 
#define HSE_VALUE    ((uint32_t)8000000) /*!< Value of the External oscillator in Hz*/

How retarded a programmer has to be to write code like that?

To their credit, most of those types of defines have been fixed in later releases but it is simply embarrassing to have written something like that.


Ok, I'll bite. What is retarded about the code?

since its left unanswered for the week let me shot... imho, for generic library, its wiser non the ritcher to add duplicate or error checking such as an example...
Code: [Select]
#ifndef HSE_VALUE
#define HSE_VALUE    ((uint32_t)8000000) /*!< Value of the External oscillator in Hz*/
#else
#error 1234 // just an example or no error raise at all.
#endif
Nature: Evolution and the Illusion of Randomness (Stephen L. Talbott): Its now indisputable that... organisms “expertise” contextualizes its genome, and its nonsense to say that these powers are under the control of the genome being contextualized - Barbara McClintock
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: Commercial product source code
« Reply #67 on: April 26, 2014, 02:24:54 pm »
Or take a look at STM32FCube - particularly where it generates the code.

Totally retarded too.
================================
https://dannyelectronics.wordpress.com/
 

Offline madires

  • Super Contributor
  • ***
  • Posts: 7695
  • Country: de
  • A qualified hobbyist ;)
Re: Commercial product source code
« Reply #68 on: April 28, 2014, 10:56:21 am »
Maybe I'm just anal, but I never let my code go out with any compiler warnings. I know my colleagues don't care so much about some of them, but I feel it's important.

That's a very good coding practice! It also makes it easier to spot the problems if you're not overrun by ton's of compiler warnings.
 

Offline Mechatrommer

  • Super Contributor
  • ***
  • Posts: 11534
  • Country: my
  • reassessing directives...
Re: Commercial product source code
« Reply #69 on: April 28, 2014, 10:56:45 am »
which used to compile with hundreds of warnings about potentially unused variables.
...but I never let my code go out with any compiler warnings.
there are some circumtances where we cant avoid warnings, esp higher level or fancier library, though it is agreed excessive use of variables is unwise, and the burden of "variabling" is usually passed to the end developer albeit generic (just like most std c lib). otoh warning flags can be disabled in compiler and at most the penalty is redundant or dormant memory allocation (if the compiler is stupid enough to not bin the unused var). just by looking and practising limited number of libs, if you just know how to make a proper "library" probably you'll quit and prefer to use readymade "proper" lib rather than making your own. just as demostrated, to properly check a single line of definition can take up to 5 lines, mostly managements code. now you want to build a usefull and proper lib? warnings is actually nothing imho. library maker should be from specialized computer science students, not electronics engineers or mcu maker. 2cnts.
Nature: Evolution and the Illusion of Randomness (Stephen L. Talbott): Its now indisputable that... organisms “expertise” contextualizes its genome, and its nonsense to say that these powers are under the control of the genome being contextualized - Barbara McClintock
 

Offline HackedFridgeMagnet

  • Super Contributor
  • ***
  • Posts: 2028
  • Country: au
Re: Commercial product source code
« Reply #70 on: April 28, 2014, 01:33:53 pm »
thanks for the input mechatrommer. Glad to get  a sensible answer to my question.

Quote
#define HSE_VALUE    ((uint32_t)8000000) /*!< Value of the External oscillator in Hz*/

vs

Quote
#if !defined  (HSE_VALUE)
 #define HSE_VALUE            ((uint32_t)8000000) /*!< Value of the External oscillator in Hz */
#endif /* HSE_VALUE */


Still I dont think it is very bad at all. What your crystal runs at the wrong speed if get your include files out of order.
How long before you sort that out. Anyway it's never caught me.

C and the way macros are used in C, provide lots of ways to shoot yourself in the foot and that is not near the worst of them.

Possibly the problem is with C, and the code above is a work around.
Oops ignore that last statement, it may have been a subconscious bit of trolling.


 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5550
  • Country: us
Re: Commercial product source code
« Reply #71 on: April 28, 2014, 03:56:57 pm »
Maybe I'm just anal, but I never let my code go out with any compiler warnings. I know my colleagues don't care so much about some of them, but I feel it's important.

That's a very good coding practice! It also makes it easier to spot the problems if you're not overrun by ton's of compiler warnings.

At work we have our projects configured with Treat Warnings as Errors, so nobody can check in code that produces warnings. We have also have a system that notifies everyone who broke the build. Believe me, you don't want to break the build! and that's just part of the whole build project. Just a bad and lazy description on your check-in can cause it to be reverted.
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 2051
  • Country: nl
Re: Commercial product source code
« Reply #72 on: April 28, 2014, 06:52:30 pm »
Code: [Select]
#ifndef HSE_VALUE
#define HSE_VALUE    ((uint32_t)8000000) /*!< Value of the External oscillator in Hz*/
#else
#error 1234 // just an example or no error raise at all.
#endif

If one must use a #define for some reason, then your version is already a lot safer than that happy go lucky summer intern style #define with a tip no-one will read. It's also a lot more verbose, but that's the price you pay... And I would rather have a big fat error and my code refusing to compile, than the mcu silently being configured at the wrong frequency. Or using the wrong frequency value to calculate for example some ADC/DAC settings. (Been there, done that, didn't like it).

What I don't get (except for the economic expedience of using summer interns to produce all that crazy code customers seem to expect) is why they don't use some const expressions for that.

Code: [Select]
static const uint32_t HSE_VALUE = 8000000;

Unless I'm missing something, that should take care of business. No need to explicitely do an #ifdef to check if you are accidentally overwriting a previous definition. Because unlike the preprocessor case, the compiler will whine loudly if you try to redeclare that const variable.

For ueber old code from an era where compiler optimization was maybe not super-duper, okay. But for libraries written in this century I'd think that maybe using const expressions would be better. Better in the sense that it is safer, and it optimizes exactly as well as the #define case.
 

Offline AG6QR

  • Frequent Contributor
  • **
  • Posts: 857
  • Country: us
    • AG6QR Blog
Re: Commercial product source code
« Reply #73 on: April 28, 2014, 08:02:53 pm »
Maybe I'm just anal, but I never let my code go out with any compiler warnings.

That's a very good practice.

However, I've seen code where warnings are taken somewhat casually, and it's not always quite as stupid as you might first think.  I've worked on massive software projects, and some of the source files have lived for over 20 years, and been compiled on 15 or more different compilers over time.  Compiler warnings vary widely from one compiler to another.  Granted, as you weed out warnings for the first five or six compilers, the next few compilers are less likely to find a huge number of new issues, though if the code is voluminous enough, even one new warning type may have so many thousands of occurrences that it's expensive to weed them all out every time you port to a new compiler.  Often it's worth doing, but sometimes it doesn't quite make the top of the priority list. 

I've worked in groups that, after a port to a new compiler, had a policy of, "Every time you change a source code file, clean up all the warnings in it, but don't necessarily go out of your way to fix warnings in old working code where there's no other reason to touch the file".

(For the sake of context, I've worked mainly on commercial software intended to run in big general purpose computers -- mainframes and modern desktop computers -- but I haven't worked professionally on hardware or firmware.  As software scales, the issues change.)
 

Offline Rigby

  • Super Contributor
  • ***
  • Posts: 1476
  • Country: us
  • Learning, very new at this. Righteous Asshole, too
Re: Commercial product source code
« Reply #74 on: April 28, 2014, 09:00:04 pm »
blah blah.  code is hard to get right.

lots of talk here about lots of stuff, and commercial source code is hard to obtain for one of the exact same reasons (at least) that open source is promoted by lots of folks: all bugs are shallow and obvious if enough people look at it.

no company wants their goofy little mistake to go public.  just look at what people do to each other on forums like this one over unimportant minutia - they eviscerate each other.  there are also legitimate legal reasons that closed source software is closed beyond just the nebulous "it could be embarrassing" reason.

C devs need to run their code through some static analysis tools (which are very easy to procure for businesses, and hard to procure for open source stuff because those tools are so expensive) which would have pointed out this bug many, many years ago.  It's hard enough to convince a C developer that even using an IDE is a good idea, so forget an analysis tool.  "I don't need that crap; I need [vi/vim/emacs/whatever tool one could mention that makes the speaker seem most hardcore].  It isn't done because developers don't trust tools they don't write or that aren't trusted by the community, developers don't want their code to make them look or feel stupid over a silly memcpy bug, and developers don't like it when a computer shows them a mistake that they could not have found on their own.  C devs often like C because it isn't easy, it doesn't always you all errors or warnings, only the few that are mostly obvious and then "damn i musta been drunk when I wrote that."  C programming culture is its own worst enemy.

static code analysis tools have been around a long time, and would have easily found the openssl bug.

closed source is closed usually because it needs to be.

closed source is not inherently better or worse than open source.
« Last Edit: April 28, 2014, 09:03:09 pm by Rigby »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf