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

Groups > comp.lang.c > #123220

Re: C needs to evolve

Show all headers | View raw

On Tuesday, November 21, 2017 at 4:08:43 PM UTC-5, supe...@casperkitty.com wrote:
> On Tuesday, November 21, 2017 at 2:19:22 PM UTC-6, Rick C. Hodgin wrote:
> > On Tuesday, November 21, 2017 at 2:51:48 PM UTC-5, supe...@casperkitty.com wrote:
> > > For example, presently malloc(0) may return NULL, or it may return a unique
> > > pointer that must be passed to free() once.  I would suggest that most code
> > > that would need the first behavior, as well as most code that would need
> > > the second, would also work with a different behavior which doesn't match
> > > either but would offer the advantages of both:
> > 
> > To be honest, I don't think nailing down every such detail is the
> > job of a standard.  I think it should be written in such a way like,
> > "malloc() expects a parameter of 1 or greater and allocates that size
> > in bytes," and leave it at that.  When a case arises that's outside
> > of that expectation, the library implementer is free to do whatever
> > they want.  The goal of the standard should be to provide guidance on
> > useful data processing.  The concept of malloc(0) is nebulous at best.
> > Adding the simple phrase that it expects a value of 1 or greater would
> > remove that case and make it a non-issue.
> 
> There are many situations where an operation will need to act upon N
> items, with N possibly being zero.  A good language should minimize
> the need for special code to handle the N==0 case.

I disagree.  It should be function-specific and not language specific.
There are times when 0 makes sense as an input parameter, and times
when it doesn't.  It should be on a function-by-function basis.

> Unfortunately,
> there are some places where the Standard makes it necessary to add
> special code for the N==0 case even at the machine-code level the N==0
> case could be handled just like any other.

That's the prescription I'm talking about.  Identify the functions that
exist, and their intended use and behavior, but allow the implementors
to handle cases outside of the expected data processing usage in any
way they choose.  There could be a supplemental section, or a comment
that's marked off indicating that this is not a requirement, but it is
reasonably believed it should work this way, and then identify in brief.

> A lot of code that calls malloc(N) will attempt to copy N bytes to/from
> such an allocation, or do pointer arithmetic to find the end of the usable
> allocation, and of course pass the pointer back to free(), but it won't
> care about whether the pointer compares unequal to all other allocations.
> Having malloc(0) behave in a fashion that would allow code for N>0 to
> work just as well for N==0 seems more helpful than requiring user code
> to handle the N==0 case specially.

I disagree.  I think the purpose of functions is to provide utility of
use, and relevant information.  Both must be returned.  The two return
param malloc() idea conveys both, which is why I introduce such a
creation in CAlive.

There are certain fundamentals in data processing.  They are self-
evident when you examine things closely and break things down at each
stage.  This is one of them.  It might be slower to provide both use
and information, but it is proper.  An optimizing compiler could then
use a profile-guided-optimization to remove the need for testing for
malloc(0), for example, and remove that whole block of code related
to setting the error value, if it could be known that no input would
be of that value.

One thing I introduce in CAlive are the concept of i() and ii() func-
tions.  These are internal functions that aren't visible through an
API, but are only called from code that is internal.  The i() func-
tions are internal, but may receive parameters that are invalid, so
you must check for things.  The ii() functions receive data that is
known to be good, so they bypass the validation check.  To simplify
development, I've introduced the i {..} block, which goes into an
ii() function and allows the ii() function be called as an i() func-
tion, which then will also run the i {..} block code.  When called
as an ii() function that code is not run.

There are things like this that are revealed by an examination of
the fundamentals of data processing.  And whereas I have not yet
set my sights on optimization, but only on exactness and correctness,
my goal at some point will be to then turn toward optimization, and
I will be able to identify these kinds of blocks and determine if
they are needed, allowing for a profile-guided-optimization in a
later compile.

My goals toward this end in CAlive are comprehensive, but here in C
a lot of what I'm doing in CAlive could be introduced in and of its
own rights.  It would require a departure from the existing C standard,
but would be doable in creating a C Spur-Standard , or some such.

