Peculiar g++ warning ??

[Rick C. Hodgin]

Why does g++ generate this warning?

----[ Start ]-----

#include <stdio.h>

void test_function(int* tnX)
{
*tnX++; // Warning "value computed is not used [-Wunused-value]"
}

int main(int argc, char* argv[])
{
int lnI, tnLevel;

for (lnI = 0, tnLevel = 0; lnI < 10; lnI++)
test_function(&tnLevel);

printf("%u\n", tnLevel);
return(0);
}

----[ End ]-----

I would think g++ would suppress this particular warning because the
data being updated was passed in as a parameter, which means it is
updating something external to itself.

I would expect it to warn something else, like:

"value computed is not used locally"
^^^^^^^

Best regards,
Rick C. Hodgin

[Christopher Pisz]

Yucky C style code, making it error prone.

What do you think *tnX++ is doing? What is the operator precedence
there? I'd look it up (I just did) and it means bad things for that code.

This has worse problems than the warning.


Why not:

#include <iostream>

void test_function(int & tnX)
{
++tnX;

}

int main(int argc, char* argv[])
{

for (int lnI = 0, int tnLevel = 0; lnI < 10; ++lnI)
{
test_function(&tnLevel);
}

std::cout << tnLevel << std::endl;
return 0;
}


or:


#include <iostream>

int test_function(const int tnX)
{
return ++tnX;

}

int main(int argc, char* argv[])
{

for (int lnI = 0, int tnLevel = 0; lnI < 10; ++lnI)
{
test_function(&tnLevel);
}

std::cout << tnLevel << std::endl;
return 0;
}


or if you must use printf:


#include <cstdio>

int test_function(const int tnX)
{
++tnX;

}

int main(int argc, char* argv[])
{

for (int lnI = 0, int tnLevel = 0; lnI < 10; ++lnI)
{

test_function(&tnLevel);
}

printf("%u\n", tnLevel);

return 0;
}



and why wrap the return value in parenthesis?
return (0)....
Are you telling the compiler, "Hey! You better figure out what zero
means before you return it?"

[Rick C. Hodgin]

On Thursday, October 30, 2014 5:14:51 PM UTC-4, Christopher Pisz wrote:
> Yucky C style code, making it error prone.
>
> What do you think *tnX++ is doing?

Increasing the int pointed to by tnX. I see from your cue below,
and in looking at the disassembly, that it is not, hence the warning.

> What is the operator precedence there? I'd look it up (I just did)
> and it means bad things for that code.

It disassembles in GDB to this:

0x004016b0 push ebp
0x004016b1 mov ebp,esp
0x004016b3 int3 // Breakpoint added
0x004016b4 mov eax,DWORD PTR [ebp+0x8] // Read tnX
0x004016b7 add eax,0x4 // Increase by sizeof(int)
0x004016ba mov DWORD PTR [ebp+0x8],eax // Store tnX
0x004016bd pop ebp
0x004016be ret

That's why. Thank you. Fixed. :-)

> Why not:

> void test_function(int & tnX)
> {
> ++tnX;
> }
>
> int main(int argc, char* argv[])
> {
> for (int lnI = 0, int tnLevel = 0; lnI < 10; ++lnI)
> test_function(&tnLevel);
>
> std::cout << tnLevel << std::endl;
> return 0;
> }

To answer your question, I don't like using parameters of the form
int& because they hide the underlying operation in a line-by-line
examination of the source code.

I don't like that because it leads to confusion.

> and why wrap the return value in parenthesis?
> return (0)....
> Are you telling the compiler, "Hey! You better figure out what zero
> means before you return it?"

I prefer to put return values in parenthesis because it makes it easier
for me to read. I don't know why. It's also the same reason I
vertically align everything in my code to an almost obsessive degree.

:-)

[jacob navia]

Le 30/10/2014 22:14, Christopher Pisz a écrit :
> Yucky C style code, making it error prone.

Yeah of course "C style". You can't help it.

Each time you see a bug in C++ code it is "C style" bug.

Even if it is 100% LEGAL C++ CODE!

The code has an error. Yes. But it is not necessary nor even justified
to go on with your "anti C " campaign.

[Christopher Pisz]

(good)C++ programmers don't use #include <stdio.h>, (most)C programmers do.

(good) C++ programmers don't usually pass raw pointers to public methods
or global functions, (most) C programmers do

(good) C++ programmers certainly would check if the pointer was null
before using it, (most) C programmers rely on foreknowledge and would
say, "Well, we just know the pointer has to be initialized before using
it", that's the way this API works.

This was a very good example of how C style code creates unexpected
errors. If he has passed the int by reference or by one of the many C++
constructs to manage pointers, then the error would have never occurred.

and you can see by his responses to why he didn't pass it by reference
and why he returns (0) instead of returning 0, that he is a C style
programmer, because he chalks it up to his personal preference and as is
the case all too often with C style code, that personal preference made
the code more error prone.

When "my preference" > "maintainability" we have a problem.

[Christopher Pisz]

On 10/30/2014 4:22 PM, Martin Shobe wrote:
> On 10/30/2014 3:42 PM, Rick C. Hodgin wrote:

SNIP

> The '++' operator takes precedence over the '*' operator so the line in question

True.

> ....takes the value of tnX, increments it, returns the old value of tnX,
> dereferences tnX, and discards the result.

Disagree.

tnX is a pointer. Operator ++ on a pointer is going to increment the
pointer. The pointer is now pointing to memory that the method has no
business looking at. Then we are dereferencing that memory and doing
nothing with it.

am I wrong?

[Barry Schwarz]

Yes, you are wrong. It is true that the ++ post-increment operator
increments the value of its operand. However, that incremented value
does not participate in any other operations until a sequence point is
reached. The ++ post-increment operator evaluates to the
un-incremented value of its operand. The incrementing is often
referred to as a side affect.

a = 5;
b = a++;
c = ++a;

b will be 5. c and a will both be 7.

--
Remove del for email

[Christopher Pisz]

boo, I hate being wrong. but realized that as soon as I saw the response
:P postfix...5 o clock...brain tired.

[Luca Risolia]

Why don't you try?

int a[2] = {0, 1};
int* tnX = a;
assert(*tnX++ == 0);

[Rick C. Hodgin]

On Thursday, October 30, 2014 6:27:10 PM UTC-4, Christopher Pisz wrote:
> and you can see by his responses to why he didn't pass it by reference
> and why he returns (0) instead of returning 0, that he is a C style

> programmer....

I am a C-style programmer. I am currently working on development of
a new compiler somewhere between C and C++ called RDC (Rapid Development
Compiler).

I asked this in the C++ groups because I was using g++ to compile my
project. I was surprised by your response. You could've answered my
question by replying:

"The order of precedence is causing the pointer to be updated,
and not the value being pointed to."

That would've been singularly helpful.

FWIW, the example I gave was a minimally contrived example to
demonstrate the issue I was having. It was not intended to be
fantastically beautiful, but to demonstrate the same warning I
was getting. And I do appreciate your help. It's obvious in
retrospect. :-)

[Melzzzzz]

On Thu, 30 Oct 2014 13:42:51 -0700 (PDT)
"Rick C. Hodgin" <rick.c...@gmail.com> wrote:

> Why does g++ generate this warning?

It is useful. clang issues exactly same warning, too.


--
Manjaro all the way!
http://manjaro.org/

[Rick C. Hodgin]

On Thursday, October 30, 2014 8:03:50 PM UTC-4, Melzzzzz wrote:
> On Thu, 30 Oct 2014 13:42:51 -0700 (PDT)
> "Rick C. Hodgin" <rick.c...@gmail.com> wrote:
> > Why does g++ generate this warning?
>
> It is useful. clang issues exactly same warning, too.

:-) It is useful. FWIW, Visual Studio 2008's C/C++ compiler did not
generate a warning. It compiled the code, and the disassembly showed
the same operation as g++ as the above GDB output.

Thanks, Microsoft. :-) But, the blame rests solely on my shoulders.
I should've known better. And, I actually do... it's just sometimes
that things happen. :-)

[jacob navia]

Le 30/10/2014 23:26, Christopher Pisz a écrit :
> (good)C++ programmers don't use #include <stdio.h>, (most)C programmers do.
>

Maybe, but that is completely irrelevant to this bug.

> (good) C++ programmers don't usually pass raw pointers to public methods
> or global functions, (most) C programmers do
>

C++ doesn't use pointers?

Yes, they do. Yes, C++ will let you have all kinds of abstractions about
pointers, smart ones, not so smart ones and stupid ones, that are just
that: pointers.

But that has nothing to do about the bug!

> (good) C++ programmers certainly would check if the pointer was null
> before using it, (most) C programmers rely on foreknowledge and would
> say, "Well, we just know the pointer has to be initialized before using
> it", that's the way this API works.
>

No. Any reasonable C programmer in production code tests its inputs for
NULL, when that is required: a global function in this case.

But the bug would STILL be there if it was hidden in a completely local
environment

{ char *p = buffer; *p++; }

The bug is a misunderstanding by a programmer of how pointers work, what
is normal, since it is one of the most difficult things for newcomers to
C OR C++ to grasp.

> This was a very good example of how C style code creates unexpected
> errors.

There is no error at all! It is just that the value of an operation is
not used. It is the SAME as in C, by the way. C++ and C are exactly the
same with respect to this problem.

If he has passed the int by reference or by one of the many C++
> constructs to manage pointers, then the error would have never occurred.
>

And if he wouldn't have used any pointers at all the error would
disappear also. But you are looking at a SAMPLE CODE sent by the
programmer to ask a question about a warning he did not understand.

It is not production code!

> and you can see by his responses to why he didn't pass it by reference
> and why he returns (0) instead of returning 0, that he is a C style
> programmer, because he chalks it up to his personal preference and as is
> the case all too often with C style code, that personal preference made
> the code more error prone.
>

What makes his code go bad is a basic misunderstanding of pointers and
what dereferencing is. If he would have used any of the C++ methods you
point out, he would have never had this bug and would have never learned
how pointers work and why that construct is wrong.

What bothers me again in your answer is the implicit pejorative tone
before a simple error question.

Only the people that can't learn laugh at questions, be they so "stupid"
or "C like" as you want.

[Rick C. Hodgin]

