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

Groups > comp.lang.misc > #2037 > unrolled thread

Wirth-ian languages

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

Contents

  Wirth-ian languages bruce axtens <bugmagnet@outlook.com> - 2014-04-28 16:23 +0000
    Re: Wirth-ian languages Joe Hynes <theda@southpark.net> - 2014-04-28 17:31 +0000
      Re: Wirth-ian languages Kaz Kylheku <kaz@kylheku.com> - 2014-04-28 18:47 +0000
        Re: Wirth-ian languages "BartC" <bc@freeuk.com> - 2014-04-28 20:35 +0100
          Re: Wirth-ian languages Kaz Kylheku <kaz@kylheku.com> - 2014-04-28 20:18 +0000
            Re: Wirth-ian languages "James Harris" <james.harris.1@gmail.com> - 2014-04-28 22:50 +0100
              Re: Wirth-ian languages "BartC" <bc@freeuk.com> - 2014-04-29 00:03 +0100
                Re: Wirth-ian languages Kaz Kylheku <kaz@kylheku.com> - 2014-04-28 23:51 +0000
                Re: Wirth-ian languages "James Harris" <james.harris.1@gmail.com> - 2014-04-29 07:59 +0100
                  Re: Wirth-ian languages "BartC" <bc@freeuk.com> - 2014-04-29 10:04 +0100
                    Re: Wirth-ian languages "James Harris" <james.harris.1@gmail.com> - 2014-04-29 11:33 +0100
                      Re: Wirth-ian languages "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-29 07:41 -0400
              Re: Wirth-ian languages "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-28 21:46 -0400
                Re: Wirth-ian languages "James Harris" <james.harris.1@gmail.com> - 2014-04-29 08:24 +0100
                  Re: Wirth-ian languages "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-29 07:33 -0400
                    Re: Wirth-ian languages "James Harris" <james.harris.1@gmail.com> - 2014-04-29 14:38 +0100
                      Re: Wirth-ian languages "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-30 21:28 -0400
                        Re: Wirth-ian languages "James Harris" <james.harris.1@gmail.com> - 2014-05-01 10:44 +0100
                Re: Wirth-ian languages "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-04-29 09:59 +0200
                  Re: Wirth-ian languages Kaz Kylheku <kaz@kylheku.com> - 2014-04-29 15:51 +0000
                    Re: Wirth-ian languages "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-04-30 10:57 +0200
                      Re: Wirth-ian languages Kaz Kylheku <kaz@kylheku.com> - 2014-04-30 15:47 +0000
                        Re: Wirth-ian languages "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-01 10:18 +0200
                          Re: Wirth-ian languages Kaz Kylheku <kaz@kylheku.com> - 2014-05-01 16:56 +0000
                            Re: Wirth-ian languages "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-02 10:10 +0200
                  Re: Wirth-ian languages "BartC" <bc@freeuk.com> - 2014-04-30 18:27 +0100
                    Re: Wirth-ian languages "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-01 10:18 +0200
                      Re: Wirth-ian languages Kaz Kylheku <kaz@kylheku.com> - 2014-05-01 17:10 +0000
                        Re: Wirth-ian languages "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-02 09:22 +0200
    Re: Wirth-ian languages "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-28 20:59 -0400
      Re: Wirth-ian languages "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-28 21:10 -0400
      Re: Wirth-ian languages Nils M Holm <news2009@t3x.org> - 2014-04-29 07:52 +0000
      Re: Wirth-ian languages "BartC" <bc@freeuk.com> - 2014-04-29 09:45 +0100
    Re: Wirth-ian languages Jacko <jackokring@gmail.com> - 2014-04-29 05:37 -0700

Page 1 of 2  [1] 2  Next page →

#2037 — Wirth-ian languages

Is it fair to say that most of the Wirth-ian programming languages are 
either dead or in palliative care? Delphi seems to be about the only 
thing left with any life in it. Am I missing anything?

-- Bruce

[toc] | [next] | [standalone]

#2040

On 2014-04-28, bruce axtens <bugmagnet@outlook.com> wrote:
> Is it fair to say that most of the Wirth-ian programming languages are 
> either dead or in palliative care? Delphi seems to be about the only 
> thing left with any life in it. Am I missing anything?

There's a pretty active FreePascal project and there's always Ada.
There's enough legacy Ada to keep quite a few people in business and there
always seems to be some small amount of new Ada going on. Personally, I
believe Ada is Wirthian in spirit but there were and are some damn good
language designers and implementers involved with it. Ada is mostly a clean
sheet of paper even though it may not look like that. I mean Ada up to
around 95. After that things started to deteriorate into the C++ world of
complexity and lack of restraint. Now it's harder to see its roots.

Modula-3 has a small but active community also.

What do you want to conclude? Probably Wirth's priorities and aesthetics are
not widely shared by people who choose programming languages for deployment.
gcc and Linux have taken over and blotted out most of the native species.
Linux is based on C so using anything but C/C++ will eventually bring
you to a wall you can't scale. Most people don't get there but the constant
stomping out of anything that isn't gcc has been very destructive and
limiting generally.

That and in the old days most of the technical stuff was left to technical
people. Ever since the Harvard MBA program the CEO and people that have no 
idea what they're talking about are the ones choosing stuff that most code
is written in. Their choices are not usually based on technical or
engineering criteria.

Then there's the ivory tower of academia where most of what they teach is
useless or harmful and wrong. But it sticks. They go with the lowest common
denominator and that eventually slimes over to industry where the unwashed
masses that used Java and C++ in college spec it for whatever comes up. Java
was marketed real hard and well and so was C++.

Wirth was unusual in that his sense of elegance was not impractical and
didn't fall into Dijkstra's hubris sinkhole and become a public display of
circle-jerkery. Wirth came up with basic good ideas and elegant solutions
that that other people were able to use to create truly useful things
from. Aside from Wirth and Stroustrup it's been extremely rare to see
anything come out of academia but hot air. And that's on a good day.

Joe

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

#2043

