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

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

"Death To C"

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

Contents

  "Death To C" Lynn McGuire <lmc@winsim.com> - 2015-05-04 14:41 -0500
    Re: "Death To C" Melzzzzz <mel@zzzzz.com> - 2015-05-04 22:16 +0200
      Re: "Death To C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-04 13:26 -0700
        Re: "Death To C" Melzzzzz <mel@zzzzz.com> - 2015-05-04 22:51 +0200
        Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-04 22:02 +0100
          Re: "Death To C" Melzzzzz <mel@zzzzz.com> - 2015-05-05 00:06 +0200
    Re: "Death To C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-04 13:22 -0700
      Re: "Death To C" Melzzzzz <mel@zzzzz.com> - 2015-05-04 22:41 +0200
        Re: "Death To C" Robert Wessel <robertwessel2@yahoo.com> - 2015-05-04 20:25 -0500
          Bounds checking in C (Was: "Death To C") gazelle@shell.xmission.com (Kenny McCormack) - 2015-05-05 02:15 +0000
            Re: Bounds checking in C (Was: "Death To C") BGB <cr88192@hotmail.com> - 2015-05-06 10:23 -0500
          Re: "Death To C" Les Cargill <lcargill99@comcast.com> - 2015-05-04 21:36 -0500
            Re: "Death To C" Robert Wessel <robertwessel2@yahoo.com> - 2015-05-05 01:01 -0500
              Re: "Death To C" Les Cargill <lcargill99@comcast.com> - 2015-05-05 12:23 -0500
            Re: "Death To C" CHIN Dihedral <dihedral88888@gmail.com> - 2015-05-05 03:06 -0700
          Re: "Death To C" Ian Collins <ian-news@hotmail.com> - 2015-05-05 17:43 +1200
            Re: "Death To C" Robert Wessel <robertwessel2@yahoo.com> - 2015-05-05 01:00 -0500
              Re: "Death To C" Robert Wessel <robertwessel2@yahoo.com> - 2015-05-05 01:13 -0500
                Re: "Death To C" Ian Collins <ian-news@hotmail.com> - 2015-05-05 19:15 +1200
                  Re: "Death To C" Robert Wessel <robertwessel2@yahoo.com> - 2015-05-05 02:41 -0500
                    Re: "Death To C" Ian Collins <ian-news@hotmail.com> - 2015-05-05 20:12 +1200
          Re: "Death To C" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-05 06:48 +0000
          Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-05 10:57 +0100
            Re: "Death To C" asetofsymbols@gmail.com - 2015-05-05 16:53 -0700
            Re: "Death To C" Nobody <nobody@nowhere.invalid> - 2015-05-06 08:10 +0100
              Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-06 09:53 +0100
                Re: "Death To C" Richard Heathfield <rjh@cpax.org.uk> - 2015-05-06 13:49 +0100
                  Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-06 14:29 +0100
                  Re: "Death To C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-06 09:43 -0700
                    Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-06 18:24 +0100
            Re: "Death To C" asetofsymbols@gmail.com - 2015-05-08 00:44 -0700
              Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-08 13:49 +0100
      Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-04 22:15 +0100
        Re: "Death To C" BGB <cr88192@hotmail.com> - 2015-05-08 09:09 -0500
      Re: "Death To C" Stephen Sprunk <stephen@sprunk.org> - 2015-05-04 16:18 -0500
      Re: "Death To C" Ian Collins <ian-news@hotmail.com> - 2015-05-05 12:49 +1200
    Re: "Death To C" raltbos@xs4all.nl (Richard Bos) - 2015-05-08 21:52 +0000
    Re: "Death To C" Merikissa <merikissa@no.spam.net> - 2015-05-10 04:04 +0300
    Re: "Death To C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-05-13 08:11 -0700
      Re: "Death To C" David Kleinecke <dkleinecke@gmail.com> - 2015-05-13 10:00 -0700
        Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-13 18:20 +0100
          Re: "Death To C" David Kleinecke <dkleinecke@gmail.com> - 2015-05-14 10:47 -0700
            Re: "Death To C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-05-14 11:09 -0700
            Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-15 19:21 +0100
              Re: "Death To C" David Kleinecke <dkleinecke@gmail.com> - 2015-05-16 09:10 -0700
                Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-16 20:45 +0100
                  Re: "Death To C" David Kleinecke <dkleinecke@gmail.com> - 2015-05-17 09:38 -0700
          Re: "Death To C" raltbos@xs4all.nl (Richard Bos) - 2015-05-17 10:47 +0000
            Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-17 12:20 +0100
        Re: "Death To C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-05-13 10:24 -0700
          Re: "Death To C" David Brown <david.brown@hesbynett.no> - 2015-05-13 22:01 +0200
      Re: "Death To C" Nobody <nobody@nowhere.invalid> - 2015-05-14 07:48 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#61556

