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

Groups > comp.lang.c > #101847 > unrolled thread

Dinamic array without malloc - Can be done?

Back to article view | Back to comp.lang.c

Contents

  Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 08:45 -0800
    Re: Dinamic array without malloc - Can be done? BartC <bc@freeuk.com> - 2017-01-15 16:53 +0000
      Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-15 09:34 -0800
        Re: Dinamic array without malloc - Can be done? BartC <bc@freeuk.com> - 2017-01-17 21:09 +0000
          Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-17 13:45 -0800
            Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-17 14:09 -0800
            Re: Dinamic array without malloc - Can be done? BartC <bc@freeuk.com> - 2017-01-17 22:41 +0000
            Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 15:06 -0800
              Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-17 16:49 -0800
              Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-17 16:56 -0800
                Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 20:37 -0800
                  Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-18 09:38 +0100
                  Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-31 08:49 -0800
                    Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-31 10:39 -0800
                      Re: Dinamic array without malloc - Can be done? luser droog <luser.droog@gmail.com> - 2017-01-31 10:55 -0800
                        Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-31 11:40 -0800
                      Re: Dinamic array without malloc - Can be done? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-31 10:57 -0800
                      Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-03 23:06 -0800
      Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 10:42 -0800
        Re: Dinamic array without malloc - Can be done? BartC <bc@freeuk.com> - 2017-01-15 20:15 +0000
          Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-15 12:43 -0800
          Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 15:08 -0800
    Re: Dinamic array without malloc - Can be done? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-15 12:25 -0500
      Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 10:46 -0800
        Re: Dinamic array without malloc - Can be done? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-15 20:13 +0000
          Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 15:06 -0800
      Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-15 12:46 -0800
        Re: Dinamic array without malloc - Can be done? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-15 16:10 -0500
        Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 20:37 -0800
          Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-15 21:02 -0800
            Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-30 04:23 -0800
          Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 09:05 +0100
            Re: Dinamic array without malloc - Can be done? Ian Collins <ian-news@hotmail.com> - 2017-01-16 21:16 +1300
              Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 09:48 +0100
    Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-15 09:29 -0800
      Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-15 09:37 -0800
      Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-15 09:56 -0800
        Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-15 10:34 -0800
      Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 10:48 -0800
        Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-15 11:10 -0800
        Re: Dinamic array without malloc - Can be done? Jean-Marc Bourguet <jm@bourguet.org> - 2017-01-15 20:22 +0100
          Re: Dinamic array without malloc - Can be done? Chad <cdalten@gmail.com> - 2017-01-15 11:50 -0800
          Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 15:12 -0800
    Re: Dinamic array without malloc - Can be done? Richard Heathfield <rjh@cpax.org.uk> - 2017-01-15 17:50 +0000
      Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 10:38 -0800
        Re: Dinamic array without malloc - Can be done? Richard Heathfield <rjh@cpax.org.uk> - 2017-01-15 19:34 +0000
          Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-15 12:51 -0800
            Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-15 13:10 -0800
              Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-15 16:23 -0800
                Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-15 18:08 -0800
              Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 09:56 +0100
                Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-16 08:35 -0800
                  Re: Dinamic array without malloc - Can be done? "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-16 11:07 -0800
                    Re: Dinamic array without malloc - Can be done? "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-16 11:17 -0800
                      Re: Dinamic array without malloc - Can be done? Robert Wessel <robertwessel2@yahoo.com> - 2017-01-16 15:21 -0600
                        Re: Dinamic array without malloc - Can be done? "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-31 22:22 -0800
                  Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 00:22 +0100
                    Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-16 16:23 -0800
                      Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 02:04 +0100
                        Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-16 17:27 -0800
                          Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 09:16 +0100
            Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 20:32 -0800
            Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 10:02 +0100
              Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-16 09:22 -0800
                Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 00:25 +0100
        Re: Dinamic array without malloc - Can be done? Barry Schwarz <schwarzb@dqel.com> - 2017-01-15 11:53 -0800
          Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-15 12:22 -0800
          Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 15:32 -0800
            Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-15 16:01 -0800
              Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 10:19 +0100
                Re: Dinamic array without malloc - Can be done? BartC <bc@freeuk.com> - 2017-01-16 11:28 +0000
                  Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 14:29 +0100
                    Re: Dinamic array without malloc - Can be done? BartC <bc@freeuk.com> - 2017-01-16 15:41 +0000
                      Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 17:27 +0100
                    Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-16 07:56 -0800
                      Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 17:31 +0100
                        Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-16 08:48 -0800
                          Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 00:29 +0100
                  Re: Dinamic array without malloc - Can be done? "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-16 11:25 -0800
                    Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-16 12:28 -0800
                      Re: Dinamic array without malloc - Can be done? "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-16 12:38 -0800
            Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-15 16:57 -0800
              Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-16 00:37 -0800
                Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 10:23 +0100
                  Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-16 01:35 -0800
                    Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-16 09:15 -0800
            Re: Dinamic array without malloc - Can be done? BartC <bc@freeuk.com> - 2017-01-16 01:29 +0000
          Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-16 10:08 +0100
            Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-16 08:08 -0800
              Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 00:35 +0100
                Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-16 16:31 -0800
                  Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 09:27 +0100
                    Re: Dinamic array without malloc - Can be done? BartC <bc@freeuk.com> - 2017-01-17 12:11 +0000
                      Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 14:23 +0100
                      Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 05:38 -0800
                        Re: Dinamic array without malloc - Can be done? BartC <bc@freeuk.com> - 2017-01-17 14:17 +0000
                          Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 07:09 -0800
                    Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 05:14 -0800
                      Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 14:40 +0100
                        Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 06:41 -0800
                          Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-17 16:00 +0100
                            Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 07:45 -0800
                              Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-17 08:18 -0800
                                Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-17 08:27 -0800
                                  Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 09:29 -0800
                                Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 09:23 -0800
                                  Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-17 10:35 -0800
                                    Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 12:41 -0800
                                      Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-17 13:45 -0800
                            Re: Dinamic array without malloc - Can be done? Robert Wessel <robertwessel2@yahoo.com> - 2017-01-17 21:00 -0600
        Re: Dinamic array without malloc - Can be done? fir <profesor.fir@gmail.com> - 2017-01-15 11:55 -0800
        Re: Dinamic array without malloc - Can be done? Siri Cruise <chine.bleu@yahoo.com> - 2017-01-15 14:59 -0800
      Re: Dinamic array without malloc - Can be done? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-15 20:04 +0000
        Re: Dinamic array without malloc - Can be done? David Brown <david.brown@hesbynett.no> - 2017-01-15 21:33 +0100
          Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-15 13:00 -0800
            Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 20:27 -0800
          Re: Dinamic array without malloc - Can be done? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-15 16:34 -0500
            Re: Dinamic array without malloc - Can be done? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-15 16:43 -0500
              Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-15 16:17 -0800
                Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 20:22 -0800
                  Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-15 21:00 -0800
                    Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-30 05:01 -0800
                      Re: Dinamic array without malloc - Can be done? Keith Thompson <kst-u@mib.org> - 2017-01-30 11:35 -0800
                        Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-01 16:18 -0800
                          Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-02-01 16:37 -0800
                            Re: Dinamic array without malloc - Can be done? Robert Wessel <robertwessel2@yahoo.com> - 2017-02-01 23:21 -0600
                            Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-02 00:27 -0800
                              Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-02-02 10:58 -0800
                                Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-03 22:51 -0800
    Re: Dinamic array without malloc - Can be done? "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-15 15:41 -0800
      Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 15:44 -0800
        Re: Dinamic array without malloc - Can be done? "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-15 16:17 -0800
    Re: Dinamic array without malloc - Can be done? Alla _ <modelling.data@gmail.com> - 2017-01-16 01:47 -0800
      Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-16 01:50 -0800
        Re: Dinamic array without malloc - Can be done? Alla _ <modelling.data@gmail.com> - 2017-01-16 02:38 -0800
          Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-16 03:15 -0800
            Re: Dinamic array without malloc - Can be done? Alla _ <modelling.data@gmail.com> - 2017-01-16 03:40 -0800
              Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-16 04:21 -0800
            Re: Dinamic array without malloc - Can be done? Alla _ <modelling.data@gmail.com> - 2017-01-16 04:29 -0800
              Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-16 04:36 -0800
      Re: Dinamic array without malloc - Can be done? Richard Heathfield <rjh@cpax.org.uk> - 2017-01-16 11:36 +0000
        Re: Dinamic array without malloc - Can be done? Alla _ <modelling.data@gmail.com> - 2017-01-16 03:44 -0800
        Re: Dinamic array without malloc - Can be done? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-16 15:34 +0000
          Re: Dinamic array without malloc - Can be done? Richard Heathfield <rjh@cpax.org.uk> - 2017-01-16 16:01 +0000
    Re: Dinamic array without malloc - Can be done? John Bode <jfbode1029@gmail.com> - 2017-01-17 10:14 -0800
      Re: Dinamic array without malloc - Can be done? James Kuyper <jameskuyper@verizon.net> - 2017-01-17 13:21 -0500
        Re: Dinamic array without malloc - Can be done? John Bode <jfbode1029@gmail.com> - 2017-01-17 11:43 -0800
          Re: Dinamic array without malloc - Can be done? James Kuyper <jameskuyper@verizon.net> - 2017-01-17 15:07 -0500
        Re: Dinamic array without malloc - Can be done? supercat@casperkitty.com - 2017-01-17 12:24 -0800
      Re: Dinamic array without malloc - Can be done? "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-17 10:24 -0800
      Re: Dinamic array without malloc - Can be done? Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-30 05:21 -0800

Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8  Next page →

