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

Groups > comp.lang.python > #57152 > unrolled thread

Python Front-end to GCC

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

Contents

  Python Front-end to GCC Philip Herron <herron.philip@googlemail.com> - 2013-10-20 10:56 -0700
    Re: Python Front-end to GCC victorgarcianet@gmail.com - 2013-10-20 15:10 -0700
      Re: Python Front-end to GCC John Nagle <nagle@animats.com> - 2013-10-22 23:48 -0700
        Re: Python Front-end to GCC Philip Herron <herron.philip@googlemail.com> - 2013-10-23 00:25 -0700
          Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-23 09:42 +0100
          Re: Python Front-end to GCC John Nagle <nagle@animats.com> - 2013-10-23 13:51 -0700
    Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-20 20:35 -0700
      Re: Python Front-end to GCC Steven D'Aprano <steve@pearwood.info> - 2013-10-21 07:46 +0000
        Re: Python Front-end to GCC Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-10-21 10:55 +0100
          Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-21 23:41 +0000
            Re: Python Front-end to GCC Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-10-22 10:14 +0100
              Re: Python Front-end to GCC Philip Herron <herron.philip@googlemail.com> - 2013-10-22 02:32 -0700
              Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 12:00 +0000
                Re: Python Front-end to GCC Chris Angelico <rosuav@gmail.com> - 2013-10-22 23:20 +1100
                  Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 17:27 +0000
                    Re: Python Front-end to GCC Chris Angelico <rosuav@gmail.com> - 2013-10-23 08:43 +1100
                Re: Python Front-end to GCC Dave Angel <davea@davea.name> - 2013-10-22 14:04 +0000
                  Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 15:22 +0000
                    Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-22 15:39 +0000
                      Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 16:40 +0000
                        Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-22 17:50 +0100
                        Re: Python Front-end to GCC Chris Kaynor <ckaynor@zindagigames.com> - 2013-10-22 09:52 -0700
                          Re: Python Front-end to GCC albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-11-01 22:48 +0000
                        Re: Python Front-end to GCC Frank Miles <fpm@u.washington.edu> - 2013-10-22 16:53 +0000
                          Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 17:23 +0000
                            Re: Python Front-end to GCC Chris Kaynor <ckaynor@zindagigames.com> - 2013-10-22 10:35 -0700
                            Re: Python Front-end to GCC Neil Cerutti <neilc@norwich.edu> - 2013-10-22 17:37 +0000
                            Re: Python Front-end to GCC Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-10-22 18:37 +0100
                            Re: Python Front-end to GCC MRAB <python@mrabarnett.plus.com> - 2013-10-22 18:42 +0100
                            Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-22 18:49 +0000
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 04:40 +0100
                            Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 04:55 -0700
                            Re: Python Front-end to GCC Dan Sommers <dan@tombstonezero.net> - 2013-10-25 12:55 +0000
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 15:18 +0100
                            Re: Python Front-end to GCC Ned Batchelder <ned@nedbatchelder.com> - 2013-10-25 10:35 -0400
                            Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 11:26 -0700
                              Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-25 19:06 +0000
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 19:40 +0100
                            Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 11:45 -0700
                              Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-25 11:59 -0700
                                Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 12:09 -0700
                                  Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-25 12:15 -0700
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 20:02 +0100
                            Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 12:18 -0700
                              Re: Python Front-end to GCC John Nagle <nagle@animats.com> - 2013-10-26 14:31 -0700
                                Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-26 15:10 -0700
                                Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-27 15:14 -0700
                                  Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-27 19:15 -0700
                                    Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-28 08:44 +0000
                                      Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-28 02:31 -0700
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 20:36 +0100
                            Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 12:49 -0700
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 21:14 +0100
                            Re: Python Front-end to GCC Tim Delaney <timothy.c.delaney@gmail.com> - 2013-10-26 07:11 +1100
                            Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 13:29 -0700
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 21:36 +0100
                              Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-26 02:42 +0000
                                [OT] Re: Python Front-end to GCC Antoine Pitrou <solipsis@pitrou.net> - 2013-10-29 11:04 +0000
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 21:44 +0100
                            Re: Python Front-end to GCC Tim Delaney <timothy.c.delaney@gmail.com> - 2013-10-26 07:48 +1100
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 21:56 +0100
                            Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 14:02 -0700
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 22:11 +0100
                            Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 14:37 -0700
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 22:56 +0100
                            Re: Python Front-end to GCC Chris Angelico <rosuav@gmail.com> - 2013-10-26 13:36 +1100
                    Re: Python Front-end to GCC Neil Cerutti <neilc@norwich.edu> - 2013-10-22 17:15 +0000
                      Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-22 18:58 +0000
                        Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-22 20:26 +0000
                  Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-22 15:36 +0000
                Re: Python Front-end to GCC Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-10-22 15:15 +0100
        Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-21 13:14 -0700
        Re: Python Front-end to GCC Ned Batchelder <ned@nedbatchelder.com> - 2013-10-21 16:29 -0400
          Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-21 20:40 -0700
    Re: Python Front-end to GCC Philip Herron <herron.philip@googlemail.com> - 2013-10-21 04:08 -0700
      Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-21 13:26 -0700
        Re: Python Front-end to GCC Philip Herron <herron.philip@googlemail.com> - 2013-10-21 14:03 -0700
          Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-21 16:04 -0700
            Re: Python Front-end to GCC Piet van Oostrum <piet@vanoostrum.org> - 2013-10-21 23:45 -0400
              Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-21 21:24 -0700
                Re: Python Front-end to GCC Steven D'Aprano <steve@pearwood.info> - 2013-10-22 05:25 +0000
              Re: Python Front-end to GCC Dave Angel <davea@davea.name> - 2013-10-22 04:39 +0000
              Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-22 08:04 -0700
                Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 17:09 +0000
                Re: Python Front-end to GCC Piet van Oostrum <piet@vanoostrum.org> - 2013-10-22 13:20 -0400
              Re: Python Front-end to GCC Ned Batchelder <ned@nedbatchelder.com> - 2013-10-22 11:46 -0400
              Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-22 16:52 +0100
              Re: Python Front-end to GCC Benjamin Kaplan <benjamin.kaplan@case.edu> - 2013-10-22 09:03 -0700
              Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-22 10:50 -0700
                Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-22 11:11 -0700
                Re: Python Front-end to GCC Neil Cerutti <neilc@norwich.edu> - 2013-10-22 18:18 +0000
                  Re: Python Front-end to GCC Piet van Oostrum <piet@vanoostrum.org> - 2013-10-22 15:20 -0400
                    Re: Python Front-end to GCC Neil Cerutti <neilc@norwich.edu> - 2013-10-22 19:27 +0000
                      Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-22 20:38 +0100
                        Re: Python Front-end to GCC Neil Cerutti <neilc@norwich.edu> - 2013-10-22 20:00 +0000
                    Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-22 20:32 +0100
              Re: Python Front-end to GCC Skip Montanaro <skip@pobox.com> - 2013-10-22 13:08 -0500
              Re: Python Front-end to GCC MRAB <python@mrabarnett.plus.com> - 2013-10-22 19:16 +0100
              Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-22 11:16 -0700
              Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-22 11:22 -0700
              Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-22 11:28 -0700
                Re: Python Front-end to GCC Piet van Oostrum <piet@vanoostrum.org> - 2013-10-22 18:11 -0400
                  Re: Python Front-end to GCC Chris Angelico <rosuav@gmail.com> - 2013-10-23 17:28 +1100
                Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-22 22:47 +0000
              Re: Python Front-end to GCC Ned Batchelder <ned@nedbatchelder.com> - 2013-10-22 14:23 -0400
                Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-22 11:40 -0700
                  Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-22 19:58 +0100
              Re: Python Front-end to GCC Ned Batchelder <ned@nedbatchelder.com> - 2013-10-22 14:40 -0400
                Re: Python Front-end to GCC alex23 <wuwei23@gmail.com> - 2013-10-23 11:36 +1000
                  Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-22 21:04 -0700
                  Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-23 07:06 +0100
              Re: Python Front-end to GCC MRAB <python@mrabarnett.plus.com> - 2013-10-22 19:47 +0100
              Re: Python Front-end to GCC Ned Batchelder <ned@nedbatchelder.com> - 2013-10-22 13:56 -0400
              Re: Python Front-end to GCC Michael Torrie <torriem@gmail.com> - 2013-10-22 22:05 -0600
              Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-23 07:13 +0100
              Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-26 14:25 -0700
              Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-26 14:33 -0700
              Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-26 22:38 +0100
              Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-26 22:35 +0100
                Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-28 14:21 +0000
                  Re: Python Front-end to GCC Chris Angelico <rosuav@gmail.com> - 2013-10-29 01:26 +1100
                    Re: Python Front-end to GCC Neil Cerutti <neilc@norwich.edu> - 2013-10-28 15:01 +0000
      Re: Python Front-end to GCC Antoine Pitrou <solipsis@pitrou.net> - 2013-10-22 08:55 +0000
        Re: Python Front-end to GCC Philip Herron <herron.philip@googlemail.com> - 2013-10-22 02:08 -0700
        Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 10:10 +0000
          Re: Python Front-end to GCC Antoine Pitrou <solipsis@pitrou.net> - 2013-10-22 15:51 +0000
      Re: Python Front-end to GCC Stefan Behnel <stefan_ml@behnel.de> - 2013-10-24 08:47 +0200
    Re: Python Front-end to GCC xDog Walker <thudfoo@gmail.com> - 2013-10-25 14:49 -0700
    Re: Python Front-end to GCC sharath.cs.smp@gmail.com - 2013-11-15 07:59 -0800

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

