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

Groups > comp.lang.c > #164046

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

Show all headers | View raw

On Tue, 21 Dec 2021 16:41:27 -0300, Meredith Montgomery wrote:

> 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!

First off, 
  char *argv[]
defines argv as an array of {pointer to char}, so each element of argv
(each argv[something]) contains a pointer.

Now, the pointers may point to various places, and not maintain an ascending order. So
  argv[0] can hold a pointer that points to address 1000
and
  argv[1] can hold a pointer that points to address 500
and this difference does not affect the order or spacing of the array.

In your example,
  argv[0] is located at address 4294954096, and holds a pointer that
  points somewhere
while
  argv[1] is located at address 4294954104, and holds a pointer that
  points somewhere else.

Note that your argv[1] is 8 bytes further along than argv[0]. That
8 bytes is the size of the pointer (and, possibly some padding) that argv[0] holds within itself.

Try this example to see if it makes things clearer:

/* CODE STARTS HERE */
#include <stdio.h>
#include <stdlib.h>


int main(int argc, char *argv[])
{
  printf("argc = %d\n",argc);
  for (int arg = 0; arg < argc; ++arg)
    printf("argv[%d] at %p points to %p, which starts string \"%s\"\n",
           arg,                 /* %d */
           (void *)(&argv[arg]),/* %p */
           (void *)(argv[arg]), /* %p */
           argv[arg]            /* %s */);

  return EXIT_SUCCESS;
}

/* CODE ENDS HERE */


Example execution:
./args one 2 thr33
argc = 4
argv[0] at 0x7ffcc79cc488 points to 0x7ffcc79cd42c, which starts string "./args"
argv[1] at 0x7ffcc79cc490 points to 0x7ffcc79cd433, which starts string "one"
argv[2] at 0x7ffcc79cc498 points to 0x7ffcc79cd437, which starts string "2"
argv[3] at 0x7ffcc79cc4a0 points to 0x7ffcc79cd439, which starts string "thr33"

-- 
Lew Pitcher
"In Skills, We Trust"

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