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

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

Arrays sorting!!

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

Contents

  Arrays sorting!! Christopher <info@invalid.invalid> - 2017-06-12 04:55 +0100
    Re: Arrays sorting!! luser droog <luser.droog@gmail.com> - 2017-06-11 21:30 -0700
      Re: Arrays sorting!! bartc <bc@freeuk.com> - 2017-06-12 13:32 +0100
        Re: Arrays sorting!! bartc <bc@freeuk.com> - 2017-06-12 13:48 +0100
          Re: Arrays sorting!! supercat@casperkitty.com - 2017-06-12 07:36 -0700
            Re: Arrays sorting!! David Brown <david.brown@hesbynett.no> - 2017-06-12 21:22 +0200
              Re: Arrays sorting!! supercat@casperkitty.com - 2017-06-12 14:00 -0700
                Re: Arrays sorting!! David Brown <david.brown@hesbynett.no> - 2017-06-12 23:39 +0200
                  Re: Arrays sorting!! "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-12 18:47 -0400
    Re: Arrays sorting!! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-12 12:03 +0100
      Re: Arrays sorting!! "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-12 20:23 +0800
        Re: Arrays sorting!! mark.bluemel@gmail.com - 2017-06-12 07:32 -0700
          Re: Arrays sorting!! "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-12 23:06 +0800
        Re: Arrays sorting!! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-12 16:08 +0100
          Re: Arrays sorting!! "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-12 23:11 +0800
            Re: Arrays sorting!! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-12 16:46 +0100
              Re: Arrays sorting!! "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-13 17:49 +0800
      Re: Arrays sorting!! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-12 15:57 +0100
    Re: Arrays sorting!! Real Troll <Real.Troll@Trolls.com> - 2017-06-12 16:55 -0400

#111988 — Arrays sorting!!

Can anybody tell me why is this array giving me corruption?

/* Program begins */
#include <stdio.h>
#include <time.h>
#include <stdlib.h>

void sort (int a[], int n);

int main (void)
{

	int i, j, k, nums[ 60 ];

	srand( ( int ) time( NULL ) ) ;

	for ( i = 0; i < 60; i++ )
		nums[ i ] = i;

	for ( i = 0 ; i < 60 ; i++ )
	{
		j = ( rand() % 60 ) + 1 ;
		k = nums[ i ] ;
		nums[ i ] = nums[ j ] ;
		nums[ j ] = k ;
	}



	printf( "Six random numbers are: \n") ;
	for ( i = 0 ; i < 6 ; i++ )
		printf("nums[%i] = %i\n", i, nums[i]);
	
	sort (nums, 6);
	printf("\n");
	
	for ( i = 0 ; i < 6 ; i++ )
		printf("nums[%i] = %i\n", i, nums[i]);

	return 0;
}

void sort (int a[], int n)
{
	int i, j, temp;
	for ( i = 0; i < n - 1; ++i )
		for ( j = i + 1; j < n; ++j )
			if ( a[i] > a[j] ) {
				temp = a[i];
				a[i] = a[j];
				a[j] = temp;
			}
}

/* Program ends */

There are just 60 random numbers (1 to 60) out of which I am selecting 6 and sorting them but the corruption occurs in VS2010.

I tried using 61 instead of 60 but the problem doesn't go away!!

I am accessing the numbers using the index numbered 0 to 5 (6 numbers here).

[toc] | [next] | [standalone]

#111990

On Sunday, June 11, 2017 at 10:42:18 PM UTC-5, Christopher wrote:
> Can anybody tell me why is this array giving me corruption?
> 
[...]
> 	int i, j, k, nums[ 60 ];
[...]
> 		j = ( rand() % 60 ) + 1 ;
[...]
> 		nums[ i ] = nums[ j ] ;
> 		nums[ j ] = k ;

Lose the "+ 1". j will sometimes be out of bounds.

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

#112009