#57273

On 22/10/2013 17:40, Steven D'Aprano wrote:
> On Tue, 22 Oct 2013 15:39:42 +0000, Grant Edwards wrote:
>
>>> No, I was thinking of an array. Arrays aren't automatically initialised
>>> in C.
>>
>> If they are static or global, then _yes_they_are_.  They are zeroed.
>
> Not that I don't believe you, but do you have a reference for this?
> Because I keep finding references to uninitialised C arrays filled with
> garbage if you don't initialise them.
>
> Wait... hang on a second...
>
> /fires up the ol' trusty gcc
>
>
> [steve@ando c]$ cat array_init.c
> #include<stdio.h>
>
> int main()
> {
>    int i;
>    int arr[10];
>    for (i = 0; i < 10; i++) {
>      printf("arr[%d] = %d\n", i, arr[i]);
>      }
>      printf("\n");
>      return 0;
> }
>
> [steve@ando c]$ gcc array_init.c
> [steve@ando c]$ ./a.out
> arr[0] = -1082002360
> arr[1] = 134513317
> arr[2] = 2527220
> arr[3] = 2519564
> arr[4] = -1082002312
> arr[5] = 134513753
> arr[6] = 1294213
> arr[7] = -1082002164
> arr[8] = -1082002312
> arr[9] = 2527220
>
>
> What am I missing here?
>
>