<pipedream> And it is my hope that if we are able to create a much
simpler standard, one which leaves much implementation detail up
to the implementors, but yet provides solid guidance on those things
the language should provide, such as the class, exceptions, etc.,
then eventually the C Spur-Standard would be migrated into the real
C Standard and all that I've been working for would finally be
introduced. </pipedream>

-- 
Rick C. Hodgin

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

Thread

C needs to evolve "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-11-17 06:04 -0800
  Re: C needs to evolve "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-11-17 22:14 +0800
    Re: C needs to evolve "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-11-17 22:15 +0800
    Re: C needs to evolve "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-11-17 06:18 -0800
      Re: C needs to evolve Mark Storkamp <mstorkamp@yahoo.com> - 2017-11-17 09:12 -0600
    Re: C needs to evolve "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-11-17 06:21 -0800
  Re: C needs to evolve mark.bluemel@gmail.com - 2017-11-17 07:09 -0800
    Re: C needs to evolve "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-11-17 07:24 -0800
      Re: C needs to evolve gazelle@shell.xmission.com (Kenny McCormack) - 2017-11-17 15:45 +0000
    Re: C needs to evolve "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-11-17 07:29 -0800
      Re: C needs to evolve "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-11-17 23:33 +0800
      Re: C needs to evolve mark.bluemel@gmail.com - 2017-11-17 07:35 -0800
        Re: C needs to evolve "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-11-17 10:43 -0500
          Re: C needs to evolve supercat@casperkitty.com - 2017-11-21 07:56 -0800
            Re: C needs to evolve "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-11-21 08:28 -0800
              Re: C needs to evolve supercat@casperkitty.com - 2017-11-21 11:51 -0800
                Re: C needs to evolve "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-11-21 12:19 -0800
                Re: C needs to evolve supercat@casperkitty.com - 2017-11-21 13:08 -0800
                Re: C needs to evolve fir <profesor.fir@gmail.com> - 2017-11-21 13:36 -0800
                Re: C needs to evolve "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-11-21 13:41 -0800
                Re: C needs to evolve "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-11-21 14:10 -0800
                Re: C needs to evolve Ian Collins <ian-news@hotmail.com> - 2017-11-22 11:19 +1300
                Re: C needs to evolve "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-11-21 16:07 -0800
                Re: C needs to evolve Ian Collins <ian-news@hotmail.com> - 2017-11-22 13:09 +1300
                Re: C needs to evolve "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-11-21 17:25 -0800
                Re: C needs to evolve Ian Collins <ian-news@hotmail.com> - 2017-11-22 14:31 +1300
                Re: C needs to evolve supercat@casperkitty.com - 2017-11-21 14:33 -0800
                Re: C needs to evolve "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-11-22 05:27 -0800
    Re: C needs to evolve Thiago Adams <thiago.adams@gmail.com> - 2017-11-17 08:32 -0800
      Re: C needs to evolve David Kleinecke <dkleinecke@gmail.com> - 2017-11-17 11:55 -0800
  Re: C needs to evolve zacariaz@gmail.com - 2017-12-01 11:31 -0800
    Re: C needs to evolve Keith Thompson <kst-u@mib.org> - 2017-12-01 11:57 -0800
    Re: C needs to evolve Thiago Adams <thiago.adams@gmail.com> - 2017-12-01 13:26 -0800
      Re: C needs to evolve Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2017-12-01 22:36 +0100
      Re: C needs to evolve supercat@casperkitty.com - 2017-12-01 13:54 -0800
        Re: C needs to evolve Thiago Adams <thiago.adams@gmail.com> - 2017-12-01 14:32 -0800
          Re: C needs to evolve Thiago Adams <thiago.adams@gmail.com> - 2017-12-01 14:39 -0800
      Re: C needs to evolve "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-12-02 04:13 +0100
  Re: C needs to evolve zacariaz@gmail.com - 2017-12-01 15:50 -0800
  Re: C needs to evolve zacariaz@gmail.com - 2017-12-02 03:44 -0800

csiph-web