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

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

How might multiple `entry` points have looked/worked?

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

Contents

  How might multiple `entry` points have looked/worked? luser droog <luser.droog@gmail.com> - 2016-12-08 20:57 -0800
    Re: How might multiple `entry` points have looked/worked? Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2016-12-09 07:28 +0100
    Re: How might multiple `entry` points have looked/worked? fir <profesor.fir@gmail.com> - 2016-12-09 00:25 -0800
      Re: How might multiple `entry` points have looked/worked? fir <profesor.fir@gmail.com> - 2016-12-09 00:32 -0800
      Re: How might multiple `entry` points have looked/worked? fir <profesor.fir@gmail.com> - 2016-12-09 00:53 -0800
    Re: How might multiple `entry` points have looked/worked? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 13:11 +0000
      Re: How might multiple `entry` points have looked/worked? Noob <root@127.0.0.1> - 2016-12-09 16:36 +0100
        Re: How might multiple `entry` points have looked/worked? Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 16:00 +0000
        Re: How might multiple `entry` points have looked/worked? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 16:18 +0000
    Re: How might multiple `entry` points have looked/worked? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-09 11:25 -0500
      Re: How might multiple `entry` points have looked/worked? luser droog <luser.droog@gmail.com> - 2016-12-09 15:51 -0800
    Re: How might multiple `entry` points have looked/worked? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-09 12:48 -0500
      Re: How might multiple `entry` points have looked/worked? Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 18:16 +0000
    Re: How might multiple `entry` points have looked/worked? Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 07:16 -0800
      Re: How might multiple `entry` points have looked/worked? Noob <root@127.0.0.1> - 2016-12-10 16:58 +0100
        Re: How might multiple `entry` points have looked/worked? Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-14 21:15 -0800

#98452 — How might multiple `entry` points have looked/worked?

The `entry` keyword. They must have put some thought
into it to reserve that name for so long. But there
must also have been insurmountable difficulty in the 
way of getting it right, or else they'd've done it.

So, how might multiple `entry` points have looked/worked?
What was the point? What can it do? Could it be done now?
Why (not)?

[toc] | [next] | [standalone]

#98453

On 09.12.16 5:57, luser droog wrote:
> The `entry` keyword. They must have put some thought
> into it to reserve that name for so long. But there
> must also have been insurmountable difficulty in the
> way of getting it right, or else they'd've done it.
>
> So, how might multiple `entry` points have looked/worked?
> What was the point? What can it do? Could it be done now?
> Why (not)?
>
Fortran had that for ages. I have not used it, but it worked.
So it should be possible in C.
And be just as useless.
Just use a variable to control how the start of the routine
should work.

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

#98455

W dniu piątek, 9 grudnia 2016 05:58:08 UTC+1 użytkownik luser droog napisał:
> The `entry` keyword. They must have put some thought
> into it to reserve that name for so long. But there
> must also have been insurmountable difficulty in the 
> way of getting it right, or else they'd've done it.
> 
> So, how might multiple `entry` points have looked/worked?
> What was the point? What can it do? Could it be done now?
> Why (not)?

it was been talked alteady, thay could look like

void foo(int n)
{
  printf(" ala");

  void zz{int n}
  {
   printf(" has %d",n);

   printf(" cats");

  }
  
  return

}

void main()
{
  foo(2);
  foo.zz(3);
}

one should invent real usecases of it though 
(this may be assumpt to think over general block
combining in c but im like to tired to think on it)
[esp i dont want to enlarge this group sin 
which is = not talking on real coding]

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

#98457

>   foo.zz(3);

