All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Måns Rullgård" <mans@mansr.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] C99 and dynamic arrays
Date: Wed, 13 Mar 2013 19:55:37 +0000	[thread overview]
Message-ID: <yw1xk3pbcbwm.fsf@unicorn.mansr.com> (raw)
In-Reply-To: <CAPnjgZ3oddM64su-O3B5TaayTj367uG9gwpaPJOknaUjjWoc3w@mail.gmail.com> (Simon Glass's message of "Wed, 13 Mar 2013 11:48:47 -0700")

Simon Glass <sjg@chromium.org> writes:

> [once more from correct address, sorry]
>
> Hi,
>
> On Wed, Mar 13, 2013 at 11:03 AM, M?ns Rullg?rd <mans@mansr.com> wrote:
>> Simon Glass <sjg@google.com> writes:
>>
>>> Hi Mans,
>>>
>>> On Wed, Mar 13, 2013 at 3:29 AM, M?ns Rullg?rd <mans@mansr.com> wrote:
>>>> Tom Rini <tom.rini@gmail.com> writes:
>>>>
>>>>> On Tue, Mar 12, 2013 at 7:22 PM, Simon Glass <sjg@google.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Given that we seem to allow C99 features in U-Boot I wonder if it
>>>>>> would be OK to use dynamic arrays in SPL?
>>>>>>
>>>>>> I am trying to replace:
>>>>>>
>>>>>> ptr = malloc(size);
>>>>>>
>>>>>> with:
>>>>>>
>>>>>> char ptr[size];
>>>>>>
>>>>>> to avoid use of malloc in SPL. Can I assume that is permitted?
>>>>>
>>>>> Without knowing the underlying mechanics of how that works, "maybe".
>>>>
>>>> How it works depends on the compiler.  Some compilers implement it by
>>>> calling malloc().  GCC uses the stack.
>>>>
>>>> Regardless of how they are implemented, variable-length arrays should,
>>>> in my opinion, never be used.  There is simply no way they can be used
>>>> safely since no mechanism for detecting failure is provided.  If the
>>>> requested size is too large, you will silently overflow the stack or end
>>>> up with an invalid/null pointer.  In an environment without full memory
>>>> protection, errors resulting from this are very hard to track down.
>>>
>>> I suppose we could check the available stack space. However I don't
>>> really see a clear stack bottom in U-Boot - I think it is set up to
>>> grow downwards as much as needed. I can certainly add sanity checks on
>>> the input values.
>>
>> There is no way to check stack usage from C.
>
> Well there is an architecture-specific way. A function can generally
> find its own stack pointer by taking the address of a local variable,
> so it is possible to write a function to check for stack overflow.

Performing such checks without getting into undefined behaviours is
tricky if not impossible, and modern compilers are quite effective at
exploiting these, rendering such checks useless.  Remember the deleted
null checks in the kernel a while back?

> We could add this in U-Boot if it is a general problem. For my
> purposes the amount of stack I intend to allocate is fairly small
> (1-2KB perhaps).

I'm sure what you _intend_ to allocate is safe, but what's to guarantee
that the values are sane?

>>>> If the size is somehow limited to a safe value, it is more efficient to
>>>> simply allocate this maximum size statically.
>>>
>>> Yes although this does waste BSS.
>>
>> Sorry, I meant a statically sized stack allocation.
>
> OK, then I suppose this is not much different from dynamic arrays?

It gives more efficient code, if nothing else.

-- 
M?ns Rullg?rd
mans at mansr.com

  reply	other threads:[~2013-03-13 19:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAPnjgZ2211cc1ZQuFajVRdcr5qvJfRtmCp-_E-itTZLq4pbOfA@mail.gmail.com>
2013-03-12 23:48 ` [U-Boot] C99 and dynamic arrays Tom Rini
2013-03-13 10:29   ` Måns Rullgård
2013-03-13 17:01     ` Simon Glass
2013-03-13 18:03       ` Måns Rullgård
2013-03-13 18:36         ` Stephen Warren
2013-03-13 20:16           ` Måns Rullgård
2013-03-13 18:48         ` Simon Glass
2013-03-13 19:55           ` Måns Rullgård [this message]
2013-03-20  2:24             ` Steve Strobel
2013-03-13 10:41   ` Simon Glass
2013-03-13 16:06     ` Wolfgang Denk
2013-03-13 16:14     ` Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=yw1xk3pbcbwm.fsf@unicorn.mansr.com \
    --to=mans@mansr.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.