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

Groups > comp.lang.c > #164053

Re: isn't an array a contiguous region of memory?

Show all headers | View raw

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Meredith Montgomery <mmontgomery@levado.to> writes:
>> For this question, keep in mind that I'm running MSYS2.  (I don't know if
>> it is relevant at all, though.)
>>
>> My idea of an array is a contiguous region of memory.  But I was totally
>> surprised what I saw today and I can't make any sense of this.  Here's
>> what I did.  I wrote the program below, which produced the executable
>> argv.exe.  I renamed it to a.exe and ran it as ``./a.exe a bc d''.  I'm
>> very surprised by the memory location 6446082752 being an integer
>> greater than 6446078248.  As you can see in the source code, the first
>> number is &argv[0] and the second is &argv[1].  In my mind, the latter
>> should be *always* greater than the former.
>>
>> --8<---------------cut here---------------start------------->8---
>> %./a.exe a bc d
>> we have 4 arguments
>> argv[0] = ./a
>> argv[1] = a
>> argv[2] = bc
>> argv[3] = d
>> 6446082752 -> . = 46
>> 6446078248 -> a = 97
>> --8<---------------cut here---------------end--------------->8---
>>
>> I need to explain a detail about this output.  In MSYS2, even though the
>> shell prepares the argv of a.exe with argv[0] = "./a.exe", we really
>> only see "./a" in the output.  I tried the program off of MSYS2 --- that
>> is, compiling running it through cmd.exe, that is, without msys-2.0.dll
>> --- and this effect does not happen.  I'm saying this because maybe
>> msys-2.0.dll has something to do with this.  If that's the case,
>> nevermind the question --- I'd go and ask in some MinGW group, wherever
>> it may be.
>>
>> (*) Source code
>>
>> #include <stdio.h>
>>
>> int main(int argc, char *argv[]) {
>>   printf("we have %d arguments\n", argc);
>>
>>   for (int i = 0; i < argc; ++i) 
>>     printf("argv[%d] = %s\n", i, argv[i]);
>>
>>   printf("%lu -> %c = %d\n", 
>>      (unsigned long) &argv[0], argv[0][0], argv[0][0]);
>>   printf("%lu -> %c = %d\n", 
>>      (unsigned long) &argv[1], argv[1][0], argv[1][0]);
>>   return 0;
>> }
>>
>> %make argv
>> gcc -Wall -x c -g -std=c99 -pedantic-errors    argv.c   -o argv
>>
>> %mv argv.exe a.exe
>> %
>>
>> I think the renaming has nothing to do with the question.  I'm only
>> showing that because that's what I did when I got the strange output
>> above.
>>
>> I can't seem to reproduce that situation.
>>
>> When I run it right now, for instance, I see the sensible output:
>>
>> %./a.exe a bc d
>> we have 4 arguments
>> argv[0] = ./a
>> argv[1] = a
>> argv[2] = bc
>> argv[3] = d
>> 4294954096 -> . = 46
>> 4294954104 -> a = 97
>> %
>>
>> It was counting bytes here that I conjectured that mysys-2.0.dll must be
>> erasing the ".exe" off of "./a.exe" because you can see that &argv[0] is
>> at 4294954096 but &argv[1] is at 4294954104.
>>
>> I'll appreciate any insights you might have.  Thank you!
>
> That's odd.

Indeed.  I was confused and posted a no-problem.  Sorry about that.

> argv is of type char**.  It points to the initial element of an array of
> char* elements.  Yes, arrays are contiguous chunks of memory, and yes,
> &argv[1] is strictly greater than &argv[0].
>
> Assuming that char** is the same size as unsigned long (please check
> that, I don't know whether it's true under MSYS2), 

Over here it is.  I'm running a 64-bit MSYS2.

%cat sizes.c | grep 'unsigned long'
  printf("%3ld is the size of unsigned long int\n", sizeof (unsigned long int));
  printf("%3ld is the size of unsigned long\n", sizeof (unsigned long));
  printf("%3ld is the size of unsigned long long\n", sizeof (unsigned long long));

%./sizes.exe | grep 'unsigned long'
  8 is the size of unsigned long int
  8 is the size of unsigned long
  8 is the size of unsigned long long
%

> and assuming a typical addressing scheme (which is a safe assumption
> given your environment), I can't explain the initial output you got.
> My only guess is that you modified the code accidentally saw the
> output of a program that's different from the one you showed us.  The
> fact that you can't reproduce the behavior tends to support that.

Lol.  You got that totally right.

> Or it might be a mismatch between pointer sizes and unsigned long.  If
> you want to print address values I recommend using "%p" and casting to
> void*.  The result is typically in hexadecimal, which I think most
> people will find clearer -- and it won't lose information as converting
> to an integer might.

It's clearer indeed, but not when I'm counting bytes one by one.  It's
harder for me to count in hex than it is in decimal.

> The truncation of "a.exe" to "a" shouldn't be relevant.  argv is still a
> pointer object pointing to the initial element of an array object.  The
> transformation of "./a.exe" to "./a" would happen before argv is populated.

That makes sense.

Thanks!  Sorry about the no-problem and false alarm.

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

Thread

isn't an array a contiguous region of memory? Meredith Montgomery <mmontgomery@levado.to> - 2021-12-21 16:41 -0300
  Re: isn't an array a contiguous region of memory? scott@slp53.sl.home (Scott Lurndal) - 2021-12-21 20:10 +0000
    Re: isn't an array a contiguous region of memory? scott@slp53.sl.home (Scott Lurndal) - 2021-12-21 20:13 +0000
  Re: isn't an array a contiguous region of memory? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-12-21 20:19 +0000
    Re: isn't an array a contiguous region of memory? Meredith Montgomery <mmontgomery@levado.to> - 2021-12-21 21:43 -0300
  Re: isn't an array a contiguous region of memory? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-12-21 12:22 -0800
    Re: isn't an array a contiguous region of memory? Meredith Montgomery <mmontgomery@levado.to> - 2021-12-21 21:48 -0300
  Re: isn't an array a contiguous region of memory? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-12-22 16:38 -0800
    Irreproducible results (Was: isn't an array a contiguous region of memory?) gazelle@shell.xmission.com (Kenny McCormack) - 2021-12-23 12:46 +0000
      Re: Irreproducible results Meredith Montgomery <mmontgomery@levado.to> - 2021-12-25 21:57 -0300

csiph-web