arr is local to main, not static or global.

-- 
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

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

#57274

[Multipart message — attachments visible in raw view] — view raw

On Tue, Oct 22, 2013 at 9:40 AM, Steven D'Aprano <
steve+comp.lang.python@pearwood.info> wrote:

> On Tue, 22 Oct 2013 15:39:42 +0000, Grant Edwards wrote:
>
> >> No, I was thinking of an array. Arrays aren't automatically initialised
> >> in C.
> >
> > If they are static or global, then _yes_they_are_.  They are zeroed.
>
> Not that I don't believe you, but do you have a reference for this?
> Because I keep finding references to uninitialised C arrays filled with
> garbage if you don't initialise them.
>
> Wait... hang on a second...
>
> /fires up the ol' trusty gcc
>
>
> [steve@ando c]$ cat array_init.c
> #include<stdio.h>
>
> int main()
> {
>   int i;
>   int arr[10];
>   for (i = 0; i < 10; i++) {
>     printf("arr[%d] = %d\n", i, arr[i]);
>     }
>     printf("\n");
>     return 0;
> }
>
> [steve@ando c]$ gcc array_init.c
> [steve@ando c]$ ./a.out
> arr[0] = -1082002360
> arr[1] = 134513317
> arr[2] = 2527220
> arr[3] = 2519564
> arr[4] = -1082002312
> arr[5] = 134513753
> arr[6] = 1294213
> arr[7] = -1082002164
> arr[8] = -1082002312
> arr[9] = 2527220
>