On 2014-04-28, Joe Hynes <theda@southpark.net> wrote:
> On 2014-04-28, bruce axtens <bugmagnet@outlook.com> wrote:
>> Is it fair to say that most of the Wirth-ian programming languages are 
>> either dead or in palliative care? Delphi seems to be about the only 
>> thing left with any life in it. Am I missing anything?
>
> There's a pretty active FreePascal project and there's always Ada.
> There's enough legacy Ada to keep quite a few people in business and there
> always seems to be some small amount of new Ada going on. Personally, I
> believe Ada is Wirthian in spirit but there were and are some damn good
> language designers and implementers involved with it. Ada is mostly a clean
> sheet of paper even though it may not look like that. I mean Ada up to
> around 95. After that things started to deteriorate into the C++ world of
> complexity and lack of restraint. Now it's harder to see its roots.
>
> Modula-3 has a small but active community also.
>
> What do you want to conclude? Probably Wirth's priorities and aesthetics are
> not widely shared by people who choose programming languages for deployment.
> gcc and Linux have taken over and blotted out most of the native species.
> Linux is based on C so using anything but C/C++ will eventually bring
> you to a wall you can't scale.

C is pretty much a "Wirthian" language. The basic model of program organization
and comptuation in, say, Modula-2 or C is the same: statically typed, block
scoped language based on machine-language-like primitive types, and simple
aggregates thereof, with poor support for polymorphism. Programs in these
languages define "mills" that pump word-sized data through a Von Neumann
machine.

Nobody really needs alternatives to C which are almost the same thing,
just with more clunky syntax and pointless limitations.

> Most people don't get there but the constant
> stomping out of anything that isn't gcc has been very destructive and
> limiting generally.

Nobody is holding gun to anyone's head regarding what to include in a distro
of free software, and you can start your own if you don't like any of them.

Freeware distros give you more programming languages as standard packages
than any proprietary OS.

> That and in the old days most of the technical stuff was left to technical
> people. Ever since the Harvard MBA program the CEO and people that have no
> idea what they're talking about are the ones choosing stuff that most code
> is written in.

Even if that is true now, it has no bearing on the rejection of things
Pascalian, which is rooted in the old days.

When Lisp hacker Richard Stallman decided, the middle 1980's that the thing
to do to kickstart the freware movement was to make a C compiler, that probably
didn't have to do with Havard MBA's choosing stuff that code is written in.

Look, even Knuth caved in: http://www-cs-faculty.stanford.edu/~uno/faq.html
See: "What is your favorite programming language".  That was more than 20 years
ago.

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

#2044

"Kaz Kylheku" <kaz@kylheku.com> wrote in message
news:20140428111524.742@kylheku.com...
> On 2014-04-28, Joe Hynes <theda@southpark.net> wrote:
>> On 2014-04-28, bruce axtens <bugmagnet@outlook.com> wrote:
>>> Is it fair to say that most of the Wirth-ian programming languages are
>>> either dead or in palliative care? Delphi seems to be about the only
>>> thing left with any life in it. Am I missing anything?

>> What do you want to conclude? Probably Wirth's priorities and aesthetics
>> are
>> not widely shared by people who choose programming languages for
>> deployment.
>> gcc and Linux have taken over and blotted out most of the native species.
>> Linux is based on C so using anything but C/C++ will eventually bring
>> you to a wall you can't scale.
>
> C is pretty much a "Wirthian" language. The basic model of program
> organization
> and comptuation in, say, Modula-2 or C is the same: statically typed,
> block
> scoped language based on machine-language-like primitive types, and simple
> aggregates thereof, with poor support for polymorphism. Programs in these
> languages define "mills" that pump word-sized data through a Von Neumann
> machine.
>
> Nobody really needs alternatives to C which are almost the same thing,
> just with more clunky syntax and pointless limitations.

Yes we do. It wouldn't take me long to list a hundred things that are wrong
with C, yet after fixing all those the resulting language wouldn't do that
much more. It would just get rid of all the baggage, and have a smaller,
tidier and more streamlined language that is far nicer to use.

>> Most people don't get there but the constant
>> stomping out of anything that isn't gcc has been very destructive and
>> limiting generally.
>
> Nobody is holding gun to anyone's head regarding what to include in a
> distro
> of free software, and you can start your own if you don't like any of
> them.
>
> Freeware distros give you more programming languages as standard packages
> than any proprietary OS.

> Look, even Knuth caved in:
> http://www-cs-faculty.stanford.edu/~uno/faq.html
> See: "What is your favorite programming language".  That was more than 20
> years
> ago.

Is this the same guy who devised MIX, a made-up machine language, to
describe algorithms in his books? He probably isn't too hot on designing
elegant languages then. And he may have been partly forced to migrate to C
for the same reasons everyone else has found it necessary to move in that 
direction.

I even started to move there myself a year and a half ago, but am now
rebelling and moving away again to do my own thing.

There are a couple of things that are good about C: the language is
ubiquitous, and compilers for it can generate pretty good code. But that
says nothing about the language itself, which 'sucks' (and even C
programmers agree about some of its problems).

But there is little else that can do the same job (ie. implement everything
else from the ground up). Hence the need for an alternative.

-- 
Bartc 

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

#2045

On 2014-04-28, BartC <bc@freeuk.com> wrote:
> "Kaz Kylheku" <kaz@kylheku.com> wrote in message
>> Nobody really needs alternatives to C which are almost the same thing,
>> just with more clunky syntax and pointless limitations.
>
> Yes we do. It wouldn't take me long to list a hundred things that are wrong
> with C, yet after fixing all those the resulting language wouldn't do that

You'd have to read the specification of C first, or else few would
take you seriously. That could burn up a chunk of time.

> much more. It would just get rid of all the baggage, and have a smaller,
> tidier and more streamlined language that is far nicer to use.

C is already small enough to the point of being stupidly small.

>>> Most people don't get there but the constant
>>> stomping out of anything that isn't gcc has been very destructive and
>>> limiting generally.
>>
>> Nobody is holding gun to anyone's head regarding what to include in a
>> distro
>> of free software, and you can start your own if you don't like any of
>> them.
>>
>> Freeware distros give you more programming languages as standard packages
>> than any proprietary OS.
>
>> Look, even Knuth caved in:
>> http://www-cs-faculty.stanford.edu/~uno/faq.html
>> See: "What is your favorite programming language".  That was more than 20
>> years
>> ago.
>
> Is this the same guy who devised MIX, a made-up machine language, to
> describe algorithms in his books? He probably isn't too hot on designing

It's also the same guy who wrote TeX in Pascal, using a "literate programming"
tool of his own design, so that the program and its documentation could be
produced from the same sources.