Robert Wessel wrote:
> On Tue, 05 May 2015 19:15:25 +1200, Ian Collins <ian-news@hotmail.com>
> wrote:
>> Robert Wessel wrote:
>>>
>>> A more direct example of the difficulty:
>>>
>>>     struct s {char s[8]; char t[8]; void (*fp)();} s1;
>>>     void *vp = &s1;
>>>     char *cp = vp;
>>>     cp += offsetof(s, t);
>>>     strcpy(cp, "abcdefghihjk");
>>>
>>> How do you prevent the strcpy from overlaying the function pointer?
>>> Assume that these five lines are wildly separated.
>>
>> You can't...
>>
>> These are the sorts of examples where an idiomatic C++ solution can lead
>> to much safer code, often where the only overhead is in the bounds checking.
>
> I'm confused.  I came in with "C makes thorough bounds checking almost
> impossible.  You *can* check named (static/automatic) and allocated
> objects as a whole fairly easily (…), doing that within objects is
> nearly, if not actually, impossible while maintaining full C
> semantics."  And I got people disagreeing with me.

Not me...

> Certainly following some good coding techniques can help a great deal,
> but you're relying on the programmer to do it right, and it can't be
> easily enforced by the compiler.

One very common coding rule in C++ is not to expose raw pointers, which 
while unenforceable by the compiler, is enforceable through code review. 
  Not foolproof, but better than C where you often cant avoid exposing 
raw pointers.

I guess you could enforce a similar rule in C through code review: if a 
struct has a raw pointer, it must be used as an opaque type.

-- 
Ian Collins

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

#61548

Robert Wessel <robertwessel2@yahoo.com> wrote:

(snip)
>> It's easy enough to implement safe arrays in another
>>> language, but they you lose the speed of raw writes to memory.

>>It's easy enough to bounds check but who does it?
 
> No it's really not.  C makes thorough bounds checking almost
> impossible.  You *can* check named (static/automatic) and allocated
> objects as a whole fairly easily (although with fairly high overhead,
> usually with some sort of fat pointer scheme), doing that within
> objects is nearly, if not actually, impossible while maintaining full
> C semantics.

Yes it has to be done for whole allocations, as that is the
way C defines what you can do with pointers. If that isn't good
enough, you just have to specifically allocate each object you
want checked.

In the OS/2 1.x days, I could easily do this, and with no additional
overhead.  (That is, no more than 80286 protected mode does for
far pointer access.)

Instead of calling malloc(), I directly called the OS/2 segment
allocator, allocating the exact length needed. Then supply a zero
offset and store into a pointer. The 80286 hardware traps access
to non-allocated segment selectors, and access past the end of
the allocated length for each segment. One thing not checked is
that offsets will wrap at 64K, and so could come back into the
actual segment. Then again, with 16 bit int, subscript calculation
itself could wrap. But you don't have to worry about overwriting
any other segment.

For the 80386, segments and segment selectors are still there,
and the Watcom C compiler will generate large model 32 bit code
(pointers have a 16 bit segment selector, and 32 bit offset).
It might be that OS/2 2.0 and up can use that, but pretty much
all the other OS expect to allocate one big segment (maybe two,
a code and a data segment).  No help in bounds checking.

-- glen

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

#61557

On 05/05/2015 02:25, Robert Wessel wrote:
> On Mon, 4 May 2015 22:41:34 +0200, Melzzzzz <mel@zzzzz.com> wrote:
>
>> On Mon, 4 May 2015 13:22:02 -0700 (PDT)
>> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:

>> It's easy enough to implement safe arrays in another
>>> language, but they you lose the speed of raw writes to memory.

It's not necessarily slow. If the bounds *are* known, then frequently 
you will also know that accesses are within bounds:

for (i=0; i<=len(A); ++i)
    A[i]=0;

No bounds checking needed here. But C doesn't always have a len(A) that 
is directly tied to the array bounds.

>> It's easy enough to bounds check but who does it?
>
> No it's really not.  C makes thorough bounds checking almost
> impossible.  You *can* check named (static/automatic) and allocated
> objects as a whole fairly easily (although with fairly high overhead,
> usually with some sort of fat pointer scheme), doing that within
> objects is nearly, if not actually, impossible while maintaining full
> C semantics.

Part of the problem is the language being vague about what is and isn't 
an array. Any pointer can potentially be used to step along an array 
whether it points to the middle of one or not.

And even if it does, it won't know the bounds (only when it goes past 
the edge of an allocation, if it uses fat pointers), if it is a row of a 
2D array for example, or a slice that you've just decided to use.

So I think that making array and pointer ops interchangeable, while not 
exactly a mistake, doesn't help.

-- 
Bartc

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

#61591

Bart wrote something as:

< for(j=0;j<a(0); ++j) a[j]=0
Yes done but using C++ and matrix not arrays 


#include <stdio.h>
#include <stdlib.h>
#include <stdarg.h>
#include <iostream.h>

#define  G(a,b)   if(a)goto b
#define  R   return
#define  P   printf
#define  M   malloc
#define  Fr  free
#define  F   for
#define  S   sizeof
#define  u8  unsigned char
#define  u16 unsigned short
#define  u32 unsigned
#define  i32 int
#define  d64 double