> What am I missing here?
>

The array you made there is an auto variable (stack), not a static or a
global. Try one of the following (neither has been tested):

Static:

int main()
{
  int i;
  static int arr[10];
  for (i = 0; i < 10; i++) {
    printf("arr[%d] = %d\n", i, arr[i]);
    }
    printf("\n");
    return 0;
}



Global:

int arr[10];
int main()
{
  int i;
  for (i = 0; i < 10; i++) {
    printf("arr[%d] = %d\n", i, arr[i]);
    }
    printf("\n");
    return 0;
}

As for a reference:
http://stackoverflow.com/questions/1831290/static-variable-initialization
 and
http://stackoverflow.com/questions/3373108/why-are-static-variables-auto-initialized-to-zero,
both of which then reference the C++ standard.


>
> --
> Steven
> --
> https://mail.python.org/mailman/listinfo/python-list
>

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

#58296

In article <mailman.1362.1382460759.18130.python-list@python.org>,
Chris Kaynor  <ckaynor@zindagigames.com> wrote:
>-=-=-=-=-=-
<SNIP>
>Global:
>
>int arr[10];
>int main()
>{
>  int i;
>  for (i = 0; i < 10; i++) {
>    printf("arr[%d] = %d\n", i, arr[i]);
>    }
>    printf("\n");
>    return 0;
>}
>
>As for a reference:
>http://stackoverflow.com/questions/1831290/static-variable-initialization
> and
>http://stackoverflow.com/questions/3373108/why-are-static-variables-auto-initialized-to-zero,
>both of which then reference the C++ standard.


Or even better:

#include<stdio.h>

int arr[] = {1,2,3,4,5,6,7,8};

int main()
{
  int i;
  for (i = 0; i < sizeof(arr)/sizeof(int); i++) {
    printf("arr[%d] = %d\n", i, arr[i]);
    }
    printf("\n");
    return 0;
}

Output:
"
albert@cherry:/tmp$ a.out
arr[0] = 1
arr[1] = 2
arr[2] = 3
arr[3] = 4
arr[4] = 5
arr[5] = 6
arr[6] = 7
arr[7] = 8
"


This is the output of
objdump -x a.out (after stripping)

"
a.out:     file format elf64-x86-64
a.out
architecture: i386:x86-64, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x0000000000400450

....
Lots of segments.

 23 .got.plt      00000030  0000000000600900  0000000000600900  00000900  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 24 .data         00000040  0000000000600940  0000000000600940  00000940  2**5
                  CONTENTS, ALLOC, LOAD, DATA
 25 .bss          00000010  0000000000600980  0000000000600980  00000980  2**3
                  ALLOC
 26 .comment      0000001c  0000000000000000  0000000000000000  00000980  2**0
                  CONTENTS, READONLY
SYMBOL TABLE:
no symbols
"

Look at .data It is CONTENTS LOAD DATA, i.e. it has content
in the executable binary and this is loaded as such into memory
at startup.

You can also ask to dump the content of the sections:

objdump -s a.out


a.out:     file format elf64-x86-64

...

