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!

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!

First off, it's generally easier to work with hexadecimal memory
addresses.

Second off, argv is an array of pointers.

argv (when argc = 3):
+==============================+
| Pointer to array of char | argv[0] - usually program name/path
+------------------------------+
| Pointer to array of char | argv[1] - first argument
+------------------------------+
| Pointer to array of char | argv[2] - second argument
+------------------------------+

$ ./a.out jefferson lloyd

argv[0] will point to the array of characters containing './a.out'
argv[1] will point to the array of characters containing 'jefferson'
argv[2] will point to the array of characters containing 'lloyd'

argv[1][2] will point to the single character 'f'.
argv[2][4] will point to the single character 'd'.
argv[2][5] will point to the nul terminator character (i.e. '\0').

scott@slp53.sl.home (Scott Lurndal) 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.)

>>%./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, it's generally easier to work with hexadecimal memory
>addresses.
>
>Second off, argv is an array of pointers.
>
>argv (when argc = 3):
>+==============================+
>| Pointer to array of char | argv[0] - usually program name/path
>+------------------------------+
>| Pointer to array of char | argv[1] - first argument
>+------------------------------+
>| Pointer to array of char | argv[2] - second argument
>+------------------------------+
>
>$ ./a.out jefferson lloyd
>
>argv[0] will point to the array of characters containing './a.out'
>argv[1] will point to the array of characters containing 'jefferson'
>argv[2] will point to the array of characters containing 'lloyd'
>
>argv[1][2] will point to the single character 'f'.
>argv[2][4] will point to the single character 'd'.
>argv[2][5] will point to the nul terminator character (i.e. '\0').

On your system (64-bit), pointers are 8-bytes. Hence the 8-byte (sizeof(const char **)) offset
between the address of argv[0] and argv[1].

'%p' is the printf formatting sequence used for pointers.

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"

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 */

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:

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

[...]

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

[...]

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

I think you're showing me that the addresses of each position in the
array are really in memory-ascending-order, but the values in each array
bucket (say), could be any numbers at all. That makes perfect sense.

Wait. I did not present the problem properly. But your answer is the
answer that I was looking for anyhow. I was confused --- I thought that
&argv[0] and &argv[1] would be the same values as argv[0] and argv[1].
You know that's not true. When I presented the difficulty here I did
not realized that I had changed the program to print &argv[0] and
&argv[1] --- and that explains why I couldn't reproduce ``the problem''
because, indeed, to reproduce it I must write argv[0] and argv[1], two
addresses that can totally be any numbers at all. Order is back in the
house. I apologize for the mess.

> Try this example to see if it makes things clearer:

It did! Thanks so much.

[...]

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.

On 12/21/2021 11:41 AM, Meredith Montgomery wrote:
>
> 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.
>

Yes, it should be.

The first result you quoted makes no sense. The only possible
explanation is that you are most certainly making something up in the
first quoted output. Yes, it is possible that `unsigned long` is too
narrow to represent a pointer value on your platform, but it still
wouldn't normally produce the result you quoted.

Meanwhile, the second result you quoted makes perfect sense.

So, yes, an array _is_ a contiguous region of memory and `&argv[1]` is
always greater than `&argv[0]`. And next time you want to convert a
pointer value to an integer, please use `uintptr_t` (and `PRIuPTR` to
print it). This will eliminate this additional and completely
unnecessary source of confusion.

--
Best regards,
Andrey Tarasevich

In article <sq0gdk$lnu$1@dont-email.me>,
Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
....
>Yes, it should be.
>
>The first result you quoted makes no sense. The only possible
>explanation is that you are most certainly making something up.

Someday, someone is going to post the following C program:

int main(void) { printf("2+2 = %d\n",2+2); }

and state that the output he gets from compiling and running this program is:

2+2 = 5

And then we are all going to spend much time and many responses trying both to
figure out how he got that result -- and explaining to him that that result is
impossible and must be due to a cut-and-paste error.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/GodDelusion

gazelle@shell.xmission.com (Kenny McCormack) writes:

> In article <sq0gdk$lnu$1@dont-email.me>,
> Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
> ...
>>Yes, it should be.
>>
>>The first result you quoted makes no sense. The only possible
>>explanation is that you are most certainly making something up.
>
> Someday, someone is going to post the following C program:
>
> int main(void) { printf("2+2 = %d\n",2+2); }
>
> and state that the output he gets from compiling and running this program is:
>
> 2+2 = 5
>
> And then we are all going to spend much time and many responses trying both to
> figure out how he got that result -- and explaining to him that that result is
> impossible and must be due to a cut-and-paste error.

Yes. But this is what happens to the novice. If the person has very
little experience with arithmetic --- if that were possible ---,
something literally as you describe could happen. If I had a clue about
what I was looking at, I would have realized that I must have been
confused --- and would be much more careful in posting something like
that. But, yes, I wouldn't blame you for getting annoyed, say.