/*
Each element until sz is u32
pInd[0],pInd[1],..,pInd[pInd[0]], sizeElement, sz, [matrix data]
     0       1          pInd[0]   pInd[0]+1    pInd[0]+2     indirizzo
     1       2          pInd[0]+1 pInd[0]+2    pInd[0]+3     nelement
pInd[0]:         is the number of index as 32 bit
pInd[1]:         is the first max index as 32 bit
....
pInd[pInd[0]]:   is the last max index
pInd[pInd[0]+1]: is the size of element as 32 bit

sz:     size of   "data" area
data    is matrix "data" area
*/

// access to size of matrix data    as u32* 
#define  SZ(a)   ((a)+*(a)+2)
// access to size element of matrix as u32*
#define  SZe(a)  ((a)+*(a)+1)
// access to data                   as u8*
#define  Data(a) (u8*) ((a)+*(a)+3)

/*
  reserve mem space to matrix of element msize for dimension
  i0xi1x...xin taken as input
  where i0, i1 etc are max+1 index and n<=255
  the last max+1 index is -1 that end the input
  Return -1 for error
  Return  0 all ok
NB
 **The first function to call on pm [construct matrix] **
 **the last  function to call on pm [destruct  matrix] **
*/
i32 Mcon(u32**  pm, u32  msize, ...)
{va_list           ap;
 u32       v, i, s, j;
 u32         arr[256];

    G(pm, l1);
l0:     R -1;                   // for error
n0:     va_end(ap); *pm=0; G(1,l0);
l1: G(msize, l3);  Fr(*pm);      /* free the Matrix */
l2:     R  0;                   // for all ok
y0:     va_end(ap); G(1,l2);
l3: va_start(ap, msize); G(msize>0xFFF, n0); G(msize==1, n0); i=0;
l4:   v=va_arg(ap, u32); //v the first index;if i==0 means no element
      G(v>0xFFFF && v!= -1, n0); G(v!=-1, la); G(i==0, n0); 
           s=1; j=1;
l5:        s*=arr[j-1]; G(s>0xFFFFF, n0); ++j; G( j<=i, l5);
           s*=msize;    G(s>0xFFFFF, n0);
           *pm=(u32*)M((i+3)*sizeof(u32)+s); G(*pm==0, n0);
           (*pm)[0]=i; *SZe(*pm)=msize; *SZ(*pm)=s; j=1;
l6:        (*pm)[j]=arr[j-1]; ++j; G(j<=i,l6);
           G(1,y0);
la:   G(i>255, n0); arr[i++]=v; G(1,l4);
}

// return one pointer to element
// or 0 if find some error
u8*  Aelm(u32*  pm, ...)
{va_list              ap;
 u8                   *r;
 u32 maxn, size, v, s, i;

    G(pm,l1);
l0:   R  0;
n0:   va_end(ap); G(1,l0);
l1: maxn=pm[0]; size= *SZe(pm); G(size>0xFFFF, l0);
                              //                0 1  
    G(maxn>=256||maxn==0,l0); //for 2x2 y*n+x  (y,x)e[0..m-1]x[0..n-1]
    va_start(ap, pm);         // gets all index       i0 i1  maxn=2
    i=1; s=0;                 // s is the index where is the elment
l3: v =va_arg(ap,u32); G(v>=pm[i],n0); s+=v*pm[i+1]; ++i; G(i<maxn-1, l3);
    v =va_arg(ap,u32); G(v>=pm[i],n0); s+=v;   
    v=s*size; r=Data(pm); r+=v;
    va_end(ap);
    R r;
}

// for now only nxm matrix of u8 u16 u32  d64[double]
void PrntMtrx(u32*  m)
{va_list           ap;
 d64               dv;
 u8         *p, *pmax;
 u32    i,j,maxn, max, size, v;
 u32       Index[256];

    G(m, l1);
l0:     R;  // error
l1: G(m[0]>2, l0);
    size= *SZe(m);
    G(size>8||size==0, l0);
    i=0; p=Data(m); pmax=p+(size*m[1]*m[2]);
m0: G(size==1,l2);G(size==2,l3);G(size==4,l4);G(size==8,l11);G(1,l0);
l11:dv=*(d64*)p; P("%10.2f",dv); G(1,l5); 
l2: v=*(u8*) p;  P("%3u ",  v); G(1,l5);
l3: v=*(u16*)p;  P("%5u ",  v); G(1,l5);
l4: v=*(u32*)p;  P("%10u ", v);
l5: G( (i+1)% m[2] != 0, l6); P("\n");
l6: p+=size; ++i; G(p<pmax, m0);
    R;
}

template<class T> class Matrix{
public:
 Matrix(u32 a, u32  b){Mcon(&mtr, S(T), a, b, -1);}
 Matrix(u32 a, u32  b, u32  c){Mcon(&mtr, S(T), a, b, c, -1);}
 Matrix(u32 a, u32  b, u32  c, u32  d){Mcon(&mtr, S(T), a, b, c, d, -1);}
~Matrix(){Mcon(&mtr, 0);}

T&  elm(u32 i, u32 j){R *(T*) Aelm(mtr, i,j);}
T&  elm(u32 i, u32 j, u32  k){R *(T*) Aelm(mtr, i,j,k); }
T&  elm(u32 i, u32 j, u32  k, u32  v){R *(T*) Aelm(mtr, i,j,k, v); }

/* ritorna il sup dell'indice consentito */
/* indici = 0, 1, 2 ,3 ,4 */
u32  operator[](u32  i)
{if(mtr==0||mtr[0]<=i)  R  0;
 R  mtr[i+1];
}

int  print(void){PrntMtrx(mtr);}

u32    *mtr;
};