Contents of section .data:
 600940 00000000 00000000 00000000 00000000  ................
 600950 00000000 00000000 00000000 00000000  ................
 600960 01000000 02000000 03000000 04000000  ................
 600970 05000000 06000000 07000000 08000000  ................
Contents of section .comment:
 0000 4743433a 20284465 6269616e 20342e34  GCC: (Debian 4.4
 0010 2e352d38 2920342e 342e3500           .5-8) 4.4.5.



>
>
>>
>> --
>> Steven
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
>-=-=-=-=-=-
>[Alternative: text/html]
>-=-=-=-=-=-
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#57275

On Tue, 22 Oct 2013 16:40:32 +0000, Steven D'Aprano wrote:

> On Tue, 22 Oct 2013 15:39:42 +0000, Grant Edwards wrote:
> 
>>> No, I was thinking of an array. Arrays aren't automatically
>>> initialised in C.
>> 
>> If they are static or global, then _yes_they_are_.  They are zeroed.
> 
> Not that I don't believe you, but do you have a reference for this?
> Because I keep finding references to uninitialised C arrays filled with
> garbage if you don't initialise them.
> 
> Wait... hang on a second...
> 
> /fires up the ol' trusty gcc
> 
> 
> [steve@ando c]$ cat array_init.c
> #include<stdio.h>
> 
> int main()
> {
>   int i;
>   int arr[10];
>   for (i = 0; i < 10; i++) {
>     printf("arr[%d] = %d\n", i, arr[i]);
>     }
>     printf("\n");
>     return 0;
> }
> 
> [steve@ando c]$ gcc array_init.c
> [steve@ando c]$ ./a.out
> arr[0] = -1082002360
> arr[1] = 134513317
> arr[2] = 2527220
> arr[3] = 2519564
> arr[4] = -1082002312
> arr[5] = 134513753
> arr[6] = 1294213
> arr[7] = -1082002164
> arr[8] = -1082002312
> arr[9] = 2527220
> 
> 
> What am I missing here?

What you're missing is that arr[] is an automatic variable.  Put
a "static" in front of it, or move it outside the function (to become
global) and you'll see the difference.

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

#57279

On Tue, 22 Oct 2013 16:53:07 +0000, Frank Miles wrote:

[snip C code]
> What you're missing is that arr[] is an automatic variable.  Put a
> "static" in front of it, or move it outside the function (to become
> global) and you'll see the difference.

Ah, that makes sense. Thanks to everyone who corrected my 
misunderstanding.

Well, actually, no it doesn't. I wonder why C specifies such behaviour? 
Why would you want non-global arrays to be filled with garbage?


-- 
Steven

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

#57281

[Multipart message — attachments visible in raw view] — view raw

On Tue, Oct 22, 2013 at 10:23 AM, Steven D'Aprano <
steve+comp.lang.python@pearwood.info> wrote:

> On Tue, 22 Oct 2013 16:53:07 +0000, Frank Miles wrote:
>
> [snip C code]
> > What you're missing is that arr[] is an automatic variable.  Put a
> > "static" in front of it, or move it outside the function (to become
> > global) and you'll see the difference.
>
> Ah, that makes sense. Thanks to everyone who corrected my
> misunderstanding.
>
> Well, actually, no it doesn't. I wonder why C specifies such behaviour?
> Why would you want non-global arrays to be filled with garbage?
>
>
Its a performance benefit, for cases where you are going to fill the array
from other means, such as from a file or other sources such as literals.
The global and static variables are effectively free to zero due to
standard OS behaviours.

The issue is actually more general than arrays, as the same behavior exists
for all the types in C. Stack and heap variables have undefined value when
initialized, while global and static variables (which are really the same
thing, but with differing lexical scopes) are zero-filled.


>
> --
> Steven
> --
> https://mail.python.org/mailman/listinfo/python-list
>

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

#57282

