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

Groups > comp.lang.c > #112012 > unrolled thread

Unexpected error on x[0] != y[0]

Back to article view | Back to comp.lang.c

Contents

  Unexpected error on x[0] != y[0] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-12 06:57 -0700
    Re: Unexpected error on x[0] != y[0] bartc <bc@freeuk.com> - 2017-06-12 15:11 +0100
      Re: Unexpected error on x[0] != y[0] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-12 07:18 -0700
        Re: Unexpected error on x[0] != y[0] bartc <bc@freeuk.com> - 2017-06-12 15:29 +0100
          Re: Unexpected error on x[0] != y[0] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-12 07:41 -0700
            Re: Unexpected error on x[0] != y[0] bartc <bc@freeuk.com> - 2017-06-12 18:32 +0100
              Re: Unexpected error on x[0] != y[0] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-12 10:56 -0700
                Re: Unexpected error on x[0] != y[0] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-13 08:14 -0700
                  Re: Unexpected error on x[0] != y[0] bartc <bc@freeuk.com> - 2017-06-13 17:52 +0100
                    Re: Unexpected error on x[0] != y[0] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-13 10:00 -0700
                      Re: Unexpected error on x[0] != y[0] scott@slp53.sl.home (Scott Lurndal) - 2017-06-13 17:19 +0000
                        Re: Unexpected error on x[0] != y[0] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-13 10:33 -0700
                          Re: Unexpected error on x[0] != y[0] scott@slp53.sl.home (Scott Lurndal) - 2017-06-13 17:56 +0000
                            Re: Unexpected error on x[0] != y[0] Gareth Owen <gwowen@gmail.com> - 2017-06-13 19:45 +0100
                              Re: Unexpected error on x[0] != y[0] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-13 17:54 -0700
                                Re: Unexpected error on x[0] != y[0] joel.rees@gmail.com - 2017-06-13 20:57 -0700
                                Re: Unexpected error on x[0] != y[0] Gareth Owen <gwowen@gmail.com> - 2017-06-14 06:41 +0100
                                  Re: Unexpected error on x[0] != y[0] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-14 03:37 -0700
                                    Re: Unexpected error on x[0] != y[0] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-14 03:54 -0700
                            Re: Unexpected error on x[0] != y[0] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-13 17:45 -0700
                              Re: Unexpected error on x[0] != y[0] David Brown <david.brown@hesbynett.no> - 2017-06-14 08:49 +0200
                      Re: Unexpected error on x[0] != y[0] bartc <bc@freeuk.com> - 2017-06-13 19:07 +0100
                        Re: Unexpected error on x[0] != y[0] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-13 19:23 +0100
                          Re: Unexpected error on x[0] != y[0] bartc <bc@freeuk.com> - 2017-06-13 22:30 +0100
                            Re: Unexpected error on x[0] != y[0] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-13 23:29 +0100
                        Re: Unexpected error on x[0] != y[0] supercat@casperkitty.com - 2017-06-13 11:51 -0700
                        Re: Unexpected error on x[0] != y[0] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-13 17:53 -0700
                          Re: Unexpected error on x[0] != y[0] Reinhardt Behm <rbehm@hushmail.com> - 2017-06-14 13:34 +0800
                            Re: Unexpected error on x[0] != y[0] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-14 03:24 -0700
                          Re: Unexpected error on x[0] != y[0] David Brown <david.brown@hesbynett.no> - 2017-06-14 09:10 +0200
    Re: Unexpected error on x[0] != y[0] John Bode <jfbode1029@gmail.com> - 2017-06-12 07:26 -0700
      Re: Unexpected error on x[0] != y[0] "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-12 10:54 -0400
        Re: Unexpected error on x[0] != y[0] Keith Thompson <kst-u@mib.org> - 2017-06-12 09:23 -0700
      Re: Unexpected error on x[0] != y[0] Gareth Owen <gwowen@gmail.com> - 2017-06-12 19:05 +0100
    Re: Unexpected error on x[0] != y[0] Anton Shepelev <anton.txt@gmail.com> - 2017-06-12 17:29 +0300
    Re: Unexpected error on x[0] != y[0] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-12 15:52 +0100
      Re: Unexpected error on x[0] != y[0] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-12 08:31 -0700
    Re: Unexpected error on x[0] != y[0] joel.rees@gmail.com - 2017-06-13 22:09 -0700
      Re: Unexpected error on x[0] != y[0] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-14 11:24 +0100