one could ev rethink foo(2).zz(3) (not in this case but in general where you want to pass more args /though i not sure if this proper etc - analysing it should bring the answers but im probably to distracted to research it - got more important things to do
this seems btw step down in paradigmates as if you will use it youre probably should stop talking abouf functions and talk about blocks of code and its managemant

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

#98463

W dniu piątek, 9 grudnia 2016 09:25:46 UTC+1 użytkownik fir napisał:
> W dniu piątek, 9 grudnia 2016 05:58:08 UTC+1 użytkownik luser droog napisał:
> > The `entry` keyword. They must have put some thought
> > into it to reserve that name for so long. But there
> > must also have been insurmountable difficulty in the 
> > way of getting it right, or else they'd've done it.
> > 
> > So, how might multiple `entry` points have looked/worked?
> > What was the point? What can it do? Could it be done now?
> > Why (not)?
> 
> it was been talked alteady, thay could look like
> 
> void foo(int n)
> {
>   printf(" ala");
> 
>   void zz{int n}
>   {

yet as to this, here maybe it should be more 
zz(int n) {} as function encorporates 3 things 
- block body and name
- entry passing args
- function exit/ret

so like natural it semms that

zz {

}
 
could denote block

int zz {

}

should denote block that return value 

zz(int z)
{

}

block that takes arg

as to return value it is though some doubt if that should mean return value by ret or maybe some more 'lightweight' general one, maybe inline keyword could distinguish it

>    printf(" has %d",n);
> 
>    printf(" cats");
> 
>   }
>   
>   return
> 
> }
> 
> void main()
> {
>   foo(2);
>   foo.zz(3);
> }
> 
> one should invent real usecases of it though 
> (this may be assumpt to think over general block
> combining in c but im like to tired to think on it)
> [esp i dont want to enlarge this group sin 
> which is = not talking on real coding]

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

#98494

luser droog <luser.droog@gmail.com> writes:

> The `entry` keyword. They must have put some thought
> into it to reserve that name for so long.

Who is "they"?  This looks like it might be a from a cross post with
followup-to set because I can't find the parent article.

<snip>
-- 
Ben.

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

#98529

On 09/12/2016 14:11, Ben Bacarisse wrote:

> luser droog <luser.droog@gmail.com> writes:
> 
>> The `entry` keyword. They must have put some thought
>> into it to reserve that name for so long.
> 
> Who is "they"?  This looks like it might be a from a cross post with
> followup-to set because I can't find the parent article.

What makes you think there is a parent post?

I think "they" might be (?) either K&R or WG14.

Although I'm quite confused in that "entry" has never been
a keyword, AFAIK.

Regards.

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

#98542

On 09/12/16 15:36, Noob wrote:
> On 09/12/2016 14:11, Ben Bacarisse wrote:
>
>> luser droog <luser.droog@gmail.com> writes:
>>
>>> The `entry` keyword. They must have put some thought
>>> into it to reserve that name for so long.
>>
>> Who is "they"?  This looks like it might be a from a cross post with
>> followup-to set because I can't find the parent article.
>
> What makes you think there is a parent post?
>
> I think "they" might be (?) either K&R or WG14.
>
> Although I'm quite confused in that "entry" has never been
> a keyword, AFAIK.

You're right. See p192 of K&R2, which tells us that 'entry' was reserved 
for use as a keyword but never actually used.

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

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

#98550

Noob <root@127.0.0.1> writes:

> On 09/12/2016 14:11, Ben Bacarisse wrote:
>
>> luser droog <luser.droog@gmail.com> writes:
>> 
>>> The `entry` keyword. They must have put some thought
>>> into it to reserve that name for so long.
>> 
>> Who is "they"?  This looks like it might be a from a cross post with
>> followup-to set because I can't find the parent article.
>
> What makes you think there is a parent post?

You are right -- there is none.  It was the fact I could not connect it
to C that made me think it had come from another group.

> I think "they" might be (?) either K&R or WG14.

Yes, it must be K&R.

> Although I'm quite confused in that "entry" has never been
> a keyword, AFAIK.

It's in K&R1 but since it's unused I'd forgotten all about it.  It seems
(from Richard's reply) that it's also in K&R2, but it never made it into
any standard.

-- 
Ben.

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

#98553

On Thursday December 8 2016 23:57, in comp.lang.c, "luser droog"
<luser.droog@gmail.com> wrote:

> The `entry` keyword. They must have put some thought
> into it to reserve that name for so long. But there
> must also have been insurmountable difficulty in the
> way of getting it right, or else they'd've done it.
> 
> So, how might multiple `entry` points have looked/worked?

There's not a clue as to what the C 'entry' keyword (if it had been
implemented) would have done or how it would have worked. Only Brian
Kernighan or Dennis Ritchie (or, perhaps, S.C. Johnson) could tell you.

> What was the point? 

One might imagine that "the implementors" expected to use "entry" in the same
way that S.I Feldman and P. J. Weinberger of Bell Labs had used it in
their "Portable Fortran 77 Compiler" for Unix. In that Fortran 77
compiler, 'entry' provided an additional, secondary entrypoint for any
Fortran subroutine or function subprogram (their terminology). To quote the
Bell Labs "A Portable Fortran 77 Compiler":
  "Multiple entry points are now legal. Subroutine and function subprograms
   may have additional entry points, declared by an /entry/ statement with an
   optional argument list.
      entry extra(a,b,c)
   Execution begins at the first statement following the /entry/ line. All
   variable declarations must precede all executable statements in the
   procedure. ... If any entry is a character-valued function, then all
   entries must be. "

If that was the intent of the C 'entry' reserved word, then one might imagine
it would permit the C programmer to combine the logic from several similar C
functions into one function with several entrypoints.

> What can it do?

The C 'entry' reserved word? It can do nothing (other than discourage the
programmer from using the token <<entry>> in their code). It was never
implemented as a keyword, never designated a function in the C language.

> Could it be done now?

Of course it could. "Nothing" can always be done.

> Why (not)?  

Isn't it obvious?

-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

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

#98625

On Friday, December 9, 2016 at 10:25:19 AM UTC-6, Lew Pitcher wrote:
> On Thursday December 8 2016 23:57, in comp.lang.c, "luser droog"
> <luser.droog@gmail.com> wrote:
> 
> > The `entry` keyword. They must have put some thought
> > into it to reserve that name for so long. But there
> > must also have been insurmountable difficulty in the
> > way of getting it right, or else they'd've done it.
> > 
> > So, how might multiple `entry` points have looked/worked?
> 
> There's not a clue as to what the C 'entry' keyword (if it had been
> implemented) would have done or how it would have worked. Only Brian
> Kernighan or Dennis Ritchie (or, perhaps, S.C. Johnson) could tell you.
> 
> > What was the point? 
> 
> One might imagine that "the implementors" expected to use "entry" in the same
> way that S.I Feldman and P. J. Weinberger of Bell Labs had used it in
> their "Portable Fortran 77 Compiler" for Unix. In that Fortran 77
> compiler, 'entry' provided an additional, secondary entrypoint for any
> Fortran subroutine or function subprogram (their terminology). To quote the
> Bell Labs "A Portable Fortran 77 Compiler":
>   "Multiple entry points are now legal. Subroutine and function subprograms
>    may have additional entry points, declared by an /entry/ statement with an
>    optional argument list.
>       entry extra(a,b,c)
>    Execution begins at the first statement following the /entry/ line. All
>    variable declarations must precede all executable statements in the
>    procedure. ... If any entry is a character-valued function, then all
>    entries must be. "
> 
> If that was the intent of the C 'entry' reserved word, then one might imagine
> it would permit the C programmer to combine the logic from several similar C
> functions into one function with several entrypoints.
> 
> > What can it do?
> 
> The C 'entry' reserved word? It can do nothing (other than discourage the
> programmer from using the token <<entry>> in their code). It was never
> implemented as a keyword, never designated a function in the C language.
> 
> > Could it be done now?
> 
> Of course it could. "Nothing" can always be done.
> 
> > Why (not)?  
> 
> Isn't it obvious?
> 