On 2013-10-22, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> On Tue, 22 Oct 2013 16:53:07 +0000, Frank Miles wrote:
>
> [snip C code]
>> What you're missing is that arr[] is an automatic variable.  Put a
>> "static" in front of it, or move it outside the function (to become
>> global) and you'll see the difference.
>
> Ah, that makes sense. Thanks to everyone who corrected my 
> misunderstanding.
>
> Well, actually, no it doesn't. I wonder why C specifies such
> behaviour? Why would you want non-global arrays to be filled
> with garbage?

Fish(enc)ey.

-- 
Neil Cerutti

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

#57283

On 22 October 2013 18:23, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Tue, 22 Oct 2013 16:53:07 +0000, Frank Miles wrote:
>
> [snip C code]
>> What you're missing is that arr[] is an automatic variable.  Put a
>> "static" in front of it, or move it outside the function (to become
>> global) and you'll see the difference.
>
> Ah, that makes sense. Thanks to everyone who corrected my
> misunderstanding.
>
> Well, actually, no it doesn't. I wonder why C specifies such behaviour?
> Why would you want non-global arrays to be filled with garbage?

It's not that you want them filled with garbage but rather that you
know you will fill them with useful values later and you don't want to
waste time pre-filling them with zeros first. Or perhaps you have some
other way of knowing which values are to be considered initialised.
This is reasonable in some contexts.

OTOH why in particular would you want to initialise them with zeros? I
often initialise arrays to nan which is useful for debugging. It means
that you can see if you made a mistake when you were supposed to have
initialised everything to useful values. In many contexts it would be
difficult to distinguish between a valid zero and a zero because you
haven't yet inserted a value. This kind of error can show up more
quickly if you don't zero the memory since the uninitialised values
will often be out of range for what you expected and will give very
noticeable results (such as a seg-fault).


Oscar

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

#57284

On 22/10/2013 18:23, Steven D'Aprano wrote:
> On Tue, 22 Oct 2013 16:53:07 +0000, Frank Miles wrote:
>
> [snip C code]
>> What you're missing is that arr[] is an automatic variable.  Put a
>> "static" in front of it, or move it outside the function (to become
>> global) and you'll see the difference.
>
> Ah, that makes sense. Thanks to everyone who corrected my
> misunderstanding.
>
> Well, actually, no it doesn't. I wonder why C specifies such behaviour?
> Why would you want non-global arrays to be filled with garbage?
>
Static variables need be initialised only once, whereas auto variables
exist on the stack, so they would need to be initialised repeatedly,
which was considered too expensive, especially as they would be
assigned to before use anyway (hopefully!).

Of course, these days, with our much faster CPUs, we're not so
bothered, and prefer to allocate on the heap.

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

#57299

On 2013-10-22, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> On Tue, 22 Oct 2013 16:53:07 +0000, Frank Miles wrote:
>
> [snip C code]
>> What you're missing is that arr[] is an automatic variable.  Put a
>> "static" in front of it, or move it outside the function (to become
>> global) and you'll see the difference.
>
> Ah, that makes sense. Thanks to everyone who corrected my 
> misunderstanding.
>
> Well, actually, no it doesn't. I wonder why C specifies such behaviour? 
> Why would you want non-global arrays to be filled with garbage?

Firstly, it's not non-global arrays that have undefined contents. 
It's _auto_ arrays that have undefined contents.

void foo(void)
{
  int a[4];   // non-global, _auto_ variable and has undefined contents
}

void bar(void)
{
  static int a[4];  // non-global, _static_ variable initially 0's
}

As to _why_ it's that way, you'd have to ask the guys who decided
that.  I supect it's because zeroing static variables involves very
little run-time overhead, while zeroing auto variables could cause
huge amounts of overhead if that auto variable is declared inside the
innermost of nested loops.  [Presumably a good optimizing compiler
would not zero an auto variable that was always set before it was
referenced, but it takes a lot of smarts for compiler to figure that
out correctly 100% of the time -- probably more smarts than a PDP-11
had room for.]