#102047

On 17/01/17 15:41, supercat@casperkitty.com wrote:
> On Tuesday, January 17, 2017 at 7:40:53 AM UTC-6, David Brown wrote:
>> On 17/01/17 14:14, supercat wrote:
>>> Microchip's early so-called "C" compilers worked that way, but none of the
>>> versions of Keil I used ever did.
>>
>> Microchip's early compilers were appalling - huge prices for a tool that
>> could not manage an array of structs or a struct with an array, and
>> required so much hand-optimising of the C code that you might as well
>> write in assembly.
> 
> I used to use the CCS Compiler for the PICs.  Its dialect of C was goofier
> that Microchip's [type "short" being ONE bit!?  C'mon!] but coding for it
> was easier than coding in assembly.  I jumped ship on it when some bugs
> appeared I couldn't code around (if a compiler randomly miscomputes the
> target addresses of jumps there's really not much a programmer can do).
> 
>> I don't know what version of Keil is involved here.  I also don't
>> remeber the details here, and I don't have the tool on my systems to
>> test it.
> 
> Fair enough.  Was it 20+ years ago?

No, it was last year.

>  I did my first major project using
> Keil-51 around 1995.  The compiler had been sold as a "pro" version of
> Archimedes by the makers of that product, but I don't know that there was
> anything different from the ordinary Keil compiler apart from the branding.
> 
>> I don't blame the compiler for generating slow code on the rotten
>> processor architecture that was an outdated design when it was created
>> some 35 years ago.  And it's fair enough that you need compiler
>> extensions and special pointer types to get the best out of the device.
>>
>> But I /do/ blame the compiler for generating incorrect code that does
>> not follow the rules of C.
> 
> If I had noticed such things, I would have shared your view.  All I can
> figure is that you were using a different version than I was.  If that is
> the case, I'm not sure that your views of Keil from back then should
> negatively affect your views of the company today.