On Thursday, October 30, 2014 4:43:04 PM UTC-4, Rick C. Hodgin wrote:
> 01: void test_function(int* tnX)
> 02: {
> 03: *tnX++; // Changes only the pointer
> 04: ++*tnX; // Changes the thing pointed to
> 05: }

I've been thinking... I don't think *tnX++ should do what it does
in current C/C++ compilers. I think this reveals a flaw in the
expression parsing mechanism which exists for pointers, and its
dereferencing on stand-alone statements like this.

Consider that on line 03: above, the * operation is completely and
silently lost. GCC does not give any sort of warning about unreachable
code in the pointer operation, or of having an operation which has no
effect (with regards to the * part of the code), but only that the
altered parameter value on the stack was not used. When changed to
the form above, even that warning goes away.

This reveals a flaw that is a separate issue to the original warning,
one which, to me, is far more important. The pointer operation is
being totally and completely ignored. Silently.

I believe this code should actually act on the thing and not the
pointer value itself.

I'll have to consider this, and may make this a special case exception
in RDC that when there is *tnX++; as in a stand-alone form, the operation
is actually the same as ++*tnX, and actually to update the thing pointed
to, rather than the pointer.

[Louis Krupp]

Don't do it. If you make an exception to the operator precedence
rules, you'll have programs breaking in surprising and mysterious
ways. Think of what will happen when somebody changes the expression
to:

n = *tnX++;

If tnX is suddenly incremented while before it wasn't, and *tnX is
unchanged while before it was incremented, you'll have violated the
Principle of Least Astonishment.

If you don't like the way current C/C++ compilers work, then you
should probably question how much you really like C or C++, and you
might want to make your new language look like something else. Lots
of people are not fond of C, and more people are less than thrilled by
C++. There are other languages out there to investigate or to be used
as models.

Louis

[Richard Damon]

On 10/30/14, 7:03 PM, Rick C. Hodgin wrote:
> On Thursday, October 30, 2014 4:43:04 PM UTC-4, Rick C. Hodgin
> wrote:
>> 01: void test_function(int* tnX) 02: { 03: *tnX++; // Changes
>> only the pointer 04: ++*tnX; // Changes the thing pointed to
>> 05: }
>
> I've been thinking... I don't think *tnX++ should do what it does in
> current C/C++ compilers. I think this reveals a flaw in the
> expression parsing mechanism which exists for pointers, and its
> dereferencing on stand-alone statements like this.
>

> Best regards, Rick C. Hodgin
>

The typical use for *p++ is in expressions (in loops) like

*p++ = 0; /* Clear a buffer */

or

*p1++ = *p2++; /* Copy a buffer */

In this case it make a lot of sense to have the priorities the way they
are.

Basically, having pointers into buffers you want to manipulate is more
common than a pointer to a simple variable you might want to increment.
(or that *++p would be more common than ++*p)

You always have the option to write it as: (*p)++ to modify the object
pointed to by the pointer.

[Rick C. Hodgin]

On Thursday, October 30, 2014 10:46:50 PM UTC-4, Louis Krupp wrote:
> On Thu, 30 Oct 2014 19:03:42 -0700 (PDT), "Rick C. Hodgin"

> >in RDC that when there is *tnX++; as in a stand-alone form...
^^^^^^^^^^^^^^^^^^^^^^^^

> Don't do it. If you make an exception to the operator precedence
> rules, you'll have programs breaking in surprising and mysterious
> ways. Think of what will happen when somebody changes the expression
> to:
>
> n = *tnX++;

I did say "as in a stand-alone form" ... meaning it exists only on
a single line of source code by itself (as per my original example).

Your example would work properly in my compiler. The other example
posted after would work properly. I'm just saying ++*tnX would work
the same as *tnX++ when that is all that's on the source code line,
as being that one special case.

[Nobody]

On Thu, 30 Oct 2014 19:03:42 -0700, Rick C. Hodgin wrote:

> I'll have to consider this, and may make this a special case exception
> in RDC that when there is *tnX++; as in a stand-alone form, the operation
> is actually the same as ++*tnX, and actually to update the thing pointed
> to, rather than the pointer.

Special-case exceptions are almost invariably a dumb idea, falling into
the category of "it seemed like a good idea at the time".

Even more so when the only reason for having it is that the developer
once made a mistake and would prefer to believe that the mistake was the
language's fault rather than his own.

[David Brown]

On 31/10/14 02:38, jacob navia wrote:
> Le 30/10/2014 23:26, Christopher Pisz a écrit :

>
>> This was a very good example of how C style code creates unexpected
>> errors.
>
> There is no error at all! It is just that the value of an operation is
> not used. It is the SAME as in C, by the way. C++ and C are exactly the
> same with respect to this problem.
>
>> If he has passed the int by reference or by one of the many C++
>> constructs to manage pointers, then the error would have never occurred.
>>
>

Yes, there was an error - Rick had written code with an error because he
misunderstood the precedence of the "*" and "++" operators. It is
common enough to make such mistakes, even for experienced C or C++
developers - personally, I am a fan of extra brackets or splitting up
the calculation in order to avoid such risks. The best solution, IMHO,
is to write "(*tnX)++;".

But if he had used a reference (as is common in C++ code), rather than a
pointer (which is common in C, and uncommon though still legal in C++),
then he could not possibly have made the same mistake. Using C++ style
coding in a C++ program would have avoided this error.

Now, it is fine for Rick to say he prefers the C style, even in C++
code. It is also fine to say using C++ style could have increased the
risks of other errors (such as the one Christopher made in his C++
examples). But /this/ particular error would have been avoided if Rick
had used C++ references.

[David Brown]

Check that you've got all warnings enabled, and also at least basic
optimisations - many compilers give better warnings when optimising code
(since they can track data flow better).

[David Brown]

On 31/10/14 03:03, Rick C. Hodgin wrote:
> On Thursday, October 30, 2014 4:43:04 PM UTC-4, Rick C. Hodgin wrote:
>> 01: void test_function(int* tnX)
>> 02: {
>> 03: *tnX++; // Changes only the pointer
>> 04: ++*tnX; // Changes the thing pointed to
>> 05: }
>
> I've been thinking... I don't think *tnX++ should do what it does
> in current C/C++ compilers. I think this reveals a flaw in the
> expression parsing mechanism which exists for pointers, and its
> dereferencing on stand-alone statements like this.
>
> Consider that on line 03: above, the * operation is completely and
> silently lost. GCC does not give any sort of warning about unreachable
> code in the pointer operation, or of having an operation which has no
> effect (with regards to the * part of the code), but only that the
> altered parameter value on the stack was not used. When changed to
> the form above, even that warning goes away.
>
> This reveals a flaw that is a separate issue to the original warning,
> one which, to me, is far more important. The pointer operation is
> being totally and completely ignored. Silently.
>

If you just have "*tnX", gcc will warn about that too.

There is always scope for more warnings in the compiler, but gcc gives
quite a number (when enabled).

> I believe this code should actually act on the thing and not the
> pointer value itself.
>
> I'll have to consider this, and may make this a special case exception
> in RDC that when there is *tnX++; as in a stand-alone form, the operation
> is actually the same as ++*tnX, and actually to update the thing pointed
> to, rather than the pointer.
>

Re-consider it - you don't want the same expression to mean different
things when it is written alone, or part of another statement. It makes
a lot more sense to make sure you give a warning when something like
that expression is used on its own, rather than silently translating it
into something else. And if you like, make such warnings permanently
enabled rather than optional (as in gcc or clang).

[Rick C. Hodgin]

On Friday, October 31, 2014 9:10:51 AM UTC-4, David Brown wrote:
> Re-consider it - you don't want the same expression to mean different
> things when it is written alone, or part of another statement.

David, what does *tnX++; mean when used by itself?

[Nobody]

On Fri, 31 Oct 2014 09:48:57 -0700, Rick C. Hodgin wrote:

> On Friday, October 31, 2014 9:10:51 AM UTC-4, David Brown wrote:
>> Re-consider it - you don't want the same expression to mean different
>> things when it is written alone, or part of another statement.
>
> David, what does *tnX++; mean when used by itself?

It means the same as "*(tnX++);".

In most cases, that means the same as just "tnX++;", because you're not
actually using the result of the dereference and a dereference doesn't
normally have side effects.

But if tnX is "volatile T*", the two aren't the same and the original
statement may actually be useful (e.g. forcing data to be copied from
main memory to cache or from virtual memory to main memory, or triggering
an action which occurs when a memory-mapped hardware register is read from).

Yet, such cases may well occur in real-world code (and not (just) because
the programmer meant to write something else). They may result from macro
expansion; e.g. consider the macro

#define getch(fp) (*(fp)->ptr++)

typically used as "c = getch(fp);" but quite reasonably used as just
"getch(fp);" if you want to skip a character.

Such issues (warnings about valid but "odd" constructs) occur frequently
in machine-generated code. Having the compiler attempt to second-guess the
intent in such cases would make it much harder to generate reliable code.
And it would probably also make it harder for humans, who won't always
remember (or even know about) all of the "special case" rules.

The problem with "DWIM" ("Do What I Mean") is: who is the "I"? The
person that developed the software, or the person trying to use it?

[Richard Damon]

Increment tnX, and then provide the value that the previous value of tnX
pointed to (which is then ignored if the phrase is written alone).

Something like (where temp has the same type as tnX):

( (temp = tnX) , (tnx = tnx+1) , (*tnX))

[Rick C. Hodgin]

I appreciate your input. I will consider it.

FWIW, I hold that volatile constraints place things in a completely
separate category. And in this case, outside of their use, neither
GCC or MSVC generated assembly opcodes for the dereference in non-
optimization mode (where one would expect it to be generated if any
were to be generated).

To me, that non-generation is telling.

Best regards,
Rick C. Hodgin

PS - Sylvia told me you called today, but then hung up? What's up with
that? :-) (+2 if you get that ancient reference)

[David Brown]

On 31/10/14 22:18, Rick C. Hodgin wrote:
> On Friday, October 31, 2014 3:25:08 PM UTC-4, Nobody wrote:
>> On Fri, 31 Oct 2014 09:48:57 -0700, Rick C. Hodgin wrote:
>>> On Friday, October 31, 2014 9:10:51 AM UTC-4, David Brown wrote:
>>>> Re-consider it - you don't want the same expression to mean different
>>>> things when it is written alone, or part of another statement.
>>> David, what does *tnX++; mean when used by itself?
>>