In a 1993 interview with "Computer Literacy Bookshops" 
(http://tex.loria.fr/litte/knuth-interview) Knuth said:

  CLB: Did you integrate WEB with C because so many programmers today are using
  it, or do you personally like C and write with it?

  Knuth: I think C has a lot of features that are very important. The
  way C handles pointers, for example, was a brilliant innovation; it
  solved a lot of problems that we had before in data structuring and
  made the programs look good afterwards. C isn't the perfect language,
  no language is, but I think it has a lot of virtues, and you can avoid
  the parts you don't like. I do like C as a language, especially
  because it blends in with the operating system (if you're using UNIX,
  for example).

  All through my life, I've always used the programming language that
  blended best with the debugging system and operating system that I'm
  using. If I had a better debugger for language X, and if X went well
  with the operating system, I would be using that.

  [Then he goes on to discuss an extreme case of X, where X was
  some awful language called IMP on some early Cray machine, but he used it
  anyway because it was well supported.]

It's clear that Knuth switched to C partly due to impetus, but he also likes
many of its spects, like how pointers are represented.

> There are a couple of things that are good about C: the language is
> ubiquitous, and compilers for it can generate pretty good code. But that
> says nothing about the language itself, which 'sucks' (and even C
> programmers agree about some of its problems).

Yes.

C has too many undefined behaviors, and also insufficient "reflection".

C could benefit from standardized access under the hood to answer questions
like "what function called me?" "what is the backtrace?" "how many arguments
were passed to me?" (or how many arguments are in this va_list?)

(Even if some of these things can't be implemented in some systems, it's better
if there is a standard API on those systems where it can be, and way to test
whether it is available.)

C would be a much better language if the operands of all operators, and
function arguments, evaluated strictly from left to right, and the whole
"sequence point" concept were discarded.

A longjmp which doesn't trash local variables would be nice, as well to have a
way to execute clean-up code unconditionally when a block is terminated by any
means.

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

#2046

"Kaz Kylheku" <kaz@kylheku.com> wrote in message 
news:20140428125523.803@kylheku.com...
> On 2014-04-28, BartC <bc@freeuk.com> wrote:
>> "Kaz Kylheku" <kaz@kylheku.com> wrote in message

...

>  Knuth: I think C has a lot of features that are very important. The
>  way C handles pointers, for example, was a brilliant innovation; it
>  solved a lot of problems that we had before in data structuring and
>  made the programs look good afterwards. C isn't the perfect language,
>  no language is, but I think it has a lot of virtues, and you can avoid
>  the parts you don't like. I do like C as a language, especially
>  because it blends in with the operating system (if you're using UNIX,
>  for example).

That's an interesting association between language and OS. As I am working 
on both I have often seen a lot of overlap and tried hard to keep the two 
concepts separate but together they do form a sort of programming system or 
algorithm execution environment. There does seem to be a synergy between the 
two concepts that can benefit a software developer.

>  All through my life, I've always used the programming language that
>  blended best with the debugging system and operating system that I'm
>  using. If I had a better debugger for language X, and if X went well
>  with the operating system, I would be using that.
>
>  [Then he goes on to discuss an extreme case of X, where X was
>  some awful language called IMP on some early Cray machine, but he used it
>  anyway because it was well supported.]
>
> It's clear that Knuth switched to C partly due to impetus, but he also 
> likes
> many of its spects, like how pointers are represented.
>
>> There are a couple of things that are good about C: the language is
>> ubiquitous, and compilers for it can generate pretty good code. But that
>> says nothing about the language itself, which 'sucks' (and even C
>> programmers agree about some of its problems).
>
> Yes.
>
> C has too many undefined behaviors, and also insufficient "reflection".
>
> C could benefit from standardized access under the hood to answer 
> questions
> like "what function called me?" "what is the backtrace?" "how many 
> arguments
> were passed to me?" (or how many arguments are in this va_list?)

Many things could be added to a function interface in C by adding extra 
parameters. Calls don't have to be as minimal as they are; things could be 
added but programmers would have to write the extra arguments individually. 
Maybe they wouldn't like having to do that. Another language could provide 
boxed tuples or store related data in lots of small pieces of memory.

> (Even if some of these things can't be implemented in some systems, it's 
> better
> if there is a standard API on those systems where it can be, and way to 
> test
> whether it is available.)
>
> C would be a much better language if the operands of all operators, and
> function arguments, evaluated strictly from left to right, and the whole
> "sequence point" concept were discarded.
>
> A longjmp which doesn't trash local variables would be nice, as well to 
> have a
> way to execute clean-up code unconditionally when a block is terminated by 
> any
> means.

That's interesting. I think we could all come up with a list of improvements 
we would like.

I often think it strange that many people, including me, have so many issues 
with C and yet it despite the things I don't like or wish could be better it 
is still far and a away my language of choice for a lot of work. How can one 
language be so bad yet so choosable? What makes it so good to program in 
despite the faults that people identify? People, especially those who don't 
use it, might be able to list a series of failings in its design and those 
criticisms may be valid yet despite its faults it is still so effective and, 
of course, very influential and good to use.

There are times I use Python or assembly depending on need but for a lot of 
work C is in the Goldilocks position of being just right.

I see the comment above that Knuth switched to C which, for a theoretician, 
is very interesting given the academic criticisms of the language.

In my own designs I tend to avoid including the features of C due to things 
like their lack of security but then it becomes very difficult to provide 
the same facilities in a secure way. I don't believe it is impossible but it 
is challenging. C's semantics and associated features are mature and 
complete enough to allow almost any job to be done well.

Rather than design a new language I wonder how feasible it would be for one 
of us to evolve C into something better by means of a series of small steps. 
The language base is there just asking to be improved. Anyone tried that?

To be clear I do not mean to add things to C so that it gradually accretes 
more baggage. ISTM that other languages have done that and while they have 
added some beneficial features they have become bulky and cumbersome as a 
result. C++ I'm talking about you! I don't know why but while I have tried 
to learn C++ a few times each time I feel myself losing the will to live. I 
can see the sense in some of its changes, for sure, but something about the 
language leaves me wanting to just go and do something more interesting. I 
don't think I have ever felt that about C.

James

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

#2047

"James Harris" <james.harris.1@gmail.com> wrote in message
news:ljmifb$1gn$1@dont-email.me...
> "Kaz Kylheku" <kaz@kylheku.com> wrote in message
<snip>
>> better
>> if there is a standard API on those systems where it can be, and way to
>> test
>> whether it is available.)
>>
>> C would be a much better language if the operands of all operators, and
>> function arguments, evaluated strictly from left to right, and the whole
>> "sequence point" concept were discarded.
>>
>> A longjmp which doesn't trash local variables would be nice, as well to
>> have a
>> way to execute clean-up code unconditionally when a block is terminated
>> by any
>> means.
>
> That's interesting. I think we could all come up with a list of
> improvements we would like.