It is possible that the compiler in question was a particular fixed
version (for compatibility with the device vendor) rather than the
latest version, but it was not old.

However, I can't give details about either the tool in question or the
bugs found, because I don't remember them and have no way to test them
or reproduce them.

To be fair on Keil, if I had to get a compiler for the 8051 then I would
certainly consider it - I know it is a weird sort-of C, and that it has
bugs, but I also know it generates impressively efficient code and it is
perfectly possible that alternative tools are worse.

> 
>> (I also blame the thoughtless SoC hardware designers that think the 8051
>> is a sane choice of core when they want to add a small cpu to their chips.)
> 
> I hear you on that one.  While Intel made some dubious design choices in the
> 8051, the architecture is reasonably practical for the kinds of things one
> would do in machine language with a microcontroller that only needs 256 bytes
> of RAM.  When I first started working with the 8051 and heard that there was
> a C compiler for it, I found the concept unbelievable given its many disjoint
> forms of memory addressing; when I started programming it in C some years
> later, I was surprised to find it was surprisingly workable (though I suspect
> my background in 8051 assembly language helped a lot).
> 
> As for why SoC vendors would be using it, all I can figure is that it's cheap.
> I have at times wondered, though, what it would take to develop an open-source
> 8-bit core that was better and cheaper, that vendors could use instead.  I
> think the concept of addressing regions is a good thing (and even compilers
> for the ARM could benefit if the ABI would recognize such a thing!) but
> hardware should support a universal-pointer type.

I think it is more a matter of habit than any serious consideration.
And I think the decisions are made by people far removed from the
software people.  It's some project managers saying "this chip could do
with a microcontroller to run the hardware - what could we use?"  "Well,
we used an 8051 core on that last device - lets us it again here."  "Is
it expensive?"  "No."  And that is as far as it gets.

> 
>>> Compiler prices are absurd, and price does not always translate to quality.
>>
>> /Some/ compiler prices are absurd.  Others are quite reasonable, and
>> some are high and yet still good value for money.
> 
> I should have said compiler pricING is absurd.  Some compilers are reasonable,
> and are absurdly cheap, but I can identify no rhyme or reason to how things
> are priced.
> 

Fair enough.

>>> On the other hand, when you say such things shouldn't exist today, what
>>> would you suggest as alternative for writing code for a piece of 8051-based
>>> hardware that already exists?  
>>
>> The "best" choice would depend on the circumstances.  If you have to
>> work with code already designed for Keil, then Keil will be the best
>> choice if you can afford it - because the code is already in Keil-C
>> rather than C.  For an unrestrained choice, then there are alternatives
>> like IAR, Tasking, and of course SDCC.  I have no experience with any of
>> them, and cannot comment on them.
> 
> Never used those, though I found Keil's tools a little nicer than IAR's
> for the ARM.

I only tried IAR's tools for the AVR, long, long ago, and was not hugely
impressed.  But I admit to being a bit fussy :-)

> 
>> But whether or not there are better alternatives, the kind of bug I have
>> had to deal with in Keil 8051 should not be in a modern compiler.  With
>> the prices they charge, they should be expected to have comprehensive
>> test suites and correct behaviour in almost all code.
> 
> Does Keil's 8051 compiler *presently* behave as you describe?

As I say, the problems were during recent development, but I can't say
which tool versions or any details about the problem.  I was not
directly involved, I just helped distinguish between problems in the
source code and problems in the compiler.

> 
>>> The limitations of the 8051 architecture are the fault of Intel, not Keil.
>>> Maybe you had a different version of Keil from what I used, but I had no
>>> complaints about mine.
>>
>> My experience with Keil is mostly limited to helping others determine if
>> the bug is in their code or the compiler, which of course makes me very
>> biased - I have only seen the tool at its worst.
> 
> Another possibility, btw, is that the compiler might offer options for
> things like integer promotions, and people might be using projects where
> they are set in non-standard fashion.  

That is conceivable.  The developers working on it had only limited
control of project build options - it was all generated as part of the
hardware vendor's system.

