Re: Wikipedia goes wrong: is this possible?

Discussion in 'C Programming' started by Stephen Sprunk, Jun 13, 2013.

  1. On 13-Jun-13 08:56, paskali wrote:
    > David Brown <> wrote:
    >> These two functions (assuming you correct the leak in the second
    >> version)
    >>

    >
    > There are not leak or error on my code,


    Yes, there is:

    >>> arr = NULL;
    >>> free(arr);


    By clearing the pointer to the object _before_ freeing it, and then
    calling free(NULL), you leak that object's memory. That you made such
    an obvious error in your example showing the "superiority" of this
    solution shows just how difficult this can be to do correctly.

    With VLAs, the compiler automatically cleans up the memory when the
    object goes out of scope, so a memory leak is not possible. There is no
    need to rely on the programmer being perfect.

    >> In my business, small systems embedded programming with an emphasis
    >> on reliability, the first version might be considered acceptable if
    >> there are clear restrictions on "var". The second version is
    >> completely unacceptable - dynamic memory must be avoided unless
    >> there is no other way to handle it, and even then "malloc" and
    >> "free" are rarely the right way to implement it.
    >>

    >
    > When you will use any day the first form, say me and all our here.


    He just told you when (and why) he uses the VLA form.

    S

    --
    Stephen Sprunk "God does not play dice." --Albert Einstein
    CCIE #3723 "God is an inveterate gambler, and He throws the
    K5SSS dice at every possible opportunity." --Stephen Hawking
    Stephen Sprunk, Jun 13, 2013
    #1
    1. Advertising

  2. Stephen Sprunk

    Ian Collins Guest

    paskali wrote:
    >
    > What you say is very interesting but for me the use of C, in general, is not a
    > good solution in this case. Apart the use of not (or pseudo) standard solution,
    > the use of C in embedded system is not suggested, i see (here in Italy) the use
    > of more evolute and modern platforms like .NET or Java.


    Then you are either deliberately trolling, or have a different view of
    embedded devices to those of us who work with them...

    > The virtual machines permit a better memory and resources managment, you do not
    > have to play with pointers, dinamic memory managment, use or not virtual memory,
    > etc..... It is sure, i do not like so J2EE or .NET, but, may be, there is a
    > valid reason of their existense.


    Another reason not to like them is they don't run on the vast majority
    of embedded devices.

    --
    Ian Collins
    Ian Collins, Jun 15, 2013
    #2
    1. Advertising

  3. On Fri, 14 Jun 2013 19:26:34 +0000, paskali wrote:

    > What you say is very interesting but for me the use of C, in general, is
    > not a good solution in this case. Apart the use of not (or pseudo)
    > standard solution, the use of C in embedded system is not suggested, i
    > see (here in Italy) the use of more evolute and modern platforms like
    > .NET or Java.


    Good luck trying to run a .Net or Java VM on a device that has in total
    4MB Flash and 1MB RAM, and don't forget that your program with all its
    data also has to fit into that memory.

    And if you think that there are no embedded devices with that small an
    amount of memory, then you are dead wrong. I have worked on them, and I
    might even be on the generous side here with my memory estimations.

    Only 10 years ago, it was very common for a (high-end) television set to
    have a processor with only 128KB ROM and 4KB RAM. Memory sizes surely
    have increased in that decade, but I would not be surprised to find such
    limited processors in dishwashers or toasters today.

    <snip>
    > The virtual machines permit a better memory and resources managment, you
    > do not have to play with pointers, dinamic memory managment, use or not
    > virtual memory, etc..... It is sure, i do not like so J2EE or .NET, but,
    > may be, there is a valid reason of their existense.


    Sure, C is not the ideal language for everything, but there are also
    still areas where your only choices are C or assembler.

    Bart v Ingen Schenau
    Bart van Ingen Schenau, Jun 15, 2013
    #3
  4. On 15-Jun-13 14:40, paskali wrote:
    > http://en.wikipedia.org/wiki/.NET_Micro_Framework


    I thought you hated Wikipedia?

    S

    --
    Stephen Sprunk "God does not play dice." --Albert Einstein
    CCIE #3723 "God is an inveterate gambler, and He throws the
    K5SSS dice at every possible opportunity." --Stephen Hawking
    Stephen Sprunk, Jun 15, 2013
    #4
  5. Stephen Sprunk

    Ian Collins Guest

    paskali wrote:
    > Ian Collins <> wrote:
    >
    >> paskali wrote:
    >>>
    >>> What you say is very interesting but for me the use of C, in general, is not a
    >>> good solution in this case. Apart the use of not (or pseudo) standard solution,
    >>> the use of C in embedded system is not suggested, i see (here in Italy) the use
    >>> of more evolute and modern platforms like .NET or Java.

    >>
    >> Then you are either deliberately trolling, or have a different view of
    >> embedded devices to those of us who work with them...
    >>
    >>> The virtual machines permit a better memory and resources managment, you do not
    >>> have to play with pointers, dinamic memory managment, use or not virtual memory,
    >>> etc..... It is sure, i do not like so J2EE or .NET, but, may be, there is a
    >>> valid reason of their existense.

    >>
    >> Another reason not to like them is they don't run on the vast majority
    >> of embedded devices.
    >>

    >
    > http://www.netmf.com/what-is-the-net-micro-framework.aspx


    "The typical .NET Micro-Framework device has a 32 bit processor"

    The majority of embedded devices use 8 and 16 bit CPUs.

    --
    Ian Collins
    Ian Collins, Jun 15, 2013
    #5
  6. Stephen Sprunk

    Ian Collins Guest

    paskali wrote:
    > Bill Leary <> wrote:
    >
    >> "Bart van Ingen Schenau" wrote in message
    >> news:kph549$hgd$...
    >>> ((..omitted..))
    >>> And if you think that there are no embedded devices with that small
    >>> an amount of memory, then you are dead wrong. I have worked on
    >>> them, and I might even be on the generous side here with my memory
    >>> estimations.
    >>>
    >>> Only 10 years ago, it was very common for a (high-end) television set
    >>> to have a processor with only 128KB ROM and 4KB RAM. Memory sizes
    >>> surely have increased in that decade, but I would not be surprised to
    >>> find such limited processors in dishwashers or toasters today.

    >>
    >> Quite. Even five years back I was working on the internal monitor for a
    >> cabinet sized disk array. 128K ROM, 2K RAM. Programmed in C with embedded
    >> extensions.
    >>
    >> - Bill

    >
    > I think today there is not reason that a similar thing has not 128 or 256kb ram.
    > I think the costs of 2k are the same.


    Then you think wrong. Small micros are very price sensitive, so
    minimising die size is essential to meet a price point. RAM uses a lot
    of die space.

    --
    Ian Collins
    Ian Collins, Jun 15, 2013
    #6
  7. Stephen Sprunk

    Ian Collins Guest

    paskali wrote:
    > Ian Collins <> wrote:
    >
    >> paskali wrote:
    >>> Ian Collins <> wrote:
    >>>
    >>>> paskali wrote:
    >>>>>
    >>>>> What you say is very interesting but for me the use of C, in general, is not a
    >>>>> good solution in this case. Apart the use of not (or pseudo) standard

    > solution,
    >>>>> the use of C in embedded system is not suggested, i see (here in Italy)

    > the use
    >>>>> of more evolute and modern platforms like .NET or Java.
    >>>>
    >>>> Then you are either deliberately trolling, or have a different view of
    >>>> embedded devices to those of us who work with them...
    >>>>
    >>>>> The virtual machines permit a better memory and resources managment, you

    > do not
    >>>>> have to play with pointers, dinamic memory managment, use or not virtual

    > memory,
    >>>>> etc..... It is sure, i do not like so J2EE or .NET, but, may be, there is a
    >>>>> valid reason of their existense.
    >>>>
    >>>> Another reason not to like them is they don't run on the vast majority
    >>>> of embedded devices.
    >>>>
    >>>
    >>> http://www.netmf.com/what-is-the-net-micro-framework.aspx

    >>
    >> "The typical .NET Micro-Framework device has a 32 bit processor"
    >>
    >> The majority of embedded devices use 8 and 16 bit CPUs.
    >>

    >
    > No, there are a lot of 32bit devices, as well as i wrote there are not
    > economical reasons to choice 8bit devices in the place of more modern 32bit's.


    You obviously don't understand the market (were cents per component
    count) many of us work in.

    --
    Ian Collins
    Ian Collins, Jun 15, 2013
    #7
  8. Stephen Sprunk

    Jorgen Grahn Guest

    On Sat, 2013-06-15, Robert Wessel wrote:
    > On Sat, 15 Jun 2013 19:40:54 GMT, "paskali" <>
    > wrote:

    ....
    >>http://msdn.microsoft.com/en-us/library/cc533012.aspx
    >>
    >>http://en.wikipedia.org/wiki/.NET_Micro_Framework

    >
    > Considering the links in all three of your posts, none of those run on
    > more than a tiny fraction of the embedded devices out there. Most
    > embedded systems are simply too small to run one of those.


    And as for the rest of them, surely most run Linux these days? No
    ..NET there, or anyway no programmers prepared to use it.

    That has been my experience with "big embedded" for the last decade
    anyway -- some Unix variant, and C.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Jun 15, 2013
    #8
  9. On Saturday, June 15, 2013 6:42:31 PM UTC+1, David Brown wrote:
    > On 14/06/13 12:26, paskali wrote:
    >
    > No, I mean it is only occasionally acceptable to use any sort of dynamic
    > memory management in the sort of embedded systems I work with - and when
    > it is unavoidable, you use specialised functions rather than standard
    > malloc.
    >

    Yes, this does make life difficult.

    Let's say we want to calculate the median of a list of numbers. For the
    of view of a straightforwards, reusable, intuitive implementation of
    the function, the problem is unbounded. We need to create a temporary
    list, sort it, get the middle element, and destroy it. So we need malloc().

    But if the program is running on an embedded system, you can't call
    malloc(). The problem must be bounded, there must be an upper limit to
    the size of the list, or there's no solution at all. If there's a limit,
    we can avoid malloc() by passing in two buffers.

    But that means we've got to rewrite the function. it also creates problems
    for caller, because his fixed buffer is used only whilst the function is
    executing, and if he's short of RAM, he'll want that space for something
    else. So he's got to devise some complex overlay scheme, which is a burden.
    Malcolm McLean, Jun 16, 2013
    #9
  10. Malcolm McLean <> writes:
    > On Saturday, June 15, 2013 6:42:31 PM UTC+1, David Brown wrote:
    >> On 14/06/13 12:26, paskali wrote:
    >>
    >> No, I mean it is only occasionally acceptable to use any sort of dynamic
    >> memory management in the sort of embedded systems I work with - and when
    >> it is unavoidable, you use specialised functions rather than standard
    >> malloc.
    >>

    > Yes, this does make life difficult.
    >
    > Let's say we want to calculate the median of a list of numbers. For the
    > of view of a straightforwards, reusable, intuitive implementation of
    > the function, the problem is unbounded. We need to create a temporary
    > list, sort it, get the middle element, and destroy it. So we need malloc().


    You don't need to sort the entire array to compute the median.
    You can use an algorithm similar to Quicksort, but without bothering
    to sort any partition that doesn't include the center element.
    (That doesn't help with the memory issue, but it's faster if you
    don't need a sorted copy of the array for other reasons.)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jun 16, 2013
    #10
  11. On 2013-06-13, Stephen Sprunk <> wrote:
    >
    > With VLAs, the compiler automatically cleans up the memory when the
    > object goes out of scope, so a memory leak is not possible. There is no
    > need to rely on the programmer being perfect.


    Brush up on the distinction between scope and extent. The array
    may well go out of scope (indeed, it probably will for any non-trivial
    function) but continue to exist before it comes back into scope.
    Call another function inside that function and it is out of scope
    within the callee, but it comes back again when control returns to
    the caller.

    --
    Andrew Smallshaw
    Andrew Smallshaw, Jun 17, 2013
    #11
  12. On 2013-06-15, paskali <> wrote:
    >
    > No, there are a lot of 32bit devices, as well as i wrote there are not
    > economical reasons to choice 8bit devices in the place of more modern 32bit's.


    Cite me one 32-bitter with a unit cost under 10 cents...

    --
    Andrew Smallshaw
    Andrew Smallshaw, Jun 17, 2013
    #12
  13. Stephen Sprunk

    Ivan Shmakov Guest

    [OT] 8-bit vs. 32-bit

    >>>>> paskali <> writes:
    >>>>> Andrew Smallshaw <> wrote:
    >>>>> On 2013-06-15, paskali <> wrote:


    [Cross-posting to news:comp.arch.embedded, as ISTR that the
    issue was already discussed there.]

    >>> No, there are a lot of 32bit devices, as well as I wrote there are
    >>> no economical reasons to choice 8bit devices in the place of more
    >>> modern 32bit's.


    >> Cite me one 32-bitter with a unit cost under 10 cents...


    > Euros or Dollars?


    I guess either 0.10 USD or 0.10 EUR would make quite an example.

    FWIW, the MCUs I've dealt with are mostly in the 0.8 USD to some
    2 USD range per piece, whether they're 8- or 32-bit. I believe
    I've never bought an MCU for less than 0.5 USD a piece. But
    then, I've never bought more than a dozen of a kind at any
    single deal, which probably explains the difference.

    --
    FSF associate member #7257
    Ivan Shmakov, Jun 17, 2013
    #13
  14. Andrew Smallshaw <> writes:
    > On 2013-06-13, Stephen Sprunk <> wrote:
    >> With VLAs, the compiler automatically cleans up the memory when the
    >> object goes out of scope, so a memory leak is not possible. There is no
    >> need to rely on the programmer being perfect.

    >
    > Brush up on the distinction between scope and extent. The array
    > may well go out of scope (indeed, it probably will for any non-trivial
    > function) but continue to exist before it comes back into scope.
    > Call another function inside that function and it is out of scope
    > within the callee, but it comes back again when control returns to
    > the caller.


    What you're calling "extent" is what the Standard calls "storage
    duration" or "lifetime". An object's storage duration is either
    static, thread, automatic, or allocated ("thread" was added by C11).
    It's *lifetime* is "the portion of program execution during which
    storage is guaranteed to be reserved for it" (C11 6.2.4p2).

    The term *scope*, on the other hand, applies to an identifier.
    Quoting the standard again (6.2.1p2):

    For each different entity that an identifier designates, the
    identifier is *visible* (i.e., can be used) only within a region
    of program text called its *scope*.

    Note that *scope* is a region of program text, while *lifetime*
    is a subset of the time during which the program is executing.
    It doesn't necessarily make sense to talk about an object (actually
    the identifier that names the object) going in an out of scope
    during program execution -- though I suppose you could relate it
    to the chunk of code that's executing at a given moment.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jun 17, 2013
    #14
  15. Keith Thompson <> writes:
    [...]
    > What you're calling "extent" is what the Standard calls "storage
    > duration" or "lifetime". An object's storage duration is either
    > static, thread, automatic, or allocated ("thread" was added by C11).
    > It's *lifetime* is "the portion of program execution during which
    > storage is guaranteed to be reserved for it" (C11 6.2.4p2).


    s/It's/Its/ (d'oh!)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jun 17, 2013
    #15
  16. Stephen Sprunk

    Jukka Marin Guest

    Re: [OT] 8-bit vs. 32-bit

    On 2013-06-17, Ivan Shmakov <> wrote:
    > FWIW, the MCUs I've dealt with are mostly in the 0.8 USD to some
    > 2 USD range per piece, whether they're 8- or 32-bit. I believe
    > I've never bought an MCU for less than 0.5 USD a piece. But
    > then, I've never bought more than a dozen of a kind at any
    > single deal, which probably explains the difference.


    The NXP LPC8xx series is expected to be in the 50 cent range (and up).
    Not bad for a 32-bit RISC in DIP8... :) (Yes, they do have DIP8.)

    -jm
    Jukka Marin, Jun 17, 2013
    #16
  17. Stephen Sprunk

    Uwe Bonnes Guest

    Re: [OT] 8-bit vs. 32-bit

    In comp.arch.embedded Jukka Marin <> wrote:
    > On 2013-06-17, Ivan Shmakov <> wrote:
    > > FWIW, the MCUs I've dealt with are mostly in the 0.8 USD to some
    > > 2 USD range per piece, whether they're 8- or 32-bit. I believe
    > > I've never bought an MCU for less than 0.5 USD a piece. But
    > > then, I've never bought more than a dozen of a kind at any
    > > single deal, which probably explains the difference.


    > The NXP LPC8xx series is expected to be in the 50 cent range (and up).
    > Not bad for a 32-bit RISC in DIP8... :) (Yes, they do have DIP8.)


    "Expected"? Argh!

    A price you can't see for parts avaiable at mouser or digikey is not real...
    --
    Uwe Bonnes -darmstadt.de

    Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
    --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
    Uwe Bonnes, Jun 17, 2013
    #17
  18. Re: [OT] 8-bit vs. 32-bit

    In article <kpo0gf$i84$-darmstadt.de>,
    -darmstadt.de says...
    >
    > In comp.arch.embedded Jukka Marin <> wrote:
    > > On 2013-06-17, Ivan Shmakov <> wrote:
    > > > FWIW, the MCUs I've dealt with are mostly in the 0.8 USD to some
    > > > 2 USD range per piece, whether they're 8- or 32-bit. I believe
    > > > I've never bought an MCU for less than 0.5 USD a piece. But
    > > > then, I've never bought more than a dozen of a kind at any
    > > > single deal, which probably explains the difference.

    >
    > > The NXP LPC8xx series is expected to be in the 50 cent range (and up).
    > > Not bad for a 32-bit RISC in DIP8... :) (Yes, they do have DIP8.)

    >
    > "Expected"? Argh!
    >
    > A price you can't see for parts avaiable at mouser or digikey is not real...


    That's been my criteria for designing in parts for more than a decade.
    If you can't find it at one of those two, it really isn't something I
    want to put in a design. Those companies have become a my proxy
    of choice for a good purchasing agent when I am looking for quantities
    under 100 of almost anything. Granted, that I may pay a bit more per
    part---but that's nothing in comparison to designing in a part I can't
    find in time to deliver my product.

    Mark Borgerson
    Mark Borgerson, Jun 18, 2013
    #18
  19. Stephen Sprunk

    Jukka Marin Guest

    Re: [OT] 8-bit vs. 32-bit

    On 2013-06-17, Uwe Bonnes <-darmstadt.de> wrote:
    >> The NXP LPC8xx series is expected to be in the 50 cent range (and up).
    >> Not bad for a 32-bit RISC in DIP8... :) (Yes, they do have DIP8.)

    >
    > "Expected"? Argh!


    :) Arrow says the price is 0.39 eur (@ 10000 pcs). Haven't actually
    tried to buy any. Got a demo board from NXP recently, so the chip does
    exist. Digi-Key knows the part numbers, but has 0 stock.

    -jm
    Jukka Marin, Jun 18, 2013
    #19
  20. Stephen Sprunk

    Oliver Betz Guest

    Re: [OT] 8-bit vs. 32-bit

    Jukka Marin wrote:

    >On 2013-06-17, Ivan Shmakov <> wrote:
    >> FWIW, the MCUs I've dealt with are mostly in the 0.8 USD to some
    >> 2 USD range per piece, whether they're 8- or 32-bit. I believe
    >> I've never bought an MCU for less than 0.5 USD a piece. But
    >> then, I've never bought more than a dozen of a kind at any
    >> single deal, which probably explains the difference.

    >
    >The NXP LPC8xx series is expected to be in the 50 cent range (and up).
    >Not bad for a 32-bit RISC in DIP8... :) (Yes, they do have DIP8.)


    Infineon XMC1000 might be in the same range and has really powerful
    peripherals. Kinetis KL0 is also cheap.

    Oliver
    --
    Oliver Betz, Munich
    despammed.com is broken, use Reply-To:
    Oliver Betz, Jun 18, 2013
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Siri Cruise

    Re: Wikipedia goes wrong: is this possible?

    Siri Cruise, Jun 13, 2013, in forum: C Programming
    Replies:
    4
    Views:
    196
    zebra9forC
    Jun 15, 2013
  2. Eric Sosman

    Re: Wikipedia goes wrong: is this possible?

    Eric Sosman, Jun 13, 2013, in forum: C Programming
    Replies:
    10
    Views:
    282
    Kenny McCormack
    Jun 19, 2013
  3. Noob
    Replies:
    0
    Views:
    191
  4. Stephen Sprunk

    Re: Wikipedia goes wrong: is this possible?

    Stephen Sprunk, Jun 13, 2013, in forum: C Programming
    Replies:
    9
    Views:
    179
    Tim Rentsch
    Jun 18, 2013
  5. James Kuyper

    Re: Wikipedia goes wrong: is this possible?

    James Kuyper, Jun 13, 2013, in forum: C Programming
    Replies:
    3
    Views:
    196
    Stephen Sprunk
    Jun 15, 2013
Loading...

Share This Page