I'll try and put something together. I may or may not post it. As I think
you say somewhere, such a list will be different for everyone.

> I often think it strange that many people, including me, have so many
> issues with C and yet it despite the things I don't like or wish could be
> better it is still far and a away my language of choice for a lot of work.
> How can one language be so bad yet so choosable? What makes it so good to
> program in despite the faults that people identify? People, especially
> those who don't use it, might be able to list a series of failings in its
> design and those criticisms may be valid yet despite its faults it is
> still so effective and, of course, very influential and good to use.

My own languages had plenty of problems of their own, but would always be my
first choice. (For one thing, I would spend considerably less time battling
the language and/or compiler, and more time on getting my work done.)

> There are times I use Python or assembly depending on need but for a lot
> of work C is in the Goldilocks position of being just right.

Yes, there is a need for such a language at this level. It's a shame it had 
to be C. (And my own enhancements to it wouldn't make it much higher level; 
I don't want to turn it into C++.)

> I see the comment above that Knuth switched to C which, for a
> theoretician, is very interesting given the academic criticisms of the
> language.
>
> In my own designs I tend to avoid including the features of C due to
> things like their lack of security but then it becomes very difficult to
> provide the same facilities in a secure way. I don't believe it is
> impossible but it is challenging. C's semantics and associated features
> are mature and complete enough to allow almost any job to be done well.

Try this one (an actual requirement I had): you have a pointer to a function
(in a dynamic library for example), and it needs N parameters (to keep
things simple, they're all of int type). How to call such a function in C
without writing N different calls? (Let's say N could be 0 to 12; so 13 lots
of calls.)

(In my languages, I would either step into inline assembly for this, or use
an odd statement I had called 'stack' which would push any expression onto
the hardware stack.)

> Rather than design a new language I wonder how feasible it would be for
> one of us to evolve C into something better by means of a series of small
> steps. The language base is there just asking to be improved. Anyone tried
> that?

I don't think it's possible without keeping all the bad stuff. It would be
easier to create a new language, and a few have come out (sadly inheriting
C's syntax in most cases). Not quite low level enough though.

For example, how do you get rid of the ghastly type declaration syntax in
one step?

> To be clear I do not mean to add things to C so that it gradually accretes
> more baggage. ISTM that other languages have done that and while they have
> added some beneficial features they have become bulky and cumbersome as a
> result. C++ I'm talking about you! I don't know why but while I have tried
> to learn C++ a few times each time I feel myself losing the will to live.

I've felt exactly the same. Usually when reading about the OO stuff. But my 
own requirement is a little unusual as I only need a static compiled 
language to code my interpreters in, and perhaps the odd library function. 
It doesn't need to be big or have lots of advanced features.

-- 
Bartc 

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

#2048

On 2014-04-28, BartC <bc@freeuk.com> wrote:
> Try this one (an actual requirement I had): you have a pointer to a function
> (in a dynamic library for example), and it needs N parameters (to keep
> things simple, they're all of int type). How to call such a function in C
> without writing N different calls? (Let's say N could be 0 to 12; so 13 lots
> of calls.)

This capability is actually the subject of a library, which is part of a
collection of four libraries. Unfortunately, this collection, "libffcall", is
GNU licensed:

http://www.gnu.org/software/libffcall/

Though the libraries are GPL'ed, they provide a plausible API for doing
some very useful things which could be added to the C language. Or at least
cloned in the form of more permissive implementations.

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

#2053

"BartC" <bc@freeuk.com> wrote in message 
news:57B7v.161805$Qm2.151455@fx16.am4...

...

> Try this one (an actual requirement I had): you have a pointer to a 
> function
> (in a dynamic library for example), and it needs N parameters (to keep
> things simple, they're all of int type). How to call such a function in C
> without writing N different calls? (Let's say N could be 0 to 12; so 13 
> lots
> of calls.)

Perhaps I don't understand the requirement properly but wondered if you 
could use the va_arg facilities. They may be unsafe but they are flexible. 
If fp was the function pointer (and assuming that function pointers are 
automartically derefrenced so the preceding * is not needed) could you do

  fp(1, parm1);
  fp(5, parm1, parm2, parm3, parm4, parm5);

etc?

> (In my languages, I would either step into inline assembly for this, or 
> use
> an odd statement I had called 'stack' which would push any expression onto
> the hardware stack.)

Parms can also be stored as a block in memory. AIUI some would call this a 
control block. The address of the control block can be passed to a function 
such as

  fp(&cb);

Would either that or the va_arg idea above solve the problem you mentioned?

>> Rather than design a new language I wonder how feasible it would be for
>> one of us to evolve C into something better by means of a series of small
>> steps. The language base is there just asking to be improved. Anyone 
>> tried
>> that?
>
> I don't think it's possible without keeping all the bad stuff. It would be
> easier to create a new language, and a few have come out (sadly inheriting
> C's syntax in most cases). Not quite low level enough though.
>
> For example, how do you get rid of the ghastly type declaration syntax in
> one step?

Could you not declare variables and constants in your own preferred way? You 
mean it's hard to come up with a declaration syntax that both looks better 
or is better organised but which is also as comprehensive as C's?

James

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

#2058

"James Harris" <james.harris.1@gmail.com> wrote in message
news:ljnilc$f30$1@dont-email.me...
> "BartC" <bc@freeuk.com> wrote in message
> news:57B7v.161805$Qm2.151455@fx16.am4...
>
> ...
>
>> Try this one (an actual requirement I had): you have a pointer to a
>> function
>> (in a dynamic library for example), and it needs N parameters (to keep
>> things simple, they're all of int type). How to call such a function in C
>> without writing N different calls? (Let's say N could be 0 to 12; so 13
>> lots
>> of calls.)
>
> Perhaps I don't understand the requirement properly but wondered if you
> could use the va_arg facilities. They may be unsafe but they are flexible.
> If fp was the function pointer (and assuming that function pointers are
> automartically derefrenced so the preceding * is not needed) could you do
>
>  fp(1, parm1);
>  fp(5, parm1, parm2, parm3, parm4, parm5);
>
> etc?

I'm not sure. I asked about this in comp.lang.c, and apparently these was no
way to do it in actual C (there is a library which I think I looked at, but
there must have been some issue with it because I just needed up with a
switch statement and dozens of different calls!).

The problem can be expressed better as the implementation of this function:

int call_dll_function (void* fnaddr, int* paramlist, int nparams, int*
result) {
 .....
}

So: fnaddr is the address of the function you want to call; paramlist points
to a list of <nparams> int arguments (nparams can be zero, and an upper
limit could be assumed); result is NULL, or a pointer to an int to receive
the result type. It might return some status value.


> Could you not declare variables and constants in your own preferred way?
> You mean it's hard to come up with a declaration syntax that both looks
> better or is better organised but which is also as comprehensive as C's?

No, it's very easy. (Look at the CDECL program, eg.
http://www.lemoda.net/c/cdecl/index.cgi, which translates between C type
specs and English. The English is a left-to-right linear description of the
type. This left-to-right form, or a more compact version (pinched from 
Algol-68) is what I use.)

But how to incorporate it into the language? It would need to support both
somehow. But people who are 'into' C apparently aren't bothered with the 
that part of it. (Although it begs the question of why someone thought it 
necessary to create such a utility as CDECL in the first place!)

-- 
Bartc 

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

#2059

"BartC" <bc@freeuk.com> wrote in message 
news:qXJ7v.229545$n%4.33370@fx10.am4...

...

>>> Try this one (an actual requirement I had): you have a pointer to a
>>> function
>>> (in a dynamic library for example), and it needs N parameters (to keep
>>> things simple, they're all of int type). How to call such a function in 
>>> C
>>> without writing N different calls? (Let's say N could be 0 to 12; so 13
>>> lots
>>> of calls.)
>>
>> Perhaps I don't understand the requirement properly but wondered if you
>> could use the va_arg facilities. They may be unsafe but they are 
>> flexible.
>> If fp was the function pointer (and assuming that function pointers are
>> automartically derefrenced so the preceding * is not needed) could you do
>>
>>  fp(1, parm1);
>>  fp(5, parm1, parm2, parm3, parm4, parm5);
>>
>> etc?
>
> I'm not sure. I asked about this in comp.lang.c, and apparently these was 
> no
> way to do it in actual C (there is a library which I think I looked at, 
> but
> there must have been some issue with it because I just needed up with a
> switch statement and dozens of different calls!).
>
> The problem can be expressed better as the implementation of this 
> function:
>
> int call_dll_function (void* fnaddr, int* paramlist, int nparams, int*
> result) {
> .....
> }

OK. The problem seems to be that there would be no way for call_dll_function 
to issue the call because the number of parameters to a C call has to be 
manifest in the source. Good point. I don't know of any language which would 
support that except assembly. As you say, a language could have a 
"parameter" statement so that calls were made by

  parameter 1
  parameter 2
  ...
  parameter N
  invoke call_dll_function
  remove N parameters

Then it would work. (The parameters might need to be stated in the other 
direction, i.e. from N down to 1.)

If you wrote the called DLLs they could, instead, get their parameters from 
a control block as in

  dll1(int *paramlist) {
    /* access paramlist[0], paramlist[1], etc */

But if you didn't write the DLLs then your options are limited. That's one 
thing I've seen with compilers in general: despite being code generators 
they are very poor at interfacing. People don't seem to build in to them the 
ability to customise the generated code for specific calls. Instead, the 
routines they interface with are expected to adapt to the dictats of the 
particular compiler's selected calling convention. Although C is normally 
low level its calling sequence is fairly high level and is one thing I would 
change: have a default but also allow variants to be indicated where 
required.

...

>> Could you not declare variables and constants in your own preferred way?
>> You mean it's hard to come up with a declaration syntax that both looks
>> better or is better organised but which is also as comprehensive as C's?
>
> No, it's very easy. (Look at the CDECL program, eg.
> http://www.lemoda.net/c/cdecl/index.cgi, which translates between C type
> specs and English. The English is a left-to-right linear description of 
> the
> type. This left-to-right form, or a more compact version (pinched from 
> Algol-68) is what I use.)
>
> But how to incorporate it into the language? It would need to support both
> somehow. But people who are 'into' C apparently aren't bothered with the 
> that part of it. (Although it begs the question of why someone thought it 
> necessary to create such a utility as CDECL in the first place!)

If you did choose to evolve C into something else you would probably not 
want to keep it backwards compatible. If you don't like the existing 
declarations surely the purpose is, then, to remove them and replace them 
with something better. No point in keeping compatible with something you 
dislike.

James

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

#2061

On Tue, 29 Apr 2014 06:33:50 -0400, James Harris  
<james.harris.1@gmail.com> wrote:

> If you did choose to evolve C into something else you would
> probably not want to keep it backwards compatible.

Why wouldn't you?

1) C is everywhere
2) if the C compiler has a preprocessor,
     you can do most any syntax conversion
3) C can do everything, or C++ can if C can't,
     and C++ was coded in C ...

LOL. ;-)

AISI, the easy place to start is to write your language parser in C.
Yes, you may need to rewrite it in the host language, eventually,
or you could cross-compile.


Rod Pemberton

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

#2052

On Mon, 28 Apr 2014 17:50:34 -0400, James Harris  
<james.harris.1@gmail.com> wrote:

> I often think it strange that many people, including me, have so many
> issues with C and yet it despite the things I don't like or wish could be
> better it is still far and a away my language of choice for a lot of  
> work.
> How can one language be so bad yet so choosable?

It's your perception of what is "bad" combined with your perception
of what is "useful."  If you perceived other languages to be as
useful as C, then you wouldn't chose C, would you?  I.e., decades
ago, when people had a choice of BASIC, Cobol, FORTRAN, or Pascal,
they usually chose BASIC.  It was/is a general purpose language
good with integers and strings, albeit an unstructured language.

Although many argue for domain specific languages to solve specific
sets of problems, or argue for a high level of abstraction so that
mathematicians, physicists, or engineers can solve problems without
needing to learn how to reduce the problem to the machine level,
such languages don't work well when needed to make the machine do
something.  The correct path, IMO, is for mathematicians, physicists,
and engineers to learn how to program real world machines, and learn
how to convert their problems into programs those machines can run.
Yes, I know that's not a popular perspective.

> What makes it so good to program in despite the faults that
> people identify?

I think it has two aspects.  First, what C gets correct.  Second,
when and where C gets stuff incorrect.  Most of the incorrect
stuff is either trivial, low-use, or on the periphery.

I can identify quite a few and if you've seen my past posts, here,
a.o.d., a.l.a., c.l.a.x., you're probably aware of some of the many
faults of C.

So, let's list some (what I recall right now...) of what I think
C gets correct:

1) pointers
2) declaration syntax of objects matches usage syntax
3) symbols for symbolic operations not text, i.e., '<' instead of '.LT.'
4) curly braces for blocks
5) user doesn't have to manually maintain variables on a stack, or
     manually setup and pass parameters to procedures