> I don't remember such an option,
> but if earlier 8051 compilers did not promote, it's possible some production
> 8051 code relied upon such behavior.  Perhaps a project got imported from
> an older compiler with broken promotion rules (but the code for the project
> at the time was set up to deal with them) and the rules were set to be
> compatible with the old compiler.
> 

[toc] | [prev] | [next] | [standalone]

#102052

On Tuesday, January 17, 2017 at 9:00:51 AM UTC-6, David Brown wrote:
> It is possible that the compiler in question was a particular fixed
> version (for compatibility with the device vendor) rather than the
> latest version, but it was not old.

One of the reasons I would want a temporary-alloc function to have a
corresponding "free" is to allow code using such things to be ported to
ancient compilers.  If "freea" is a macro which takes both the size
and the pointer, and an implementation is allowed to use either, both,
or neither in releasing the last object that was "alloca"'ed, that
opens up a lot of possibilities to implement such a thing even on a
compiler which cannot be modified and includes no features to support it.

Likewise, I'd like to see a means by which code could specify that it wants
to create a

   [signed | unsigned] integer type with a size of 
   [8 | 16 | 32 | 64] bits, stored as a sequence of octets in
   [big-endian | little-endian | native-endian] order, aligned on
   [1 | 2 | 4 | 8] byte boundaries, and alias-compatible with
   [anything | any fixed-format type | only types derived from it]

using a syntax which, with the aid of the preprocessor, could be supported
on existing implementations to create typedefs for types they already
support.  Such a feature would make it possible to write code that needs
particular layouts in device-independent fashion.  While such code might
not run on all compilers, such a standard would let compilers provide a
clear porting path for code targeting other systems.  While some might
view such types as leaving 36-bit computers out in the cold, I'd suggest
it would instead do the opposite.  If such types are used only in cases
where exact format matters, a 36-bit compiler could probably support them
much more efficiently than it could process code needed to work around
their absence.  For example, if "x" is a fixed-format 32-bit number in
the machine's byte order, x++ could be implemented at the machine level
using an OR, ADD, and AND [if _x is the 36-bit machine representation,
use _x = (_x | 0400400400400) + 1 & 0377377377377], rather than by having
to use three shifts and three ORs to assemble four octets into an integer,
then adding one to that, and then using three shifts and four ANDs to
convert the result back to octets.

[toc] | [prev] | [next] | [standalone]

#102054

W dniu wtorek, 17 stycznia 2017 16:45:44 UTC+1 użytkownik supe...@casperkitty.com napisał:
> On Tuesday, January 17, 2017 at 9:00:51 AM UTC-6, David Brown wrote:
> > It is possible that the compiler in question was a particular fixed
> > version (for compatibility with the device vendor) rather than the
> > latest version, but it was not old.
> 
> One of the reasons I would want a temporary-alloc function to have a
> corresponding "free" is to allow code using such things to be ported to
> ancient compilers.  If "freea" is a macro which takes both the size

if alloca is

char* alloca(int size)
{
 asm sub esp, size;
 return esp;
}

then frea you could do as just alloca minus value like

char* p = alloca(100);
//...
alloca(-100);

but (if im not wrong) you cannot make things that will
put things on stack between alloca and this frea 
(it is maybe only function call that is disallowed, im not sure)

[toc] | [prev] | [next] | [standalone]

#102055

W dniu wtorek, 17 stycznia 2017 17:19:04 UTC+1 użytkownik fir napisał:
> W dniu wtorek, 17 stycznia 2017 16:45:44 UTC+1 użytkownik supe...@casperkitty.com napisał:
> > On Tuesday, January 17, 2017 at 9:00:51 AM UTC-6, David Brown wrote:
> > > It is possible that the compiler in question was a particular fixed
> > > version (for compatibility with the device vendor) rather than the
> > > latest version, but it was not old.
> > 
> > One of the reasons I would want a temporary-alloc function to have a
> > corresponding "free" is to allow code using such things to be ported to
> > ancient compilers.  If "freea" is a macro which takes both the size
> 
> if alloca is
> 
> char* alloca(int size)
> {
>  asm sub esp, size;
>  return esp;
> }
> 
> then frea you could do as just alloca minus value like
> 
> char* p = alloca(100);
> //...
> alloca(-100);
> 
> but (if im not wrong) you cannot make things that will
> put things on stack between alloca and this frea 
> (it is maybe only function call that is disallowed, im not sure)

function call could even be maybe legal as it cleans the stack for self (unles those functions thal alloca itself)

so im not sure as to this but it seems that realloca could work though it is not provided .. (but i only started to 
look into that so i dont know maybe not)

[toc] | [prev] | [next] | [standalone]

#102057

On Tuesday, January 17, 2017 at 10:27:22 AM UTC-6, fir wrote:
> function call could even be maybe legal as it cleans the stack for self (unles those functions thal alloca itself)

Compilers sometimes like to leave things on the stack between function calls.
Given
    foo(1);
    bar(2);

A compiler might generate:

   push 1
   call foo
   push 2
   call bar
   add  sp,8 ; Pop both values

