Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #402702

Re: MISRA C

Show all headers | View raw

On 2026-10-05 11:02, Waldek Hebisch wrote:
> Ben Bacarisse <ben@bsb.me.uk> wrote:
>> Sorry I'm jumping in here.  I don't read Usenet much these days but this
>> got me going.
>>
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> You can implement the Ackermann function without explicit recursion, just
>>> using a single loop and with allocated stacks or lists to hold the progress.
>>> But you /cannot/ do so with a single allocation at the start.   If you are
>>> asked to calculate A(m, n), you cannot calculate an upper bound on the stack
>>> size you need without calculating the function.
>>
>> Hmm...  This is likely to confuse people.  You can calculate A(m, n)
>> using O(m) extra space.  You can pre-allocate the space you need before
>> starting the calculation.  (Aside: this disregards the space needed to
>> store the numbers.  A(m, n) grows so large that you need extra space
>> just to store the integers, but that complicates the discussion and I
>> think everyone has been ignoring it in this thread anyway.)
> 
> Not everone.  C does not have unbounded integers, so in C using
> signed numbers computation will very quickly lead to overflow.
> On can handle non-overflowing cases by very simple iterative code.
> Even in language with unbounded integers in practice Ackermann
> very quickly will overflow.  So in practice Ackermann is easily
> computable, you either get overflow or comptational cost is
> related to size of the answer.

I don't think the question here was about a "universal Ackermann"
function, neither concerning the representation of integers with
its extreme growth, nor with any need to going as fundamental as
to Turing machines. The previously posted "iterative Ackermann"
C-function showed the same range of numerically representable
arguments and results as the respective recursive function, and
its space demands appear to not be larger than the recursive one
(with its internal stack hidden by the programming language's
implicit mechanisms).

I'd like to also remind that Alan's original example was not as
extreme as Ackermann function (which is of rare practical use),
but rather he mentioned the common recursive tree-algorithms.
Their "non-linearity" would make iterative versions also have to
introduce some stack-"memory" (so is in that respect not different).
The point is that you can formulate these recursive algorithms in
a much more obvious (simple) way than with introducing explicit
stacks.

Janis

> [...]

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

MISRA C (was: buckle-up ....) Alan Mackenzie <acm@muc.de> - 2026-09-25 10:01 +0000
  Re: MISRA C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-25 14:52 +0200
    Re: MISRA C Alan Mackenzie <acm@muc.de> - 2026-09-25 13:48 +0000
      Re: MISRA C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-25 16:39 +0200
        Re: MISRA C Alan Mackenzie <acm@muc.de> - 2026-09-25 15:10 +0000
          Re: MISRA C bart <bc@freeuk.com> - 2026-09-25 16:57 +0100
          Re: MISRA C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-25 11:42 -0700
            Re: MISRA C Alan Mackenzie <acm@muc.de> - 2026-09-25 20:21 +0000
              Re: MISRA C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-25 14:05 -0700
                Re: MISRA C David Brown <david.brown@hesbynett.no> - 2026-09-26 08:43 +0200
                Re: MISRA C Alan Mackenzie <acm@muc.de> - 2026-09-26 17:55 +0000
                Re: MISRA C Ben Bacarisse <ben@bsb.me.uk> - 2026-10-03 23:55 +0100
                Re: MISRA C David Brown <david.brown@hesbynett.no> - 2026-10-04 16:10 +0200
                Re: MISRA C Ben Bacarisse <ben@bsb.me.uk> - 2026-10-05 01:22 +0100
                Re: MISRA C David Brown <david.brown@hesbynett.no> - 2026-10-05 07:59 +0200
                Re: MISRA C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-05 01:23 -0700
                Re: MISRA C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-05 01:24 -0700
                Re: MISRA C antispam@fricas.org (Waldek Hebisch) - 2026-10-05 09:02 +0000
                Re: MISRA C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-05 12:07 +0200
                Re: MISRA C Ben Bacarisse <ben@bsb.me.uk> - 2026-10-05 15:29 +0100
                Re: MISRA C antispam@fricas.org (Waldek Hebisch) - 2026-10-05 20:29 +0000
                Re: MISRA C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-06 22:13 -0700
                Re: MISRA C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-06 22:14 -0700
          Re: MISRA C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-27 10:52 -0700
          Re: MISRA C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-28 13:08 +0200
            Re: MISRA C bart <bc@freeuk.com> - 2026-09-28 13:07 +0100
            Re: MISRA C David Brown <david.brown@hesbynett.no> - 2026-09-28 14:08 +0200
              Re: MISRA C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-28 14:28 +0200
            Re: MISRA C Alan Mackenzie <acm@muc.de> - 2026-09-28 12:17 +0000
              Re: MISRA C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-28 14:40 +0200
          Re: MISRA C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-30 10:21 -0700
            Re: MISRA C Alan Mackenzie <acm@muc.de> - 2026-09-30 19:57 +0000
              Re: MISRA C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-30 13:09 -0700
                Re: MISRA C David Brown <david.brown@hesbynett.no> - 2026-10-01 08:47 +0200
                Re: MISRA C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-01 15:18 -0700
      Re: MISRA C Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-27 04:58 +0800
  Re: MISRA C David Brown <david.brown@hesbynett.no> - 2026-09-25 17:02 +0200
  Re: MISRA C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-26 15:37 -0700

csiph-web