Page 1 of 2  [1] 2  Next page →

#112012 — Unexpected error on x[0] != y[0]

I came across this today.  I had coded it this way by accident, but when
I saw the error message it made me wonder why it's an error in C?

    const char y[] = "Y";

    void example(void)
    {
        char x;

        x = derive_x_from_something();

        if (x[0] == y[0])
        {
            // Code here for match
        }
    }

In this case, I'm comparing x[0] to y[0].  Obviously y[0] works just
fine, but the C compiler complained about x[0], giving the error:

    Microsoft's C Compiler for Visual Studio 2010
    C2109, "subscript requires array or pointer type"

Obviously c is a char, but isn't it also, by definition, an array of
exactly one element?  Why wouldn't x[0] be valid?  I could use this
and have it work:

    if (((char *)&x)[0] == y[0])
    {
        // Code here for match
    }

In this case it doesn't change anything at all, but the reference is
then resolvable to the compiler because it's looking at the same single
byte through the new lens of a pointer type, rather than a single char.

It just struck me as odd because CAlive will recognize single variables
as arrays of exactly one element, and even do bounds checking on their
references at compile time.

Thank you,
Rick C. Hodgin

[toc] | [next] | [standalone]

#112014

On 12/06/2017 14:57, Rick C. Hodgin wrote:

>          char x;

>          if (x[0] == y[0])

> In this case, I'm comparing x[0] to y[0].  Obviously y[0] works just
> fine, but the C compiler complained about x[0], giving the error:
> 
>      Microsoft's C Compiler for Visual Studio 2010
>      C2109, "subscript requires array or pointer type"
> 
> Obviously c is a char, but isn't it also, by definition, an array of
> exactly one element?

It might be considered that. But x[0] is *(x+0). x needs to be a pointer 
of type char*. That conversion happens when x is an array (char[]), but 
not when x is just char. You can't dereference a char type.

> It just struck me as odd because CAlive will recognize single variables
> as arrays of exactly one element, and even do bounds checking on their
> references at compile time.

Not an good idea. Even worse than C mixing it all up so that you have no 
idea what is what, whether something is an array, or an actual pointer. 
But at least a simple  variable needs *(T*)& to be used as an 
array/pointer otherwise swathes of wrong code can get through undetected.

What would be wrong anyway with declaring char x[1] when you want a 
short array?


-- 
bartc

[toc] | [prev] | [next] | [standalone]

#112016

On Monday, June 12, 2017 at 10:11:10 AM UTC-4, Bart wrote:
> On 12/06/2017 14:57, Rick C. Hodgin wrote:
> > It just struck me as odd because CAlive will recognize single variables
> > as arrays of exactly one element, and even do bounds checking on their
> > references at compile time.
> 
> Not an good idea. Even worse than C mixing it all up so that you have no 
> idea what is what, whether something is an array, or an actual pointer. 
> But at least a simple  variable needs *(T*)& to be used as an 
> array/pointer otherwise swathes of wrong code can get through undetected.

CAlive takes the viewpoint of data being data, and allows you to access
it in that way.  It considers all levels of access to be type checking,
and enforces those rules, but ultimately the underlying data exists as
a byte or sequence of bytes (or some bits within), and that is the data
being wielded.  There is no issue in translating char c to a pointer to
the one-byte value of c's content, or creating an array reference to the
one-byte content of c's data, etc.

> What would be wrong anyway with declaring char x[1] when you want a 
> short array?