"Nobody" gave a good answer here - my comments are near the end.

What it is telling you is that on its own, "*tnX++" has no effect unless
there is a "volatile" somewhere. Since tnX is a value parameter, any
changes made to it are not passed back to the caller - they are
discarded. Therefore the compiler doesn't have to generate any code for
it in the first place. Similarly, the "*tnX" bit requests a read of the
value pointed at by tnX - but since that value is not read (and the
access is not volatile), the compiler can ignore that too. Thus the
compiler can figure out that the statement does nothing at all, and
generates no code. (It is free to do this regardless of optimisation
settings - optimisation settings are merely a hint.)

[Rick C. Hodgin]

On Sunday, November 2, 2014 5:29:46 PM UTC-5, David Brown wrote:
> >> On Fri, 31 Oct 2014 09:48:57 -0700, Rick C. Hodgin wrote:
> >>> David, what does *tnX++; mean when used by itself?

> >>> [snip]

> >>> To me, that non-generation is telling.
>
> What it is telling you is that on its own, "*tnX++" has no effect unless
> there is a "volatile" somewhere. Since tnX is a value parameter, any
> changes made to it are not passed back to the caller - they are
> discarded. Therefore the compiler doesn't have to generate any code for
> it in the first place. Similarly, the "*tnX" bit requests a read of the
> value pointed at by tnX - but since that value is not read (and the
> access is not volatile), the compiler can ignore that too. Thus the
> compiler can figure out that the statement does nothing at all, and
> generates no code. (It is free to do this regardless of optimisation
> settings - optimisation settings are merely a hint.)

My point in my original reply to you was this: What is it doing?
Nothing. Nobody indicated it would do something when volatile, to
which I wrote a lengthy reply which can be summed up with this brief
snippet: "Seriously? Somebody was use THAT feature to affect
something in main memory? Sounds like it needs refactoring severely."

Since *tnX++; by itself has no purpose, and arguably no purpose even
under the volatile constraint, I see no reason not to have it work in
the same way as ++*tnX, but it would just use the nicer syntax as
*tnX++; looks nice, and ++*tnX; doesn't. :-)

I'm still considering if I will support it to mean this form. I
can see myself using that form in code from time to time.

[David Brown]

On 02/11/14 23:43, Rick C. Hodgin wrote:
> On Sunday, November 2, 2014 5:29:46 PM UTC-5, David Brown wrote:
>>>> On Fri, 31 Oct 2014 09:48:57 -0700, Rick C. Hodgin wrote:
>>>>> David, what does *tnX++; mean when used by itself?
>>>>> [snip]
>>>>> To me, that non-generation is telling.
>>
>> What it is telling you is that on its own, "*tnX++" has no effect unless
>> there is a "volatile" somewhere. Since tnX is a value parameter, any
>> changes made to it are not passed back to the caller - they are
>> discarded. Therefore the compiler doesn't have to generate any code for
>> it in the first place. Similarly, the "*tnX" bit requests a read of the
>> value pointed at by tnX - but since that value is not read (and the
>> access is not volatile), the compiler can ignore that too. Thus the
>> compiler can figure out that the statement does nothing at all, and
>> generates no code. (It is free to do this regardless of optimisation
>> settings - optimisation settings are merely a hint.)
>
> My point in my original reply to you was this: What is it doing?
> Nothing. Nobody indicated it would do something when volatile, to
> which I wrote a lengthy reply which can be summed up with this brief
> snippet: "Seriously? Somebody was use THAT feature to affect
> something in main memory? Sounds like it needs refactoring severely."

Of /course/ "*tnX++" will "do something" when tnX is declared "volatile
int* tnX". The compiler will generate code to read the memory at *tnX.
It may or may not implement the "++" part - if tnX is not used again,
it will not bother doing so.

I don't know all the possible target applications you are thinking of
for RDC, but "volatile" - and accessing memory correctly when volatile
is specified - is vital for all embedded systems, and for many low-level
libraries and OS routines.

[Rick C. Hodgin]

On Sunday, November 2, 2014 7:14:46 PM UTC-5, David Brown wrote:
> On 02/11/14 23:43, Rick C. Hodgin wrote:
> > My point in my original reply to you was this: What is it doing?
> > Nothing. Nobody indicated it would do something when volatile, to
> > which I wrote a lengthy reply which can be summed up with this brief

> > snippet: "Seriously? Somebody was [using] THAT feature to affect
> > something in [main/os] memory? Sounds like it needs refactoring

> > severely."
>
> Of /course/ "*tnX++" will "do something" when tnX is declared "volatile
> int* tnX". The compiler will generate code to read the memory at *tnX.
> It may or may not implement the "++" part - if tnX is not used again,
> it will not bother doing so.
>
> I don't know all the possible target applications you are thinking of
> for RDC, but "volatile" - and accessing memory correctly when volatile
> is specified - is vital for all embedded systems, and for many low-level
> libraries and OS routines.

I am well aware of that. When volatile it will behave like normal.
When not volatile, that particular instruction is in error because
it does nothing except increase the value of tnX, but because it has
the dereference operator, it's incorrect in one way or another:

(1) Either the developer intended volatile and forgot it, or
(2) It is an improperly coded statement.

In either case it is a statement with no valid purpose when it
exists without volatile as a stand-alone.

I'm pretty sure I will allow *tnX++; to operate as ++*tnX; when it
is stand-alone. I will do so and generate a particular suppressible
warning when that condition is encountered so that by default the
developer will see the cue, and when he/she recognizes that they
desire the ++*tnX; behavior with that syntax, then they can shut
it off.

RDC also has additional features which allow it to integrate with the
IDE and be a continuous compiler. Under that case, individual
instances of warnings can be suppressed, and those suppression
settings can be exported to go along with the source files to other
machines.

[Louis Krupp]

If I'm not mistaken, you mean ((temp = tnX), (tnX = tnX + 1), (*temp))

Louis

[Tobias Müller]

"Rick C. Hodgin" <rick.c...@gmail.com> wrote:

> On Sunday, November 2, 2014 7:14:46 PM UTC-5, David Brown wrote:
>> On 02/11/14 23:43, Rick C. Hodgin wrote:
>>> My point in my original reply to you was this: What is it doing?
>>> Nothing. Nobody indicated it would do something when volatile, to
>>> which I wrote a lengthy reply which can be summed up with this brief
>>> snippet: "Seriously? Somebody was [using] THAT feature to affect
>>> something in [main/os] memory? Sounds like it needs refactoring
>>> severely."
>>
>> Of /course/ "*tnX++" will "do something" when tnX is declared "volatile
>> int* tnX". The compiler will generate code to read the memory at *tnX.
>> It may or may not implement the "++" part - if tnX is not used again,
>> it will not bother doing so.
>>
>> I don't know all the possible target applications you are thinking of
>> for RDC, but "volatile" - and accessing memory correctly when volatile
>> is specified - is vital for all embedded systems, and for many low-level
>> libraries and OS routines.
>
> I am well aware of that. When volatile it will behave like normal.
> When not volatile, that particular instruction is in error because
> it does nothing except increase the value of tnX, but because it has
> the dereference operator, it's incorrect in one way or another:
>
> (1) Either the developer intended volatile and forgot it, or
> (2) It is an improperly coded statement.

IMO it is very important that features of a programming language are
sufficiently orthogonal and independent.
That means, the effect of a combination of features should always be clear
from the individual features.
This will inevitably lead to the fact, that you will find nonsensical
combinations, that are still allowed.

Usually such cases can be caught with compiler warnings or lint. But I
don't think it's worth complicating the language rules.

And disallowing such cases is one thing, but changing the semantics of an
language feature depending on the context and other features is dangerous
and should be avoided under any circumstances.

Tobi

[Ben Bacarisse]

"Rick C. Hodgin" <rick.c...@gmail.com> writes:
<snip>

> I'm pretty sure I will allow *tnX++; to operate as ++*tnX; when it
> is stand-alone. I will do so and generate a particular suppressible
> warning when that condition is encountered so that by default the
> developer will see the cue, and when he/she recognizes that they
> desire the ++*tnX; behavior with that syntax, then they can shut
> it off.

When you write the RDC documentation (or even the road map for
development) put this feature front and centre. It will save readers
much time.

<snip>
--
Ben.

[Rick C. Hodgin]

Ben Bacarisse wrote:
> When you write the RDC documentation (or
> even the road map for development) put this
> feature front and centre. It will save readers
> much time.

Am writing RDC specs draft presently. Lord
willing, I will publish for review this week.

[David Brown]

On 03/11/14 03:03, Rick C. Hodgin wrote:
> On Sunday, November 2, 2014 7:14:46 PM UTC-5, David Brown wrote:
>> On 02/11/14 23:43, Rick C. Hodgin wrote:
>>> My point in my original reply to you was this: What is it doing?
>>> Nothing. Nobody indicated it would do something when volatile, to
>>> which I wrote a lengthy reply which can be summed up with this brief
>>> snippet: "Seriously? Somebody was [using] THAT feature to affect
>>> something in [main/os] memory? Sounds like it needs refactoring
>>> severely."
>>
>> Of /course/ "*tnX++" will "do something" when tnX is declared "volatile
>> int* tnX". The compiler will generate code to read the memory at *tnX.
>> It may or may not implement the "++" part - if tnX is not used again,
>> it will not bother doing so.
>>
>> I don't know all the possible target applications you are thinking of
>> for RDC, but "volatile" - and accessing memory correctly when volatile
>> is specified - is vital for all embedded systems, and for many low-level
>> libraries and OS routines.
>
> I am well aware of that. When volatile it will behave like normal.

No, when "volatile" it will behave like "volatile". When non-volatile,
it will behave like "normal".

> When not volatile, that particular instruction is in error because
> it does nothing except increase the value of tnX, but because it has
> the dereference operator, it's incorrect in one way or another:
>
> (1) Either the developer intended volatile and forgot it, or
> (2) It is an improperly coded statement.
>
> In either case it is a statement with no valid purpose when it
> exists without volatile as a stand-alone.

Incorrect.

Without volatile, the statement "*tnX++;" does not do anything on its
own. But if it were followed by other statements, or if tnX were
returned to the caller, the "tnX++;" part would have an effect. And as
has been pointed out by others, such statements could be generated by
macros.

