12 May
2017
12 May
'17
3:49 a.m.
Bjarne agrees with you. He put the * (and the &) with the type name to emphasize it
is part of the type.
This works fine as long as you only use one declaration per statement.
The problem with that is that * doesn't really bind to the type name. It binds to
the variable.
char* cp1, cp2; // cp1 is pointer to char, cp2 is just a char.
I always found it confusing that the * is used to indicate an pointer here, where as when
you want to change an lvalue to a pointer, you use &.
But if we're going to gripe about the evolution of C. My biggest gripe is when they
fixed structs to be real types, they didn't also do so for arrays.
Arrays and their degeneration to poitners is one of the biggest annoyances in C.
Am I the only one here who thinks that e.g. a char
pointer should be
"char* cp1, cp2" instead of "char *cp1, *cp2"? I.e. the fundamental
type is "char*", not "char", and to this day I still write:
12 May
12 May
4:01 a.m.
But wouldn't that imply you didn't need to use the * when referencing
the actual value?
For example, if you do this:
char *p;
char c;
The correct way to get the character it's pointing to dereference like this:
c=*p;
If the type was char* (not char)
Wouldn't that imply I wouldn't need the * to dereference the pointer?
On 5/11/2017 5:49 PM, Ron Natalie wrote:
Bjarne agrees with you. He put the * (and the &)
with the type name to emphasize it is part of the type.
This works fine as long as you only use one declaration per statement.
The problem with that is that * doesn't really bind to the type name. It binds to
the variable.
char* cp1, cp2; // cp1 is pointer to char, cp2 is just a char.
I always found it confusing that the * is used to indicate an pointer here, where as when
you want to change an lvalue to a pointer, you use &.
But if we're going to gripe about the evolution of C. My biggest gripe is when
they fixed structs to be real types, they didn't also do so for arrays.
Arrays and their degeneration to poitners is one of the biggest annoyances in C.
Am I the only one here who thinks that e.g. a
char pointer should be
"char* cp1, cp2" instead of "char *cp1, *cp2"? I.e. the fundamental
type is "char*", not "char", and to this day I still write:
5:44 a.m.
On Thu, 11 May 2017, Arthur Krewat wrote:
But wouldn't that imply you didn't need to
use the * when referencing
the actual value?
For example, if you do this:
char *p;
char c;
The correct way to get the character it's pointing to dereference like
this:
c=*p;
If the type was char* (not char)
Wouldn't that imply I wouldn't need the * to dereference the pointer?
No, because you'd be assigning the contents i.e. the address (or however
references are implemented on a given architecture) to a character;
whether the fundamental type is "char*" or ("mostly char but it's
really a
pointer") is the same.
Then again, I learned ALGOLW (and PASCAL) before I learned C, and it has a
"REFERENCE" type...
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
4:03 a.m.
On 12 May 2017, at 07:49, Ron Natalie
<ron(a)ronnatalie.com> wrote:
<…>
But if we're going to gripe about the evolution of C. My biggest gripe is when
they fixed structs to be real types, they didn't also do so for arrays.
Arrays and their degeneration to poitners is one of the biggest annoyances in C.
And, conversely (perversely?) one of its greatest joys.
d
4:32 a.m.
On Fri, May 12, 2017 at 08:03:28AM +1000, David Arnold wrote:
I dunno if it is one of its greatest joys but pointers in C have always
made sense to me.
I'm curious as to what is busted about arrays in C? To me they just
seemed like a way to define how to look at a wad of memory and they
seem to work for me. About the only thing I don't like about them is
that there is no late binding as to the size, Ada has late binding and
I thought it could be useful (I only know because Rob Netzer and I
wrote an Ada compiler for CS736 at UW-Madison that did a lot of Ada
but exceptions and late binding we did not do).
--lm
On 12 May
2017, at 07:49, Ron Natalie <ron(a)ronnatalie.com> wrote:
<???>
But if we're going to gripe about the evolution of C. My biggest gripe is when
they fixed structs to be real types, they didn't also do so for arrays.
Arrays and their degeneration to poitners is one of the biggest annoyances in C.
And, conversely (perversely?) one of its greatest joys.
4:41 a.m.
I'm curious as to what is busted about arrays in
C? To me they just
seemed like a way to define how to look at a wad of memory and
they seem to
work for me.
The problem is they don't work like every other type. Somewhere around
the phototypesetter release or V7, they fixed structs to be
assignable/passable to functions.
They didn't do that for arrays. They retained their half-assed
quasipointer status. It would have been easy to bite the bullet back in
those days before people codified the inane behavior.
For example:
struct foo {
int a;
int b;
};
struct foo x;
x.a = 1;
x.b = 1;
struct foo y;
y = x; // works fine.
struct foo myfunc(struct foo arg) {
arg.a = 5;
return 5;
}
y = myfunc(x); // does not modify x
Now look at arrays:
char x[4] = { 1, 2, 3, 4};
char y[4];
y = x ; // illegal
void myfunc(char arg[4]) {
arg[0] = 1000;
}
myfunc(x); // CHANGES X!
If had my way, y = x and passing and returning arrays by value would work
just like every other C type.
13 May
13 May
7:24 a.m.
On Thu, May 11, 2017 at 06:41:47PM -0400, Ron Natalie wrote:
If had my way, y = x and passing and returning arrays
by value would work
just like every other C type.
Maybe, just maybe, now that makes sense. But even now that would be a
perf hit unless you added some magical copy on write semantics like
Tcl has so it can have pass by value semantics but pass by reference
performance.
Back then, I think the perf hit would have been so bad everyone would be
passing arrays as a reference anyway.
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
8:45 a.m.
There's no performance "hit" because it doesn't work now.
There's really
no difference performance or computational complexity wise for
char x[4], y[4];
x = y;
and
struct { char a[4]; } x, y;
x = y;
About the only thing it would have broken (and would still break today), is
the fact that function parameters that are defined to be arrays, really pass
pointers.
char x[4];
void foo(char a[4]);
foo(x);
would be costlier than it is now doing the pass by value. Of course you
could always fudge if you wanted to pass the pointer by actually doing it
that way...
char x[4]
void foo(char *a);
foo(x);
-----Original Message-----
From: Larry McVoy [mailto:lm@mcvoy.com]
Sent: Friday, May 12, 2017 9:24 PM
To: Ron Natalie
Cc: 'Larry McVoy'; 'David Arnold'; 'The Eunuchs Hysterical
Society'
Subject: Re: [TUHS] C declarations.
On Thu, May 11, 2017 at 06:41:47PM -0400, Ron Natalie wrote:
If had my way, y = x and passing and returning arrays
by value would
work just like every other C type.
Maybe, just maybe, now that makes sense. But even now that would be a perf
hit unless you added some magical copy on write semantics like Tcl has so it
can have pass by value semantics but pass by reference performance.
Back then, I think the perf hit would have been so bad everyone would be
passing arrays as a reference anyway.
--
---
Larry McVoy lm at mcvoy.com
http://www.mcvoy.com/lm
6:20 p.m.
On 12 May 2017 22:45 -0400, from ron(a)ronnatalie.com (Ron Natalie):
About the only thing it would have broken (and would
still break today), is
the fact that function parameters that are defined to be arrays, really pass
pointers.
char x[4];
void foo(char a[4]);
foo(x);
would be costlier than it is now doing the pass by value.
Correct me if I am wrong, but _pass by value_ as opposed to _pass by
reference_ requires making a copy, no? That's the whole point, to
allow the callee to poke at the value it is given at will. At the very
least, it would require making a copy when a part of the passed value
is modified. Where is that memory going to come from, when even
malloc() isn't a part of the language but rather a part of the
standard library? Where is all that going to come from if you pass a
large array on a memory-constrained system of specs common back in the
days when C was designed, especially one that lacks virtual memory
support?
What if (yes, somewhat contrived example) we had pass by value
semantics, and foo() is implemented as
void foo(char a[4])
{
a[8] = 123;
}
What exactly should happen? The function delcaration says we are
interested in four char, but the function uses far more than that. You
could of course invoke the almighty term _undefined behavior_, but you
really have to say _something_. And of course, nothing stops us from
calling that function as
char x[100];
foo(x);
To reliably prevent that, it seems to me you'd need to at least amend
arrays to know their own size, especially if you don't want the
compiler to throw its hands in the air as soon as it sees a malloc()
(and recognizes it).
Now consider instead something like
struct foo_t { char a[4]; char b[10]; };
union foo_u { char[14] x; struct foo_t s; };
void foo(foo_u u)
{
u.s.a[8] = 123;
}
(Please excuse any syntax errors there; unions have never been my
strong side.)
While I agree that _you shouldn't be doing that in the first place_,
the fact remains that doing it is not _disallowed_ by the language. It
could be disallowed by the language if the array knows its size, but
to reliably disallow it, you'd need to be able to detect it at compile
time. That would seem to significantly increase the complexity of the
compiler, which of course we wouldn't want on a low-spec system. (I
have a strong suspicion that my microwave oven has more computing
power and memory than some of the systems C was designed to run on...)
Of course you
could always fudge if you wanted to pass the pointer by actually doing it
that way...
char x[4]
void foo(char *a);
foo(x);
...in which case you need to know from somewhere else whether foo()
wants a zero-terminated char array or not. Not impossible -- we
already have a similar situation with, say, memcmp() and strncmp() --
but unless you're willing to introduce some additional syntax, it
seems to me that you lose expressiveness in the language by lumping
the two cases together.
All the above said, _please don't get me wrong_. Pass by value
semantics is a really nice feature to have, and I have been known to
curse at certain languages more than once where the normal behavior is
pass by reference and pass by value requires a good deal of extra
code. But for potentially large (or even undefined-size) types, pass
by value comes at a significant cost in terms of memory, and even the
copying itself. Copy-on-write solves some of that but requires
elaborate bookkeeping instead, to know what goes where (it's at least
one additional layer of indirection), and risks fragmentation. For
simplicity and predictability, it's hard to beat pass by reference.
--
Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se
“People who think they know everything really annoy
those of us who know we don’t.” (Bjarne Stroustrup)
6:35 p.m.
On 13 May 2017, at 13:20, Michael Kjörling <michael(a)kjorling.se> wrote:
Correct me if I am wrong, but _pass by value_ as opposed to _pass by
reference_ requires making a copy, no? That's the whole point, to
allow the callee to poke at the value it is given at will. At the very
least, it would require making a copy when a part of the passed value
is modified. Where is that memory going to come from, when even
malloc() isn't a part of the language but rather a part of the
standard library? Where is all that going to come from if you pass a
large array on a memory-constrained system of specs common back in the
days when C was designed, especially one that lacks virtual memory
support?
Are there languages that copy arrays in function calls defaultly? Perhaps Fortran has
some convention that allows that but I doubt it gets used very much, because it would be
insane in most cases: COMPUTE_MEAN_TEMPERATURE(ATMOS) is really *not* going to work very
well if it involves copying the ATMOS array.
6:42 p.m.
On 13 May 2017 13:35 +0100, from tfb(a)tfeb.org (Tim Bradshaw):
Are there languages that copy arrays in function calls
defaultly?
Perhaps Fortran has some convention that allows that but I doubt it
gets used very much, because it would be insane in most cases:
COMPUTE_MEAN_TEMPERATURE(ATMOS) is really *not* going to work very
well if it involves copying the ATMOS array.
I'm not completely sure about arrays, but at least Java has pass by
reference in some cases where you might expect pass by value. IIRC
function return values is a prime example.
--
Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se
“People who think they know everything really annoy
those of us who know we don’t.” (Bjarne Stroustrup)
9:36 p.m.
On Sat, 13 May 2017 12:42:47 +0000, Michael Kjörling <michael(a)kjorling.se>
wrote:
On 13 May 2017 13:35 +0100, from tfb(a)tfeb.org (Tim
Bradshaw):
Technically (and this is serious nit-picking), Java is always pass-by-value,
but the value of an array or object *variable* is the reference to the array
or object, not the array or object itself. So the behaviour is
pass-by-reference for arrays and objects (although that’s a simplification
too, and unhelpful in some instances).
The same applies to return values: primitive types are returned by value
(copied), arrays and objects are returned via their reference (which is
copied too).
Regards,
Stephen
Are there languages that copy arrays in function
calls defaultly?
Perhaps Fortran has some convention that allows that but I doubt it
gets used very much, because it would be insane in most cases:
COMPUTE_MEAN_TEMPERATURE(ATMOS) is really *not* going to work very
well if it involves copying the ATMOS array.
I'm not completely sure about arrays, but at least Java has pass by
reference in some cases where you might expect pass by value. IIRC
function return values is a prime example. 
14 May
14 May
7:59 a.m.
I am not troubled at all by C’s conflation of arrays and pointers. That has always seemed
natural - it is what is really going on under the covers.*
I’m the sort of person who fiddles with the source code until the compiler generates the
code I want. C is great for this. Not always, but C compilers usually do the
straightforward and obvious thing and generate the code you would write if you had to do
it in assembler, only the compiler keeps track of the stupid details like frame offsets
and inventing symbol names for branch targets.
I’ve written substantive things in Java, Modula-3, common lisp, python, and so forth, but
when I write performance sensitive code, I do it in C**
I tend to work on communications code and when you are counting cycles in some HPC
library, you write in C but think of every load, store, and shift. My affinity for the
language began the same way it probably did for a lot of people here: when I realized that
*i++ was exactly a PDP11 addressing mode.
When the assistant rector at my church had a meeting about sacred texts, I brought in
K&R (“the New Testament” second edition) and my prized copies of the BSTJ Unix
issues.
-L
PS
* - But I have never been able to remember the syntax for function pointers. I always
“man qsort” to refresh my memory.
** - If the code uses multidimensional arrays or subarrays, then maybe FORTRAN, because
really x[i*stride+j] gets really old.
8:23 a.m.
On Sat, 13 May 2017, Lawrence Stewart wrote:
* - But I have never been able to remember the syntax
for function
pointers. I always “man qsort” to refresh my memory.
"cdecl" is your friend:
% cdecl
Type `help' or `?' for help
declare foo as pointer to function (int, double) returning void
void (*foo)(int , double )
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
10:24 a.m.
On Sat, 13 May 2017 21:59:57 EDT Lawrence Stewart <stewart(a)serissa.com> wrote:
* - But I have never been able to remember the syntax for function pointers. > I
always "man qsort" to refresh my memory.
The way I remember:
given *x[] or *x(), x /sticks/ to the /right/ first. Thus
int *x[]; // x is array of ptr to int
int *x(); // x is a function returning ptr to int
If you don't want a var to stick to its right, separate using
using parentheses.
int (*x)[]; // x is a ptr to array of ints
int (*x)(); // x is a ptr to function returning int
int *(*x)[]; // x is a ptr to array of ptrs to int
This sort of also works for multiple variables in one declaration. Given
int *x, y; // * /sticks/ to the right (x) first, so not available for y.
Now if they'd allowed parenthesizing the type, as in
(int *)x, y;
we would see that both x & y are of type int *. That would've also allowed
declaring multiple vars in one declaration where the previous rule applies!
(int*)(*f,*g)();
Part of the confusion is * is tacked on at the front while []
& () at the back of a variable. Someone (Chandy?) had
proposed unifying this syntax but it didn't go anywhere. I
think the author used @ in a suffix place though I don't
recall any other details. But if you put the var all the way
to the right and read a declaration right to left, it works:
int*[] x // x is a array of ptr to ints
int() f // f is a function returning it
int*()* f // f is a ptr to function returning ptr to int
int*()* f,g // f & g are ptrs to function returning ptr to int
This is only slightly weird if you are used to the current syntax
but you can easily retrain yourself.
IMHO, where evolution of C, Scheme and most programming
languages goes wrong is doing evolutionary design by
committee. Most users grasp what is easier to use vs what is
hard but they don't have the aesthetic sense or imagination or
training to make things simple. And in large groups popularity
or force of personality or some other irrelevant attribute
wins not aesthetics. Language evolution IMHO must be done by
benevolent dictatorship or a guild of like minded people who
have worked together for a long time! Go seems to have
adapted that style....
12:12 p.m.
I can't resist jumping in here. My main point is that system coding
is a rather different beast than most application programming. An
operating system must be able to handle memory allocation requests
from a user without knowing any details of what is requested. Dennis
explicitly left out a heap and garbage collection code in C because he
didn't want OS code to be burdened with it. Similarly with a "real"
string type (with concatenation, etc.).
An example that speaks to me is that of creating a symbol table.
This isn't kernel programming, but consider what is needed:
* A structure that holds the individual table entries
* A tree of lookup tables that reflects the scoping rules of the
language -- several tables might need to be searched to find an entry
* A function that looks up a name in a scope, returns the entry if
it's defined, and adds a new entry in the appropriate scope if it
isn't there yet.
Statistically a majority of the calls do not change the symbol table,
but some do, and you can't tell in advance. And in the same way,
many of the possible scopes where a variable might reside need not be
searched.
So how much of this table should we copy into the lookup function?
The answer seems obvious to me -- none of it...
Before Unix, Dennis and I and several other people worked on a
symbolic algebra system written in FORTRAN. Dennis wrote a dynamic
storage allocator, which was a real feat in FORTRAN, complete with
garbage collector. The goal was to have the program work on the 6
major manufacturers' FORTRANs. We got it up and running on many of
the systems, but did not have easy access to OS 360. Finally, we
were granted the third shift on the OS 360, and ran our program (that
had become rather solid by this time...). It was a disaster -- the
brogram ran for a few second and then the OS dies and could not be
restarted (turns out the core dump area allotted on the disc was not
big enough to hold our program).
The problem turned out to be that the IBM compiler did copy in/copy
out argument passing, while all the other compilers passed by
reference. If you passed in an argument that was dynamically
allocated, and the system did a garbage collection, all the elements
that were still live were moved around but kept their contents
intact... until the function returned, and tried to copy the changed
value out _where that block used to be at the time of the call._
It took us about 6 months to rewrite the system so we didn't do that
-- we had to allocate everything that would be needed first, then do
the work, and then free things...
None of us were fans of copy in/copy out after that experience...
Steve
----- Original Message -----
From: "Bakul Shah" <bakul(a)bitblocks.com>
To:"Lawrence Stewart" <stewart(a)serissa.com>
Cc:"tuhs" <tuhs(a)minnie.tuhs.org>
Sent:Sat, 13 May 2017 21:24:11 -0700
Subject:Re: [TUHS] C declarations.
On Sat, 13 May 2017 21:59:57 EDT Lawrence Stewart
<stewart(a)serissa.com> wrote:
* - But I have never been able to remember the syntax for function
pointers. > I
always "man qsort" to refresh my memory.
The way I remember:
given *x[] or *x(), x /sticks/ to the /right/ first. Thus
int *x[]; // x is array of ptr to int
int *x(); // x is a function returning ptr to int
If you don't want a var to stick to its right, separate using
using parentheses.
int (*x)[]; // x is a ptr to array of ints
int (*x)(); // x is a ptr to function returning int
int *(*x)[]; // x is a ptr to array of ptrs to int
This sort of also works for multiple variables in one declaration.
Given
int *x, y; // * /sticks/ to the right (x) first, so not available for
y.
Now if they'd allowed parenthesizing the type, as in
(int *)x, y;
we would see that both x & y are of type int *. That would've also
allowed
declaring multiple vars in one declaration where the previous rule
applies!
(int*)(*f,*g)();
Part of the confusion is * is tacked on at the front while []
& () at the back of a variable. Someone (Chandy?) had
proposed unifying this syntax but it didn't go anywhere. I
think the author used @ in a suffix place though I don't
recall any other details. But if you put the var all the way
to the right and read a declaration right to left, it works:
int*[] x // x is a array of ptr to ints
int() f // f is a function returning it
int*()* f // f is a ptr to function returning ptr to int
int*()* f,g // f & g are ptrs to function returning ptr to int
This is only slightly weird if you are used to the current syntax
but you can easily retrain yourself.
IMHO, where evolution of C, Scheme and most programming
languages goes wrong is doing evolutionary design by
committee. Most users grasp what is easier to use vs what is
hard but they don't have the aesthetic sense or imagination or
training to make things simple. And in large groups popularity
or force of personality or some other irrelevant attribute
wins not aesthetics. Language evolution IMHO must be done by
benevolent dictatorship or a guild of like minded people who
have worked together for a long time! Go seems to have
adapted that style....
12:48 p.m.
So the problem was your assumptions didn't match IBM's! Most likely the FORTRAN
standard /allowed/ pass by value/result instead of pass by ref.
None of the changes I suggested in my previous email (that focused on arrays in C) would
have required a GC or heap. It would've increased programmer convenience and reduced
bugs though!
On May 13, 2017, at 11:12 PM, Steve Johnson
<scj(a)yaccman.com> wrote:
I can't resist jumping in here. My main point is that system coding is a rather
different beast than most application programming. An operating system must be able to
handle memory allocation requests from a user without knowing any details of what is
requested. Dennis explicitly left out a heap and garbage collection code in C because he
didn't want OS code to be burdened with it. Similarly with a "real" string
type (with concatenation, etc.).
An example that speaks to me is that of creating a symbol table. This isn't kernel
programming, but consider what is needed:
A structure that holds the individual table entries
A tree of lookup tables that reflects the scoping rules of the language -- several tables
might need to be searched to find an entry
A function that looks up a name in a scope, returns the entry if it's defined, and
adds a new entry in the appropriate scope if it isn't there yet.
Statistically a majority of the calls do not change the symbol table, but some do, and
you can't tell in advance. And in the same way, many of the possible scopes where a
variable might reside need not be searched.
So how much of this table should we copy into the lookup function? The answer seems
obvious to me -- none of it...
Before Unix, Dennis and I and several other people worked on a symbolic algebra system
written in FORTRAN. Dennis wrote a dynamic storage allocator, which was a real feat in
FORTRAN, complete with garbage collector. The goal was to have the program work on the 6
major manufacturers' FORTRANs. We got it up and running on many of the systems, but
did not have easy access to OS 360. Finally, we were granted the third shift on the OS
360, and ran our program (that had become rather solid by this time...). It was a
disaster -- the brogram ran for a few second and then the OS dies and could not be
restarted (turns out the core dump area allotted on the disc was not big enough to hold
our program).
The problem turned out to be that the IBM compiler did copy in/copy out argument passing,
while all the other compilers passed by reference. If you passed in an argument that was
dynamically allocated, and the system did a garbage collection, all the elements that were
still live were moved around but kept their contents intact... until the function
returned, and tried to copy the changed value out where that block used to be at the time
of the call.
It took us about 6 months to rewrite the system so we didn't do that -- we had to
allocate everything that would be needed first, then do the work, and then free things...
None of us were fans of copy in/copy out after that experience...
Steve
----- Original Message -----
From: "Bakul Shah" <bakul(a)bitblocks.com>
To:"Lawrence Stewart" <stewart(a)serissa.com>
Cc:"tuhs" <tuhs(a)minnie.tuhs.org>
Sent:Sat, 13 May 2017 21:24:11 -0700
Subject:Re: [TUHS] C declarations.
On Sat, 13 May 2017 21:59:57 EDT Lawrence Stewart <stewart(a)serissa.com> wrote:
* - But I have never been able to remember the syntax for function pointers. > I
always "man qsort" to refresh my memory.
The way I remember:
given *x[] or *x(), x /sticks/ to the /right/ first. Thus
int *x[]; // x is array of ptr to int
int *x(); // x is a function returning ptr to int
If you don't want a var to stick to its right, separate using
using parentheses.
int (*x)[]; // x is a ptr to array of ints
int (*x)(); // x is a ptr to function returning int
int *(*x)[]; // x is a ptr to array of ptrs to int
This sort of also works for multiple variables in one declaration. Given
int *x, y; // * /sticks/ to the right (x) first, so not available for y.
Now if they'd allowed parenthesizing the type, as in
(int *)x, y;
we would see that both x & y are of type int *. That would've also allowed
declaring multiple vars in one declaration where the previous rule applies!
(int*)(*f,*g)();
Part of the confusion is * is tacked on at the front while []
& () at the back of a variable. Someone (Chandy?) had
proposed unifying this syntax but it didn't go anywhere. I
think the author used @ in a suffix place though I don't
recall any other details. But if you put the var all the way
to the right and read a declaration right to left, it works:
int*[] x // x is a array of ptr to ints
int() f // f is a function returning it
int*()* f // f is a ptr to function returning ptr to int
int*()* f,g // f & g are ptrs to function returning ptr to int
This is only slightly weird if you are used to the current syntax
but you can easily retrain yourself.
IMHO, where evolution of C, Scheme and most programming
languages goes wrong is doing evolutionary design by
committee. Most users grasp what is easier to use vs what is
hard but they don't have the aesthetic sense or imagination or
training to make things simple. And in large groups popularity
or force of personality or some other irrelevant attribute
wins not aesthetics. Language evolution IMHO must be done by
benevolent dictatorship or a guild of like minded people who
have worked together for a long time! Go seems to have
adapted that style....
15 May
15 May
5:06 a.m.
You all are missing the point as to what the cost of passing arrays by value
or what other languages do.
C is implicitly a pass/return by value language for EVERY SINGLE POSSIBLE
DATATYPE WITH THE EXCEPTION OF ARRAYS.
Arrays are special for no reason other than it was thought to costly to do
it any otherway. In fact, had it not been kludged up into a
pseudo-pass-by-reference,
nobody would have probably been the wiser. It was too hard to pass/return
structs by value either in the initial compilers, but they fixed it to work
exactly that way.
So we have this array kludge that works differently than everything else.
Further, due to the kludgosity, it's not even exactly type safe.
5:34 a.m.
On 5/14/2017 7:06 PM, Ron Natalie wrote:
array kludge
Is it really a kludge? It's a
pointer.
int array[128];
Want to reference the array in a memcpy? Do: memcpy(destination, array,
sizeof(array));
Want to reference an element in the array? array[element #]
Want to pass (a reference to) said array to a function? function(array)
Not sure what the kludge is.
I think C is more consistent when it comes to arrays than a lot of other
languages. At least with C you KNOW it's a pointer to the original.
6:14 a.m.
On Sun, May 14, 2017 at 7:34 PM, Arthur Krewat <krewat(a)kilonet.net> wrote:
Of course it is! But that doesn't mean that it SHOULD be, which is the
point.
int array[128];
> Want to reference the array in a memcpy?
Do: memcpy(destination, array,
> sizeof(array));
> Want to reference an element in the array?
array[element #]
> Want to pass (a reference to) said array to
a function? function(array)
> Not sure what the kludge is.
The kludge is that it works different than everything else for no really
good reason.
I think C is more consistent when it comes to arrays than a lot of other
> languages. At least with C you KNOW it's a pointer to the original.
Sure! But if someone had told you, back when you first learned C, that it
was an array and had value semantics, would you have thought THAT was
strange? "If you want a pointer to the array, use the address operator on
the array and pass that; that'll behave like a 'foo*' pointer for an array
of foo. Most people do this for efficiency."
The point is that it's a thought exercise. It's not that folks don't
understand how C works now or the semantics of array-decay-to-pointer; it's
just that folks can also imagine a world where things had been done
differently. That world doesn't exist, but we can still imagine it.
- Dan C.
On 5/14/2017 7:06 PM, Ron Natalie wrote:
array kludge
Is it really a kludge?
Yes.
It's a pointer.
6:23 a.m.
It's a pointer.
Ø Of course it is! But that doesn't mean that it SHOULD be, which is the point.
Actually, it is **Not a pointer**, it gets passed as a pointer, but it is an array on both
ends.
The implicit conversion of the array name to a pointer to its first item is a different
issue. This bothers me less, but it’s still hokie in my opinion.
9:43 a.m.
On Sun, May 14, 2017, at 20:23, Ron Natalie wrote:
Actually, it is **Not a pointer**, it gets passed as a
pointer, but it is
an array on both ends.
I'm not sure what you mean by "on both ends". It is a pointer in the
function. sizeof(dst) is 2, not 256, even if it were declared as int
dst[128].
On Sun, May 14, 2017, at 19:34, Arthur Krewat wrote:
Is it really a kludge? It's a pointer.
int array[128];
Want to reference the array in a memcpy? Do: memcpy(destination, array,
sizeof(array));
The argument is that that should have to be memcpy(&destination, &array,
sizeof(array)), the same as if you were copying between two structs.
6:40 a.m.
On Sun, May 14, 2017 at 08:14:47PM -0400, Dan Cross wrote:
The kludge is that it works different than everything
else for no really
good reason.
I'd be curious what Steve thinks about all this, I know he weighed in
a bit, but does he think that Dennis / Brian/ Ken regret this design choice?
Personally, I can easily see why they did it. C doesn't really have a lot
of behind-the-scenes magic, it can easily be viewed as a pleasant way to
do portable code that sits directly on the hardware, no frameworks, no
garbage collector, no magic. It's predictable in ways that higher level
languages are not. That's one of the things I like about C, I can reason
about it.
But I suspect it was more basic than that. They were running on 16 bit
pretty slow machines and having a pass by value model for arrays just
didn't make any sense. *Everyone* would pass by reference so why bother
having a pass by value model? If you really, really wanted that you
could get it
int salaries[100];
int payroll = add_them_up(malloc_and_copy(salaries, sizeof(salaries));
But any sane person in that day and age would go "why on God's green earth
would you do that? It's slow. Just don't change the salaries array and
you'll be fine".
Think about all the str* stuff - you really want to malloc and free that?
It would have killed performance.
Personally I think they looked at it, said "everyone will use references
for arrays anyway, let's make them references by default".
I get that it is not clean and pure and doesn't match how other types work,
I do see that, but I also see that their choice made a ton of sense at the
time. And maybe still does. It's not the same as the other types because
the other types are, typically, small. Arrays can be big, really big.
--lm
8 a.m.
On Sun, May 14, 2017 at 7:40 PM, Larry McVoy <lm(a)mcvoy.com> wrote:
I get that it is not clean and pure and doesn't
match how other types work,
I do see that, but I also see that their choice made a ton of sense at the
time. And maybe still does. It's not the same as the other types because
the other types are, typically, small. Arrays can be big, really big.
IIRC, you couldn't pass or return structs either. Also, no function
prototypes, so passing data of different sizes would have been a bit more
difficult.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
4:21 p.m.
Larry McVoy <lm(a)mcvoy.com> wrote:
On Sun, May 14, 2017 at 08:14:47PM -0400, Dan Cross
wrote:
I wonder how much of it was due to evolving in stages from BCPL, where
everything is a word, and structs and arrays are just pointers (with maybe
an allocation of space for the pointer to point to).
And C couldn't pass structs by value for quite a long time.
Tony.
--
f.anthony.n.finch <dot(a)dotat.at> http://dotat.at/ - I xn--zr8h punycode
Fair Isle, Faeroes: Southeast 5 or 6, increasing 7 or gale 8 for a time.
Moderate or rough, occasionally very rough in Faeroes. Fair then rain with fog
patches. Good, becoming moderate or very poor.
The kludge is that it works different than
everything else for no really
good reason.
I'd be curious what Steve thinks about all this, I know he weighed in
a bit, but does he think that Dennis / Brian/ Ken regret this design choice?
10:35 a.m.
On Sat, 13 May 2017, Bakul Shah wrote:
int*()* f // f is a ptr to function returning ptr to
int
Nope.
aneurin% cdecl
Type `help' or `?' for help
explain int*()* f
syntax error
declare f as ptr to function returning ptr to int
int *(*f)()
(Sigh; "cdecl" really needs to print a "> " prompt or something.)
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
10:54 a.m.
On Mon, 15 May 2017 14:35:34 +1000 Dave Horsfall <dave(a)horsfall.org> wrote:
On Sat, 13 May 2017, Bakul Shah wrote:
Sorry, I was less than clear. I was just doing a thought
experiment about an alternate declaration syntax. Requoting
from my email:
But if you put the var all the way
to the right and read a declaration right to left, it works:
Basically suggesting that if all type machinery *preceded* an
object declaration (including for functions), we don't need any
parentheses and declarations are very easy to understand --
you just read a declaration from right to left. So no need
for cdel! Too late for this, of course!
int*()* f // f is a ptr to function returning ptr
to int
Nope.
aneurin% cdecl
Type `help' or `?' for help
explain int*()* f
syntax error
declare f as ptr to function returning ptr to int
int *(*f)()
(Sigh; "cdecl" really needs to print a "> " prompt or something.)
11:01 a.m.
On Sun, 14 May 2017, Bakul Shah wrote:
Sorry - entirely my fault (which I'd realised just *after* I'd sent it, of
course). Yes, your idea is a lot better.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
Nope.
aneurin% cdecl
Type `help' or `?' for help
explain int*()* f
syntax error
declare f as ptr to function returning ptr to int
int *(*f)()
Sorry, I was less than clear. I was just doing a thought
experiment about an alternate declaration syntax. Requoting
from my email:
6:58 p.m.
On 15 May 2017 14:35 +1000, from dave(a)horsfall.org (Dave Horsfall):
(Sigh; "cdecl" really needs to print a
"> " prompt or something.)
It does print "cdecl> " as a prompt on my system.
$ cdecl
Type `help' or `?' for help
cdecl> explain int*()* f
syntax error
cdecl> declare f as ptr to function returning ptr to int
int *(*f)()
cdecl> ^D
$
However, running it with -q turns this off:
$ cdecl -q
declare f as ptr to function returning ptr to int
int *(*f)()
^D
$
The man page for mine says 2.5, Jan 1996, and the Debian package
version says 2.5-11. 1996 in 2017 is old even for Debian.
Are you sure that you don't have a stray alias somewhere, or something
that might be causing it to misdetect as not running in a terminal?
--
Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se
“People who think they know everything really annoy
those of us who know we don’t.” (Bjarne Stroustrup)
10:58 p.m.
On Mon, 15 May 2017, Michael Kjörling wrote:
It does print "cdecl> " as a prompt on my
system.
[...]
The man page for mine says 2.5, Jan 1996, and the
Debian package
version says 2.5-11. 1996 in 2017 is old even for Debian.
I've got 2.5 as well (on FreeBSD 10.3), and "set prompt" has no effect.
I even rebuilt it in case there was a later version.
Are you sure that you don't have a stray alias
somewhere, or something
that might be causing it to misdetect as not running in a terminal?
aneurin% cdecl
Type `help' or `?' for help
set prompt
set options
[...]
Current set values are:
noprompt
interactive
WTF?
I'll fire up GDB and have a poke around (once I'm properly awake; I only
got up for a glass of water, and couldn't help but check my email).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
16 May
16 May
1 a.m.
New subject: cdecl (Re: C declarations.
pkg upgrade cdecl
2.5 didn't show a prompt but 3.1.3 does (though the prompt is in /green/. Sigh...)
On May 15, 2017, at 9:58 AM, Dave Horsfall
<dave(a)horsfall.org> wrote:
On Mon, 15 May 2017, Michael Kjörling wrote:
It does print "cdecl> " as a prompt on my system.
[...]
The man page for mine says 2.5, Jan 1996, and the
Debian package
version says 2.5-11. 1996 in 2017 is old even for Debian.
I've got 2.5 as well (on FreeBSD 10.3), and "set prompt" has no effect.
I even rebuilt it in case there was a later version.
Are you sure that you don't have a stray
alias somewhere, or something
that might be causing it to misdetect as not running in a terminal?
aneurin% cdecl
Type `help' or `?' for help
set prompt
set options
[...]
Current set values are:
noprompt
interactive
WTF?
I'll fire up GDB and have a poke around (once I'm properly awake; I only
got up for a glass of water, and couldn't help but check my email).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
4:52 a.m.
New subject: cdecl (Re: C declarations.
On Mon, 15 May 2017, Bakul Shah wrote:
pkg upgrade cdecl
Didn't work; all my packages are up to date, so I guess you're running
FreeBSD 11 or something?
2.5 didn't show a prompt but 3.1.3 does (though
the prompt is in
/green/. Sigh...)
I'll wait for 3.1.3 to be ported then, although I might bash ahead with
GDB anyway.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
13 May
13 May
7:46 p.m.
On Sa, 2017-05-13 at 13:35 +0100, Tim Bradshaw wrote:
Are there languages that copy arrays in
function calls defaultly?
Yes, Pascal is an example. If you do *not* want
an argument to be copied, its corresponding
parameter name must be preceded by the keyword
"var". The "User Manual and Report" explicitly
warns about the inefficiency incurred when
calling functions with parameters of structured
types (arrays or records) without "var".
Hellwig
14 May
14 May
1:08 a.m.
On Sat, May 13, 2017, at 08:35, Tim Bradshaw wrote:
Are there languages that copy arrays in function calls
defaultly?
Perhaps Fortran has some convention that allows that but I doubt it gets
used very much, because it would be insane in most cases:
COMPUTE_MEAN_TEMPERATURE(ATMOS) is really *not* going to work very well
if it involves copying the ATMOS array.
Fortran, for the record, passes nearly everything by reference - to call
a fortran function from C (or to make a C function callable from
fortran) you've got to mangle the name and change almost everything to
pointers.
5:21 a.m.
On Sat, 13 May 2017, Random832 wrote:
Fortran, for the record, passes nearly everything by
reference [...]
And if you passed a constant and the local argument was modified, so was
the (single instance of) constant...
Actually, wasn't FORTRAN value-result i.e. all args were copied straight
back again, or am I confusing that with ALGOL? Blimey, it's been over 40
years since I last submitted a card deck.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
8:48 p.m.
On 13 May 2017 at 19:21, Dave Horsfall <dave(a)horsfall.org> wrote:
On Sat, 13 May 2017, Random832 wrote:
Probably depends on the implementation. VAX-FORTRAN passed by
reference (but not on the stack).
Off-topic: I recall a working function that crashed when fed a
constant string. Spelunking revealed that someone had replaced a
letter-by-letter case-insensitive comparison with a "faster version"
(written in VAX assembler, no less) that converted both arguments to
upper case and then block-compared.
N.
Fortran, for the record, passes nearly everything
by reference [...]
And if you passed a constant and the local argument was modified, so was
the (single instance of) constant...
1:05 a.m.
On Sat, May 13, 2017, at 08:20, Michael Kjörling wrote:
Correct me if I am wrong, but _pass by value_ as
opposed to _pass by
reference_ requires making a copy, no? That's the whole point, to
allow the callee to poke at the value it is given at will.
If that were the issue, the callee could simply automatically make the
copy if-and-only-if it needs it.
The reason that it can't be done without making a copy is, rather, that
there might be some *other* reference in play, through which the
original array could be modified (thus improperly changing what the
callee sees).
7:14 p.m.
On Sat, May 13, 2017 at 03:05:24PM -0400, Random832 wrote:
On Sat, May 13, 2017, at 08:20, Michael Kjörling
wrote:
I recall reading a proposed ABI for C on MIPS which would have done
something similar for passing structs by value, namely pass a pointer
but allocate local storage space in the callee. If the callee ever
assigned to the passed struct, it was to copy the actual values,
then update its pointer. I don't think that ABI was ever implemented.
DF
Correct me if I am wrong, but _pass by value_ as
opposed to _pass by
reference_ requires making a copy, no? That's the whole point, to
allow the callee to poke at the value it is given at will.
If that were the issue, the callee could simply automatically make the
copy if-and-only-if it needs it.
12 May
12 May
6:15 a.m.
On Thu, 11 May 2017 15:32:32 PDT Larry McVoy <lm(a)mcvoy.com> wrote:
I dunno if it is one of its greatest joys but pointers in C have always
made sense to me.
I'm curious as to what is busted about arrays in C? To me they just
seemed like a way to define how to look at a wad of memory and they
seem to work for me. About the only thing I don't like about them is
that there is no late binding as to the size, Ada has late binding and
I thought it could be useful (I only know because Rob Netzer and I
wrote an Ada compiler for CS736 at UW-Madison that did a lot of Ada
but exceptions and late binding we did not do).
Coming from a Pascal background I really liked the terseness
of C. But theere were three things that bothered me.
a) K&R style argument declarations. This got fixed in ANSI C.
C declarations were messy but that did not bother me much.
b) No nested procedures. Gnu C had added them but the
implementation was a bit screwy and most people didn't care
in any case so there was no hope of this getting fixed.
Partly because most people used it as a portable assembly
language!
c) arrays were not first class objects. Given "T v[N];" v[i]
is of type T and i+v or v+i is of type T* -- this is
perfectly well defined and fine. What is not fine is that
an array is a second class object. Thus you can not do
for example,
int v[5];
struct foo {
int w[5];
int x;
} y;
...
y.w = v;
You can not pass a whole array to a function (or return
one) without enclosing it in a struct. You can not take an
address of an array, only an element of it. There is no way
to declare or pass a subarray. A function that operates on a
arbitray sized multi dim. array can be written but can get
messy.
One big impact of current array behavior is that the onus
to do boundary condition checks is on the programmer and
can't be done by the compiler.
Just as Pascal got "conformant arrays" in its 1990 standard,
arrays could've been made first class (but without "ref"
parameters code can look messy). For instance, consider the
folloowing:
double a[5,20], b[20,10], c[5,10];
int err = mat_multiply(c, a, b);
int mat_mult(ref double c[int cx, cy], a[int ax, ay], b[int bx, by]) {
if (cx != ax || cy != by || ay != bx) return -1;
...
return 0;
}
This can be implemented without much trouble and allows
full boundary condition checking. Currently the user will
have to manually pass {a,b,c}{x,y} parameters and he would
have to either create auxiliary vectors to point to each row
or have the function to do all the index arithmetic explicitly
(and the compiler can't check if your code has no boundary
condition bugs).
A slightly more difficult situation arises when you want to
pass sub arrays. For instance,
mat_mutl(c[5,0:9], a[5,10:19], b[0:9,0:5])
Here you will have to somehow pass stride and offset (or use
iliffe vectors or some such).
8:41 a.m.
I tend to stay away from using arrays as arguments of procedures, too many
surprises. Instead I use structures.
For example:
typedef struct {
.........
xteam NoSo[MAXB], EsWe[MAXB];
} xboard;
............
xboard TB;
............
ScoreBoard(..., &TB, ...);
Of course, in my old age I only do simple game programming
Theo Pavlidis
(
Member of 1127: 1980-86)
On Thu, May 11, 2017 at 8:15 PM, Bakul Shah <bakul(a)bitblocks.com> wrote:
On Thu, 11 May 2017 15:32:32 PDT Larry McVoy
<lm(a)mcvoy.com> wrote:
I dunno if it is one of its greatest joys but pointers in C have always
made sense to me.
I'm curious as to what is busted about arrays in C? To me they just
seemed like a way to define how to look at a wad of memory and they
seem to work for me. About the only thing I don't like about them is
that there is no late binding as to the size, Ada has late binding and
I thought it could be useful (I only know because Rob Netzer and I
wrote an Ada compiler for CS736 at UW-Madison that did a lot of Ada
but exceptions and late binding we did not do).
Coming from a Pascal background I really liked the terseness
of C. But theere were three things that bothered me.
a) K&R style argument declarations. This got fixed in ANSI C.
C declarations were messy but that did not bother me much.
b) No nested procedures. Gnu C had added them but the
implementation was a bit screwy and most people didn't care
in any case so there was no hope of this getting fixed.
Partly because most people used it as a portable assembly
language!
c) arrays were not first class objects. Given "T v[N];" v[i]
is of type T and i+v or v+i is of type T* -- this is
perfectly well defined and fine. What is not fine is that
an array is a second class object. Thus you can not do
for example,
int v[5];
struct foo {
int w[5];
int x;
} y;
...
y.w = v;
You can not pass a whole array to a function (or return
one) without enclosing it in a struct. You can not take an
address of an array, only an element of it. There is no way
to declare or pass a subarray. A function that operates on a
arbitray sized multi dim. array can be written but can get
messy.
One big impact of current array behavior is that the onus
to do boundary condition checks is on the programmer and
can't be done by the compiler.
Just as Pascal got "conformant arrays" in its 1990 standard,
arrays could've been made first class (but without "ref"
parameters code can look messy). For instance, consider the
folloowing:
double a[5,20], b[20,10], c[5,10];
int err = mat_multiply(c, a, b);
int mat_mult(ref double c[int cx, cy], a[int ax, ay], b[int bx, by]) {
if (cx != ax || cy != by || ay != bx) return -1;
...
return 0;
}
This can be implemented without much trouble and allows
full boundary condition checking. Currently the user will
have to manually pass {a,b,c}{x,y} parameters and he would
have to either create auxiliary vectors to point to each row
or have the function to do all the index arithmetic explicitly
(and the compiler can't check if your code has no boundary
condition bugs).
A slightly more difficult situation arises when you want to
pass sub arrays. For instance,
mat_mutl(c[5,0:9], a[5,10:19], b[0:9,0:5])
Here you will have to somehow pass stride and offset (or use
iliffe vectors or some such).
2778
days inactive
2782
days old
39 comments
19 participants
participants (19)
-
Arthur Krewat -
Bakul Shah -
Dan Cross -
Dave Horsfall -
David Arnold -
Derek Fawcus -
Hellwig Geisse -
Larry McVoy -
Lawrence Stewart -
Michael Kjörling -
Nemo -
Nevin Liber -
Random832 -
Ron Natalie -
Stephen Kitt -
Steve Johnson -
Theo Pavlidis -
Tim Bradshaw -
Tony Finch