int  main(void)
{Matrix<u32>  m1(2,2), m2(2,3);
 Matrix<d64>  m3(2,2);
 u32  i,j;

 F(i=0; i<m2[0]; ++i)
   F(j=0; j<m2[1]; ++j)
        m2.elm(i,j)=10*i+j;

 m1.elm(0,0)=123; m1.elm(0,1)=124;
 m1.elm(1,0)=125; m1.elm(1,1)=126; 

 F(i=0; i<m3[0]; ++i)
    F(j=0; j<m3[1]; ++j)
        m3.elm(i,j)=10.23*i+j;

 m1.print(); P("\n\n"); m2.print();P("\n\n"); m3.print();
 R  0;
}

       123        124
       125        126


         0          1          2
        10         11         12


      0.00      1.00
     10.23     11.23

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

#61594

On Tue, 05 May 2015 10:57:03 +0100, Bartc wrote:

> It's not necessarily slow. If the bounds *are* known, then frequently you
> will also know that accesses are within bounds:
> 
> for (i=0; i<=len(A); ++i)
>     A[i]=0;
> 
> No bounds checking needed here.

"<="?

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

#61601

On 06/05/2015 08:10, Nobody wrote:
> On Tue, 05 May 2015 10:57:03 +0100, Bartc wrote:
>
>> It's not necessarily slow. If the bounds *are* known, then frequently you
>> will also know that accesses are within bounds:
>>
>> for (i=0; i<=len(A); ++i)
>>      A[i]=0;
>>
>> No bounds checking needed here.
>
> "<="?

Sorry, I'm more used to 1-based code.

