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

Groups > comp.lang.misc > #2066

Re: Wirth-ian languages

Show all headers | View raw

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.

Back to comp.lang.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web