The sensible action is to give a warning message for code like this.
Then the programmer can figure out if he forgot a "volatile", simply
made a mistake somewhere, or if it is the consequence of generated code.
Guessing the programmers intention and changing the meaning of the
statement is the second worst possible action (the worst choice being to
change its meaning without even giving a warning).

Even if you could be sure of the developer's /real/ intentions here,
allowing them to write sloppy code that would have a different meaning
elsewhere would encourage bad habits and lead to more problems later.

[Rick C. Hodgin]

On Monday, November 3, 2014 7:18:57 AM UTC-5, David Brown wrote:
> On 03/11/14 03:03, Rick C. Hodgin wrote:
> > On Sunday, November 2, 2014 7:14:46 PM UTC-5, David Brown wrote:
> >> On 02/11/14 23:43, Rick C. Hodgin wrote:
> >>> My point in my original reply to you was this: What is it doing?
> >>> Nothing. Nobody indicated it would do something when volatile, to
> >>> which I wrote a lengthy reply which can be summed up with this brief
> >>> snippet: "Seriously? Somebody was [using] THAT feature to affect
> >>> something in [main/os] memory? Sounds like it needs refactoring
> >>> severely."
> >>
> >> Of /course/ "*tnX++" will "do something" when tnX is declared "volatile
> >> int* tnX". The compiler will generate code to read the memory at *tnX.
> >> It may or may not implement the "++" part - if tnX is not used again,
> >> it will not bother doing so.
> >>
> >> I don't know all the possible target applications you are thinking of
> >> for RDC, but "volatile" - and accessing memory correctly when volatile
> >> is specified - is vital for all embedded systems, and for many low-level
> >> libraries and OS routines.
> >
> > I am well aware of that. When volatile it will behave like normal.
>
> No, when "volatile" it will behave like "volatile". When non-volatile,
> it will behave like "normal".

Allow me to restate: When volatile it will behave like [a volatile-declared variable would behave].

> > When not volatile, that particular instruction is in error because
> > it does nothing except increase the value of tnX, but because it has
> > the dereference operator, it's incorrect in one way or another:
> >
> > (1) Either the developer intended volatile and forgot it, or
> > (2) It is an improperly coded statement.
> >
> > In either case it is a statement with no valid purpose when it
> > exists without volatile as a stand-alone.
>
> Incorrect.
>
> Without volatile, the statement "*tnX++;" does not do anything on its
> own. But if it were followed by other statements, or if tnX were
> returned to the caller, the "tnX++;" part would have an effect. And as
> has been pointed out by others, such statements could be generated by
> macros.

The *tnX++; stand-alone does not do anything on its own. It is a corrupt
statement that is malformed when non-volatile stand-alone. It updates tnX,
but it is also in error in so doing because the dereference is impotent.

> The sensible action is to give a warning message for code like this.
> Then the programmer can figure out if he forgot a "volatile", simply
> made a mistake somewhere, or if it is the consequence of generated code.
> Guessing the programmers intention and changing the meaning of the
> statement is the second worst possible action (the worst choice being to
> change its meaning without even giving a warning).

Existing compilers do this.

> Even if you could be sure of the developer's /real/ intentions here,
> allowing them to write sloppy code that would have a different meaning
> elsewhere would encourage bad habits and lead to more problems later.

*tnX++; in stand-alone is a special case in RDC. I will treat it as
such, generating a suppressible warning on its stand-alone use. When
used as normal with other code where the dereference has meaning, it
will behave as it would today in C.

This behavior will be able to be overridden with the -strict=C option.

It's interesting this issue came up. Stuff like this happens to me
from time to time. I find myself riding through it all going "Hmmm,
that's interesting."

[David Brown]

Yes, that's correct. Some people seem to think that a compiler should
"do exactly what I tell it and not be smart about it", and thus view
"volatile" behaviour as "normal", and "optimised" behaviour as "too
smart for its own good". I just wanted to be absolutely sure you were
not thinking along those lines.

>
>>> When not volatile, that particular instruction is in error
>>> because it does nothing except increase the value of tnX, but
>>> because it has the dereference operator, it's incorrect in one
>>> way or another:
>>>
>>> (1) Either the developer intended volatile and forgot it, or (2)
>>> It is an improperly coded statement.
>>>
>>> In either case it is a statement with no valid purpose when it
>>> exists without volatile as a stand-alone.
>>
>> Incorrect.
>>
>> Without volatile, the statement "*tnX++;" does not do anything on
>> its own. But if it were followed by other statements, or if tnX
>> were returned to the caller, the "tnX++;" part would have an
>> effect. And as has been pointed out by others, such statements
>> could be generated by macros.
>
> The *tnX++; stand-alone does not do anything on its own. It is a
> corrupt statement that is malformed when non-volatile stand-alone.

It is neither "corrupt" nor "malformed". It is not particularly useful
in this case, but there are many things that get written in C code that
don't end up producing object code or even affecting the compilation.

> It updates tnX, but it is also in error in so doing because the
> dereference is impotent.

It may be that the programmer has made an error - and thus a warning
makes sense. But the statement itself is not in error. Doing nothing
is never an error in itself, but can often be an indication that the
programmer has made an error.

>
>> The sensible action is to give a warning message for code like
>> this. Then the programmer can figure out if he forgot a "volatile",
>> simply made a mistake somewhere, or if it is the consequence of
>> generated code. Guessing the programmers intention and changing the
>> meaning of the statement is the second worst possible action (the
>> worst choice being to change its meaning without even giving a
>> warning).
>
> Existing compilers do this.

Existing compilers generate a warning, if that's what you mean.
Existing compilers do not change the meaning of the code.

>
>> Even if you could be sure of the developer's /real/ intentions
>> here, allowing them to write sloppy code that would have a
>> different meaning elsewhere would encourage bad habits and lead to
>> more problems later.
>
> *tnX++; in stand-alone is a special case in RDC. I will treat it as
> such, generating a suppressible warning on its stand-alone use.
> When used as normal with other code where the dereference has
> meaning, it will behave as it would today in C.

It is /your/ compiler, of course, but I think you are absolute wrong on
this one. I don't think there is anything more I can say to emphasis
that more strongly - either you understand the importance of consistency
in the language or you will end up with countless more "special cases"
and leave users with little idea of what any particular statement or
expression will do in any particular context. You are at the top of a
slippery slope here, and heading down it fast.

>
> This behavior will be able to be overridden with the -strict=C
> option.

I assume that this flag will put your compiler into "C mode", and then
you must do your best to follow the standards as closely as you can.
But don't be tempted to have flags that allow different features of RDC
to be interpreted in different ways, as this will cause a lot of confusion.

[Rick C. Hodgin]

On Monday, November 3, 2014 8:37:20 AM UTC-5, David Brown wrote:
> [snip]

Nobody, Tobias, David, Ben, you've all convinced me. I'm on board with
leaving it as it is and producing a warning.

I still may have T-Shirts made up:

*tnX++; // :-)

[Mr Flibble]

On 03/11/2014 11:25, Rick C. Hodgin wrote:
> Ben Bacarisse wrote:
>> When you write the RDC documentation (or
>> even the road map for development) put this
>> feature front and centre. It will save readers
>> much time.
>
> Am writing RDC specs draft presently. Lord
> willing, I will publish for review this week.

He was being sarcastic, couldn't you tell?

/Flibble

[Rick C. Hodgin]

Of course. His sarcasm didn't alter my answer though.

[Mr Flibble]

That is because you are not taking your medication.

/Flibble

[Rick C. Hodgin]

On Monday, November 3, 2014 9:36:24 AM UTC-5, Rick C. Hodgin wrote:
> On Monday, November 3, 2014 8:37:20 AM UTC-5, David Brown wrote:
> > [snip]
>
> Nobody, Tobias, David, Ben, you've all convinced me. I'm on board with
> leaving it as it is and producing a warning.

I have reversed my thinking on this. The source code line *tnX++; by
itself has no appropriate meaning whatsoever when tnX is not volatile.
As such, and because it is a nicer looking than ++*tnX;, I will define
the two to mean the same thing in the RDC compiler when in stand-alone
form.

And there may be others.

Things which are decoded into executable code should translate into
something which means something. If not, they will be optimized away
and have no impact. The way around this is to declare tnX as volatile,
or to cast it as such upon instance use.

[Nobody]

On Tue, 11 Nov 2014 14:46:03 -0800, Rick C. Hodgin wrote:

>> Nobody, Tobias, David, Ben, you've all convinced me. I'm on board with
>> leaving it as it is and producing a warning.
>
> I have reversed my thinking on this. The source code line *tnX++; by
> itself has no appropriate meaning whatsoever when tnX is not volatile.