But an automatic system would deal with it properly: the compiler would 
either object immediately, or would leave in bounds-checking (maybe the 
loop is exited early, in a more elaborate case, or an indexing operation 
is guarded by a conditional, so perhaps this is what is intended. So 
allow it, but leave in the bounds check in the case the coder has no 
idea what he's doing.)

(It also demonstrates the errorprone nature of C for-loops I'm always 
complaining about. A 'for' that didn't need you to specify the exact 
compare op needed, or better still a 'forall', would have fewer such 
problems.)

-- 
Bartc

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

#61607

On 06/05/15 09:53, Bartc wrote:
> On 06/05/2015 08:10, Nobody wrote:
>> On Tue, 05 May 2015 10:57:03 +0100, Bartc wrote:
>>
>>> It's not necessarily slow. If the bounds *are* known, then frequently you
>>> will also know that accesses are within bounds:
>>>
>>> for (i=0; i<=len(A); ++i)
>>>      A[i]=0;
>>>
>>> No bounds checking needed here.
>>
>> "<="?
>
> Sorry, I'm more used to 1-based code.

In which case, why did you set i to 0?

In 0-based languages, iterating over an array in ascending order is 
idiomatic: for(i = 0; i < N; i++) is the pattern. Your fingers get used 
to it in time.

> But an automatic system would deal with it properly:

So does a programmer who is used to the idiom, and he can deal with it 
without incurring the overhead of automatic bounds-checking. There is no 
such thing as a free lunch. Everything costs cycles. The programmer who 
can be trusted to think about bounds himself is able to squeeze more out 
of the processor than someone who has to rely on an automated 
bounds-check to save his code from blowing up. It is absolutely right 
and proper that automatic bounds-checking systems should be available, 
but absolutely wrong that everyone should be forced to use them, or even 
to be forced into the decision of whether or not to use them all the 
time. So if an implementation wants to offer optional bounds-checking 
via a command line switch, I'm all for it. But it has to be 
switchable-offable.


> the compiler would
> either object immediately, or would leave in bounds-checking (maybe the
> loop is exited early, in a more elaborate case, or an indexing operation
> is guarded by a conditional, so perhaps this is what is intended. So
> allow it, but leave in the bounds check in the case the coder has no
> idea what he's doing.)

This penalises programmers who actually do know what they're doing. A 
wise programmer will consider the possibility that he doesn't know what 
he's doing, and (if the option is available to him) switch on 
bounds-checking for extra checks during debugging and testing, and then 
(if the drop in performance indicates it) switch it off and re-test.

> (It also demonstrates the errorprone nature of C for-loops I'm always
> complaining about.

Everything is error-prone. English is error-prone, as your sentence 
above amply demonstrates. (Not a dig - I make plenty of errors in 
English, too.) My own view is that C's for loops, like any sharp tool, 
can be dangerous and should be handled with care. But, like any sharp 
tool, they can be extraordinarily useful. I would not want to see the 
syntax changed just because /some/ people find them to be particularly 
error-prone.

> A 'for' that didn't need you to specify the exact
> compare op needed, or better still a 'forall', would have fewer such
> problems.)

The latter would be a better option. Not quite sure how you'd implement 
it in C, though, given that the compiler may not be able to tell how 
many items forall should cover. Consider:

void foo(int *p)
{
   size_t n;
   forall(p, n) /* how does the compiler know how many times to run this 
loop? */
   {
     foo(p[n]);
   }
}

It would be a fairly major change to the language, and would almost 
certainly involve information about the array being squirrelled away by 
the compiler, which squirrelling would inevitably incur a performance 
overhead.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#61609

On 06/05/2015 13:49, Richard Heathfield wrote:
> On 06/05/15 09:53, Bartc wrote:

> In which case, why did you set i to 0?

It just got mixed up.

>> But an automatic system would deal with it properly:
>
> So does a programmer who is used to the idiom, and he can deal with it
> without incurring the overhead of automatic bounds-checking. There is no
> such thing as a free lunch. Everything costs cycles. The programmer who
> can be trusted to think about bounds himself is able to squeeze more out
> of the processor than someone who has to rely on an automated
> bounds-check to save his code from blowing up. It is absolutely right
> and proper that automatic bounds-checking systems should be available,
> but absolutely wrong that everyone should be forced to use them, or even
> to be forced into the decision of whether or not to use them all the
> time. So if an implementation wants to offer optional bounds-checking
> via a command line switch, I'm all for it. But it has to be
> switchable-offable.

Sure. It would be for debugging only. In any case, an array-bounds error 
is of no more use to a customer than a seg-fault (but might contains 
information useful to the developer).

>> A 'for' that didn't need you to specify the exact
>> compare op needed, or better still a 'forall', would have fewer such
>> problems.)
>
> The latter would be a better option. Not quite sure how you'd implement
> it in C, though, given that the compiler may not be able to tell how
> many items forall should cover. Consider:
>
> void foo(int *p)
> {
>    size_t n;
>    forall(p, n) /* how does the compiler know how many times to run this
> loop? */
>    {
>      foo(p[n]);
>    }
> }
>
> It would be a fairly major change to the language, and would almost
> certainly involve information about the array being squirrelled away by
> the compiler, which squirrelling would inevitably incur a performance
> overhead.

I added forall to my own language last week (just so I could say how it 
could be done in C). It was a simple implementation that only copes with 
the cases where the compiler knows the size of the array.

Where the array is dynamic then, assuming the programmer knows what the 
size is, that information can perhaps be imparted in the form of a slice 
of the array (I might use A[1..n] or A[:N] or something like that). In 
the simple case, the forall looks like this in the source language:

[0:10]int data
int x

forall x in data do
    println x
od

(I've made the array 0-based which is what the 0: means), and the output 
C code is along these lines (edited to change things like illegal $ 
signs in names and extraneous labels):

int data[10];
int x;
int _temp1;
     for (_temp1=0; _temp1<=9; ++_temp1) {
         x = data[_temp1];
         printf("%d\n",x);
     }

(Interestingly, this uses the "=" and "<=" pattern that I'd used wrongly 
before!)

Possibly the C code could take the form of a pointer iterating across 
the array, but I'm sure a C compiler can optimise this. Notice the C 
needs: a loop index, an 0 initialiser, a "<=" compare, a "9" limit, a 
"++" operation, and an assignment, which are not needed in the original. 
(As well as a "%d", which needs to match the array element type, but 
that's another matter.)

-- 
Bartc

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

#61622

On Wednesday, May 6, 2015 at 1:49:37 PM UTC+1, Richard Heathfield wrote:
>
> The latter would be a better option. Not quite sure how you'd implement 
> it in C, though, given that the compiler may not be able to tell how 
> many items forall should cover. Consider:
> 
> void foo(int *p)
> {
>    size_t n;
>    forall(p, n) /* how does the compiler know how many times to run this 
> loop? */
>    {
>      foo(p[n]);
>    }
> }
> 
> It would be a fairly major change to the language, and would almost 
> certainly involve information about the array being squirrelled away by 
> the compiler, which squirrelling would inevitably incur a performance 
> overhead.
> 
What you'd have to do (I'm not sure this is a good idea, but might as well float it)
is have some syntax to indicate that a pointer is the return value from malloc().
You could say int [] ptr or something.
Then you have a function called msize( void [] ptr) that returns the size of the
block. That puts constraints on malloc() internals. But it means that if you allocate
arrays dynamically, and don't try to slice and dice them, you the size can't become
detached from the array.

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

#61629

On 06/05/2015 17:43, Malcolm McLean wrote:
> On Wednesday, May 6, 2015 at 1:49:37 PM UTC+1, Richard Heathfield wrote:
>>
>> The latter would be a better option. Not quite sure how you'd implement
>> it in C, though, given that the compiler may not be able to tell how
>> many items forall should cover. Consider:
>>
>> void foo(int *p)
>> {
>>     size_t n;
>>     forall(p, n) /* how does the compiler know how many times to run this
>> loop? */
>>     {
>>       foo(p[n]);
>>     }
>> }
>>
>> It would be a fairly major change to the language, and would almost
>> certainly involve information about the array being squirrelled away by
>> the compiler, which squirrelling would inevitably incur a performance
>> overhead.
>>
> What you'd have to do (I'm not sure this is a good idea, but might as well float it)
> is have some syntax to indicate that a pointer is the return value from malloc().
> You could say int [] ptr or something.
> Then you have a function called msize( void [] ptr) that returns the size of the
> block. That puts constraints on malloc() internals. But it means that if you allocate
> arrays dynamically, and don't try to slice and dice them, you the size can't become
> detached from the array.

If changes are going to be made which aren't just syntax, then a 
relatively simple addition is to introduce a 'slice'. This is just a 
composite type consisting of a pointer, and a length.

So when a dynamic array of type T is allocated, the result is a slice of 
type T. Slices of T are passed around instead of T* values (where you 
can't even tell if this is a single value, or a part of an array, or an 
element of an array that nevertheless you want to treat as a single value).

With a slice, then bounds checking becomes far more practical. However, 
because a slice (the pointer and/or length) can be modified, there is 
still some trust that the compiler has to place in the programmer that 
the correct length is present for that pointer. But this is still better 
than taking any random pointer P and a random index i and being able to 
do P[i], no questions asked, and no bounds checking because it is 
impossible other than when it strays outside program memory.

Slices can also refer to sub-arrays inside a larger one, and to counted 
substrings of a string. They are handy.

(To some extent some of this can be done now by manually defining such a 
composite type, but without proper language support it will look 
terrible, worse than dealing with separate pointers and lengths.

Also, for dynamic arrays that are going to change size, you will need a 
slice that contains a bit more info. But these are details.)

-- 
Bartc

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

#61752

Bart wrote:"
It's not necessarily slow. If the bounds *are* known, then frequently 
you will also know that accesses are within bounds: 

for (i=0; i<=len(A); ++i) 
    A[i]=0;
"

This is already possible 
If A it is in the stack or global
than sizeof A should return it's size
in bytes

If A it is one malloc return than
could be possible access A Len in
bytes from malloc structure

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

#61762

On 08/05/2015 08:44, asetofsymbols@gmail.com wrote:
> Bart wrote:"
> It's not necessarily slow. If the bounds *are* known, then frequently
> you will also know that accesses are within bounds:
>
> for (i=0; i<=len(A); ++i)
>      A[i]=0;
> "
>
> This is already possible
> If A it is in the stack or global
> than sizeof A should return it's size
> in bytes

When A is not a pointer, then yes it's easy.

> If A it is one malloc return than
> could be possible access A Len in
> bytes from malloc structure

How do you tell if A is a pointer allocated by malloc?

A can be:

* A pointer to a static array

* A pointer to a stack (VLA) array)