-- 
Grant Edwards               grant.b.edwards        Yow! Let's send the
                                  at               Russians defective
                              gmail.com            lifestyle accessories!

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

#57492

On 22/10/2013 18:37, Oscar Benjamin wrote:

>
> OTOH why in particular would you want to initialise them with zeros? I
> often initialise arrays to nan which is useful for debugging. It means
> that you can see if you made a mistake when you were supposed to have
> initialised everything to useful values. In many contexts it would be
> difficult to distinguish between a valid zero and a zero because you
> haven't yet inserted a value. This kind of error can show up more
> quickly if you don't zero the memory since the uninitialised values
> will often be out of range for what you expected and will give very
> noticeable results (such as a seg-fault).
>

In his book "Writing Solid Code" Steve Maguire states that he 
initialises with 0xA3 for Macintosh programs, and that Microsoft uses 
0xCC, for exactly the reasons that you describe above.

-- 
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

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

#57518

On Thu, Oct 24, 2013 at 8:40 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> On 22/10/2013 18:37, Oscar Benjamin wrote:
>> OTOH why in particular would you want to initialise them with zeros? I
>> often initialise arrays to nan which is useful for debugging.

Is this some kind of joke?  What has this list become?

-- 
MarkJ
Tacoma, Washington

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

#57523

On Fri, 25 Oct 2013 04:55:43 -0700, Mark Janssen wrote:

> On Thu, Oct 24, 2013 at 8:40 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
>> On 22/10/2013 18:37, Oscar Benjamin wrote:

>>> OTOH why in particular would you want to initialise them with zeros?
>>> I often initialise arrays to nan which is useful for debugging.

> Is this some kind of joke?  What has this list become?

We used to initialize RAM to 0xdeadbeef on CPU reset (and sometimes
calls to free in a debugging environment) for the same reason:  if a
program crashesd, and I saw that value in one of the CPU registers, then
I knew that some part of the program accessed "uninitialized" (or freed)
memory.  That pattern also sticks out like a sore thumb (insert your own
C++/hammer joke here) in a core dump.

That said, I seem to recall that somewhere along the way, ANSI C began
to guarantee that certain static (in the technical sense) values were
initialized to 0, or NULL, or something like that, on program startup,
before any user-level code executed.

Dan

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

#57525

On 25/10/2013 12:55, Mark Janssen wrote:
> On Thu, Oct 24, 2013 at 8:40 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
>> On 22/10/2013 18:37, Oscar Benjamin wrote:
>>> OTOH why in particular would you want to initialise them with zeros? I
>>> often initialise arrays to nan which is useful for debugging.
>
> Is this some kind of joke?  What has this list become?
>

What did *I* write?  Something about real world practical programming 
that a text book theorist such as yourself wouldn't understand.  The 
only snag is you haven't quoted anything that I've written.

-- 
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

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

#57527

On 10/25/13 7:55 AM, Mark Janssen wrote:
> On Thu, Oct 24, 2013 at 8:40 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
>> On 22/10/2013 18:37, Oscar Benjamin wrote:
>>> OTOH why in particular would you want to initialise them with zeros? I
>>> often initialise arrays to nan which is useful for debugging.
> Is this some kind of joke?  What has this list become?
>

It's a useful debugging technique to initialize memory to distinctive 
values that should never occur in real data.  Perhaps it better to say, 
"pre-initialize".  If the program is working correctly, then that data 
will be written over with actual initial values, and you'll never see 
the distinctive values.  But if your program does encounter one of those 
values, it's clear that there's a bug that needs to be fixed.  
Additionally, if you have a number of different distinctive values, then 
the actual value encountered provides a clue as to what might have gone 
wrong.

In an array of floats, initializing to NaN would be very useful, since 
NaNs propagate through calculations, or raise exceptions.

--Ned.

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

#57542