6) all objects map onto arrays of bytes
     (ease of copying or moving blocks of data or loading files etc)
7) very good with strings and integers
8) fits the computing architecture of microprocessor based machines
9) supports two's complement arithmetic
10) nul terminated strings

It can be argued that many of these features, and others, exist in C
because the original authors (Kernighan, Ritchie, Thompson) ported
C to so many different computing platforms and had to redesign the
language to fit, as many as possible, as cleanly as possible.

Yes, I know some/many on that list are controversial too.  Just mention
nul terminated strings in comp.lang.forth.  Forth uses counted strings.
But, nul terminated strings solved the problem with incorrect lengths
on counted strings.  Of course, it's possible in C to end up with
an unterminated string.

> In my own designs I tend to avoid including the features of C due to
> things like their lack of security but then it becomes very difficult
> to provide the same facilities in a secure way.

Bingo!

Lack of pointers is a serious problem to have.  The Pascal that I learned
decades ago didn't have them.  It was very difficult to solve some
basic problems without them.  I'm not sure how Java etc get around the
issue.  Of course, we've since learned that pointers can be very unsafe.
So, we have a power or flexibility versus safety issue.

> Rather than design a new language I wonder how feasible it would be for
> one of us to evolve C into something better by means of a series of small
> steps.  The language base is there just asking to be improved. Anyone
> tried that?