Nothing, and that would work.  But beneath the hood, the data is the
same ... so why not allow them to merge?

Thank you,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#112019

On 12/06/2017 15:18, Rick C. Hodgin wrote:
> On Monday, June 12, 2017 at 10:11:10 AM UTC-4, Bart wrote:
>> On 12/06/2017 14:57, Rick C. Hodgin wrote:
>>> It just struck me as odd because CAlive will recognize single variables
>>> as arrays of exactly one element, and even do bounds checking on their
>>> references at compile time.
>>
>> Not an good idea. Even worse than C mixing it all up so that you have no
>> idea what is what, whether something is an array, or an actual pointer.
>> But at least a simple  variable needs *(T*)& to be used as an
>> array/pointer otherwise swathes of wrong code can get through undetected.
> 
> CAlive takes the viewpoint of data being data, and allows you to access
> it in that way.  It considers all levels of access to be type checking,
> and enforces those rules, but ultimately the underlying data exists as
> a byte or sequence of bytes (or some bits within), and that is the data
> being wielded.  There is no issue in translating char c to a pointer to
> the one-byte value of c's content, or creating an array reference to the
> one-byte content of c's data, etc.
> 
>> What would be wrong anyway with declaring char x[1] when you want a
>> short array?
> 
> Nothing, and that would work.  But beneath the hood, the data is the
> same ... so why not allow them to merge?

Because this is not assembly code?

But such a thing would be highly unusual, so I don't see the problem 
with having to be explicit about it. Otherwise anyone reading the code 
won't have a clue what's going on. Especially if you write this:

  x[0][0][0][i][0][0][0][0][0][0][0][j][0][k][0]

which I believe your approach would allow.

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#112022

On Monday, June 12, 2017 at 10:29:43 AM UTC-4, Bart wrote:
> On 12/06/2017 15:18, Rick C. Hodgin wrote:
> > On Monday, June 12, 2017 at 10:11:10 AM UTC-4, Bart wrote:
> >> What would be wrong anyway with declaring char x[1] when you want a
> >> short array?
> > 
> > Nothing, and that would work.  But beneath the hood, the data is the
> > same ... so why not allow them to merge?
> 
> Because this is not assembly code?

As the developer, I presume to have some knowledge over the data I'm
working with, knowledge which exceeds the compiler's ability to know
things for me.

As such, if things are allowable legally in the hardware, I intend to
expose them to the developer.  The developer does not have to use them,
and can stay within the warm, safe waters of conventional language use,
but if they do dip into the cooler, more treacherous waters of closer-
to-assembly use, I'm not going to stop them.  They're adults, they can
choose for themselves.

> But such a thing would be highly unusual, so I don't see the problem 
> with having to be explicit about it. Otherwise anyone reading the code 
> won't have a clue what's going on. Especially if you write this:
> 
>   x[0][0][0][i][0][0][0][0][0][0][0][j][0][k][0]
> 
> which I believe your approach would allow.

Assuming i, j, k were known to be zero at compile-time, yes.  And FWIW,
I've never considered that possibility before.  Very interesting.  It
would literally resolve down to the single byte in question, and yes it
would be legal in CAlive, because that particular expression is exactly
equal to char x; in its one-byte access.

Thank you,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#112061

On 12/06/2017 15:41, Rick C. Hodgin wrote:
> On Monday, June 12, 2017 at 10:29:43 AM UTC-4, Bart wrote:

>> But such a thing would be highly unusual, so I don't see the problem
>> with having to be explicit about it. Otherwise anyone reading the code
>> won't have a clue what's going on. Especially if you write this:
>>
>>    x[0][0][0][i][0][0][0][0][0][0][0][j][0][k][0]
>>
>> which I believe your approach would allow.
> 
> Assuming i, j, k were known to be zero at compile-time, yes.  And FWIW,
> I've never considered that possibility before.  Very interesting.  It
> would literally resolve down to the single byte in question, and yes it
> would be legal in CAlive, because that particular expression is exactly
> equal to char x; in its one-byte access.