On 12/06/2017 05:30, luser droog wrote:
> On Sunday, June 11, 2017 at 10:42:18 PM UTC-5, Christopher wrote:
>> Can anybody tell me why is this array giving me corruption?
>>
> [...]
>> 	int i, j, k, nums[ 60 ];
> [...]
>> 		j = ( rand() % 60 ) + 1 ;
> [...]
>> 		nums[ i ] = nums[ j ] ;
>> 		nums[ j ] = k ;
> 
> Lose the "+ 1". j will sometimes be out of bounds.
> 

Didn't the OP say he tried 61 and the problem was still there?

(Presumably he used nums[61] without changing all the other 60s...)

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

#112010

On 12/06/2017 13:32, bartc wrote:
> On 12/06/2017 05:30, luser droog wrote:
>> On Sunday, June 11, 2017 at 10:42:18 PM UTC-5, Christopher wrote:
>>> Can anybody tell me why is this array giving me corruption?
>>>
>> [...]
>>>     int i, j, k, nums[ 60 ];
>> [...]
>>>         j = ( rand() % 60 ) + 1 ;
>> [...]
>>>         nums[ i ] = nums[ j ] ;
>>>         nums[ j ] = k ;
>>
>> Lose the "+ 1". j will sometimes be out of bounds.
>>
> 
> Didn't the OP say he tried 61 and the problem was still there?
> 
> (Presumably he used nums[61] without changing all the other 60s...)

On second thoughts, that might not matter. The array access can be well 
in bounds, but it's using an element that is not initialised.