Releasing alloca'ed storage between the two calls would work just fine
if it was done by adding a value to the stack pointer.  Trying to alloca()
something between the two calls, however, would result in disaster unless
the compiler recognized that any temporary items must be popped off the
stack before invoking any ASM code that could modify the stack pointer.

[toc] | [prev] | [next] | [standalone]

#102056

On Tuesday, January 17, 2017 at 10:19:04 AM UTC-6, fir wrote:
> if alloca is
> 
> char* alloca(int size)
> {
>  asm sub esp, size;
>  return esp;
> }
> 
> then frea you could do as just alloca minus value like
> 
> char* p = alloca(100);
> //...
> alloca(-100);
> 
> but (if im not wrong) you cannot make things that will
> put things on stack between alloca and this frea 
> (it is maybe only function call that is disallowed, im not sure)

The situations in which alloc() can safely put things on the stack would
tend to be the same as those in which freea() could take them off.  If
the compiler has placed things on the stack between alloca() and freea()
that would be bad, but the same problems would arise if the freea() were
another alloca().

Presently, alloca() is commonly implemented as as "subtract from stack
pointer and hope the compiler refrains from doing anything tricky with
the stack", and its semantics are consistent with those of a compiler
that uses a frame pointer and doesn't attempt to do any stack-related
optimizations.  All that a compiler that would naturally uses the common
frame-pointer pattern would need to do to support alloca is refrain from
applying any optimizations that would deviate from that pattern.  Any
platform that didn't use a frame pointer and wanted to support alloca()
would have to keep track of all the places alloca() is used and ensure
that the resulting allocations--however they were processed--got released.

In many cases, if a program was willing to configure (perhaps as a link-
time or library-build) option, or perhaps using an init_alloca() routine,
the total storage that would be required for all alloca() requests on a
given thread, then alloca and freea could be implemented as something like:

extern char* __alloca_ptr;

inline void *alloca(size_t size)
{
  char *result = __alloca_ptr;
  __alloca_ptr = result + ((size-1u) |3 +1);
}

// Following could could also use (__alloca_ptr -= (size))
#define freea(void *ptr, size_t size) (void)(__alloca_ptr = (ptr)) 