This also needs to make sense within the type system. Allowing any 
scalar variable X to also be expressed as X[0] can give rise to 
confusing code as shown; another example is:

   X == X[0]

But take:

   int A[4];

And the expression:

   A[0];

Now, this is ambiguous. Does it mean the same thing as A (as in the X 
example), which is a 4-element array of ints, or does it index the array 
this time, to give the first int?

Or is X==X[0] only allowed when X is scalar?

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#112066

On Monday, June 12, 2017 at 1:32:45 PM UTC-4, Bart wrote:
> On 12/06/2017 15:41, Rick C. Hodgin wrote:
> > On Monday, June 12, 2017 at 10:29:43 AM UTC-4, Bart wrote:
> 
> >> But such a thing would be highly unusual, so I don't see the problem
> >> with having to be explicit about it. Otherwise anyone reading the code
> >> won't have a clue what's going on. Especially if you write this:
> >>
> >>    x[0][0][0][i][0][0][0][0][0][0][0][j][0][k][0]
> >>
> >> which I believe your approach would allow.
> > 
> > Assuming i, j, k were known to be zero at compile-time, yes.  And FWIW,
> > I've never considered that possibility before.  Very interesting.  It
> > would literally resolve down to the single byte in question, and yes it
> > would be legal in CAlive, because that particular expression is exactly
> > equal to char x; in its one-byte access.
> 
> This also needs to make sense within the type system. Allowing any 
> scalar variable X to also be expressed as X[0] can give rise to 
> confusing code as shown; another example is:
> 
>    X == X[0]

In CAlive, you're considering it from a data-centric point of view.
So if you knew what X was, you would have an image in your mind of
what data it held, and you would be able to visualize X and X[0] as
mapping to the same thing.

CAlive also intends to be closely integrated with a GUI editor, so
it could probably provide feedback to indicate this in a literal and
real visual way.

In the above example, it would probably produce a level-4 warning
that the statement is a constant.

> But take:
>    int A[4];
> 
> And the expression:
>    A[0];
> 
> Now, this is ambiguous. Does it mean the same thing as A (as in the X 
> example), which is a 4-element array of ints, or does it index the array 
> this time, to give the first int?

It's contextual.  If you were using a scalar and A in some way, then A
would resolve to just the first element.  If it were a different type,
then it would look for the required operator as would be defined in
CAlive's global operator scope, or in an associated class, etc.

> Or is X==X[0] only allowed when X is scalar?

Look at the underlying data.  If the syntax resolves down to the same
root source of the fundamental type, then it can be used.

Thank you,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#112108

On Monday, June 12, 2017 at 1:56:39 PM UTC-4, Rick C. Hodgin wrote:
> On Monday, June 12, 2017 at 1:32:45 PM UTC-4, Bart wrote:
> > On 12/06/2017 15:41, Rick C. Hodgin wrote:
> > > On Monday, June 12, 2017 at 10:29:43 AM UTC-4, Bart wrote:
> > 
> > >> But such a thing would be highly unusual, so I don't see the problem
> > >> with having to be explicit about it. Otherwise anyone reading the code
> > >> won't have a clue what's going on. Especially if you write this:
> > >>
> > >>    x[0][0][0][i][0][0][0][0][0][0][0][j][0][k][0]
> > >>
> > >> which I believe your approach would allow.
> > > 
> > > Assuming i, j, k were known to be zero at compile-time, yes.  And FWIW,
> > > I've never considered that possibility before.  Very interesting.  It
> > > would literally resolve down to the single byte in question, and yes it
> > > would be legal in CAlive, because that particular expression is exactly
> > > equal to char x; in its one-byte access.
> > 
> > This also needs to make sense within the type system. Allowing any 
> > scalar variable X to also be expressed as X[0] can give rise to 
> > confusing code as shown; another example is:
> > 
> >    X == X[0]
> 
> In CAlive, you're considering it from a data-centric point of view.
> So if you knew what X was, you would have an image in your mind of
> what data it held, and you would be able to visualize X and X[0] as
> mapping to the same thing.
> 
> CAlive also intends to be closely integrated with a GUI editor, so
> it could probably provide feedback to indicate this in a literal and
> real visual way.
> 
> In the above example, it would probably produce a level-4 warning
> that the statement is a constant.
> 
> > But take:
> >    int A[4];
> > 
> > And the expression:
> >    A[0];
> > 
> > Now, this is ambiguous. Does it mean the same thing as A (as in the X 
> > example), which is a 4-element array of ints, or does it index the array 
> > this time, to give the first int?
> 
> It's contextual.  If you were using a scalar and A in some way, then A
> would resolve to just the first element.  If it were a different type,
> then it would look for the required operator as would be defined in
> CAlive's global operator scope, or in an associated class, etc.
> 
> > Or is X==X[0] only allowed when X is scalar?
> 
> Look at the underlying data.  If the syntax resolves down to the same
> root source of the fundamental type, then it can be used.