Using nums[61] and setting nums[60] to 999999 at the start might confirm 
that on some runs (not all because only 6 elements are displayed, 
although the 6 can be increased for test purposes. If 999999 sometimes 
appears, then there's a bug).

-- 
bartc

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

#112021

On Monday, June 12, 2017 at 7:49:00 AM UTC-5, Bart wrote:
> On second thoughts, that might not matter. The array access can be well 
> in bounds, but it's using an element that is not initialised.

Under C11, if an automatic-duration object is not initialized but its address
is taken, and if the type is one without any trap representations, conforming
implementations are required to ensure that reading the variable will yield
some (possibly arbitrary) value of that type.

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

#112074

On 12/06/17 16:36, supercat@casperkitty.com wrote:
> On Monday, June 12, 2017 at 7:49:00 AM UTC-5, Bart wrote:
>> On second thoughts, that might not matter. The array access can be well
>> in bounds, but it's using an element that is not initialised.
> 
> Under C11, if an automatic-duration object is not initialized but its address
> is taken, and if the type is one without any trap representations, conforming
> implementations are required to ensure that reading the variable will yield
> some (possibly arbitrary) value of that type.
> 

6.7.9 (Initialization):

"If an object that has automatic storage duration is not initialized 
explicitly, its value is indeterminate."


Annex J.2 has a list of undefined behaviour, including:

"the value of an object with automatic storage duration is used while it 
is indeterminate (6.2.4, 6.7.9, 6.8)."



To me, that sounds like using the value of an uninitialised automatic 
storage object, before it has been written, is undefined behaviour. 
This appears to be the case whether you read it directly, or if you take 
a pointer and read through that.

Can you give the reference in C11 for your interpretation of something 
different?

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

#112086

On Monday, June 12, 2017 at 2:22:57 PM UTC-5, David Brown wrote:
> On 12/06/17 16:36, supercat wrote:
> > Under C11, if an automatic-duration object is not initialized but its address
> > is taken, and if the type is one without any trap representations, conforming
> > implementations are required to ensure that reading the variable will yield
> > some (possibly arbitrary) value of that type.
> > 
> 
> 6.7.9 (Initialization):
> 
> "If an object that has automatic storage duration is not initialized 
> explicitly, its value is indeterminate."
> 
> 
> Annex J.2 has a list of undefined behaviour, including:
> 
> "the value of an object with automatic storage duration is used while it 
> is indeterminate (6.2.4, 6.7.9, 6.8)."
>
> To me, that sounds like using the value of an uninitialised automatic 
> storage object, before it has been written, is undefined behaviour. 
> This appears to be the case whether you read it directly, or if you take 
> a pointer and read through that.
>
> Can you give the reference in C11 for your interpretation of something 
> different?

The descriptions in Annex J2 are sometimes over-generalized, listing things
which will *often*, though not always, invoke UB.

See section 6.3.2.1:

- If the lvalue designates an object of automatic storage duration
  that could have been declared with the register storage class (never
  had its address taken), and that object is uninitialized (not declared
  with an initializer and no assignment to it has been performed prior
  to use), the behavior is undefined.

Given "int arr[60]", the expression arr[i] is defined as taking the address
of arr (as an int*), adding i, and then dereferencing the resulting pointer.

If the type of the array had trap representations, then accessing an
Indeterminate Value of that type would yield Undefined Behavior regardless
of the object's storage duration, but the vast minority of implementations
specify that "int" has no trap representations.

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

#112091

On 12/06/17 23:00, supercat@casperkitty.com wrote:
> On Monday, June 12, 2017 at 2:22:57 PM UTC-5, David Brown wrote:
>> On 12/06/17 16:36, supercat wrote:
>>> Under C11, if an automatic-duration object is not initialized but its address
>>> is taken, and if the type is one without any trap representations, conforming
>>> implementations are required to ensure that reading the variable will yield
>>> some (possibly arbitrary) value of that type.
>>>
>>
>> 6.7.9 (Initialization):
>>
>> "If an object that has automatic storage duration is not initialized
>> explicitly, its value is indeterminate."
>>
>>
>> Annex J.2 has a list of undefined behaviour, including:
>>
>> "the value of an object with automatic storage duration is used while it
>> is indeterminate (6.2.4, 6.7.9, 6.8)."
>>
>> To me, that sounds like using the value of an uninitialised automatic
>> storage object, before it has been written, is undefined behaviour.
>> This appears to be the case whether you read it directly, or if you take
>> a pointer and read through that.
>>
>> Can you give the reference in C11 for your interpretation of something
>> different?
> 
> The descriptions in Annex J2 are sometimes over-generalized, listing things
> which will *often*, though not always, invoke UB.
> 

It seems to me to be pretty clear: "The behavior is undefined in the 
following circumstances:".  It lists things that whose behaviour is not 
defined by the C standard.  It is quite possible that some cases have 
their behaviour defined in other places (like implementation 
documentation) - just not defined in the C standard.

> See section 6.3.2.1:
> 
> - If the lvalue designates an object of automatic storage duration
>    that could have been declared with the register storage class (never
>    had its address taken), and that object is uninitialized (not declared
>    with an initializer and no assignment to it has been performed prior
>    to use), the behavior is undefined.

How do you get from that to the idea that if you have taken its address, 
then reading the uninitialised object gives a value of that type?  That 
paragraph says /nothing/ about what happens when you read from an 
uninitialised object whose address has been taken.  Nothing else in 
6.3.2.1 says so either.  There is no definition of the behaviour - 
therefore, the behaviour is undefined just as surely as if the standards 
said so explicitly (see section 4).

> 
> Given "int arr[60]", the expression arr[i] is defined as taking the address
> of arr (as an int*), adding i, and then dereferencing the resulting pointer.
> 
> If the type of the array had trap representations, then accessing an
> Indeterminate Value of that type would yield Undefined Behavior regardless
> of the object's storage duration, but the vast minority of implementations
> specify that "int" has no trap representations.
> 

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

#112095

On 06/12/2017 05:39 PM, David Brown wrote:
> On 12/06/17 23:00, supercat@casperkitty.com wrote:
...
>> The descriptions in Annex J2 are sometimes over-generalized, listing things
>> which will *often*, though not always, invoke UB.
>>
>
> It seems to me to be pretty clear: "The behavior is undefined in the
> following circumstances:".  It lists things that whose behaviour is not
> defined by the C standard.

Annex J says (right under the title) that it is "(Informative)". 
Informative text is intended to summarize the meaning of normative text. 
If it says anything that differs from what the normative text says, it's 
simply wrong - informative text cannot override normative text. It's not 
uncommon for informative text to be less precisely worded than the 
normative text whose meaning it is explaining; that imprecision doesn't 
change that meaning, it just describes it somewhat inaccurately.

...
>> See section 6.3.2.1:
>>
>> - If the lvalue designates an object of automatic storage duration
>>    that could have been declared with the register storage class (never
>>    had its address taken), and that object is uninitialized (not declared
>>    with an initializer and no assignment to it has been performed prior
>>    to use), the behavior is undefined.
>
> How do you get from that to the idea that if you have taken its address,
> then reading the uninitialised object gives a value of that type?

"never had its address taken" is a pre-condition for the applicability 
of 6.3.2.1. Since the behavior is defined elsewhere unless that sentence 
applies, taking the address is sufficient o make the behavior defined.

> ... That
> paragraph says /nothing/ about what happens when you read from an
> uninitialised object whose address has been taken.   Nothing else in
> 6.3.2.1 says so either. ...

Actually, the relevant words occur earlier in that same paragraph (cited 
below). You might need some supporting citations before you understand 
how those words are applicable, so I'll provide those citations first.

> ... There is no definition of the behaviour -
> therefore, the behaviour is undefined just as surely as if the standards
> said so explicitly (see section 4).

6.8p3 "... The initializers of objects that have automatic storage 
duration, and the variable length array declarators of ordinary 
identifiers with block scope, are evaluated and the values are stored in 
the objects (including storing an indeterminate value in objects without 
an initializer) each time the declaration is reached in the order of 
execution, ...".

Thus, the indeterminate value that an uninitialized variable has is 
considered to have been stored in it whenever the point where it is 
declared is reached in the order of execution. Note the following 
definitions:

3.19.2p1: indeterminate value
"either an unspecified value or a trap representation"

3.19.3p1: unspecified value
"valid value of the relevant type where this International Standard 
imposes no requirements on which value is chosen in any instance"

The standard defines several types that are guaranteed to have no trap 
representations. In addition, code that's not require to be portable can 
rely upon the documentation of a particular implementation that 
guarantees that a given type has no trap values, on that implementation. 
If a trap representation can be ruled out for a given type, then an 
indeterminate value of that type is necessarily an unspecified value, 
and therefore a valid one.

The following clause defines the behavior when an lvalue expression 
designating such an object gets evaluated:

6.3.2.1p2 "Except when [several cases that don't apply here], an lvalue 
that does not have array type is converted to the value stored in the 
designated object ...".

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

#112001

Christopher <info@invalid.invalid> writes:

> Can anybody tell me why is this array giving me corruption?

OK, that's been done.  But let me comment o the algorithm...

> /* Program begins */
> #include <stdio.h>
> #include <time.h>
> #include <stdlib.h>
>
> void sort (int a[], int n);
>
> int main (void)
> {
>
> 	int i, j, k, nums[ 60 ];
>
> 	srand( ( int ) time( NULL ) ) ;
>
> 	for ( i = 0; i < 60; i++ )
> 		nums[ i ] = i;
>
> 	for ( i = 0 ; i < 60 ; i++ )
> 	{
> 		j = ( rand() % 60 ) + 1 ;
> 		k = nums[ i ] ;
> 		nums[ i ] = nums[ j ] ;
> 		nums[ j ] = k ;
> 	}

Do a search for Fisher-Yates shuffle.  It's only a small variation on
yours but, in its modern form, allows you to stop shuffling when you
have the six elements you need.

Another option is to use Floyd's choose n from m algorithm:

  void choose(int choose_n, int from_m, int *chosen)
  {
       for (int i = 0, j = 0; j < choose_n; i++)
            if (true_with_probability(choose_n - j, from_m - i))
                 chosen[j++] = i;
  }

The function

  bool true_with_probability(int n, int m);

returns 1 with probability n/m.

<snip>
-- 
Ben.

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

#112007

On 12/6/2017 7:03 PM, Ben Bacarisse wrote:
> Do a search for Fisher-Yates shuffle.  It's only a small variation on
> yours but, in its modern form, allows you to stop shuffling when you
> have the six elements you need.

Why not just simple qsort() aka quick sort?

-- 
   @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
  / v \  Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
   ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

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

#112020

On Monday, 12 June 2017 13:24:00 UTC+1, Mr. Man-wai Chang  wrote:
> On 12/6/2017 7:03 PM, Ben Bacarisse wrote:
> > Do a search for Fisher-Yates shuffle.  It's only a small variation on
> > yours but, in its modern form, allows you to stop shuffling when you
> > have the six elements you need.
> 
> Why not just simple qsort() aka quick sort?

Because Ben is suggesting how to populate the list, not how to sort it?

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

#112029

On 12/6/2017 10:32 PM, mark.bluemel@gmail.com wrote:
> On Monday, 12 June 2017 13:24:00 UTC+1, Mr. Man-wai Chang  wrote:
>> On 12/6/2017 7:03 PM, Ben Bacarisse wrote:
>>> Do a search for Fisher-Yates shuffle.  It's only a small variation on
>>> yours but, in its modern form, allows you to stop shuffling when you
>>> have the six elements you need.
>>
>> Why not just simple qsort() aka quick sort?
> 
> Because Ben is suggesting how to populate the list, not how to sort it?
> 

So the subject was wrong? I saw the word "sort", Excuse me. ;)

-- 
   @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
  / v \  Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
   ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

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

#112031

"Mr. Man-wai Chang" <toylet.toylet@gmail.com> writes:

> On 12/6/2017 7:03 PM, Ben Bacarisse wrote:
>> Do a search for Fisher-Yates shuffle.  It's only a small variation on
>> yours but, in its modern form, allows you to stop shuffling when you
>> have the six elements you need.
>
> Why not just simple qsort() aka quick sort?

Because sorting has nothing to do with what I was commenting on!

I was (a) suggesting how to do less shuffling; and (b) suggesting how
to avoid shuffling and sorting altogether.

-- 
Ben.

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

#112033

On 12/6/2017 11:08 PM, Ben Bacarisse wrote:
> 
> Because sorting has nothing to do with what I was commenting on!
> 
> I was (a) suggesting how to do less shuffling; and (b) suggesting how
> to avoid shuffling and sorting altogether.

I had a similar problem when writing a simple tool to analyze the files 
and folders in a hard disk.

Your *subject* should be more accurate then, pardon my ignorance.

-- 
   @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
  / v \  Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
   ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

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

#112040

"Mr. Man-wai Chang" <toylet.toylet@gmail.com> writes:

> On 12/6/2017 11:08 PM, Ben Bacarisse wrote:
>>
>> Because sorting has nothing to do with what I was commenting on!
>>
>> I was (a) suggesting how to do less shuffling; and (b) suggesting how
>> to avoid shuffling and sorting altogether.
>
> I had a similar problem when writing a simple tool to analyze the
> files and folders in a hard disk.
>
> Your *subject* should be more accurate then, pardon my ignorance.

Then why did you not change it when you replied about sorting?  Oh, I
know, because you've just made up the idea that the subject should
reflect the emphasis of every single reply!

(I am reluctant to change the subject of a post because some newsreaders
collect threads by subject and I rarely want to bread the thread.)

-- 
Ben.

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

#112103

On 12/6/2017 11:46 PM, Ben Bacarisse wrote:
> 
> Then why did you not change it when you replied about sorting?  Oh, I
> know, because you've just made up the idea that the subject should
> reflect the emphasis of every single reply!

If the subject didn't summarize the message content, why bother to have 
a subject?

-- 
   @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
  / v \  Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
   ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

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

#112028

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>Another option is to use Floyd's choose n from m algorithm:
>
>   I was not able to find it under this name.
>
>   Knuth gives something similar as "Algorithm S" in 3.4.2 and
>   reportedly credits C. T. Fan, M. E. Muller, and I. Rezucha
>   (1962) and T. G. Jones (1962).

Ah, OK.  I associate it with Floyd, but that's from, I think, a
Programming Pearls article where Bentley may not have dug out the proper
attribution.  I don't really want to call it that Fan, Muller, Rezucha,
Jones algorithm, but I've got no excuse not to now!

<snip>
-- 
Ben.

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

#112085

I've changed a bit in your code and this works on my machine:
(I can't comment on the quality of your sort code because it works so 
keep it as it is!!).

I inserted some printf after each for loop to understand what exactly is 
going on.  It looks like you are trying to get unique numbers by 
populating the array and then generating the random indexes to pick 6 
numbers from 60.

I have also sequenced the array so that it starts from 1 (not zero) as I 
am used to Delphi and so I decided to keep it as in delphi.  I like 
counting from 1 !!!!!

/* Program begins */
#include <stdio.h>
#include <time.h>
#include <stdlib.h>

void sort (int a[], int n);

int main (void)
{
     int i, j, k, Nums[ 61 ];

     srand( ( int ) time( NULL ) ) ;

     for ( i = 1; i < 61; i++ )
         Nums[ i ] = i;

     for ( i = 1 ; i < 61 ; i++ )
     {
         j = ( rand() % 60 ) + 1 ;
         k = Nums[ i ] ;
         Nums[ i ] = Nums[ j ] ;
         Nums[ j ] = k ;
     }

     printf( "Six random numbers are: \n") ;
     for ( i = 1 ; i < 7 ; i++ )
         printf("Nums[%i] = %i\n", i, Nums[i]);

     sort (Nums, 7);
     printf("\n");

     for ( i = 1 ; i < 7 ; i++ )
         printf("Nums[%i] = %i\n", i, Nums[i]);

     return 0;
}

void sort (int a[], int n)
{
     int i, j, temp;
     for ( i = 0; i < n - 1; ++i )
         for ( j = i + 1; j < n; ++j )
             if ( a[i] > a[j] ) {
                 temp = a[i];
                 a[i] = a[j];
                 a[j] = temp;
             }
}

/* Program ends */



On 12/06/2017 04:55, Christopher wrote:
>
> Can anybody tell me why is this array giving me corruption?
>
> /* Program begins */
> #include <stdio.h>
> #include <time.h>
> #include <stdlib.h>
>
> void sort (int a[], int n);
>
> int main (void)
> {
>
>     int i, j, k, nums[ 60 ];
>
>     srand( ( int ) time( NULL ) ) ;
>
>     for ( i = 0; i < 60; i++ )
>         nums[ i ] = i;
>
>     for ( i = 0 ; i < 60 ; i++ )
>     {
>         j = ( rand() % 60 ) + 1 ;
>         k = nums[ i ] ;
>         nums[ i ] = nums[ j ] ;
>         nums[ j ] = k ;
>     }
>
>
>
>     printf( "Six random numbers are: \n") ;
>     for ( i = 0 ; i < 6 ; i++ )
>         printf("nums[%i] = %i\n", i, nums[i]);
>
>     sort (nums, 6);
>     printf("\n");
>
>     for ( i = 0 ; i < 6 ; i++ )
>         printf("nums[%i] = %i\n", i, nums[i]);
>
>     return 0;
> }
>
> void sort (int a[], int n)
> {
>     int i, j, temp;
>     for ( i = 0; i < n - 1; ++i )
>         for ( j = i + 1; j < n; ++j )
>             if ( a[i] > a[j] ) {
>                 temp = a[i];
>                 a[i] = a[j];
>                 a[j] = temp;
>             }
> }
>
> /* Program ends */
>
> There are just 60 random numbers (1 to 60) out of which I am selecting 
> 6 and sorting them but the corruption occurs in VS2010.
>
> I tried using 61 instead of 60 but the problem doesn't go away!!
>
> I am accessing the numbers using the index numbered 0 to 5 (6 numbers 
> here).
>

[toc] | [prev] | [standalone]

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

csiph-web