It has a well-defined meaning. Its meaning is identical to "tnX++;". It's
also identical to "x = *tnX++;" where x is a variable which is never read
from (and isn't volatile).

> As such, and because it is a nicer looking than ++*tnX;, I will define
> the two to mean the same thing in the RDC compiler when in stand-alone
> form.

If you haven't realised how dumb an idea this is, it can only be because
you're wilfully avoiding that realisation.

It has already been pointed out that changing semantics based upon context
makes it practically impossible to write robust macros (as macros
inevitably divorce code from its context).

On the plus side, it's unlikely to actually cause problems for anyone
other than yourself, as I can't imagine anyone else ever using "RDC". If
you can't even get simple stuff like this right, I dread to think what
other flaws it will have.

[Rick C. Hodgin]

On Wednesday, November 12, 2014 3:48:06 AM UTC-5, Nobody wrote:
> On Tue, 11 Nov 2014 14:46:03 -0800, Rick C. Hodgin wrote:
> >> Nobody, Tobias, David, Ben, you've all convinced me. I'm on board with
> >> leaving it as it is and producing a warning.
> > I have reversed my thinking on this. The source code line *tnX++; by
> > itself has no appropriate meaning whatsoever when tnX is not volatile.
> It has a well-defined meaning. Its meaning is identical to "tnX++;".

Its meaning is not identical to tnX++;. Its application in compiled
code is identical to tnX++;, but its meaning is something else which
is incomplete and invalid because the dereference is lost-but-
provided-for in source code.

> It's also identical to "x = *tnX++;" where x is a variable which is
> never read > from (and isn't volatile).

x = *tnX++; is not a stand-alone statement. It has valid meaning and
will be conveyed as purposed even if x is ultimately optimized away
due to non-use. It is a fully formed, fully utilized statement.

*tnX++; on a line by itself is not

> > As such, and because it is a nicer looking than ++*tnX;, I will define
> > the two to mean the same thing in the RDC compiler when in stand-alone
> > form.
>
> If you haven't realised how dumb an idea this is, it can only be because
> you're wilfully avoiding that realisation.

I place emphasis on the fact that the dereference is lost, and that it
indicates an error in the statement. As such, it is re-mapped to the
form which has meaning in this context.

> It has already been pointed out that changing semantics based upon context
> makes it practically impossible to write robust macros (as macros
> inevitably divorce code from its context).
>
> On the plus side, it's unlikely to actually cause problems for anyone
> other than yourself, as I can't imagine anyone else ever using "RDC". If
> you can't even get simple stuff like this right, I dread to think what
> other flaws it will have.

I appreciate your consideration on the matter. Nobody has to use RDC.
Its features will be there for examination. RDC will also contain a
-strict=c compiler flag which will keep behavior as it is in C/C++.

[David Brown]

On 12/11/14 12:23, Rick C. Hodgin wrote:
> On Wednesday, November 12, 2014 3:48:06 AM UTC-5, Nobody wrote:
>> On Tue, 11 Nov 2014 14:46:03 -0800, Rick C. Hodgin wrote:
>>>> Nobody, Tobias, David, Ben, you've all convinced me. I'm on board with
>>>> leaving it as it is and producing a warning.
>>> I have reversed my thinking on this. The source code line *tnX++; by
>>> itself has no appropriate meaning whatsoever when tnX is not volatile.
>> It has a well-defined meaning. Its meaning is identical to "tnX++;".
>
> Its meaning is not identical to tnX++;. Its application in compiled
> code is identical to tnX++;, but its meaning is something else which
> is incomplete and invalid because the dereference is lost-but-
> provided-for in source code.
>
>> It's also identical to "x = *tnX++;" where x is a variable which is
>> never read > from (and isn't volatile).
>
> x = *tnX++; is not a stand-alone statement. It has valid meaning and
> will be conveyed as purposed even if x is ultimately optimized away
> due to non-use. It is a fully formed, fully utilized statement.
>
> *tnX++; on a line by itself is not

In C, "*tnX++;" on a line by itself is a fully formed, syntactically
correct and valid statement (called an "expression statement" in the
standards). Since "x = *tnX++;" is /also/ an expression, it too is an
"expression statement". In the grammar of C, there is no difference
between them.

Thus if you are going to make a distinction here, you are changing some
of the very fundamental parts of C grammar. In itself, there is nothing
wrong with that - a non-C-like programming language does not have to
share the grammar of C, and many languages consider "assignment" to be a
type of statement rather than a type of expression, and then disallow
the use of expressions as statements. But you have to make a clear,
consistent, documented decision here. It is up to you which way you go,
but the worst choice is a mixture full of special cases - it will be bad
for the compiler, bad for the IDE, and even worse for the user.

Try to write out your language grammar in BNF form - it is key to the
documentation you will need, and it will make it clear as to how
consistent and logical your grammar really is.

[Rick C. Hodgin]

On Wednesday, November 12, 2014 6:55:21 AM UTC-5, David Brown wrote:
> In C...

I'm writing RDC, not C. Under -strict=c constraints, it will work as C
compilers do today.

In RDC form (the default) it will work as I am defining.

You take exception to everything I propose or espouse, and that's fine.
However, it is not for me to continue in, and this will be my last
response to you. I wish you well, David.

[David Brown]

When you come up with an idea that I think is bad, I ask questions, give
suggestions, and encourage you to re-think it. My posts on technical
matters regarding RDC are clear, helpful, and relevant - as are those of
many others here. Yet you continually ignore the advice you are given
and continue with your own fixed ideas.

The simple fact is that you are not capable of designing a language of
the scope you are targeting with RDC. You don't have the experience,
the technical training, or the academic background. Very few people are
capable of such a job alone - I know I certainly am not. So in the real
world, where new programming languages are designed, implemented and
used, people work together. People ask for advice, then listen to the
answers. When they are told they are doing something stupid, they take
a step back and re-think the idea - especially when they are told the
same thing by many different people.

I have made a large number of posts here regarding RDC. Sometimes these
were of wider interest in c.l.c++ and c.l.c, but the great majority had
one purpose only - to help /you/. But you continually reject and push
away all who help you due to your delusions of grandeur and your beliefs
that anyone who does not agree with you on every topic is evil, hateful,
and inspired by the devil.


If you can find a single other person who thinks that an inconsistent
and undocumented grammar filled with special-case exceptions is a good
idea for a programming language, let me know. If you can find a single
person who thinks context-sensitive interpretation of expressions and
operating binding precedence is a good idea, let me know. If you can
find a single person who thinks scraping data structures is a good idea,
let me know. Or if you can find a single person who thinks tools should
be based on piss-poor compilers with weak languages compensated by
colourful editors, let me know.


Until then, I stand by my posts that were made for /your/ benefit. But
I am getting pretty tired of your ungrateful, petty, spiteful,
thoughtless and arrogant remarks. I don't think I am the only one.

[Mr Flibble]

On 12/11/2014 15:34, David Brown wrote:
> On 12/11/14 15:09, Rick C. Hodgin wrote:
>> On Wednesday, November 12, 2014 6:55:21 AM UTC-5, David Brown wrote:
>>> In C...
>>
>> I'm writing RDC, not C. Under -strict=c constraints, it will work as C
>> compilers do today.
>>
>> In RDC form (the default) it will work as I am defining.
>>
>> You take exception to everything I propose or espouse, and that's fine.
>> However, it is not for me to continue in, and this will be my last
>> response to you. I wish you well, David.
>>
>
> When you come up with an idea that I think is bad, I ask questions, give

[snip]

His idea isn't just bad, it is fucking demented.

/Flibble

[JiiPee]

On 30/10/2014 21:48, Rick C. Hodgin wrote:
> On Thursday, October 30, 2014 5:14:51 PM UTC-4, Christopher Pisz wrote:
>> Yucky C style code, making it error prone.
>>
>> What do you think *tnX++ is doing?
> Increasing the int pointed to by tnX. I see from your cue below,
> and in looking at the disassembly, that it is not, hence the warning.
>

The name of the function can help though. For example if you change the
function to:

incrementByOne(tnLevel);

then its pretty clear that tnLevel will be changed by ref, isnt it?

Also, why cannot you use just a return value in this case:

int test_function(int tnX)
{
return ++tnX;
}

tnLevel = test_function(tnLevel);

? And if its an inline function there should be no overhead isn't it?

[JiiPee]

On 31/10/2014 10:41, David Brown wrote:
> Yes, there was an error - Rick had written code with an error because he
> misunderstood the precedence of the "*" and "++" operators. It is
> common enough to make such mistakes, even for experienced C or C++
> developers - personally, I am a fan of extra brackets or splitting up
> the calculation in order to avoid such risks.

> The best solution, IMHO,
> is to write "(*tnX)++;".

totally agree. Why make things look difficult... we are humans so lets
help us :).


>
> But if he had used a reference (as is common in C++ code), rather than a
> pointer (which is common in C, and uncommon though still legal in C++),
> then he could not possibly have made the same mistake. Using C++ style
> coding in a C++ program would have avoided this error.

I do C++ programmer. I would never use pointer in that kind of
situation, exatcly because of this kind of problems plus its more
"natural" for me to use ref or by value. But by reference changin must
be very careful indeed imo that the function name is clear that its
gonna change the variable. And I would consider returning the result
actually (inline function maybe).

>
> Now, it is fine for Rick to say he prefers the C style, even in C++
> code. It is also fine to say using C++ style could have increased the
> risks of other errors (such as the one Christopher made in his C++
> examples). But /this/ particular error would have been avoided if Rick
> had used C++ references.

But this is exatcly the reason we use many other things as well, like
"const" to make sure the content is not changed by accident. Yes,
reference makes the code a bit more difficult to read but which one is
more dangerous? But as I said, its very important imo that the function
name is like: "increaseThisVariable(...)", so the intent is seen clearly
from calling side.

>
>

[Ike Naar]

On 2014-11-13, JiiPee <n...@notvalid.com> wrote:
> On 30/10/2014 21:48, Rick C. Hodgin wrote:
> int test_function(int tnX)
> {
> return ++tnX;

return tnX+1; /* no unnecessary side effect */

> }

[Mr Flibble]

On 12/11/2014 14:09, Rick C. Hodgin wrote:
> On Wednesday, November 12, 2014 6:55:21 AM UTC-5, David Brown wrote:
>> In C...
>
> I'm writing RDC, not C. Under -strict=c constraints, it will work as C
> compilers do today.
>
> In RDC form (the default) it will work as I am defining.

Is RDC an abbreviation for "Really Dumb C" or "Really Dangerous C"
because your approach is both dumb and dangerous but hopefully nobody
writing safety critical software would touch your demented language with
a barge pole.

/Flibble

[JiiPee]

Ins't the assembly code the same for both? Thats what I would think.
Compiler not very wise if cannot do that :). I would prefer ++tnX to be
consistant in code (because its used everywhere else as well).

[Rick C. Hodgin]

RDC stands for Rapid Development Compiler. It removes some of the
mechanical syntax requirements for data access, and introduces ways
to access the same data in different ways to allow a wide array of
processing. It is generally very very C-like, but there are some
notable exceptions. RDC also introduces the class into C-like code,
so that some of the desirable encapsulating features of C++ are
there, but without the complexity.

I plan on eventually getting a fully C-compliant version completed
as well (probably C99). But, that's a later goal because it's not
a great priority for me. There aren't that many things different
between RDC and C such that I would need to spend so much time
writing a fully compliant compiler today. It would be faster to
change the small handful of things in my code that need changed to
allow my own code to compile in my own compiler, and move forward
from there.

We'll see though. All of these plans are subject to the Lord's will.
I can only set goals. It is only He who gives me the ability to
follow through on those goals. He may well have other plans for my
life. Time will tell.

[Rick C. Hodgin]

When optimized they would probably produce the same. Without
optimization the return ++tnX has a read, add, write, and possibly
another read to obtain the return value. Without optimization,
the return tnX + 1 has one read, and one add to obtain the return
value.

return tnX + 1;

This would definitely be better on unoptimized code.

[Ike Naar]

It seems a bit unnatural to use the version with side effect if
the side effect is not needed.

Can you explain why you prefer ++tnX (or tnX++) over tnX+1 ?

[JiiPee]

ok, good to know. Well then I would still use myself ++tnX and just
remember in debuggin mode this issue. But its a taste issue I guess....

Without much thinking, don't we have the same proglem in other than
return-value code as well? Like:

int i=7;
int x=9;
...
x = ++i;

is here also

x = i + 1;

less assembly code in debuggin mode? Don't we have the same issue here
as well?

[JiiPee]

On 13/11/2014 18:23, Ike Naar wrote:
> On 2014-11-13, JiiPee <n...@notvalid.com> wrote:
>> On 13/11/2014 16:26, Ike Naar wrote:
>>> On 2014-11-13, JiiPee <n...@notvalid.com> wrote:
>>>> On 30/10/2014 21:48, Rick C. Hodgin wrote:
>>>> int test_function(int tnX)
>>>> {
>>>> return ++tnX;
>>> return tnX+1; /* no unnecessary side effect */
>>>
>> Ins't the assembly code the same for both? Thats what I would think.
>> Compiler not very wise if cannot do that :). I would prefer ++tnX to be
>> consistant in code (because its used everywhere else as well).
> It seems a bit unnatural to use the version with side effect if
> the side effect is not needed.
>
> Can you explain why you prefer ++tnX (or tnX++) over tnX+1 ?

Like I said, I prefer it because I use it everywhere else in my code as
well. I never do tnX+1 style in my code. For example in loops i do:

for (int i ....; ++i)

I do not do:

for (int i ....; i=i+1)

So I want to use the same style everywhere, thats why....Its better for
me as a human to read the code. Or do you have a special reason why
elsewhere better to use ++i and here i=i+1?

[Rick C. Hodgin]

Unoptimized ssembly:
mov eax,i
inc eax
mov i,eax
mov x,eax

> is here also
>
> x = i + 1;

Unoptimized assembly:
mov eax,i
inc eax
mov x,eax

> less assembly code in debuggin mode? Don't we have the same issue here
> as well?

Yes, but the result of the second one is i is not incremented. The
requirements of incrementing i may be a constraint in the source code.
If not, then it can be optimized away layer.

[Rick C. Hodgin]

On Thursday, November 13, 2014 1:28:52 PM UTC-5, JiiPee wrote:
> On 13/11/2014 18:23, Ike Naar wrote:
> > On 2014-11-13, JiiPee <n...@notvalid.com> wrote:
> >> On 13/11/2014 16:26, Ike Naar wrote:
> >>> On 2014-11-13, JiiPee <n...@notvalid.com> wrote:
> >>>> On 30/10/2014 21:48, Rick C. Hodgin wrote:
> >>>> int test_function(int tnX)
> >>>> {
> >>>> return ++tnX;
> >>> return tnX+1; /* no unnecessary side effect */
> >>>
> >> Ins't the assembly code the same for both? Thats what I would think.
> >> Compiler not very wise if cannot do that :). I would prefer ++tnX to be
> >> consistant in code (because its used everywhere else as well).
> > It seems a bit unnatural to use the version with side effect if
> > the side effect is not needed.
> >
> > Can you explain why you prefer ++tnX (or tnX++) over tnX+1 ?
>
> Like I said, I prefer it because I use it everywhere else in my code as
> well. I never do tnX+1 style in my code. For example in loops i do:
>
> for (int i ....; ++i)

Unoptimized assembly:
mov eax,i
inc eax

mov i,eax

> I do not do:
>
> for (int i ....; i=i+1)

Unoptimized assembly:
mov eax,i
inc eax

mov i,eax

> So I want to use the same style everywhere, thats why....Its better for
> me as a human to read the code. Or do you have a special reason why
> elsewhere better to use ++i and here i=i+1?

An optimizing compiler might use ecx for a register for the loop if
possible, or it may simply issue "inc i" which would translate to
"inc dword ptr ss:[ebp+N]" to increment the 32-bit integer value of
N on the stack at whatever location it's assigned. It would depend
on how soon after the increment i is needing to be used again. If
it's not immediately thereafter, using the inc i form would probably
be more desirable as the CPU has time to write the results in another
pipe, and non-temporally.

[JiiPee]

Oh now I got your point :). Ye, we increament the variable as well.
True....now I agree that +1 version is indeed better here. Am slow today :).