* A pointer to the middle of a malloc array (so you can't easily pick up 
the allocated size)

* A pointer to the start of a malloc array, but which occupies only part 
of the allocated block

* A pointer the a fixed array in the middle of a struct

* A pointer to an array which has been allocated outside the C system 
(from the OS, from a foreign function, or even from a malloc belonging 
to a different library)

* And, of course, also a pointer to individual variable, and not an 
array at all.

So it's not that straightforward.

-- 
Bartc

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

#61531

On 04/05/2015 21:22, Malcolm McLean wrote:
> On Monday, May 4, 2015 at 8:41:55 PM UTC+1, Lynn McGuire wrote:
>> "Death To C"
>>      http://techcrunch.com/2015/05/02/and-c-plus-plus-too/

> Thousands of language are proposed (I've done it myself, Minibasic
> has found a niche as a simple, customisable Basic variant). Only
> a handful are ever used for anything more than a demo project by
> the language implementer and a few tools for the same language.

I've created many (although all very similar), mostly to help me do my 
work over a period of nearly 20 years. For various reasons, they just 
helped me be very productive, even allowing for a couple of months to 
put one together. Some were built-in to applications and were used by 
other people.

But now it's just for fun. However they aren't 'toy' implementations and 
can do real work. They just lack extensive libraries so I make it a 
priority to allow external libraries to be used. Ones with an interface 
defined in C are the simplest.

-- 
Bartc

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

#61765

On 5/4/2015 4:15 PM, Bartc wrote:
> On 04/05/2015 21:22, Malcolm McLean wrote:
>> On Monday, May 4, 2015 at 8:41:55 PM UTC+1, Lynn McGuire wrote:
>>> "Death To C"
>>>      http://techcrunch.com/2015/05/02/and-c-plus-plus-too/
>
>> Thousands of language are proposed (I've done it myself, Minibasic
>> has found a niche as a simple, customisable Basic variant). Only
>> a handful are ever used for anything more than a demo project by
>> the language implementer and a few tools for the same language.
>
> I've created many (although all very similar), mostly to help me do my
> work over a period of nearly 20 years. For various reasons, they just
> helped me be very productive, even allowing for a couple of months to
> put one together. Some were built-in to applications and were used by
> other people.
>
> But now it's just for fun. However they aren't 'toy' implementations and
> can do real work. They just lack extensive libraries so I make it a
> priority to allow external libraries to be used. Ones with an interface
> defined in C are the simplest.
>