Note that depending upon the cost of accessing external variables, this
approach could have a *lower* run-time cost than stack pointer hackery,
since it would not interfere with stack-based optimizations [among other
things, use of a stack-based alloca() would almost certainly force an
implementation to save the frame pointer on entry and load it on exit,
adding a load and store which would in most cases otherwise not be needed.
So the cost of load and store used by the first call to alloca() within
a function would be offset by the elimination of the save/restore of the
frame pointer.

[toc] | [prev] | [next] | [standalone]

#102061

W dniu wtorek, 17 stycznia 2017 18:23:24 UTC+1 użytkownik supe...@casperkitty.com napisał:
> On Tuesday, January 17, 2017 at 10:19:04 AM UTC-6, fir wrote:
> > if alloca is
> > 
> > char* alloca(int size)
> > {
> >  asm sub esp, size;
> >  return esp;
> > }
> > 
> > then frea you could do as just alloca minus value like
> > 
> > char* p = alloca(100);
> > //...
> > alloca(-100);
> > 
> > but (if im not wrong) you cannot make things that will
> > put things on stack between alloca and this frea 
> > (it is maybe only function call that is disallowed, im not sure)
> 
> The situations in which alloc() can safely put things on the stack would
> tend to be the same as those in which freea() could take them off.  If
> the compiler has placed things on the stack between alloca() and freea()
> that would be bad, but the same problems would arise if the freea() were
> another alloca().
> 
> Presently, alloca() is commonly implemented as as "subtract from stack
> pointer and hope the compiler refrains from doing anything tricky with
> the stack", and its semantics are consistent with those of a compiler
> that uses a frame pointer and doesn't attempt to do any stack-related
> optimizations.  All that a compiler that would naturally uses the common
> frame-pointer pattern would need to do to support alloca is refrain from
> applying any optimizations that would deviate from that pattern.  Any
> platform that didn't use a frame pointer and wanted to support alloca()
> would have to keep track of all the places alloca() is used and ensure
> that the resulting allocations--however they were processed--got released.
> 
> In many cases, if a program was willing to configure (perhaps as a link-
> time or library-build) option, or perhaps using an init_alloca() routine,
> the total storage that would be required for all alloca() requests on a
> given thread, then alloca and freea could be implemented as something like:
> 
> extern char* __alloca_ptr;
> 
> inline void *alloca(size_t size)
> {
>   char *result = __alloca_ptr;
>   __alloca_ptr = result + ((size-1u) |3 +1);
> }
> 
> // Following could could also use (__alloca_ptr -= (size))
> #define freea(void *ptr, size_t size) (void)(__alloca_ptr = (ptr)) 
> 
> Note that depending upon the cost of accessing external variables, this
> approach could have a *lower* run-time cost than stack pointer hackery,
> since it would not interfere with stack-based optimizations [among other
> things, use of a stack-based alloca() would almost certainly force an
> implementation to save the frame pointer on entry and load it on exit,
> adding a load and store which would in most cases otherwise not be needed.
> So the cost of load and store used by the first call to alloca() within
> a function would be offset by the elimination of the save/restore of the
> frame pointer.

afaik the compilers use this frame pointer or if no they must manage this stack release vealue anyway (i think
on the convention where function releases self what
she alocates, though), 

think the frame pointer version is used more often,
here with alloca it could at least pay off (becouse
normally when you know statically the unwind walue
it is maybe a bit unoptimal (maybe, i dont remember the details))

anyway this stack pointer is not so much 
problem imo 

as i said im not sure though if such realloca could 
work but it maybe seems it could, only one would need
to remember only last top alloca can be reallocka'd

one should rethink the version when functions would 
allooca on return as imo it maybe would be the most usable
case (as i said in other thread, it not works on present c
but in logically improved c it would work

foo()
{
  char* new_string = crate_straing( 10 + rand()% 10);
}

ass this mixes call with alloca there sjould be rethinked if it would work

push 15
//push new_string //?
call create_string

as after return it need to reset esp it would
need maybe return the value of bythes that need to be allocka'd then (or have other kind of ret who will ret and then move stack) it seem to be doable but need consideration [easier it would be more stack, which idea i promote for longer time, but it also would need to be considered how having a couple of stack would be heavy in management (in cycles)

[toc] | [prev] | [next] | [standalone]

#102072

On Tuesday, January 17, 2017 at 12:35:39 PM UTC-6, fir wrote:
> > Note that depending upon the cost of accessing external variables, this
> > approach could have a *lower* run-time cost than stack pointer hackery,
> > since it would not interfere with stack-based optimizations [among other
> > things, use of a stack-based alloca() would almost certainly force an
> > implementation to save the frame pointer on entry and load it on exit,
> > adding a load and store which would in most cases otherwise not be needed.
> > So the cost of load and store used by the first call to alloca() within
> > a function would be offset by the elimination of the save/restore of the
> > frame pointer.
> 
> afaik the compilers use this frame pointer or if no they must manage this stack release vealue anyway (i think
> on the convention where function releases self what
> she alocates, though), 
> 
> think the frame pointer version is used more often,

Many compilers used to prefix *every* function with code to set up the
frame pointer and follow every function with code to clean it up, because
they would generate code for a function as they processed it, and might
not know until the end (after they'd generated all the code) whether the
frame pointer was actually necessary.

Nowadays, however, many compilers analyze a function before generating any
code for it, and can thus avoid creating a stack frame in cases where they
don't need one.  If the target platform supports stack-relative addressing
as well as frame-relative addressing (common on most of today's platforms)
many compilers will be able to eliminate the frame pointer in the vast
majority of functions.

[toc] | [prev] | [next] | [standalone]

#102083

W dniu wtorek, 17 stycznia 2017 21:42:13 UTC+1 użytkownik supe...@casperkitty.com napisał:
> On Tuesday, January 17, 2017 at 12:35:39 PM UTC-6, fir wrote:
> > > Note that depending upon the cost of accessing external variables, this
> > > approach could have a *lower* run-time cost than stack pointer hackery,
> > > since it would not interfere with stack-based optimizations [among other
> > > things, use of a stack-based alloca() would almost certainly force an
> > > implementation to save the frame pointer on entry and load it on exit,
> > > adding a load and store which would in most cases otherwise not be needed.
> > > So the cost of load and store used by the first call to alloca() within
> > > a function would be offset by the elimination of the save/restore of the
> > > frame pointer.
> > 
> > afaik the compilers use this frame pointer or if no they must manage this stack release vealue anyway (i think
> > on the convention where function releases self what
> > she alocates, though), 
> > 
> > think the frame pointer version is used more often,
> 
> Many compilers used to prefix *every* function with code to set up the
> frame pointer and follow every function with code to clean it up, because
> they would generate code for a function as they processed it, and might
> not know until the end (after they'd generated all the code) whether the
> frame pointer was actually necessary.
> 
> Nowadays, however, many compilers analyze a function before generating any
> code for it, and can thus avoid creating a stack frame in cases where they
> don't need one.  If the target platform supports stack-relative addressing
> as well as frame-relative addressing (common on most of today's platforms)
> many compilers will be able to eliminate the frame pointer in the vast
> majority of functions.

it is used afair to easy travel back on stack, (like in disasembly in debugger on break) without it it is harder 
(i dont remember the details)

as in optimised code you usually do not make a function calls the small slowdown are not so much important (or more i mean it is good to have an option to compile with this (and without)) [i probably would like optimised away
version more but i dont care as much as i do not do calls
in optimised parts]

in reality i think (i probably said so already) that in
present situation it would be probably best optimise 
only hotspots for speed and most of the rest of the code
for size (or better some reasonable balance))

[toc] | [prev] | [next] | [standalone]

#102097

On Tue, 17 Jan 2017 16:00:44 +0100, David Brown
<david.brown@hesbynett.no> wrote:

>> As for why SoC vendors would be using it, all I can figure is that it's cheap.
>> I have at times wondered, though, what it would take to develop an open-source
>> 8-bit core that was better and cheaper, that vendors could use instead.  I
>> think the concept of addressing regions is a good thing (and even compilers
>> for the ARM could benefit if the ABI would recognize such a thing!) but
>> hardware should support a universal-pointer type.
>
>I think it is more a matter of habit than any serious consideration.
>And I think the decisions are made by people far removed from the
>software people.  It's some project managers saying "this chip could do
>with a microcontroller to run the hardware - what could we use?"  "Well,
>we used an 8051 core on that last device - lets us it again here."  "Is
>it expensive?"  "No."  And that is as far as it gets.


An additional reason would be the significant tool-chain support for
the 8051.  A new open source core would not have that.

That being said, there are open source versions of the 8051 as well as
other microcontrollers (not least AVR, which is where I'd go if I
wanted an 8-bit core with all else being equal).

But to be fair to the 8051 architecture, for the size of system
intended (128 bytes RAM, 4KB ROM), programming in assembler was
assumed, and not much of a burden.  And it was a pretty good
improvement over the 8048.

[toc] | [prev] | [next] | [standalone]

#101871

W dniu niedziela, 15 stycznia 2017 19:38:22 UTC+1 użytkownik Fernando D. Bozzo napisał:
> El domingo, 15 de enero de 2017, 18:50:39 (UTC+1), Richard Heathfield  escribió:
> <snip> 
> > Why don't you want to use malloc?
> > 
> 
> 
> Hi Richard, the reason is just to simplify the garbage collection automatically, and not needing to free() manually at some point. If I could use some mechanism like try/catch then this could not be a problem, but without it it makes more difficult to manage the flow of a program.
> 
> May be is the little practice I have until now, but for small arrays (<1MB) could be a good idea.

you have also alloca function, it allocks area on stack and dont need to be freed, [it is said to be faster than malloc/free in some cases]

i never used it yet though (same as vla) but could eventually try it (it seem to be eventually more general than vla as you could alloca in loop (not sure as to vla made in loop), no resiza and frea though) (not sure if vla allows to change size after creation, probably not so alloca seem to be maybe a bit more raw and maybe general vla)

[toc] | [prev] | [next] | [standalone]

#101888

In article <01610cdf-e6ca-47ac-ba40-b597b0c524d0@googlegroups.com>,
 "Fernando D. Bozzo" <fdbozzo@gmail.com> wrote:

So the first step is to look up your particular compiler's documentation and/or 
identify your compiler and version. Some of these things just require some extra 
options given to the compiler. I had a similar problem with declarations in for 
statements until I learned gcc and lvm require you tell it the language version.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
'I desire mercy, not sacrifice.'
Free the Amos Yee one.
Yeah, too bad about your so-called life. Ha-ha.

[toc] | [prev] | [next] | [standalone]

#101873

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 15/01/17 16:45, Fernando D. Bozzo wrote:
>> From the beginning of my course I'm looking a way to define an array
>> with a number of elements based on some other variable which I don't
>> know, but without using the dynamic memory space (with malloc)
>
> My preference here would be to use malloc.
>
> Nevertheless, from C99 onwards you can use variable-length arrays.

Maybe.  The 'onwards' is in doubt since they are optional in C11.  You
may be right in that any compiler that supports them in C99 will
probably do so indefinitely, but that's not quite the same thing.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#101878

On 15/01/17 21:04, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>> On 15/01/17 16:45, Fernando D. Bozzo wrote:
>>> From the beginning of my course I'm looking a way to define an array
>>> with a number of elements based on some other variable which I don't
>>> know, but without using the dynamic memory space (with malloc)
>>
>> My preference here would be to use malloc.
>>
>> Nevertheless, from C99 onwards you can use variable-length arrays.
>
> Maybe.  The 'onwards' is in doubt since they are optional in C11.  You
> may be right in that any compiler that supports them in C99 will
> probably do so indefinitely, but that's not quite the same thing.
>
> <snip>
>

I wonder why C11 made VLA's optional?  Does anyone know of a compiler 
that supports all or most of C99 /except/ VLA's?  There are certainly 
compilers that support most of C99 but not complex numbers, or whose 
floating point arithmetic is not quite according to IEC 60559.  But 
VLA's are not at all difficult to support in a compiler, especially if 
the compiler already has alloca() or a similar function.

[toc] | [prev] | [next] | [standalone]

#101883

On Sunday, January 15, 2017 at 2:33:25 PM UTC-6, David Brown wrote:
> I wonder why C11 made VLA's optional?  Does anyone know of a compiler 
> that supports all or most of C99 /except/ VLA's?  There are certainly 
> compilers that support most of C99 but not complex numbers, or whose 
> floating point arithmetic is not quite according to IEC 60559.  But 
> VLA's are not at all difficult to support in a compiler, especially if 
> the compiler already has alloca() or a similar function.

The Keil/ARM compilers for embedded systems implement VLAs using
malloc/free.  Unless the linker has been configured to reserve space
for the heap, however, calls to malloc() will die (freestanding
implementations aren't required to support malloc, and for most
embedded systems no purpose would be served by doing so).  Because
the Standard does not specify any cases in which an attempt to
create a VLA cannot invoke UB, such behavior is conforming.  On
the other hand, it would be more helpful if implementations that are
not going to use malloc() could instead arrange to have any attempts
to build programs using VLAs fail with compiler or link failures.

[toc] | [prev] | [next] | [standalone]

#101911

supercat@casperkitty.com writes:

> [...]
> the Standard does not specify any cases in which an attempt to
> create a VLA cannot invoke UB, [...]

Evaluating a declaration that includes a VLA declarator (with a
positive extent) is no more or less undefined behavior than
calling a function or entering a block that declares automatic
variables.

[toc] | [prev] | [next] | [standalone]

#101886

On 01/15/2017 03:33 PM, David Brown wrote:
...
> I wonder why C11 made VLA's optional?

I haven't seen a 2011 version of the C Rationale, so I can't be sure - 
but I imagine it's because somebody complained about the difficulty of 
supporting VLAs, and the committee decided to accommodate their complaint.
The oldest message I could find using Google Groups that mentions 
__STDC_NO_VLA__, was part of a 2010 thread in which Chris Hills said:

> For several years I have been saying that some C99 features would be
> dropped in the next standard and no one believed me.   It all stemmed
> from the discussions at the end  of the WG14 meeting in April 2007.

During the entire year after April 2007, i found only two threads on 
comp.std.c, and four on comp.lang.c, that mentioned VLAs, and none of 
those threads mentioned those discussions.

> ... Does anyone know of a compiler
> that supports all or most of C99 /except/ VLA's? ...

During one of the threads I mentioned above, Kenneth Brody said:
> I don't use VLAs, as many [most?] of the compilers I use don't
> support it,

He didn't say whether any of those compilers supported any other C99 
features.

[toc] | [prev] | [next] | [standalone]

#101887

On 01/15/2017 04:34 PM, James R. Kuyper wrote:
> On 01/15/2017 03:33 PM, David Brown wrote:
> ...
>> I wonder why C11 made VLA's optional?
>
> I haven't seen a 2011 version of the C Rationale, so I can't be sure -
> but I imagine it's because somebody complained about the difficulty of
> supporting VLAs, and the committee decided to accommodate their complaint.
> The oldest message I could find using Google Groups that mentions
> __STDC_NO_VLA__, was part of a 2010 thread in which Chris Hills said:
>
>> For several years I have been saying that some C99 features would be
>> dropped in the next standard and no one believed me.   It all stemmed
>> from the discussions at the end  of the WG14 meeting in April 2007.
>
> During the entire year after April 2007, i found only two threads on
> comp.std.c, and four on comp.lang.c, that mentioned VLAs, and none of
> those threads mentioned those discussions.

I just found the relevant document:
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1460.htm>

[toc] | [prev] | [next] | [standalone]

#101902

"James R. Kuyper" <jameskuyper@verizon.net> writes:
> On 01/15/2017 04:34 PM, James R. Kuyper wrote:
>> On 01/15/2017 03:33 PM, David Brown wrote:
>> ...
>>> I wonder why C11 made VLA's optional?
>>
>> I haven't seen a 2011 version of the C Rationale, so I can't be sure -
>> but I imagine it's because somebody complained about the difficulty of
>> supporting VLAs, and the committee decided to accommodate their complaint.
>> The oldest message I could find using Google Groups that mentions
>> __STDC_NO_VLA__, was part of a 2010 thread in which Chris Hills said:
>>
>>> For several years I have been saying that some C99 features would be
>>> dropped in the next standard and no one believed me.   It all stemmed
>>> from the discussions at the end  of the WG14 meeting in April 2007.
>>
>> During the entire year after April 2007, i found only two threads on
>> comp.std.c, and four on comp.lang.c, that mentioned VLAs, and none of
>> those threads mentioned those discussions.
>
> I just found the relevant document:
> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1460.htm>

But it gives no specific information about why VLAs were made
optional, other than saying that complex arithmetic and VLAs were
"Two of the largest additions to C99".

Perhaps it would have made more sense to make VLAs (and perhaps
complex numbers?) optional for freestanding implementations, but
mandatory for hosted implementations.  (In C99, all conforming
implementations must support complex numbers, but freestanding
implementations needn't support <complex.h>.)  Making threading
and atomics optional strikes me as more reasonable, particularly
since they were first introduced in C11.

Complex numbers are an interesting case.  In C99, complex types are
mandatory, but the <complex.h> header is required only for hosted
implementations.  That meant that a freestanding implementation must
support the types _Complex float, _Complex double, and _Complex
long double, but without <complex.h> there's no portable way to
specify the value of i.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

[toc] | [prev] | [next] | [standalone]

#101910

Keith Thompson <kst-u@mib.org> writes:

> In C99, complex types are mandatory, but the <complex.h> header
> is required only for hosted implementations.  That meant that a
> freestanding implementation must support the types _Complex
> float, _Complex double, and _Complex long double, but without
> <complex.h> there's no portable way to specify the value of i.

What isn't portable about this?

    typedef _Complex float Zfloat;

    Zfloat
    imaginary_unit(){
        return  (union {float f[2]; Zfloat z;}){ {0,1} }.z;
    }

[toc] | [prev] | [next] | [standalone]

Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8  Next page →

Back to top | Article view | comp.lang.c

csiph-web