[JiiPee]

interesting, i need to learn to get the assembly code also to see these
(is it some easy command on gcc?). But I just got the whole thing... I
did not see the increment issue of the variable. So +1 is better in the
original issue..

[Rick C. Hodgin]

On Thursday, November 13, 2014 1:45:02 PM UTC-5, JiiPee wrote:
> interesting, i need to learn to get the assembly code also to see these
> (is it some easy command on gcc?).

Yes. Add "-S -masm=intel" and it will generate disassembly in Intel
syntax. If you leave off the "-masm=intel" it will use AT&T syntax
and you'll go blind.

[Mr Flibble]

You don't get it do you mate? Designing a C-like language which treats
the simple expression (*o++) differently to C is both dumb and
dangerous; if you don't listen to what people say on this matter then
you are a fool and your language is a joke.

/Flibble

[Rick C. Hodgin]

When compiled with -strict=c it will behave as C does. When compiled
without that flag, it will swap out that meaning and possibly some
others.

I am seriously considering changing the order of precedence on ++ and
--. We'll see though.

[David Brown]

On 13/11/14 19:26, JiiPee wrote:
> On 13/11/2014 18:17, Rick C. Hodgin wrote:
>> On Thursday, November 13, 2014 12:45:24 PM UTC-5, JiiPee wrote:
>>> On 13/11/2014 16:26, Ike Naar wrote:
>>>> On 2014-11-13, JiiPee <n...@notvalid.com> wrote:
>>>>> On 30/10/2014 21:48, Rick C. Hodgin wrote:
>>>>> int test_function(int tnX)
>>>>> {
>>>>> return ++tnX;
>>>> return tnX+1; /* no unnecessary side effect */
>>>>
>>> Ins't the assembly code the same for both? Thats what I would think.
>>> Compiler not very wise if cannot do that :). I would prefer ++tnX to be
>>> consistant in code (because its used everywhere else as well).
>> When optimized they would probably produce the same. Without
>> optimization the return ++tnX has a read, add, write, and possibly
>> another read to obtain the return value. Without optimization,
>> the return tnX + 1 has one read, and one add to obtain the return
>> value.
>>
>> return tnX + 1;
>>
>> This would definitely be better on unoptimized code.
>>
>> Best regards,
>> Rick C. Hodgin
>
> ok, good to know. Well then I would still use myself ++tnX and just
> remember in debuggin mode this issue. But its a taste issue I guess....

There is no problem - just don't ask your compiler to run with its
shoelaces tied together. Even when debugging, there is seldom need to
have so little optimisation that the compiler generates worse code for
"++tnX" than "tnX + 1".

[Mr Flibble]

Now I'm convinced you are just a troll.

/Flibble

[Mr Flibble]

Give it up; this guy is obviously a troll.

/Flibble

[Rick C. Hodgin]

On Thursday, November 13, 2014 5:33:14 PM UTC-5, Mr Flibble wrote:
> Now I'm convinced you are just a troll.

Well, here's something a troll would say: I am not a troll.
However, it also something a person who is not a troll would say.

I am not a troll. I am Rick C. Hodgin, a software developer from
Indianapolis, IN. I write low-level code and try very hard to
teach people about the Lord, and to follow Him in their lives, as
I try very hard to do in my life as well.

That the extent of it.

If you're ever in Indianapolis, contact me and we'll meet up and
you can talk to me face-to-face and see for yourself. I am a
normal human-looking person, in no way troll-like. :-)

http://www.visual-freepro.org/wiki/index.php/Rick_C._Hodgin

Well, maybe a little troll-like now that I look closely. :-)

[David Brown]

My post was in answer to JiiPee, not to Rick.

And I don't think Rick is a troll. A troll deliberately posts to annoy,
confuse or irritate people - I don't believe that applies to Rick. He
truly believes that his ideas about programming languages are important
and useful, even though everyone else sees them as confusing, pointless,
or dangerous. And he truly believes that his posts about religion are
helpful and that he is trying to "save" us - despite their annoyance,
irritation, and having the complete opposite effect of what he intends.

So no, he is not a troll. I think he is in a class of his own. He
makes it extremely tempting to play the amateur psychiatrist, but I
don't think that would be helpful. But I know that if ever I started to
act like he does, my family loves me enough to get me to professional help.

[Nobody]

On Wed, 12 Nov 2014 03:23:28 -0800, Rick C. Hodgin wrote:

> Its meaning is not identical to tnX++;. Its application in compiled
> code is identical to tnX++;, but its meaning is something else which
> is incomplete and invalid because the dereference is lost-but-
> provided-for in source code.

There are a lot of cases where expressions have both a value and
side-effects. Sometimes you want the value, sometimes you want the
side-effects, sometimes you want both.

It's senseless to single out that particular case just because

a) only the side-effects are being used, not the value,
b) there is a "simpler" expression which has the same side-effects, and
c) you once made a coding mistake due to getting the precedence wrong and
this must somehow be the fault of the language.

[Rick C. Hodgin]

On Friday, November 14, 2014 8:44:00 AM UTC-5, Nobody wrote:
> There are a lot of cases where expressions have both a value and
> side-effects. Sometimes you want the value, sometimes you want the
> side-effects, sometimes you want both.

What are some other ones?

> It's senseless to single out that particular case just because
>
> a) only the side-effects are being used, not the value,
> b) there is a "simpler" expression which has the same side-effects, and

The simpler expression doesn't have any side effects. It is a proper
expression which is complete and accomplishes everything its expression
form indicates.

> c) you once made a coding mistake due to getting the precedence wrong and
> this must somehow be the fault of the language.

There's no place to respond to statements like these. Anything I would
say could seem like an excuse.

I coded the *tnX++; form because it looked nicer in source code than the
++*tnX; form. I thought they did the same thing, but they did not and
that was my error. However, in coming to the understanding of what it's
doing (by looking at the disassembly), and then considering what that
actually means in terms of the "*tnX++;" expression, and what it actually
accomplishes in stand-alone non-volatile form... that's where I began to
realize it was a silly expression with no real ability to do any kind of
real work. It's kind of like "x = x = 5;" ... there's nothing wrong with
that expression. It won't cause problems or generate incorrect data...
but it's still incorrect.

