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

Groups > comp.lang.c > #164047

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

Show all headers | View raw

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.

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), 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.

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.

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.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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