I made a list of changes to C that could be done to C to create a safer,
better version of C.  Each of these changes were compatible with the
C preprocessor.  C's preprocessor can turn just about anything back into
valid C.  E.g., I've disliked C's use of '=' for assignment.  It should
be two characters to allow for searching without matching other assignment
operators in C.  A simple define of ':=' to '=' will allow one to use
':=' for assignment.  However, I moved on and starting developing my
own language, which I really dislike the syntax, but it parses easily.

> [C++]

Yes, many, including me see C++ as horrid.  It does have a few nice ideas,
but the bulk of it ... seems to just layer on complexity for no reason.


Rod Pemberton

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

#2054

"Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message 
news:op.xe11uyjf6zenlw@localhost...
> On Mon, 28 Apr 2014 17:50:34 -0400, James Harris 
> <james.harris.1@gmail.com> wrote:

... (re. C language)

>> What makes it so good to program in despite the faults that
>> people identify?
>
> I think it has two aspects.  First, what C gets correct.  Second,
> when and where C gets stuff incorrect.  Most of the incorrect
> stuff is either trivial, low-use, or on the periphery.
>
> I can identify quite a few and if you've seen my past posts, here,
> a.o.d., a.l.a., c.l.a.x., you're probably aware of some of the many
> faults of C.
>
> So, let's list some (what I recall right now...) of what I think
> C gets correct:

...

I've snipped the list as we are going off topic but we could discuss in a 
new thread if you wish. It would be interesting to also see the things you 
don't like about C. As mentioned, we wouldn't all agree on what changes we 
would want. Maybe that's why of the many derivatives of C few have been 
successful.

> It can be argued that many of these features, and others, exist in C
> because the original authors (Kernighan, Ritchie, Thompson) ported
> C to so many different computing platforms and had to redesign the
> language to fit, as many as possible, as cleanly as possible.

I was surprised to see Kernighan's name in there. What was his involvement?

I think you are right that porting a language to many different machines 
would have been a big help in identifying essential elements of the language 
and, where necessary, in designing features to abstract the differences.

...

> Lack of pointers is a serious problem to have.  The Pascal that I learned
> decades ago didn't have them.  It was very difficult to solve some
> basic problems without them.  I'm not sure how Java etc get around the
> issue.

Not my area but I believe Java allows pointers to objects but disallows 
arithmetic on them and, AFAIK, checks array bounds. So while it has pointers 
they are not completely flexible; the language stops users pointing at or 
referring to memory that the compiler cannot identify. This is not just a 
Java feature. These are basic checks. Many languages do similarly. C cannot 
check memory accesses as it has no comprehensive way to know what the memory 
limits of a bare pointer are.

>  Of course, we've since learned that pointers can be very unsafe.

Very! C's allowing pointers to be manipulated by programmers and its 
avoiding bounds checking has led to many computer security issues that we 
have had over the decades including the current one. It would be hard to 
estimate how much money C's pointer model has gained the computer industry 
in development savings vs how much it has lost the world due to bugs in 
code.

> So, we have a power or flexibility versus safety issue.

Yes, absolutely. Pointers themselves are wonderful in that they solve all 
kinds of problems naturally, simply and efficiently. Yet as implemented in C 
they are also a liability. Power and responsibility.

James

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

#2060

On Tue, 29 Apr 2014 03:24:02 -0400, James Harris  
<james.harris.1@gmail.com> wrote:
> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message

>> It can be argued that many of these features, and others, exist in C
>> because the original authors (Kernighan, Ritchie, Thompson) ported
>> C to so many different computing platforms and had to redesign the
>> language to fit, as many as possible, as cleanly as possible.
>
> I was surprised to see Kernighan's name in there. What was his  
> involvement?
>

K&R C ...  What do you think the 'K' and 'R' in K&R are for?

Brian Kernighan and Dennis Ritchie.

Did you mean Ken Thompson? The B language, Unix, and apparently
(I looked this up.) C's ++ -- operators, etc.