I'm curious what your (or other people's) response is to "There are a
lot of cases..." above.

[seeplus]

On Saturday, November 15, 2014 1:50:13 AM UTC+11, Rick C. Hodgin wrote:
> On Friday, November 14, 2014 8:44:00 AM UTC-5, Nobody wrote:
> > There are a lot of cases where expressions have both a value and
> > side-effects. Sometimes you want the value, sometimes you want the
> > side-effects, sometimes you want both.
>
> What are some other ones?
>

> Best regards,
> Rick C. Hodgin

What is your rationale for producing yet another compiler and spending so much time on the endless details and complications.
Is it just because your lord is holding your hand, or is it simply an
academic challenge?

I think you mentioned somewhere you had something against purchasing from MS.
In that case MS has now dropped Visual Studio Express.

In it's place there is a FREE version at the "Professional" level with all the
stuff like MFC, SQL, allowed to distribute the exe for small enterprises, etc.

I have now installed it across all my backup computers and it works
just the same as my high $ "Ultimate" version for what I want to do.

This could be a game changer.

Aren't you better off letting Herb's guys worry about all this
compiler stuff while you get on with writing useful apps?

[Rick C. Hodgin]

On Saturday, November 15, 2014 7:17:51 PM UTC-5, seeplus wrote:
> On Saturday, November 15, 2014 1:50:13 AM UTC+11, Rick C. Hodgin wrote:
> > On Friday, November 14, 2014 8:44:00 AM UTC-5, Nobody wrote:
> > > There are a lot of cases where expressions have both a value and
> > > side-effects. Sometimes you want the value, sometimes you want the
> > > side-effects, sometimes you want both.
> >
> > What are some other ones?
> >
> > Best regards,
> > Rick C. Hodgin
>
> What is your rationale for producing yet another compiler and spending
> so much time on the endless details and complications.
> Is it just because your lord is holding your hand, or is it simply an
> academic challenge?

My goals are to create an entire hardware and software stack which is
an offering unto the Lord, and to other men and women on this planet,
as by the skills He has first given me, and the others who will come
to work on this project.

Rather than founding our pursuit on how we can make a lot of money by
creating some whizz-bang thing and then selling it because it's better
than our neighbor's, our goals are to create some whizz-bang thing and
then give it to our neighbors so that they can then use that as a base
to create even better tools, with the hope that our methodology will
encourage them to then also give back unto their neighbors.

Hoarding some ability or talent you possess behind a wall of "YOU HAD
BETTER PAY ME BEFORE YOU USE THIS PRODUCT BECAUSE I WILL COME AND TAKE
YOU TO COURT AND HAVE YOU THROWN INTO PRISON IF YOU DON'T GIVE ME MY
MONEY!" is entirely wrong. God gave us our talents to improve
ourselves and each other's lives, and not at a cost.

The economy in Heaven operates differently than it does here. Things
in Heaven do not wear out, nor are they consumed with use. We have
the burning bush (fire without consuming the bush), we have Jesus
demonstrating with the fishes and the loaves distributed to thousands.
God operates under the model of having and sharing while still
maintaining.

Things in man's world do not operate this way. The physical world
is separated from the spiritual world, yet God (in the bush, and
Jesus distributing the fishes and the loaves), operating in the
spirit, was able to manifest His power in the physical world for
all to see.

The closest that we have to this as a tangible thing that we can
individually manipulate and then distribute is the world of the
digital. We can possess a file and share a file with everyone else
at the same time. We do not have consumption of that file through
distribution or use.

The things that I desire to setup here in this world relate back to
the Lord's Prayer, "...Thy Kingdom come, Thy Will be done, on Earth
as it is in Heaven..."

I desire to look to the Lord and see what it was I did to achieve
and attain the various gifts I possess in their measure, and it does
not take me long to realize that I did nothing to achieve them. They
were gifts from Him, and I have been given other worldly gifts in
them that as I've gone through my life I've had this opportunity or
that opportunity, and it has all been from Him. I acknowledge that as
a foundation in my life and I am bringing the choices I have in my life
to bear around it.

The LibSF was created because I looked to those around me who are the
"towering giants" of the "open source" world, Richard Stallman and his
GNU and FSF, and Linus Torvalds and the Linux kernel and all of the
subsequent infrastructure that's been created because of GNU/Linux,
and as a Christian I asked myself: Is this what I want to be a part
of? We have RMS who has publicly stated he thinks that pedophilia
and necrophilia be made legal, to which I personally emailed him over
several days inquiring of him if this was accurate or not to which
he replied it was, and then witnessing to him about Jesus Christ and
our proper course in this world, to which we ended our email exchange
in a type of untenable abeyance. And next we have Linus Torvalds who
seems like a nice enough guy, but then had no issues with giving the
employees of Nvidia the finger on camera while using profanity.

The bottom line is I serve a living God, a God who cares so much
about His people that He came down here from Heaven Himself, and
put on a body of flesh and lived under our laws so that He could
take away the shame of our eternal sin state, that He could make
a way out of no way so that we could again enter into Heaven with
Him, to be where He is, because He loved us so much that He desired
to save us more than He desired to judge us.

I look to RMS and Torvalds, and I hold them next to Jesus Christ,
and I say, "Nope. I'll go with God every day forever," and the
Liberty Software Foundation was born that very day.

http://www.libsf.org

I have proceeded from that time desiring to build the software tools
and stack to have my own OS founded completely upon this love
offering of me back to God, following after the example of His
Love (capital L) offering unto mankind. I desire to look to Him
as my source of guidance and to use the unique and special talents
I have been blessed with for His Kingdom. I desire to take these
skills I possess (software development, low-level hardware
interests) and put them to use for His Kingdom, and not for the
kingdoms of this world (money, power, corporate entities).

I have not had success in my projects so far. It is truly astounding
the number of things which keep coming up against me. My wife and I
look at each other in disbelief sometimes. It's as if a mind is
working against me, holding me back, holding us back. It's really
something to behold. Yet I persist.

My offering is unto the Lord, a focused effort upon Him. I point
to Him in the areas of my talents and abilities, in the areas of
my model and desire, in the areas of my business and distribution.
I look to my Lord and Savior to be the template by which I proceed
with my life. And I realize also I must be doing something right
because I encounter nothing but a seemingly unending series of
nay-sayers who berate everything I stand for in this world, including
your message here.

> I think you mentioned somewhere you had something against purchasing
> from MS. In that case MS has now dropped Visual Studio Express.

I am against Microsoft as an entity. They are profit-based and they
do not have genuine love interests of God as their object or focus.
And it is not just Microsoft. It is all such entities which are
aligned in those ways. I was recently solicited by Google. They
wanted me to come out to the west coast and work for them as, the
recruiter said, they would find something really intriguing for
me to work on. They had seen my work on Visual FreePro, and then
Visual FreePro, Jr. on GitHub and they solicited me. I wrote back
and told them that my focuses in this world are not upon money,
nor in serving a money interest like Google, but rather I have a
desire to serve God, and my fellow man, with the talents and skills
I possess. I want to make other people's lives better by the
things I possess.

> In it's place there is a FREE version at the "Professional" level with
> all the stuff like MFC, SQL, allowed to distribute the exe for small
> enterprises, etc.
>
> I have now installed it across all my backup computers and it works
> just the same as my high $ "Ultimate" version for what I want to do.
>
> This could be a game changer.
>
> Aren't you better off letting Herb's guys worry about all this
> compiler stuff while you get on with writing useful apps?

I will try to make this as clear as possible for you:

Microsoft has no interest in giving away their products. They have
no interest in helping out other corporations. They have no interests
in helping you out, or anyone else out. Microsoft is moving everything
they possess as a corporation, and has been since about the same time
Apple came out with their iPhone, and specifically ever since the time
they publicly announced Windows Azure, to an online presence. They
want to be able to track you, monitor you, watch you, and I don't know
why. Windows 8 routinely calls home to Redmond. The newer versions
of Visual Studio have an online presence with a Microsoft account
allowing wonderful sharing of features and data, but also a monitoring
of who you are, where you code, what you code, when you're coding at
the office, when you're coding at home, etc.

Their free tools are not free. And none of the corporations of this
world are releasing free tools for the sake of releasing free tools.

We are fighting a battle in this world. There is an enemy spirit at
work against us. That spirit is the devil, and all of his demon imps.
They are operating in this world in an end-game attempt to take as
many of us down with their judged selves as is possible, and they
will succeed in taking down many many because most people will not
hear any part of the truth about what's going on in this world
because of sin and our sin nature.

It's very easy for the rational mind to rationalize away any possibility
that God is real, that we need Jesus Christ to take away our sin, and
that there are eternal consequences to our actions, because we don't
seemingly see the end result of them as they accumulate in our life.
A person gets away with some sin, and nothing happens, so they continue
on and get away with more, etc. In that way the wicked appear to
succeed, while the ones who do right fall behind and are often even
ridiculed for their desire to do what's right. All of this was
foretold in scripture that in the end times it would be like this.
And we are here. People like me who stand up explicitly for the Lord
doing nothing other than a constant outpouring from our souls unto
Him, and unto each of you, of loving kindness, of goodness, of the
free offerings of the best of our selves, are the continued subject
of scorn and ridicule because of it.

This battle is everywhere. People will either buy into Satan's lies
because of the sin nature and their desire to serve that sin nature,
or they will want the truth and they will come out from that sin
nature pursuit, come to the Lord, repent, ask forgiveness, and be
saved, and then be born again able to see for themselves the truth
of the lie of this world, and the truth of Jesus, the cross, and
the eternal Kingdom of God.

Jesus is our only hope in this world. He teaches us the ways of
peace, of love, of sharing with one another all that we possess,
rather than hoarding and creating artificial empires which need
not otherwise exist.

Jesus is the door. He is the key. He is the gateway out of the
falseness and the lies overtaking this world, causing people to
make the wrong choices, believing they are making the right choices,
because the enemy has setup a system in this world to make it seem
to the rational thinking person that such a choice is good, even
when it flies in direct contrast to what the Lord has taught us.