Bart and supercat, I'm curious what you think of this data-centric
view of a C-like programming language?  Protocols for maintaining
types exist, and are given as warnings, but if the underlying data
conversion is legal from a data-size point of view, then there is
no error generated, save the option to enforce protocols.

I think it would greatly simplify the equivalent of what we see as
a "C Standard" type document for "CAlive Standard" in that all data
is interchangeable, and that only in the case of type enforcement
does CAlive consider it illegal to do things that are otherwise legal
from a processor's point of view, or from even a data point of view.

Thank you,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#112112

On 13/06/2017 16:14, Rick C. Hodgin wrote:

>> Look at the underlying data.  If the syntax resolves down to the same
>> root source of the fundamental type, then it can be used.
> 
> Bart and supercat, I'm curious what you think of this data-centric
> view of a C-like programming language?

It sounds a bit like the typeless language BCPL.

   Protocols for maintaining
> types exist, and are given as warnings, but if the underlying data
> conversion is legal from a data-size point of view, then there is
> no error generated, save the option to enforce protocols.
> 
> I think it would greatly simplify the equivalent of what we see as
> a "C Standard" type document for "CAlive Standard" in that all data
> is interchangeable, and that only in the case of type enforcement
> does CAlive consider it illegal to do things that are otherwise legal
> from a processor's point of view, or from even a data point of view.

So you're taking all the naughty things that are already possibly in C 
but requiring explicit casts, and removing the need for the casts?

That doesn't sound a good move! Well, not unless this new language is 
expected to be lower level than C.

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#112113

On Tuesday, June 13, 2017 at 12:53:01 PM UTC-4, Bart wrote:
> On 13/06/2017 16:14, Rick C. Hodgin wrote:
> 
> >> Look at the underlying data.  If the syntax resolves down to the same
> >> root source of the fundamental type, then it can be used.
> > 
> > Bart and supercat, I'm curious what you think of this data-centric
> > view of a C-like programming language?
> 
> It sounds a bit like the typeless language BCPL.
> 
> >   Protocols for maintaining
> > types exist, and are given as warnings, but if the underlying data
> > conversion is legal from a data-size point of view, then there is
> > no error generated, save the option to enforce protocols.
> > 
> > I think it would greatly simplify the equivalent of what we see as
> > a "C Standard" type document for "CAlive Standard" in that all data
> > is interchangeable, and that only in the case of type enforcement
> > does CAlive consider it illegal to do things that are otherwise legal
> > from a processor's point of view, or from even a data point of view.
> 
> So you're taking all the naughty things that are already possibly in C 
> but requiring explicit casts, and removing the need for the casts?
> 
> That doesn't sound a good move! Well, not unless this new language is 
> expected to be lower level than C.