> Not my area but I believe [that] Java allows pointers to objects
> but disallows arithmetic on [pointers ...]

That's actually a limitation too.  Sometimes you need to do that.
I'd think that linked-lists, binary trees, threaded-code, and even
indexing of arrays or copying of objects would be situations where
that might be used.


Rod Pemberton

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

#2064

"Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message 
news:op.xe2s1zad6zenlw@localhost...
> On Tue, 29 Apr 2014 03:24:02 -0400, James Harris 
> <james.harris.1@gmail.com> wrote:
>> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message
>
>>> It can be argued that many of these features, and others, exist in C
>>> because the original authors (Kernighan, Ritchie, Thompson) ported
>>> C to so many different computing platforms and had to redesign the
>>> language to fit, as many as possible, as cleanly as possible.
>>
>> I was surprised to see Kernighan's name in there. What was his 
>> involvement?
>>
>
> K&R C ...  What do you think the 'K' and 'R' in K&R are for?
>
> Brian Kernighan and Dennis Ritchie.

Yes, that's a book! Because the book became so popular some people assume 
Kernighan had a hand in writing C but I was sure you would have known that 
he did not. I would be interested to hear that he had a hand in porting C 
but have never heard of that before. He certainly was not an author of C.

If, on the other hand, by "authors" you meant writing books AFAIK Thompson 
has never written any books on C though he may have done.

> Did you mean Ken Thompson? The B language, Unix, and apparently
> (I looked this up.) C's ++ -- operators, etc.

No, I didn't mean him. Thompson was credited with B as Ritchie was credited 
with C. I don't know but I can easily believe that Thompson was involved in 
porting C. However, for some reason I did not imagine Kernighan being 
involved in that.

>> Not my area but I believe [that] Java allows pointers to objects
>> but disallows arithmetic on [pointers ...]
>
> That's actually a limitation too.  Sometimes you need to do that.
> I'd think that linked-lists, binary trees, threaded-code, and even
> indexing of arrays or copying of objects would be situations where
> that might be used.

No, under the no-arithmetic-on-pointers model any 'object' can be pointed at 
but the pointer stays pointing at the beginning of the object rather than 
jumping into it. And offsets within indexable objects can be referred to by 
index. So all the structures you mention can be accommodated, albeit not 
quite in the same way.

James

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

#2089

On Tue, 29 Apr 2014 09:38:41 -0400, James Harris  
<james.harris.1@gmail.com> wrote:
> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message
> news:op.xe2s1zad6zenlw@localhost...
>> On Tue, 29 Apr 2014 03:24:02 -0400, James Harris
>> <james.harris.1@gmail.com> wrote:
>>> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message

>>>> It can be argued that many of these features, and others, exist in C
>>>> because the original authors (Kernighan, Ritchie, Thompson) ported
>>>> C to so many different computing platforms and had to redesign the
>>>> language to fit, as many as possible, as cleanly as possible.
>>>
>>> I was surprised to see Kernighan's name in there. What was his
>>> involvement?
>>
>> K&R C ...  What do you think the 'K' and 'R' in K&R are for?
>>
>> Brian Kernighan and Dennis Ritchie.
>
> Yes, that's a book! Because the book became so popular some people assume
> Kernighan had a hand in writing C but I was sure you would have known  
> that
> he did not.

Interesting point.  Actually, I never gave it much thought to it.  The  
books
on C which I recollect did nothing more than mention their names in  
passing.
So, I guess that was an assumption on my part since both were named for the
book and unofficial language standard.  I've never read K&R C.  It seemed
less informative that other books.  Was that mentioned in there?

> I would be interested to hear that he had a hand in porting C
> but have never heard of that before. He certainly was not an
> author of C.

I currently only have the handful of C papers Ritchie placed on the
internet to search through for references, and a few others.  My C
library (books) has been packed away for many years, except the two
books I've told you about previously.


Rod Pemberton

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

#2100

"Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message 
news:op.xe5qdsaj6zenlw@localhost...
> On Tue, 29 Apr 2014 09:38:41 -0400, James Harris 
> <james.harris.1@gmail.com> wrote:
>> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message
>> news:op.xe2s1zad6zenlw@localhost...
>>> On Tue, 29 Apr 2014 03:24:02 -0400, James Harris
>>> <james.harris.1@gmail.com> wrote:
>>>> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message
>
>>>>> It can be argued that many of these features, and others, exist in C
>>>>> because the original authors (Kernighan, Ritchie, Thompson) ported
>>>>> C to so many different computing platforms and had to redesign the
>>>>> language to fit, as many as possible, as cleanly as possible.
>>>>
>>>> I was surprised to see Kernighan's name in there. What was his
>>>> involvement?
>>>
>>> K&R C ...  What do you think the 'K' and 'R' in K&R are for?
>>>
>>> Brian Kernighan and Dennis Ritchie.
>>
>> Yes, that's a book! Because the book became so popular some people assume
>> Kernighan had a hand in writing C but I was sure you would have known 
>> that
>> he did not.
>
> Interesting point.  Actually, I never gave it much thought to it.  The 
> books
> on C which I recollect did nothing more than mention their names in 
> passing.
> So, I guess that was an assumption on my part since both were named for 
> the
> book and unofficial language standard.  I've never read K&R C.  It seemed
> less informative that other books.  Was that mentioned in there?

I don't remember seeing it in K&R2. I thought I had seen a video of 
Kernighan saying that he was not involved but I cannot find it. However, I 
did find this:

  http://www.linuxjournal.com/article/7035

The relevant part is short enough to repeat here

LJ: What was your part in the birth and destiny of the C language?

BK: I had no part in the birth of C, period. It's entirely Dennis Ritchie's 
work. I wrote a tutorial on how to use C for people at Bell Labs, and I 
twisted Dennis's arm into writing a book with me. But, if he had been so 
motivated, he certainly could have done it without help. He's a superb 
writer, as one can tell from the C reference manuals, which are his prose, 
untouched. I've profited a great deal from being part of the book, and I 
treasure Dennis as a friend, but I didn't have anything to do with C.

I don't know about you but this seems to me to be an especially modest 
comment. Pure speculation but I could imagine Ritchie speaking more highly 
of Kernighan's input, if only in terms of useful feedback on the design.