yeah. my stuff is also a bit immature in many areas, but is more special 
purpose.

I have two major languages I am using in VMs at present:
BGBScript, which is loosely a mix of JavaScript and ActionScript, Java, 
C#, and C. syntactically, it is closer to an AS3/Java hybrid, but has a 
fair bit in common with C# and C from a semantics perspective. VM 
performance in the JIT is roughly comparable to C#. it has existed in 
some form and been on/off updated and maintained since around 2004.


C-Aux, which is a bit newer and less mature, but is essentially just C 
in a VM. I had tried recently to get Quake working in the VM, but this 
effort had shaken up a lot of bugs (compiler / VM debugging is "fun") 
and problem areas (*1), and I haven't yet gotten back to beating on it (*2).

the VMs currently use very different bytecode representations, where BS 
uses a stack-based VM, and C-Aux uses a register-based VM.


*: one issue is how to best deal with function pointers into the VM 
within the constraints of a plain C implementation.

it is possible to use va_list, but this requires at least one "true" 
argument, and there is an issue that each function can only be used once 
(short of a way of reclaiming no-longer-needed function pointers).

however, this strategy fails hard for Win32 "stdcall" function pointers 
(which don't handle variable argument lists and assume callee stack 
cleanup), which come up in a few cases (Win32 event-handler callbacks).

I had been torn between either splitting up Quake such that parts of it 
are run in native land, or resort to implementing some sort of wrapper 
layer and making Quake use this (rather than try to directly interfacing 
between interpreted code and the Win32 API).


*2: much more of my time recently is going into my electronics projects, 
which only nominally involve programming (beating on the code which 
deals with I/O to the external electronics). had partly recently started 
on a real-time electronics simulator, but I would need to invest a bit 
more time in this as well (still pretty early in development).

this was prompted mostly by most of the existing free electronics 
simulators I can find not being terribly well suited to my uses (mostly 
frustrations with LTspice and Qucs and similar).


unlike some other simulators, this one uses a partial hybrid of 
board-layout and schematic symbols (it is not purely schematic, nor does 
it intend to full graphically represent a circuit board either, but is 
sort of a hybrid). for example, TO-92, TO-220, and TO-247 transistors 
have different representations and pin layout/spacing. it also attempts 
to simulate (thus far not so well) things like wire and component 
temperatures.

it is also intended mostly for DC power-electronics, which is more often 
what I am dealing with IRL. it may have some digital components, and 
basic support for analog electronics, but this wont be a focus. 
likewise, it uses a linear solver and simplistic models, which are 
faster but wont necessarily give high precision output. time-stepping is 
likely to be 100us for real-time (should be pretty doable for 
low-complexity circuits), smaller for reduced-time (say, 1s in real-time 
is mapped to 1ms in the simulation, and the simulator would operate on a 
100ns time-step).

I may or may not consider trying to simulate things like motors. could 
be a little harder, as things like 3-phase BLDC and induction motors' 
behavior depends a fair lot on the motor specifics, things like 
inductive properties in the phase coils, ... however, the model would 
still likely be mostly hand-waved (it would likely track the rotor 
position and velocity and dynamically change the induced current and 
reluctance as a result).

don't yet know if or to what extent scripting would be used in this 
(as-is, most component behavior is hard-coded). this would mostly apply 
if/when things like microcontrollers are simulated (probably C is 
compiled in a VM using a runtime based on a mockup of what is available 
for a given MCU, then the VM is run in-sync with the simulation).


to some extent, the idea is also influenced by things like FluidSIM and 
similar (which may simulate mixed electronic and pneumatic/hydraulic 
systems).

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

#61532

On 04-May-15 15:22, Malcolm McLean wrote:
> On Monday, May 4, 2015 at 8:41:55 PM UTC+1, Lynn McGuire wrote:
>> "Death To C" http://techcrunch.com/2015/05/02/and-c-plus-plus-too/
>> 
>> "Ladies and gentlemen, the C programming language. It's a classic. 
>> It is sleek, and spartan, and elegant. (Especially compared to its
>>  sequel, that bloated mess C++, which shares all the faults I'm
>> about to describe.) It is blindingly, quicksilver fast, because
>> it's about as close to the bone of the machine as you can get. It
>> is time- tested and ubiquitous. And it is terrifyingly dangerous."
>> 
>> So what else is new?
> 
> The main problem is buffer overruns. More rarely you can also have
> dangling or alisased pointers. But no-one has come up with a nice
> fix. It's easy enough to implement safe arrays in another language,
> but they you lose the speed of raw writes to memory.

For that matter, you could implement the same under the covers in C, but
that means either fat pointers or some sort of handle/reference system
rather than raw addresses, and you'd need special tricks to link with
code not compiled that way.  A new language is going to have similar
problems, though, without the benefits of being C.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

#61535