Full typing protocols can be enforced, and will be warned about
regardless.  But my goals are to provide people with a high-end
data processing tool, one which allows people (as the developers
in charge) to bypass types and access the data they seek as they
are able if they're willing to do so in a way that operates
outside of typing.

I prefer to do this in certain cases, for example, such as in
unions, and specifically for function pointer addresses, which
I prefer to wield only as unsigned integers and not as fully
typed forms.

Thank you,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#112114

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>On Tuesday, June 13, 2017 at 12:53:01 PM UTC-4, Bart wrote:
>> On 13/06/2017 16:14, Rick C. Hodgin wrote:
>> 
>> >> Look at the underlying data.  If the syntax resolves down to the same
>> >> root source of the fundamental type, then it can be used.
>> > 
>> > Bart and supercat, I'm curious what you think of this data-centric
>> > view of a C-like programming language?
>> 
>> It sounds a bit like the typeless language BCPL.
>> 
>> >   Protocols for maintaining
>> > types exist, and are given as warnings, but if the underlying data
>> > conversion is legal from a data-size point of view, then there is
>> > no error generated, save the option to enforce protocols.
>> > 
>> > I think it would greatly simplify the equivalent of what we see as
>> > a "C Standard" type document for "CAlive Standard" in that all data
>> > is interchangeable, and that only in the case of type enforcement
>> > does CAlive consider it illegal to do things that are otherwise legal
>> > from a processor's point of view, or from even a data point of view.
>> 
>> So you're taking all the naughty things that are already possibly in C 
>> but requiring explicit casts, and removing the need for the casts?
>> 
>> That doesn't sound a good move! Well, not unless this new language is 
>> expected to be lower level than C.
>
>Full typing protocols can be enforced, and will be warned about
>regardless.  But my goals are to provide people with a high-end
>data processing tool, one which allows people (as the developers
>in charge) to bypass types and access the data they seek as they
>are able if they're willing to do so in a way that operates
>outside of typing.

You mean like Python?  Or R?  or SQL?

[toc] | [prev] | [next] | [standalone]

#112115

On Tuesday, June 13, 2017 at 1:19:16 PM UTC-4, Scott Lurndal wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >Full typing protocols can be enforced, and will be warned about
> >regardless.  But my goals are to provide people with a high-end
> >data processing tool, one which allows people (as the developers
> >in charge) to bypass types and access the data they seek as they
> >are able if they're willing to do so in a way that operates
> >outside of typing.
> 
> You mean like Python?  Or R?  or SQL?

No.  I mean more like what's allowed at the assembly level.  Something
similar would also be allowed in CAlive's use and access to data, but
with more guidance and management than what assembly would give you, so
as to help prevent errors, while still affording a developer that low-
level power when needed.

Thank you,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#112118

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>On Tuesday, June 13, 2017 at 1:19:16 PM UTC-4, Scott Lurndal wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> >Full typing protocols can be enforced, and will be warned about
>> >regardless.  But my goals are to provide people with a high-end
>> >data processing tool, one which allows people (as the developers
>> >in charge) to bypass types and access the data they seek as they
>> >are able if they're willing to do so in a way that operates
>> >outside of typing.
>> 
>> You mean like Python?  Or R?  or SQL?
>
>No.  I mean more like what's allowed at the assembly level.  Something
>similar would also be allowed in CAlive's use and access to data, but
>with more guidance and management than what assembly would give you, so
>as to help prevent errors, while still affording a developer that low-
>level power when needed.

Who would possibly want such a thing, and for what purpose?

[toc] | [prev] | [next] | [standalone]

#112124

scott@slp53.sl.home (Scott Lurndal) writes:

> Who would possibly want such a thing,

Jesus, apparently.

> and for what purpose?

Mysterious ways, sir.

[toc] | [prev] | [next] | [standalone]

#112146

On Tuesday, June 13, 2017 at 2:45:29 PM UTC-4, gwowen wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
> > Who would possibly want such a thing,
> Jesus, apparently.