Thanks everyone. Of course it was K&R to whom I referred as 'they'.

`entry` is in the list of reserved keywords in K&R1 on p. 180
with the text:

> The `entry` keyword is not currently implemented by any compiler
> but is reserved for future use. Some implementations reserve the
> words `fortran` and `asm`.

Belatedly, I performed my own search and discovered an SO question
the answers to which mentioned Fortran and PL/I as prior art.
So further searching revealed this page from a Fortran manual
which has illustrations that translate naturally-enough to the
hypothetical early C context under consideration.

quoth
http://www.hpmmsupport.com/MPE%20Manual/5000/B3150190022.12120/31.htm
:

 HP3000 Manuals
   

HP FORTRAN 77/iX Programmer's Guide
Multiple Entries into Subprograms 

A subroutine call or function reference usually invokes the subprogram at
the entry point defined by the SUBROUTINE or FUNCTION statement.  The
first statement executed is the first executable statement in the
subprogram.  However, you can use the ENTRY statement to define other
entry points within the function or subroutine.

The entry point can be anywhere within a function or subroutine after the
FUNCTION or SUBROUTINE statement, but not within an IF block or DO loop.
The ENTRY statement can only be used in a subroutine or function
subprogram, not in a main program or block data subprogram.  A subprogram
can have any number of ENTRY statements.