>>>> OTOH why in particular would you want to initialise them with zeros? I
>>>> often initialise arrays to nan which is useful for debugging.
>>
>> Is this some kind of joke?  What has this list become?
>
> It's a useful debugging technique to initialize memory to distinctive values
> that should never occur in real data.

If you're doing this, you're doing something wrong.   Please give me
the hex value for NaN so I can initialize with my array.

-- 
MarkJ
Tacoma, Washington

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

#57548

On 2013-10-25, Mark Janssen <dreamingforward@gmail.com> wrote:
>>>>> OTOH why in particular would you want to initialise them with zeros? I
>>>>> often initialise arrays to nan which is useful for debugging.
>>>
>>> Is this some kind of joke?  What has this list become?
>>
>> It's a useful debugging technique to initialize memory to distinctive
>> values that should never occur in real data.
>
> If you're doing this, you're doing something wrong.

Pardon me if I don't take your word for it.

> Please give me the hex value for NaN so I can initialize with my
> array.

Seriously?  You haven't discovered google and wikepedia yet?

   http://www.google.com/
   http://en.wikipedia.org/   

Assuming you're using IEEE-754, all 1's is a quiet NaN:

   http://en.wikipedia.org/wiki/IEEE_floating_point
   http://en.wikipedia.org/wiki/NaN

If you want a signaling NaN you've got to change one of the bits (see
the above links).

IIRC, the Pascal language required that using unintialized variables
caused an error. intializing FP values to a signalling NaN is a very
convenient way to do that.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm also against
                                  at               BODY-SURFING!!
                              gmail.com            

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

#57543

On 25/10/2013 19:26, Mark Janssen wrote:
>>>>> OTOH why in particular would you want to initialise them with zeros? I
>>>>> often initialise arrays to nan which is useful for debugging.
>>>
>>> Is this some kind of joke?  What has this list become?
>>
>> It's a useful debugging technique to initialize memory to distinctive values
>> that should never occur in real data.
>
> If you're doing this, you're doing something wrong.   Please give me
> the hex value for NaN so I can initialize with my array.
>

It is clear that you know as much about debugging as you do about 
objects and message passing, a summary here for the uninitiated 
http://code.activestate.com/lists/python-ideas/19908/. I can see why the 
BDFL described you as an embarrassment, and if he didn't, he certainly 
should have done.

-- 
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

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

#57544

>>>>>> OTOH why in particular would you want to initialise them with zeros? I
>>>>>> often initialise arrays to nan which is useful for debugging.
>>>>
>>>> Is this some kind of joke?  What has this list become?
>>>
>>> It's a useful debugging technique to initialize memory to distinctive
>>> values that should never occur in real data.
>>
>> If you're doing this, you're doing something wrong.   Please give me
>> the hex value for NaN so I can initialize with my array.
>
> It is clear that you know as much about debugging as you do about objects
> and message passing [...] can see why the
> BDFL described you as an embarrassment, and if he didn't, he certainly
> should have done.

Clearly the python list has been taken over by TheKooks.  Notice he
did not respond to the request.  Since we are talking about digital
computers (with digital memory), I'm really curious what the hex value
for NaN is to initialize my arrays....

All hail chairman Meow.  Dismissed.

-- 
MarkJ
Tacoma, Washington

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

#57546

On Saturday, October 26, 2013 12:15:43 AM UTC+5:30, zipher wrote:
> Clearly the python list has been taken over by TheKooks.  Notice he
> did not respond to the request.  Since we are talking about digital
> computers (with digital memory), I'm really curious what the hex value
> for NaN is to initialize my arrays....

I dont see how thats any more relevant than:
Whats the hex value of the add instruction?

Presumably floating point numbers are used for FP operations
FP operations barf on nans
So a mis-initialized array in which a nan shows up can be easily caught

Yes nans are not one value but a class
http://docs.oracle.com/cd/E19957-01/806-3568/ncg_math.html

but so what?

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

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

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

csiph-web