>> I would be interested to hear that he had a hand in porting C
>> but have never heard of that before. He certainly was not an
>> author of C.
>
> I currently only have the handful of C papers Ritchie placed on the
> internet to search through for references, and a few others.  My C
> library (books) has been packed away for many years, except the two
> books I've told you about previously.

Re. porting C I remember hearing a story that Ritchie and Thompson once got 
muddled up over who was going to write a certiain small subroutine and they 
both wrote it. When they realised what had happened they compared the code 
and found the two versions identical! It was because of hearing that that I 
could imagine them both being involved in porting C but that is an 
assumption on my part.

James

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

#2056

On Mon, 28 Apr 2014 21:46:00 -0400, Rod Pemberton wrote:

> So, let's list some (what I recall right now...) of what I think
> C gets correct:
> 
> 1) pointers

Since C did almost everything wrong. I will comment only on pointers, which 
is also an easy game. What is wrong with them:

1. Pointer types are improperly typed as they are matched by structure. 
Thus you cannot have two distinct pointer types for the same target type. 
The feature extremely important for building sorted containers and custom 
memory pools.

2. Pointers are not initialized with null, as they must for safety reasons. 
Neither are they checked for null when dereferenced.

3. Allocator and deallocator are not operations of the pointer type (this 
was partially fixed in C++)

4. Pointer arithmetic is a low level hack which should not be there, 
because it does not make any sense for variable sized targets or advanced 
structures like graphs and trees. It also does not make sense on certain 
machine architecture which was and is a huge problem for ones with the 
machine word shorter than the physical memory space.

5. Confusing pointers with arrays is a huge problem that caused countless 
issues throughout all life time of C. Recent example is OpenSSL.

6. Pointers are easily converted to integers and many C programmers 
consider such conversions OK, which leads to extremely fragile and 
non-portable code.

7. Each object in C is assumed to be addressable, i.e. the &-operation is 
defined on each object. This was tolerable half century ago, 
notwithstanding that K&R were seemingly unaware of Boolean and packed 
arrays. But now it is a heavy burden with machines of hundreds of registers 
and many leveled cache.

That's from the top.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

#2066

On 2014-04-29, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Mon, 28 Apr 2014 21:46:00 -0400, Rod Pemberton wrote:
>
>> So, let's list some (what I recall right now...) of what I think
>> C gets correct:
>> 
>> 1) pointers
>
> Since C did almost everything wrong. I will comment only on pointers, which 
> is also an easy game. What is wrong with them:
>
> 1. Pointer types are improperly typed as they are matched by structure. 
> Thus you cannot have two distinct pointer types for the same target type. 
> The feature extremely important for building sorted containers and custom 
> memory pools.

"Extremely" is a hyperbole, since people have developed these things in C
without even so much a fleeting thought such as "I could use pointer type names
based on name equivalence".

> 2. Pointers are not initialized with null, as they must for safety reasons. 
> Neither are they checked for null when dereferenced.

C variables in static storage are initialized to null or zero, as the case may
be.

Local variables are not initialized in C, which is a safety issue for any type,
not only pointers. An uninitialized integer could be used as bad index,
relative to a pointer which is initialized. An uninitialized floating-point
value could crash a rocket.

Any decent C compiler has a warnings for uninitialized locals, and any decent
C programmer investigates what diagnostic options are available, and uses
all of them that aren't nuisance stylistic warnings.

It is not difficult to implement the diagnostic: during data flow analysis, the
compiler can identify variable uses which are not preceded by an assignment in
the flow graph. Such cases are either provably uninitialized uses or potential.

> 3. Allocator and deallocator are not operations of the pointer type (this 
> was partially fixed in C++)
>
> 4. Pointer arithmetic is a low level hack which should not be there, 
> because it does not make any sense for variable sized targets or advanced 
> structures like graphs and trees.

Pointer arithmetic is necessary for managing variable-sized targets,
like records that have multiple variant fields, all in the same linear
memory block. These could be stuck into a graph structure.

> It also does not make sense on certain 
> machine architecture which was and is a huge problem for ones with the 
> machine word shorter than the physical memory space.

The demand for C toolchains killed those architectures, so that's not a problem
any more.

Machines with a word size that cannot address all memory are ... silly.

This is not a "huge problem" in the world; on the contrary, it is a
non-problem, now that cheap 64 bit machines are available to consumers.

> 5. Confusing pointers with arrays is a huge problem that caused countless
> issues throughout all life time of C. Recent example is OpenSSL.

No comment there. The tools and choice of tools and methods does deserve blame
here.

> 6. Pointers are easily converted to integers and many C programmers 
> consider such conversions OK, which leads to extremely fragile and 
> non-portable code.

Pointers are not easily converted to integers; an incantation is required
to do this: a cast. Without the cast, the conversion is a constraint
violation that requires a diagnostic.

The incantation isn't very verbose. Making it so wouldn't be an impediment
because programmers could use macros to overcome cumbersome incantations.  You
could language-built-in macros away from programmers, in which case they could
retort with custom preprocessors and code generation.

What would constitute sufficient difficulty in the integer-pointer conversion?
Sacrificing a goat for each instance?

The code is not fragile and non-portable at the same time. Conversions between
pointers and integers can be completely solid.

Example: the traditional return value of the POSIX function to indicate failure:
-1 cast to (void *). (Nowadays hidden behind the symbol MAP_FAILURE).

Non portable it may be, but there isn't anything "fragile" about it.
Fragility would be demonstrated by breaking, and that would just add up to
non-portability.

Integers cast to pointers are used for memory-mapped I/O registers. This is very
common in operating system kernels and embedded systems.

> 7. Each object in C is assumed to be addressable, i.e. the &-operation is 
> defined on each object.

Variables declared "register" cannot have this operation applied to them.

But even without this, the analysis is very easy for determining whether or not
a declared object is subject to the & operator over its scope.

> This was tolerable half century ago,
> notwithstanding that K&R were seemingly unaware of Boolean and packed
> arrays.

Bit-field structure members (a C feature since ANSI C of the 1980's), also
cannot have their address taken.

> But now it is a heavy burden with machines of hundreds of registers 
> and many leveled cache.

In fact the trend has been that compilers can work this out.

And so the register storage class specifier has become deprecated.

It's not unusual to see a C compiler completely optimize a variable into
a register, or make it disappear entirely.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web