Making fun of Jesus is never wise.  It heaps destruction upon your head.

> > and for what purpose?
> Mysterious ways, sir.

Thank you,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#112158

On Wednesday, June 14, 2017 at 9:54:20 AM UTC+9, Rick C. Hodgin wrote:
> On Tuesday, June 13, 2017 at 2:45:29 PM UTC-4, gwowen wrote:
> >  (Scott Lurndal) writes:
> > > Who would possibly want such a thing,
> > Jesus, apparently.
> 
> Making fun of Jesus is never wise.  It heaps destruction upon your head.

I'm sure He had a good laugh from it. (Near as I can tell, He has a sense 
of humor. Remember how He responded at the marriage when His mother said 
they were out of wine?

> > > and for what purpose?
> > Mysterious ways, sir.

Speaking of mysterious ways, I'm sure the question of whether the chuckle 
were followed by a thunderbolt or not would be determined (by Him, of 
course) by the tendency of the thunderbolt to save gwowen's soul. There 
may be better ways to save him.

--
Joel Rees

Ranting randomly:
http://reiisi.blogspot.com

[toc] | [prev] | [next] | [standalone]

#112164

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

> On Tuesday, June 13, 2017 at 2:45:29 PM UTC-4, gwowen wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>> > Who would possibly want such a thing,
>> Jesus, apparently.
>
> Making fun of Jesus is never wise.  It heaps destruction upon your head.

I am not making fun of Jesus, I am making fun of you.

The fact you cannot tell the difference tells is part of what I'm mocking.

Contrary to what you believe, the teachings of Jesus and the teachings
of Hodgkin are not very similar at all.

[toc] | [prev] | [next] | [standalone]

#112173

On Wednesday, June 14, 2017 at 1:41:25 AM UTC-4, gwowen wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> > On Tuesday, June 13, 2017, gwowen wrote:
> >> scott@slp53.sl.home (Scott Lurndal) writes:
> >> > Who would possibly want such a thing,
> >> Jesus, apparently.
> >
> > Making fun of Jesus is never wise.  It heaps destruction upon your head.
> 
> I am not making fun of Jesus, I am making fun of you.

See Matthew 25:40 below.

> The fact you cannot tell the difference tells is part of what I'm mocking.

http://biblehub.com/matthew/25-40.htm

> Contrary to what you believe, the teachings of Jesus and the teachings
> of Hodgin are not very similar at all.

What do you know of the teachings of Jesus, gwowen?  Or the teachings
of Hodgin for that matter?

Thank you,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#112174

The goal with CAlive's data model is to operate on data normally, while
still having the native ability to go lower when needed.  You can choose
to bypass CAlive's enforced typing, and work on data as data, rather than
type expressions of data.

It's a powerful feature.  I'm very pleased to include it.

Thank you,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#112144

On Tuesday, June 13, 2017 at 1:56:57 PM UTC-4, Scott Lurndal wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >On Tuesday, June 13, 2017 at 1:19:16 PM UTC-4, Scott Lurndal wrote:
> >> You mean like Python?  Or R?  or SQL?
> >No.  I mean more like what's allowed at the assembly level.  Something
> >similar would also be allowed in CAlive's use and access to data, but
> >with more guidance and management than what assembly would give you, so
> >as to help prevent errors, while still affording a developer that low-
> >level power when needed.
> 
> Who would possibly want such a thing, and for what purpose?

Why would someone write code in C?  There are languages far easier and
less prone to error to write code in.  C is fastest if it's done properly.
But even so, it's not as fast as assembly can be ... if it's also done
properly.

By giving people tools to dip down into that lower-level, by seeing and
recognizing data as data and not as fundamental C types, it then gives
them a new ability to potentially access things in ways that wasn't
previously possible within C-like forms alone.

I'm also going to try to allow inline assembly instructions which are
able to access data without having to use _asm {..} blocks.

But, that's a low priority.

Thank you,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web