Malcolm McLean wrote:
> On Monday, May 4, 2015 at 8:41:55 PM UTC+1, Lynn McGuire wrote:
>> "Death To C"
>>      http://techcrunch.com/2015/05/02/and-c-plus-plus-too/
>>
>> "Ladies and gentlemen, the C programming language. It's a classic.
>>   It is sleek, and spartan, and elegant. (Especially compared to its
>>   sequel, that bloated mess C++, which shares all the faults I'm about
>> to describe.) It is blindingly, quicksilver fast, because it's
>> about as close to the bone of the machine as you can get. It is time-
>> tested and ubiquitous. And it is terrifyingly dangerous."
>>
>> So what else is new?
>>
> The main problem is buffer overruns. More rarely you can also
> have dangling or alisased pointers. But no-one has come up with
> a nice fix.

C++...

> It's easy enough to implement safe arrays in another
> language, but they you lose the speed of raw writes to memory.

You can get close to the best of both worlds in C++ by not exposing the 
raw pointer.

-- 
Ian Collins

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

#61791

Lynn McGuire <lmc@winsim.com> wrote:

> "Death To C"
>     http://techcrunch.com/2015/05/02/and-c-plus-plus-too/
> 
> "Ladies and gentlemen, the C programming language. It’s a classic. It is sleek, and spartan, and elegant. (Especially compared to its 
> sequel, that bloated mess C++, which shares all the faults I’m about to describe.) It is blindingly, quicksilver fast, because it’s 
> about as close to the bone of the machine as you can get. It is time-tested and ubiquitous. And it is terrifyingly dangerous."
> 
> So what else is new?

Well... someone who couldn't program safely to save his own life
thinking that there's a language called "C/C++" certainly isn't new.
It's old, very old, and it is indeed Rusty.

Come back when your new project doesn't crumble whenever it meets fresh
air.

Richard

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

#61814

Lynn McGuire kirjoitti:
> "Death To C"
>     http://techcrunch.com/2015/05/02/and-c-plus-plus-too/
>
> "Ladies and gentlemen, the C programming language. It’s a classic. It is
> sleek, and spartan, and elegant. (Especially compared to its sequel,
> that bloated mess C++, which shares all the faults I’m about to
> describe.) It is blindingly, quicksilver fast, because it’s about as
> close to the bone of the machine as you can get. It is time-tested and
> ubiquitous. And it is terrifyingly dangerous."
>
> So what else is new?
>
> Lynn

My personal opinion is that the C++ is a programming language that will 
cause death by a thousand cuts. Torvalds isn't wrong here but he is 
certainly exaggerating certain things to make his point clear.

The C++ is defective by design. And there are lots of more or less 
interesting documentation about problems associated with it. One of my 
favourites is the (currently slightly outdated) C++ FQA Lite: Defective 
C++ I recommend people read.

http://yosefk.com/c++fqa/defective.html


-- 
Merikissa

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

#61937

On Monday, May 4, 2015 at 3:41:55 PM UTC-4, Lynn McGuire wrote:
> "Death To C"
>     http://techcrunch.com/2015/05/02/and-c-plus-plus-too/

C will never die.  It is too elegant, too close to the machine while
being simultaneously too easy for humans to understand.  It is a perfect
mix for high performance and ease of maintenance building atop our
shared libraries built and distributed over time.  Couple that with
macros which make the source code very easy to understand, and even
more elegant for long-term maintenance ... so nice.

The only parts of C that will die are (1) the REQUIREMENT of having
forward declarations, (2) a notable disconnect between standard include
files and standard libraries, and (3) its lack of basic class abilities.

Those three will die over time and then C will become what it should've
become within the first couple years after C++ was proposed.

-----
C compilers and/or GUIs also need to have the ability to expand macros
into hard source code for examination and debugging, and there needs to
be a way to breakout complex Boolean logic expressions into a simple
"if ((a && b) || (c && !d) || e)" form where those letters are
placeholders, and the actual logic which feeds into them are given in
proximity with the ability to test logic conditions with on/off switches
next to each in the editor, showing the path taken in complex cases
while still in the development mode.

A few other things would be nice as well.

I pray that GUIs which support RDC will get them.  They are currently
planned, but it's a lot of work for one man to do.

Best regards,
Rick C. Hodgin

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

#61944

On Wednesday, May 13, 2015 at 8:11:52 AM UTC-7, Rick C. Hodgin wrote:
> On Monday, May 4, 2015 at 3:41:55 PM UTC-4, Lynn McGuire wrote:
> > "Death To C"
> >     http://techcrunch.com/2015/05/02/and-c-plus-plus-too/
> 
> C will never die.  It is too elegant, too close to the machine while
> being simultaneously too easy for humans to understand.  It is a perfect
> mix for high performance and ease of maintenance building atop our
> shared libraries built and distributed over time.  Couple that with
> macros which make the source code very easy to understand, and even
> more elegant for long-term maintenance ... so nice.
> 
> The only parts of C that will die are (1) the REQUIREMENT of having
> forward declarations, (2) a notable disconnect between standard include
> files and standard libraries, and (3) its lack of basic class abilities.
 
Re (1):

Basically you are asking for a two-pass compiler (these can be made to
look like one-pass but the machinery is more complicated). The first
pass identifies what all the names mean and the second does the dirty
work. This would be very easy and that it has not been done suggests
that it is not wanted. Forward declaration may be a feature and not a 
bug. 

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web