The ENTRY statement, a nonexecutable statement, looks like this:

     ENTRY name(argument list)

where name is the entry point name, and the optional argument list is
made up of variable names, array names, dummy procedure names, or an
asterisk.  The asterisk, indicating an alternate return, is permitted
only in a subroutine.

When an entry name is used to enter a subprogram, execution begins with
the first executable statement that follows the ENTRY statement.  The
flow of control is illustrated in the following diagram.

                 PROGRAM main
          |<---- CALL entry1(val)
          |      CALL entry2(val) ------>|
          |                              |
          |      END                     |
          |                              |
          |      SUBROUTINE sub          |
          |                              |
          -----> ENTRY entry1(a)         |
                 a = a + 5.0             |
                 RETURN ! Return to main |
                                         |
                 ENTRY entry2(a) <--------
                 a = a + 10.0
                 END ! Return to main

A subroutine with entry points search and punctuation is shown below:

           SUBROUTINE linka(d, n, f)
           INTEGER d, n, f, table, document

     C  In subroutine linka, via primary entry point
           DO 10 i = 1, f, n
           .
           .
           .
      10   CONTINUE
           RETURN

           ENTRY search(table, f)
     C  In subroutine linka, via entry point search
           DO 20 i = 1, f
           .
           .
           .
      20   CONTINUE
           RETURN

           ENTRY punctuation(document)
     C  In subroutine linka, via entry point punctuation
           DO 30 i = 1, 5
           .
           .
           .
      30   CONTINUE
           END

In this subroutine, the names search and punctuation define alternate
entry points into subroutine linka.

The first statement executed in the subroutine is determined by the entry
point, as follows:

-------------------------------------------------------------
|                                |                          |
|    Call to the Entry Point     | First Statement Executed |
|                                |                          |
-------------------------------------------------------------
|                                |                          |
| CALL linka(var1, var2, var3)   | DO 10 I = 1, f, n        |
|                                |                          |
-------------------------------------------------------------
|                                |                          |
| CALL search(var1, var2)        | DO 20 I = 1, f           |
|                                |                          |
-------------------------------------------------------------
|                                |                          |
| CALL punctuation(var1)         | DO 30 I = 1, 5           |
|                                |                          |
-------------------------------------------------------------

The order, type, and names of the dummy arguments in an ENTRY statement
can differ from the dummy arguments in the FUNCTION, SUBROUTINE, and
other ENTRY statements in the same subprogram.  However, each reference
to a function or subroutine must use an actual argument list that agrees
in order, number, and type with the dummy argument list in the
corresponding FUNCTION, SUBROUTINE, or ENTRY statement.  Type agreement
is not required for actual arguments that have no type, such as a
subroutine name or an alternate return specifier as an actual argument.