Microsoft, Google, Apple, Oracle, IBM, Intel, AMD, all of the big
corporations, they are all moving in pursuit of this false system
of the fallen empire, the one that will seemingly rule and reign
in this world until the day which Jesus foretold that in one day
Babylon is destroyed, and all of the commerce that goes along with
Babylon is also destroyed.

Jesus is our path. He is our foundation. He is our hope. He is
our Life. He is our all-in-all. And the enemy of this world
knows that as well as we do, and he goes out of his way to discredit
Jesus by rising up all kinds of crazy things being done in His name.
But the Lord calls out to men individually. He reaches into the
hearts of each of us continually, knocking at the door, desiring that
we will hear His knock, and invite Him in. And for all who do, He
comes in an sups with us, and we with Him, and we are then together
and our worries in this world are no longer worries, but reliance
upon Him because He is God Almighty and can make a way out of no
way. He is the everlasting, the rock of ages, the one who was, and
is, and is to come, the Almighty. We seek Him because of who He is,
and He is the Good Shepherd, and stronger than any enemy, and He
can and does protect us from the things in this world the enemy
tries to ensnare us in. We will go through hard times, but because
He is with us continually, His Holy Spirit presence in our lives,
we are never alone, nor are we without hope. When everything
seems to be falling apart to our right, to our left, in front of
us, and behind us, yet is He there to fill us with hope and peace
because we know that the things here in this world are but for a
tick of the clock, and then eternity begins, eternity that never
ends.

Jesus teaches me the right foundation. He leads them on the paths
that men should pursue. He gives us cues and guidance and takes
us within ourselves for a review of our lives to figure out the
courses we should take. And we know that no matter which misguided
direction we might originally set off on, so long as we set our
focus upon the Lord, our attention upon the Lord, our sights upon
the Lord, that He is capable, able, and desiring, to turn us in the
right direction that we may pursue continually, and forever closer,
that relationship with Him, here upon this Earth, that He may live
in us, through us, and reach out to many more souls to bring them
to knowledge of Him and His eternal Kingdom, that He might then
also save them by His one-time sacrifice at the cross, so that all
of us will go to Heaven together, entering in upon the time of our
death, or upon the time of His return, whichever comes first, so
that we will be forever shed of the sin nature of this world, of
death, of pain, of the anguish brought about by the evil enemy who
does nothing but lead the whole world astray as he waits for his
own day of eternal destruction.

I will advise you to avoid the large corporate things of this
world and pursue the work of the Lord in small people like me.
We are the ones who are not big power bases in worldly terms,
but rather we focus our attention upon THE one true big power
base, the Lord Himself. Our goals are His goals, our wants are
His wants, our focus is upon Him continually, as He guides us
in our lives continually more and more toward that focus as well
because He is literally living inside of us, His Holy Spirit
dwelling within us, guiding us, teaching us unseen things in this
world that we might know the truth, and make us free.

I pursue these goals with LibSF, and as a man, because I have tasted
and seen that the Lord is good. I state in no uncertain terms that
I will not have any degree of success unless the Lord allows it, and
that if He ever does allow it the success I have will be owing
entirely and only unto Him.

I am not a self-made man. I am a man made by the living loving God,
Jesus Christ. I acknowledge this in my life, and I proclaim it at
the forefront of all I do. I stand up and look to Him and say, "Yes,
Lord, I am here." And He continually guides me in my life.

Rick the man makes mistakes. Big mistakes. Rick the man is not
always making good decisions, or even right choices. But God is
faithful, and when I turn to Him in prayer He guides me back to
where I should be. And because He knows I have my heart truly set
upon Him, He guides me even in my mistakes, even in my wrong choices.
He is always there, a loving Father, a Good Shepherd, a friend closer
than a brother.

Why do I stand up in this world and pursue my own languages, my own
kernel, my own software, and even my own hardware? Because I do not
want to court the evil spirit ruler of this world who operates in
those who are not born again, who is leading men falsely and in
contrary ways doing only harm to themselves, and to others, in all
they do continually. I want to stand up for the Lord, and acknowledge
Him as my God, as my hope, as my salvation, as my true love and the
focus of my inner-most desires, that I will be His upon this world,
using all of the talents I possess in labor for His Kingdom.

I come to forums like this and speak about the Lord, about our need
of Him in our lives, in eternity, about damnation, about the reality
of sin and of the evil spirit influence in this world. I am often
ridiculed in so doing, yet I persist because I know who He is, and I
know who the enemy is, and how the enemy is speaking through every
person who is not a born again believer, and even those who are born
again believers it takes a continuous effort, a continuous focus upon
the Lord to maintain our way in this world, and we often make mistakes
because the enemy is powerful, pervasive, and persuasive.

I look to the Lord for guidance, and I set Him in my sights as the end-
goal of all the things I do in this world. I place Him at the
foundation, I place Him in the middle, and I seek Him at the top. He
is the One to whom I have my sights focused, and I am exceedingly
pleased about that because I also know what it's like to be on the
other side of faith, having not come to be a believer until the age
of 34.

Each of us is making a choice in this life. It comes with everything
we do. We choose to follow the Lord in everything we do, or we choose
to follow our own lusts and sinful appetites, which are handed to us,
being served by an enemy who is only too desiring to entice you into
his traps of sin because he knows the end-result of that sin: the
same place he's going: eternal, unending torment in Hell. And because
his sorry self is lost, and because he hates God, and because we were
made by God in the very image of God (in His likeness), he desires to
harm as many of us as he can.

But God is faithful and will save EVERY ONE who comes out from the
deception, who is willing to hear the truth.

The only human beings who will enter into Hell will be those who,
out of their personal love and lusts for sin, flatly, and in every
way, rejected the numerous calls of the Lord upon their life, so
that on that final day all men who enter into Hell will be without
any excuse whatsoever as to who it was, and what it was they rejected.

I urge everyone reading this to evaluate your life. You do not know
on which day the last day of your life will arrive. It could be today.
The Lord advises us to seek Him while He may still be found, and to
call upon Him while it is called today because we are not promised
tomorrow.

I urge everyone reading this to get down upon your knees, to free
yourselves from the bondage of the enemy, that you might ask Him to
come into your heart, into your life, into your mind, and into your
circumstances, that you might turn around from the false and sinful
paths you've been on and instead seek the path of truth in and through
Jesus Christ.

He is willing and wanting to receive you. His arms are outstretched
for you. Literally. He stands at the door of your heart and mind
and He knocks. Open the door and let Him in. Receive Him into your
heart and let Him change your life ... forever.

I serve the Lord in this world, which means I cannot stand or those
things in this world which are not serving the Lord. There are
certain things we must go through in this world, certain things we
cannot avoid, but my focus in every area of my life is to move up
and out of these things which are tied to falseness, and supplant
them continually with Him, with His Love, with His goodness, with
everything that is of His unending Love for us in this world.

I desire to not have a system where we are using bombs and tanks
and guns to suppress violence, but rather we are all changed
from the inside by His Holy Spirit presence so that there is no
violence. We stand up in this world and profess His Holy name
because of what He's done for us. And He can do the same for
all people everywhere, if they would turn toward Him and receive
Him. His one-time sacrifice at the cross was big enough to take
away the entire sin of the world. Everyone who puts their faith
and trust in the Lord Jesus Christ is forever forgiven, and has
passed from death into eternal life, and will not face judgment
upon that final day. But everyone who does not receive Him
stands condemned already for the sins they have committed from
the day of their birth, and the sin nature which each of us
inherits in that our bodies decay, and die, and that we are
driven by all manner of selfish lusts and wants which leads us
toward falseness, away from the things the Lord guides us in.

My name is Rick C. Hodgin, and I am a desiring servant of the
Lord Jesus Christ. I desire Him in all areas of my life, and
I turn to Him and serve Him with everything I possess. If He
has other plans for me, I will be content to go there and serve
Him in those plans. But until that day, He knows what my internal
wants and wishes are, to serve Him in the areas to which I have
skills.

He is my Life. Literally. And He can be yours too. Ask Him
to come into your heart ... and if you ask Him from the place
of true, honest, desiring from within to receive Him, you'll
find He's already there.

Love you. Peace.

[Geoff]

On Sat, 15 Nov 2014 17:15:00 -0800 (PST), "Rick C. Hodgin"
<rick.c...@gmail.com> wrote:

[massive screed snipped]

If you spent as much time working on your projects as you just did
writing this and your other posts in these news groups you would be
finished already.

I would also advise you to spend time with your family instead of
writing code at home and preaching online. God wants you to dedicate
yourself to and cherish your family and offspring, not worry about
people who are not your concern.

[Rick C. Hodgin]

On Saturday, November 15, 2014 9:17:33 PM UTC-5, Geoff wrote:
> On Sat, 15 Nov 2014 17:15:00 -0800 (PST), "Rick C. Hodgin"
> <rick.c...@gmail.com> wrote:
>
> [massive screed snipped]
>
> If you spent as much time working on your projects as you just did
> writing this and your other posts in these news groups you would be
> finished already.

The projects I'm on about are comprehensive. You're free to look at
the GitHub content I've posted since July, 2012. It's non-trivial.

But beyond that, I have a priority list in my life:
(1) Family always comes first in emergencies, but barring those:
(2) Regular daily job.
(3) Family.
(4) Regular needs around the house / in my life.
(5) Software development.

> I would also advise you to spend time with your family instead of
> writing code at home and preaching online.

You do not know enough about me personally to make such a statement.
You have never met me. You have never been to my home. You have
never spoken to my family. You only see the outward appearance as
through cold, written text. Your picture of me is not complete
enough to assess me in any way, but only to have generalizations.

From within that context, I appreciate the care you offer unto me,
that you would desire me to have an improved life. Thank you.

> God wants you to dedicate yourself to and cherish your family and
> offspring,

Absolutely He does. I'm glad you recognize that about God. :-)

> not worry about people who are not your concern.

There are no people who are not a Christian's concern. Whomever the
Lord brings to us in our lives, these are our concerns in this world.
Our work is a witness unto each of them, regarding Him. And we speak
of Him because He has commanded us to, and because all of us need Him.

I do not tout the things of Rick, but I do tout the things of Jesus.
He has a plan for every person, and has all of the solutions to all
of the questions people have, including what happens after we die.
He explains who we are, who He is, why He is needed, and what it means
to have Him in our life, and to not have Him in our life.

His is nothing less than the greatest story ever told ... and there
are not inappropriate times or places to discuss He, the author of the
entire universe, and each of us.