The following example shows a function with entry points of different
data types:

     REAL FUNCTION f(x)    ! Real function f
     INTEGER k, i
     .
     .
     .
     ENTRY k(i)            ! Integer function k
     .
     .
     .
     END

The declarations of the dummy arguments can precede their use in an ENTRY
statement.  For example, in the following function:

     FUNCTION x(array1, q)
     INTEGER q
     INTEGER array1(q)
     .
     .
     .
     ENTRY y (r, q)
     .
     .
     .
     array1(q) = 100
     .
     .
     .
     END

the variable q is declared before the ENTRY statement and the last
element of the array is set to 100.

In a function subprogram, a variable name that is the same as an entry
name cannot appear in any statement that precedes the appearance of the
entry name in an ENTRY statement, except in a type statement.

Within a subprogram, an entry name cannot appear both as an entry name in
an ENTRY statement and as a dummy argument in a FUNCTION, SUBROUTINE, or
ENTRY statement.  An entry name cannot appear in an EXTERNAL statement.

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

#98581

On 12/08/2016 11:57 PM, luser droog wrote:
> The `entry` keyword. They must have put some thought
> into it to reserve that name for so long. ...

What are you talking about? You posted this to comp.lang.c, so I would 
have expected that you were talking about a name reserved by the C 
standard - but "entry" is not one of those names. ENTRY is reserved as a 
macro name if you #include <errno.h>, but that has nothing to do with 
the rest of your message.

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

#98589

On 09/12/16 17:48, James R. Kuyper wrote:
> On 12/08/2016 11:57 PM, luser droog wrote:
>> The `entry` keyword. They must have put some thought
>> into it to reserve that name for so long. ...
>
> What are you talking about? You posted this to comp.lang.c, so I would
> have expected that you were talking about a name reserved by the C
> standard - but "entry" is not one of those names.

No, but it /was/ reserved by K&R, or so K&R2 claims. Mr droog was using 
the past tense.

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

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

#98695

luser droog <luser.droog@gmail.com> writes:

> The `entry` keyword.  They must have put some thought
> into it to reserve that name for so long.  But there
> must also have been insurmountable difficulty in the
> way of getting it right, or else they'd've done it.
>
> So, how might multiple `entry` points have looked/worked?
> What was the point?  What can it do?  Could it be done now?
> Why (not)?

This is an FAQ, 20.37:

   http://c-faq.com/misc/entry.html

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

#98706

On 10/12/2016 16:16, Tim Rentsch wrote:

> luser droog <luser.droog@gmail.com> writes:
> 
>> The `entry` keyword.  They must have put some thought
>> into it to reserve that name for so long.  But there
>> must also have been insurmountable difficulty in the
>> way of getting it right, or else they'd've done it.
>>
>> So, how might multiple `entry` points have looked/worked?
>> What was the point?  What can it do?  Could it be done now?
>> Why (not)?
> 
> This is an FAQ, 20.37:
> 
>    http://c-faq.com/misc/entry.html

For an odd definition of the word "frequently".

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

#99442

Noob <root@127.0.0.1> writes:

> On 10/12/2016 16:16, Tim Rentsch wrote:
>
>> luser droog <luser.droog@gmail.com> writes:
>>
>>> The `entry` keyword.  They must have put some thought
>>> into it to reserve that name for so long.  But there
>>> must also have been insurmountable difficulty in the
>>> way of getting it right, or else they'd've done it.
>>>
>>> So, how might multiple `entry` points have looked/worked?
>>> What was the point?  What can it do?  Could it be done now?
>>> Why (not)?
>>
>> This is an FAQ, 20.37:
>>
>>    http://c-faq.com/misc/entry.html
>
> For an odd definition of the word "frequently".

Hey, I don't make the laws of physics, I just follow them.

[toc] | [prev] | [standalone]

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

csiph-web