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

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

obtaining a c value from a perl script

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

Contents

  obtaining a c value from a perl script fred flintstone <fred@server.invalid> - 2017-04-30 04:36 -0700
    Re: obtaining a c value from a perl script Noob <root@127.0.0.1> - 2017-04-30 14:48 +0200
      Re: obtaining a c value from a perl script fred flintstone <fred@server.invalid> - 2017-05-01 02:25 -0700
        Re: obtaining a c value from a perl script Keith Thompson <kst-u@mib.org> - 2017-05-01 08:46 -0700
          Re: obtaining a c value from a perl script fred flintstone <fred@server.invalid> - 2017-05-03 02:12 -0700
            Re: obtaining a c value from a perl script Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-03 11:48 +0100
    Re: obtaining a c value from a perl script Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-30 16:16 +0100
      Re: obtaining a c value from a perl script fred flintstone <fred@server.invalid> - 2017-05-01 04:18 -0700
        Re: obtaining a c value from a perl script Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-01 13:41 +0100
          Re: obtaining a c value from a perl script Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-03 05:10 -0700
            Re: obtaining a c value from a perl script Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-03 15:00 +0100
            Re: obtaining a c value from a perl script Keith Thompson <kst-u@mib.org> - 2017-05-03 08:55 -0700
              Re: obtaining a c value from a perl script Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-03 09:02 -0700
                Re: obtaining a c value from a perl script Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-03 17:22 +0100
                  Re: obtaining a c value from a perl script fred flintstone <fred@server.invalid> - 2017-05-08 01:43 -0700
                    Re: obtaining a c value from a perl script Keith Thompson <kst-u@mib.org> - 2017-05-08 09:06 -0700
                      Re: obtaining a c value from a perl script fred flintstone <fred@server.invalid> - 2017-05-09 00:35 -0700
                        Re: obtaining a c value from a perl script David Brown <david.brown@hesbynett.no> - 2017-05-09 13:59 +0200
                Re: obtaining a c value from a perl script fred flintstone <fred@server.invalid> - 2017-05-08 02:45 -0700
                  Re: obtaining a c value from a perl script Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-08 04:39 -0700
                    solved Re: obtaining a c value from a perl script fred flintstone <fred@server.invalid> - 2017-05-09 02:43 -0700
                      Re: solved Re: obtaining a c value from a perl script Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-09 15:06 +0100
                        Re: solved Re: obtaining a c value from a perl script fred flintstone <fred@server.invalid> - 2017-05-10 01:03 -0700
                          Re: solved Re: obtaining a c value from a perl script Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-10 11:18 +0100
                            Re: solved Re: obtaining a c value from a perl script fred flintstone <fred@server.invalid> - 2017-05-12 02:26 -0700
                              Re: solved Re: obtaining a c value from a perl script Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-12 11:51 +0100
                          Re: solved Re: obtaining a c value from a perl script fred flintstone <fred@server.invalid> - 2017-05-12 03:49 -0700
                        Re: solved Re: obtaining a c value from a perl script Manfred <invalid@invalid.add> - 2017-05-10 23:21 +0200
                          Re: solved Re: obtaining a c value from a perl script Keith Thompson <kst-u@mib.org> - 2017-05-10 16:23 -0700
                            Re: solved Re: obtaining a c value from a perl script Robert Wessel <robertwessel2@yahoo.com> - 2017-05-11 15:57 -0500
                              Re: solved Re: obtaining a c value from a perl script Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-11 18:57 -0400
                                Re: solved Re: obtaining a c value from a perl script Robert Wessel <robertwessel2@yahoo.com> - 2017-05-11 18:38 -0500
                                  Re: solved Re: obtaining a c value from a perl script Robert Wessel <robertwessel2@yahoo.com> - 2017-05-11 18:46 -0500
                                  Re: solved Re: obtaining a c value from a perl script Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-11 21:11 -0400
                                    Re: solved Re: obtaining a c value from a perl script Robert Wessel <robertwessel2@yahoo.com> - 2017-05-12 01:51 -0500
                                      Re: solved Re: obtaining a c value from a perl script Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-14 23:49 -0400
                    Re: obtaining a c value from a perl script Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-09 07:46 -0700
              Re: obtaining a c value from a perl script mark.bluemel@gmail.com - 2017-05-03 09:06 -0700
                Re: obtaining a c value from a perl script gazelle@shell.xmission.com (Kenny McCormack) - 2017-05-03 17:02 +0000
                Re: obtaining a c value from a perl script fred flintstone <fred@server.invalid> - 2017-05-08 01:51 -0700
        Re: obtaining a c value from a perl script Manfred <noname@invalid.add> - 2017-05-04 18:21 +0200
          Re: obtaining a c value from a perl script fred flintstone <fred@server.invalid> - 2017-05-08 03:52 -0700
            Re: obtaining a c value from a perl script Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-08 08:38 -0400
            Re: obtaining a c value from a perl script Keith Thompson <kst-u@mib.org> - 2017-05-08 09:14 -0700
            Re: obtaining a c value from a perl script "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-08 12:17 -0400
              Re: obtaining a c value from a perl script Keith Thompson <kst-u@mib.org> - 2017-05-08 09:26 -0700
                Re: obtaining a c value from a perl script jameskuyper@verizon.net - 2017-05-08 11:02 -0700
                  Re: obtaining a c value from a perl script Keith Thompson <kst-u@mib.org> - 2017-05-08 11:39 -0700
                Re: obtaining a c value from a perl script Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-09 07:16 -0700
                  Re: obtaining a c value from a perl script Keith Thompson <kst-u@mib.org> - 2017-05-09 08:18 -0700
                    Re: obtaining a c value from a perl script fred flintstone <fred@server.invalid> - 2017-05-10 00:29 -0700
                    Re: obtaining a c value from a perl script Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-10 05:26 -0700
              Re: obtaining a c value from a perl script Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-08 18:20 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#109569 — solved Re: obtaining a c value from a perl script

On 05/08/2017 04:39 AM, Malcolm McLean wrote:
> On Monday, May 8, 2017 at 10:45:31 AM UTC+1, fred flintstone wrote:
>> On 05/03/2017 09:02 AM, Malcolm McLean wrote:
>>>
>>>
>>> fred flintstone speaks English.
>>> I've also faced similar problems, and used similar words. Ben was possibly misled
>>> because "capture" is a term used with a specific meaning for lambda functions
>>> and closures.
>>>
>>
>> I didn't mean this, but now that you brought it up, is there a standard
>> implementation of closures?
>>
> When declaring a function that accepts a function pointer in C, it is good
> practice to always add a void * as a parameter, and accept a void * to pass
> back. Usually this is called something like the "context" pointer. If caller
> doesn't need it, it is simply null. But it can point to a structure containing
> detailed information, and it means you don't need a global (which can be almost
> unworkable if you've got more than one instance of the function pointer live).
>
> The context pointer is effectively a closure, but there's no real syntactical
> support, and it won't automatically call a destructor when the function pointer
> is destroyed.
>

Thanks for your elaboration, malcolm, it prompted the literal solution 
of this thread.

Make query number 11? [Y] :Y
to server is 11 2457987.25976179 2457987.25883747 2457987.2592592
right ascension of moon 10h 4m 0s
right ascension of sun 10h 4m 0s
moon seconds is 36240
sun seconds is 36240
equal, while condition fails at julian day 2457987.2592592
This program was called with "./jup".
Value from perl : 2457987.259259
Can't use an undefined value as a SCALAR reference at 3.neptune.pl line 102.
$

----

#include <stdio.h>
#include <stdlib.h>

int main (int argc, char *argv[])
{
   double d;
   printf ("This program was called with \"%s\".\n",argv[0]);

   if (argc == 2)
     {
        d = atof(argv[1]);
        printf("Value from perl : %f\n", d );
        char array[20] = "Hello from C";
        return ( array );
     }
   else
     {
       printf("The program was called wrong.\n");
     }

   return 0;
}

I tried to implement toward the idea of throwing in a pointer, just in 
case a callee requires it. That's not what the subject of this thread 
was, and I've marked it solved so that no one is obligated to hang 
around to help the hapless OP. I won't pursue it here because my 
asbestos suit is giving out.

I was hoping to see a response from C, but didn't quite get there. Perl 
caller after sig.
-- 
fred

use warnings;
use strict;
use 5.010;
use WWW::Mechanize::GZip;
use HTML::TableExtract;

#use HTML::TableExtract qw(tree);
use open ':std', OUT => ':utf8';
use Prompt::Timeout;
use constant TIMEOUT  => 3;
use constant MAXTRIES => 30;

## redesign for solar eclipse of aug 21, 2017

my $site = 'http://www.fourmilab.ch/yoursky/cities.html';
my $mech = 'WWW::Mechanize::GZip'->new;
$mech->get($site);
$mech->follow_link( text => 'Portland OR' );
my $before_bound = 2457987.04167;    #before conjunction
my $after_bound  = 2457988.0;        #after conjunction
$mech->set_fields(qw'date 2');
my $moon_seconds = 5;
my $sun_seconds  = 3;
my $upper        = $after_bound;
my $lower        = $before_bound;
my $equal;
my $equal_sec;
my $now_string = localtime;
my $filename   = '3.neptune.txt';
open( my $jh, '>>', $filename ) or die "Could not open file '$filename' $!";
say $jh "Script executed at $now_string";
say $jh "       attempt  upper  lower  guess";
my $attempts = 1;

## hard code 2 objects to look at

my $e1 = 5;    #moon
my $e2 = 2;    #sun

## hard code column

my $column = 1; #right ascension

while ( ( $sun_seconds != $moon_seconds ) ) {

     my $default = ( ( $attempts >= MAXTRIES ) ) ? 'N' : 'Y';
     my $answer = prompt( "Make query number $attempts?", $default, 
TIMEOUT );
     exit if $answer =~ /^N/i;

     my $guess = closetohalf( $upper, $lower );
     say "to server is $attempts $upper $lower $guess ";
     say $jh "to server is $attempts $upper $lower $guess ";
     $mech->set_fields( jd => $guess );
     $mech->click_button( value => "Update" );
     my $te = 'HTML::TableExtract'->new;
     $te->parse( $mech->content );
     my $table = ( $te->tables )[3];    #ephemeris table

     # looking to get the whole row

     my $row_ref1 = $table->row($e1);
     my @row1     = @$row_ref1;
     say $jh "row1 is @row1";
     my $row_ref2 = $table->row($e2);
     my @row2     = @$row_ref2;
     say $jh "row2 is @row2";



     my $moon = $row1[$column];
     say "right ascension of moon $moon";
     say $jh "right ascension of moon $moon";
     my $sun = $row2[$column];
     say "right ascension of sun $sun";
     say $jh "right ascension of sun $sun";
     $moon_seconds = string_to_second($moon);
     say "moon seconds is $moon_seconds";
     say $jh "moon seconds is $moon_seconds";
     $sun_seconds = string_to_second($sun);
     say "sun seconds is $sun_seconds";
     say $jh "sun seconds is $sun_seconds";

     if ( $sun_seconds < $moon_seconds ) {
         $upper = $guess;
     }
     elsif ( $moon_seconds < $sun_seconds ) {
         $lower = $guess;
     }
     else {
         $equal = $guess;
         say "equal, while condition fails at julian day $equal";
         say $jh "equal, while condition fails at julian day $equal";
         $equal_sec = $moon_seconds;
     }

     $attempts++;
}

say $jh "equal seconds is $equal_sec";

my $return_pointer = pass_to_c( $equal );
say "return pointer pointed to $$return_pointer";

# re-design 4-29-17 for solar eclipse

sub string_to_second {
     my $string = shift;
     my $return = 9000;
     if ( my $success = $string =~ /^(\d*)h\s+(\d*)m\s+(\d*)s$/ ) {
         $return = 3600 * $1 + 60 * $2 + $3;
     }
     else {
         say "string was misformed";
     }
     return $return;
}

sub pass_to_c {
     my $string = shift;
     my $ref_to_c;
     my $ref_from_c;
     system "./jup $string";

     return $ref_from_c;
}

sub closetohalf {
     my ( $up, $low ) = @_;
     $low + ( $up - $low ) * ( 0.4 + rand 0.2 );
}

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

#109590 — Re: solved Re: obtaining a c value from a perl script

fred flintstone <fred@server.invalid> writes:

> On 05/08/2017 04:39 AM, Malcolm McLean wrote:
<snip>
>> When declaring a function that accepts a function pointer in C, it is good
>> practice to always add a void * as a parameter, and accept a void * to pass
>> back.
<snip>
> Thanks for your elaboration, malcolm, it prompted the literal solution
> of this thread.

You may have misunderstood.  Your code has no functions that meet the
criteria in Malcolm's remark: "a function that accepts a function
pointer".

<snip>
> This program was called with "./jup".
> Value from perl : 2457987.259259
> Can't use an undefined value as a SCALAR reference at 3.neptune.pl line 102.
> $
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main (int argc, char *argv[])
> {
>   double d;
>   printf ("This program was called with \"%s\".\n",argv[0]);
>   if (argc == 2)
>     {
>        d = atof(argv[1]);
>        printf("Value from perl : %f\n", d );
>        char array[20] = "Hello from C";
>        return ( array );

You compiler should have told you that this was, at best, dodgy.  main
is an int valued function and 'array' is not an int.

Just as you are choosing to pass the number to your program as a string,
you need to get the results back as a string.  To do that you *print*
the result:

  #include <stdio.h>
  #include <stdlib.h>

  int main (int argc, char *argv[])
  {
       if (argc == 2)
            printf("%f\n", atof(argv[1]) / 2);
       else fprintf(stderr,  "Error: 1 argument expected.\n");
       return 0;
  }

and in Perl you collect this output for later use:

  $ perl -e 'print "C program returns ", `./jup 22`;'
  C program returns 11.000000

<snip>
-- 
Ben.

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

#109642 — Re: solved Re: obtaining a c value from a perl script

On 05/09/2017 07:06 AM, Ben Bacarisse wrote:
> fred flintstone <fred@server.invalid> writes:
>
>> On 05/08/2017 04:39 AM, Malcolm McLean wrote:
> <snip>
>>> When declaring a function that accepts a function pointer in C, it is good
>>> practice to always add a void * as a parameter, and accept a void * to pass
>>> back.
> <snip>
>> Thanks for your elaboration, malcolm, it prompted the literal solution
>> of this thread.
>
> You may have misunderstood.  Your code has no functions that meet the
> criteria in Malcolm's remark: "a function that accepts a function
> pointer".
>
> <snip>
>> This program was called with "./jup".
>> Value from perl : 2457987.259259
>> Can't use an undefined value as a SCALAR reference at 3.neptune.pl line 102.
>> $
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> int main (int argc, char *argv[])
>> {
>>   double d;
>>   printf ("This program was called with \"%s\".\n",argv[0]);
>>   if (argc == 2)
>>     {
>>        d = atof(argv[1]);
>>        printf("Value from perl : %f\n", d );
>>        char array[20] = "Hello from C";
>>        return ( array );
>
> You compiler should have told you that this was, at best, dodgy.  main
> is an int valued function and 'array' is not an int.
>
> Just as you are choosing to pass the number to your program as a string,
> you need to get the results back as a string.  To do that you *print*
> the result:
>
>   #include <stdio.h>
>   #include <stdlib.h>
>
>   int main (int argc, char *argv[])
>   {
>        if (argc == 2)
>             printf("%f\n", atof(argv[1]) / 2);
>        else fprintf(stderr,  "Error: 1 argument expected.\n");
>        return 0;
>   }
>
> and in Perl you collect this output for later use:
>
>   $ perl -e 'print "C program returns ", `./jup 22`;'
>   C program returns 11.000000
>
> <snip>
>

Thanks, ben,

[driver]
echo 'after compilation avec warnings, output is'
gcc -Wall -Wextra -o banana 3.receive.c


$ ./banana
Error: 1 argument expected.
$ ./banana 34.55666666
34.556667
$ cat 3.receive.c
#include <stdio.h>
#include <stdlib.h>

int
main (int argc, char *argv[])
{
   if (argc == 2)
     printf ("%f\n", atof (argv[1]) / 1.0);
   else
     fprintf (stderr, "Error: 1 argument expected.\n");
   return 0;
}
$

I'm curious whether a C compiler can decide better not to do the 
division at all....
-- 
fred

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

#109648 — Re: solved Re: obtaining a c value from a perl script

fred flintstone <fred@server.invalid> writes:
<snip>
> $ cat 3.receive.c
> #include <stdio.h>
> #include <stdlib.h>
>
> int
> main (int argc, char *argv[])
> {
>   if (argc == 2)
>     printf ("%f\n", atof (argv[1]) / 1.0);
>   else
>     fprintf (stderr, "Error: 1 argument expected.\n");
>   return 0;
> }
> $
>
> I'm curious whether a C compiler can decide better not to do the
> division at all....

Why did you do it?

-- 
Ben.

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

#109815 — Re: solved Re: obtaining a c value from a perl script

On 05/10/2017 03:18 AM, Ben Bacarisse wrote:

[OP feels better
>> I'm curious whether a C compiler can decide better not to do the
>> division at all....
>
> Why did you do it?
>

Self-interest, god-consciousness, and recon?

I'll show you what I'll do with it, if I can align this text. An 
asbestos suit works fine for clc, but I do not want to bring mis-aligned 
log-data any farther than I have to.

[I might get back on topic here, give me a little rope.]

My ostensible problem is that the output I am to reveal is actually from 
a child syntax of C, perl, and therefore untopical in 
clc...bla...bla...ginger...

Script executed at Fri May 12 01:09:56 2017
1 Moon 10h 14m 25s +11° 36.6' 59.0 ER 44.751 53.800 Up
1 Sun 10h 4m 42s +11° 48.2' 1.012 43.495 56.633 Up
2 Moon 10h 3m 2s +12° 22.4' 58.9 ER 45.588 −54.005 Up
2 Sun 10h 3m 56s +11° 52.4' 1.012 45.053 −53.845 Up
3 Moon 10h 7m 36s +12° 4.2' 58.9 ER 56.545 −12.324 Up
3 Sun 10h 4m 14s +11° 50.7' 1.012 56.441 −10.790 Up
4 Moon 10h 4m 54s +12° 15.0' 58.9 ER 51.475 −39.262 Up
4 Sun 10h 4m 4s +11° 51.7' 1.012 51.222 −38.686 Up
5 Moon 10h 3m 54s +12° 19.0' 58.9 ER 48.527 −47.478 Up
5 Sun 10h 4m 0s +11° 52.1' 1.012 48.135 −47.147 Up
6 Moon 10h 4m 22s +12° 17.2' 58.9 ER 49.927 −43.846 Up
6 Sun 10h 4m 2s +11° 51.9' 1.012 49.602 −43.411 Up
7 Moon 10h 4m 9s +12° 18.0' 58.9 ER 49.291 −45.547 Up
7 Sun 10h 4m 1s +11° 52.0' 1.012 48.936 −45.162 Up
8 Moon 10h 4m 1s +12° 18.5' 58.9 ER 48.883 −46.592 Up
8 Sun 10h 4m 0s +11° 52.0' 1.012 48.509 −46.236 Up
9 Moon 10h 3m 58s +12° 18.7' 58.9 ER 48.694 −47.064 Up
9 Sun 10h 4m 0s +11° 52.0' 1.012 48.311 −46.721 Up
10 Moon 10h 3m 59s +12° 18.6' 58.9 ER 48.780 −46.852 Up
10 Sun 10h 4m 0s +11° 52.0' 1.012 48.401 −46.503 Up
equal, while condition fails at julian second 2457987.25933652
11 Moon 10h 4m 0s +12° 18.6' 58.9 ER 48.826 −46.735 Up
11 Sun 10h 4m 0s +11° 52.0' 1.012 48.450 −46.383 Up
equal seconds is 2457987.25933652

This is preliminary data. If ER exists on a row, there must be a 
conversion to convert the previous value into AU (astronomical units). 
It will be a positive fraction, turning that 58.9 into somewhere near .05.

So the ER's will disappear by means of perl. Otherwise, it needs to line 
up. I can readily discuss limits so as to establish fields.

This will become typical line:

11 Sun 10h 4m 0s +11° 52.0' 1.012 48.450 −46.383 Up

Is the printf specifier that is gonna make this align the same in C and 
Perl? Latest, cleanest perl caller here:

https://github.com/TBlazer66/ephemeris/blob/master/3.triton.pl
-- 
fred

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

#109824 — Re: solved Re: obtaining a c value from a perl script

fred flintstone <fred@server.invalid> writes:

> On 05/10/2017 03:18 AM, Ben Bacarisse wrote:
>
> [OP feels better
>>> I'm curious whether a C compiler can decide better not to do the
>>> division at all....
>>
>> Why did you do it?
>>
>
> Self-interest, god-consciousness, and recon?
>
> I'll show you what I'll do with it, if I can align this text. An
> asbestos suit works fine for clc, but I do not want to bring
> mis-aligned log-data any farther than I have to.

Sorry.  Maybe I was not clear.  You divided a number by 1 and then asked
if the compiler could avoid the division.  I just asked why you divided
by 1 in the first place.

<snip>
-- 
Ben.

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

#109823 — Re: solved Re: obtaining a c value from a perl script

On 05/10/2017 02:57 AM, Stefan Ram wrote:
> fred flintstone <fred@server.invalid> writes:
>> #include <stdio.h>
>> #include <stdlib.h>
>>https://github.com/TBlazer66/ephemeris/blob/master/3.triton.pl
>> int
>> main (int argc, char *argv[])
>> {
>>   if (argc == 2)
>>     printf ("%f\n", atof (argv[1]) / 1.0);
>>   else
>>     fprintf (stderr, "Error: 1 argument expected.\n");
>>   return 0;
>> }
>> $
>> I'm curious whether a C compiler can decide better not to do the
>> division at all....
>
>   I don't know the reason for the division by 1.0, but at
>   least here, the compiler does not generate a DIV instruction
>   between »call atof« and »call printf«.
>

[da ich es kann]

Ich danke um die Replik. Mathematicians multiply and divide by one, 
whilst considering the consequences of dropping the myach.

Bin getroffen mit photos von Kpacneu Krishu.

Nicht vergessen wie Amis euch gegen Pavlov vertiedigen.
-- 
fritz

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

#109716 — Re: solved Re: obtaining a c value from a perl script

On 05/09/2017 04:06 PM, Ben Bacarisse wrote:
> fred flintstone <fred@server.invalid> writes:
> 
> <snip>
>> This program was called with "./jup".
>> Value from perl : 2457987.259259
>> Can't use an undefined value as a SCALAR reference at 3.neptune.pl line 102.
>> $
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> int main (int argc, char *argv[])
>> {
>>    double d;
>>    printf ("This program was called with \"%s\".\n",argv[0]);
>>    if (argc == 2)
>>      {
>>         d = atof(argv[1]);
>>         printf("Value from perl : %f\n", d );
>>         char array[20] = "Hello from C";
>>         return ( array );
> 
> You compiler should have told you that this was, at best, dodgy.  main
> is an int valued function and 'array' is not an int.
> 
> Just as you are choosing to pass the number to your program as a string,
> you need to get the results back as a string.  To do that you *print*
> the result:
> 
>    #include <stdio.h>
>    #include <stdlib.h>
> 
>    int main (int argc, char *argv[])
>    {
>         if (argc == 2)
>              printf("%f\n", atof(argv[1]) / 2);
>         else fprintf(stderr,  "Error: 1 argument expected.\n");
>         return 0;
>    }
> 
> and in Perl you collect this output for later use:
> 
>    $ perl -e 'print "C program returns ", `./jup 22`;'
>    C program returns 11.000000
> 
> <snip>
> 

It may be worth noting (if not, please forgive my redundancy) that there 
are in fact two outputs from the C program here:
1) the return value from main() - this (int) value is returned to the OS 
as exit status of the process. Being constrained as an int value (a 
single machine word in most (all?) architectures) its use is often 
limited to little more than a success/failure code.

2) the output stream (stdout, implicitly used by printf) - this is 
redirected by the calling process (the Perl interpreter in this case) 
into some receiver/container (the script context in this case, thanks to 
the syntax that Ben gave you: `./jup 22`). Being a stream, this can 
accommodate for (virtually) any kind of data. Here a stream of chars 
containing a textual representation of the double value atof(argv[1]) / 2.

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

#109723 — Re: solved Re: obtaining a c value from a perl script

Manfred <invalid@invalid.add> writes:
[...]
> It may be worth noting (if not, please forgive my redundancy) that there 
> are in fact two outputs from the C program here:
> 1) the return value from main() - this (int) value is returned to the OS 
> as exit status of the process. Being constrained as an int value (a 
> single machine word in most (all?) architectures) its use is often 
> limited to little more than a success/failure code.

In fact it's typically more limited than that.  On POSIX systems, for
example, only the low-order 8 bits of the result are passed to the
environment.

The C standard only specifies 0, EXIT_SUCCESS, and EXIT_FAILURE as
meaningful values.  0 and EXIT_SUCCESS both denote success; typically
EXIT_SUCCESS==0, but that's not guaranteed.  It's not entirely
clear that a conforming implementation is required to distinguish
between success and failure, but since this applies only to hosted
implementations I'd be surprised if there were any that don't.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#109783 — Re: solved Re: obtaining a c value from a perl script

On Wed, 10 May 2017 16:23:00 -0700, Keith Thompson <kst-u@mib.org>
wrote:

>Manfred <invalid@invalid.add> writes:
>[...]
>> It may be worth noting (if not, please forgive my redundancy) that there 
>> are in fact two outputs from the C program here:
>> 1) the return value from main() - this (int) value is returned to the OS 
>> as exit status of the process. Being constrained as an int value (a 
>> single machine word in most (all?) architectures) its use is often 
>> limited to little more than a success/failure code.
>
>In fact it's typically more limited than that.  On POSIX systems, for
>example, only the low-order 8 bits of the result are passed to the
>environment.
>
>The C standard only specifies 0, EXIT_SUCCESS, and EXIT_FAILURE as
>meaningful values.  0 and EXIT_SUCCESS both denote success; typically
>EXIT_SUCCESS==0, but that's not guaranteed.  It's not entirely
>clear that a conforming implementation is required to distinguish
>between success and failure, but since this applies only to hosted
>implementations I'd be surprised if there were any that don't.


While I don't know if a "proper" C for IBM's mainframe operating
system VSE (nee DOS)  existed at the time, but the OS's ability to
accept return codes didn't exist until one of the late VSE/SP versions
(I think - it could have been an early VSE/ESA), in the late 1980s.
But there was at least one partial C port to VSE at the time, and it
would have been unable to return a result code to the OS (as would any
other program).

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

#109791 — Re: solved Re: obtaining a c value from a perl script

On 5/11/2017 4:57 PM, Robert Wessel wrote:
> On Wed, 10 May 2017 16:23:00 -0700, Keith Thompson <kst-u@mib.org>
> wrote:
> 
>> Manfred <invalid@invalid.add> writes:
>> [...]
>>> It may be worth noting (if not, please forgive my redundancy) that there 
>>> are in fact two outputs from the C program here:
>>> 1) the return value from main() - this (int) value is returned to the OS 
>>> as exit status of the process. Being constrained as an int value (a 
>>> single machine word in most (all?) architectures) its use is often 
>>> limited to little more than a success/failure code.
>>
>> In fact it's typically more limited than that.  On POSIX systems, for
>> example, only the low-order 8 bits of the result are passed to the
>> environment.
>>
>> The C standard only specifies 0, EXIT_SUCCESS, and EXIT_FAILURE as
>> meaningful values.  0 and EXIT_SUCCESS both denote success; typically
>> EXIT_SUCCESS==0, but that's not guaranteed.  It's not entirely
>> clear that a conforming implementation is required to distinguish
>> between success and failure, but since this applies only to hosted
>> implementations I'd be surprised if there were any that don't.
> 
> 
> While I don't know if a "proper" C for IBM's mainframe operating
> system VSE (nee DOS)  existed at the time, but the OS's ability to
> accept return codes didn't exist until one of the late VSE/SP versions
> (I think - it could have been an early VSE/ESA), in the late 1980s.
> But there was at least one partial C port to VSE at the time, and it
> would have been unable to return a result code to the OS (as would any
> other program).
> 

Actually, both DOS and MVS were able to accept return codes, and could
even in the 70's.  For instance, compilers regularly returned 0, 4, 8
for OK, Warnings and Errors.  Some even returned 12 for severe errors.

Other programs regularly returned values which could be checked in JCL,

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#109793 — Re: solved Re: obtaining a c value from a perl script

On Thu, 11 May 2017 18:57:50 -0400, Jerry Stuckle
<jstucklex@attglobal.net> wrote:

>On 5/11/2017 4:57 PM, Robert Wessel wrote:
>> On Wed, 10 May 2017 16:23:00 -0700, Keith Thompson <kst-u@mib.org>
>> wrote:
>> 
>>> Manfred <invalid@invalid.add> writes:
>>> [...]
>>>> It may be worth noting (if not, please forgive my redundancy) that there 
>>>> are in fact two outputs from the C program here:
>>>> 1) the return value from main() - this (int) value is returned to the OS 
>>>> as exit status of the process. Being constrained as an int value (a 
>>>> single machine word in most (all?) architectures) its use is often 
>>>> limited to little more than a success/failure code.
>>>
>>> In fact it's typically more limited than that.  On POSIX systems, for
>>> example, only the low-order 8 bits of the result are passed to the
>>> environment.
>>>
>>> The C standard only specifies 0, EXIT_SUCCESS, and EXIT_FAILURE as
>>> meaningful values.  0 and EXIT_SUCCESS both denote success; typically
>>> EXIT_SUCCESS==0, but that's not guaranteed.  It's not entirely
>>> clear that a conforming implementation is required to distinguish
>>> between success and failure, but since this applies only to hosted
>>> implementations I'd be surprised if there were any that don't.
>> 
>> 
>> While I don't know if a "proper" C for IBM's mainframe operating
>> system VSE (nee DOS)  existed at the time, but the OS's ability to
>> accept return codes didn't exist until one of the late VSE/SP versions
>> (I think - it could have been an early VSE/ESA), in the late 1980s.
>> But there was at least one partial C port to VSE at the time, and it
>> would have been unable to return a result code to the OS (as would any
>> other program).
>> 
>
>Actually, both DOS and MVS were able to accept return codes, and could
>even in the 70's.  For instance, compilers regularly returned 0, 4, 8
>for OK, Warnings and Errors.  Some even returned 12 for severe errors.
>
>Other programs regularly returned values which could be checked in JCL,


While MVS has supported return codes from applications forever (since
the first OS/360 days), it was not something VSE (DOS) did until
around 1985 (my memory of the release dates was a bit off*).  Here's
the text of the General Information publication for VSE/SP 2.1.0:

https://archive.org/stream/bitsavers_ibm370DOSVnformationVSESystemPackageJun84_3578200/GC33-6176-0_General_Information_VSE_System_Package_Jun84_djvu.txt

There are a number of reference to the new support for "conditional
Job Control Language".

Macros, system services and subprograms had the ability to pass back
return codes to their callers before then, but there was no way to do
so to the OS.  So no conditional JCL, etc.


*I suspect that the partial C compiler I saw was in a shop that was
running a bit back level on VSE.

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

#109794 — Re: solved Re: obtaining a c value from a perl script

On Thu, 11 May 2017 18:38:49 -0500, Robert Wessel
<robertwessel2@yahoo.com> wrote:

>On Thu, 11 May 2017 18:57:50 -0400, Jerry Stuckle
><jstucklex@attglobal.net> wrote:
>
>>On 5/11/2017 4:57 PM, Robert Wessel wrote:
>>> On Wed, 10 May 2017 16:23:00 -0700, Keith Thompson <kst-u@mib.org>
>>> wrote:
>>> 
>>>> Manfred <invalid@invalid.add> writes:
>>>> [...]
>>>>> It may be worth noting (if not, please forgive my redundancy) that there 
>>>>> are in fact two outputs from the C program here:
>>>>> 1) the return value from main() - this (int) value is returned to the OS 
>>>>> as exit status of the process. Being constrained as an int value (a 
>>>>> single machine word in most (all?) architectures) its use is often 
>>>>> limited to little more than a success/failure code.
>>>>
>>>> In fact it's typically more limited than that.  On POSIX systems, for
>>>> example, only the low-order 8 bits of the result are passed to the
>>>> environment.
>>>>
>>>> The C standard only specifies 0, EXIT_SUCCESS, and EXIT_FAILURE as
>>>> meaningful values.  0 and EXIT_SUCCESS both denote success; typically
>>>> EXIT_SUCCESS==0, but that's not guaranteed.  It's not entirely
>>>> clear that a conforming implementation is required to distinguish
>>>> between success and failure, but since this applies only to hosted
>>>> implementations I'd be surprised if there were any that don't.
>>> 
>>> 
>>> While I don't know if a "proper" C for IBM's mainframe operating
>>> system VSE (nee DOS)  existed at the time, but the OS's ability to
>>> accept return codes didn't exist until one of the late VSE/SP versions
>>> (I think - it could have been an early VSE/ESA), in the late 1980s.
>>> But there was at least one partial C port to VSE at the time, and it
>>> would have been unable to return a result code to the OS (as would any
>>> other program).
>>> 
>>
>>Actually, both DOS and MVS were able to accept return codes, and could
>>even in the 70's.  For instance, compilers regularly returned 0, 4, 8
>>for OK, Warnings and Errors.  Some even returned 12 for severe errors.
>>
>>Other programs regularly returned values which could be checked in JCL,
>
>
>While MVS has supported return codes from applications forever (since
>the first OS/360 days), it was not something VSE (DOS) did until
>around 1985 (my memory of the release dates was a bit off*).  Here's
>the text of the General Information publication for VSE/SP 2.1.0:
>
>https://archive.org/stream/bitsavers_ibm370DOSVnformationVSESystemPackageJun84_3578200/GC33-6176-0_General_Information_VSE_System_Package_Jun84_djvu.txt
>
>There are a number of reference to the new support for "conditional
>Job Control Language".
>
>Macros, system services and subprograms had the ability to pass back
>return codes to their callers before then, but there was no way to do
>so to the OS.  So no conditional JCL, etc.
>
>
>*I suspect that the partial C compiler I saw was in a shop that was
>running a bit back level on VSE.


And let me add that plenty of programs *printed* a "return code" on
completion (compilers*, IDCAMS, etc.) that reflected how they ended
processing, it was not something that was returned to the OS (so
theoretically you could have parsed the printed output and picked up
the RC there).


*If the Cobol compiler generated nothing higher than a C level
diagnostic, it would print a return code of "8", if it generated an E
level, you'd see a "12".

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

#109799 — Re: solved Re: obtaining a c value from a perl script

On 5/11/2017 7:38 PM, Robert Wessel wrote:
> On Thu, 11 May 2017 18:57:50 -0400, Jerry Stuckle
> <jstucklex@attglobal.net> wrote:
> 
>> On 5/11/2017 4:57 PM, Robert Wessel wrote:
>>> On Wed, 10 May 2017 16:23:00 -0700, Keith Thompson <kst-u@mib.org>
>>> wrote:
>>>
>>>> Manfred <invalid@invalid.add> writes:
>>>> [...]
>>>>> It may be worth noting (if not, please forgive my redundancy) that there 
>>>>> are in fact two outputs from the C program here:
>>>>> 1) the return value from main() - this (int) value is returned to the OS 
>>>>> as exit status of the process. Being constrained as an int value (a 
>>>>> single machine word in most (all?) architectures) its use is often 
>>>>> limited to little more than a success/failure code.
>>>>
>>>> In fact it's typically more limited than that.  On POSIX systems, for
>>>> example, only the low-order 8 bits of the result are passed to the
>>>> environment.
>>>>
>>>> The C standard only specifies 0, EXIT_SUCCESS, and EXIT_FAILURE as
>>>> meaningful values.  0 and EXIT_SUCCESS both denote success; typically
>>>> EXIT_SUCCESS==0, but that's not guaranteed.  It's not entirely
>>>> clear that a conforming implementation is required to distinguish
>>>> between success and failure, but since this applies only to hosted
>>>> implementations I'd be surprised if there were any that don't.
>>>
>>>
>>> While I don't know if a "proper" C for IBM's mainframe operating
>>> system VSE (nee DOS)  existed at the time, but the OS's ability to
>>> accept return codes didn't exist until one of the late VSE/SP versions
>>> (I think - it could have been an early VSE/ESA), in the late 1980s.
>>> But there was at least one partial C port to VSE at the time, and it
>>> would have been unable to return a result code to the OS (as would any
>>> other program).
>>>
>>
>> Actually, both DOS and MVS were able to accept return codes, and could
>> even in the 70's.  For instance, compilers regularly returned 0, 4, 8
>> for OK, Warnings and Errors.  Some even returned 12 for severe errors.
>>
>> Other programs regularly returned values which could be checked in JCL,
> 
> 
> While MVS has supported return codes from applications forever (since
> the first OS/360 days), it was not something VSE (DOS) did until
> around 1985 (my memory of the release dates was a bit off*).  Here's
> the text of the General Information publication for VSE/SP 2.1.0:
> 
> https://archive.org/stream/bitsavers_ibm370DOSVnformationVSESystemPackageJun84_3578200/GC33-6176-0_General_Information_VSE_System_Package_Jun84_djvu.txt
> 
> There are a number of reference to the new support for "conditional
> Job Control Language".
> 
> Macros, system services and subprograms had the ability to pass back
> return codes to their callers before then, but there was no way to do
> so to the OS.  So no conditional JCL, etc.
> 
> 
> *I suspect that the partial C compiler I saw was in a shop that was
> running a bit back level on VSE.
> 

That's very interesting, considering I was a programmer at IBM in 1982
and we used return codes.  No, there was no conditional job control
language, because DOS didn't really have any JCL - at least not any
intelligent JCL.  But it still allowed return codes.

Those return codes could be checked by driver programs which executed
other programs.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#109800 — Re: solved Re: obtaining a c value from a perl script

On Thu, 11 May 2017 21:11:52 -0400, Jerry Stuckle
<jstucklex@attglobal.net> wrote:

>On 5/11/2017 7:38 PM, Robert Wessel wrote:
>> On Thu, 11 May 2017 18:57:50 -0400, Jerry Stuckle
>> <jstucklex@attglobal.net> wrote:
>> 
>>> On 5/11/2017 4:57 PM, Robert Wessel wrote:
>>>> On Wed, 10 May 2017 16:23:00 -0700, Keith Thompson <kst-u@mib.org>
>>>> wrote:
>>>>
>>>>> Manfred <invalid@invalid.add> writes:
>>>>> [...]
>>>>>> It may be worth noting (if not, please forgive my redundancy) that there 
>>>>>> are in fact two outputs from the C program here:
>>>>>> 1) the return value from main() - this (int) value is returned to the OS 
>>>>>> as exit status of the process. Being constrained as an int value (a 
>>>>>> single machine word in most (all?) architectures) its use is often 
>>>>>> limited to little more than a success/failure code.
>>>>>
>>>>> In fact it's typically more limited than that.  On POSIX systems, for
>>>>> example, only the low-order 8 bits of the result are passed to the
>>>>> environment.
>>>>>
>>>>> The C standard only specifies 0, EXIT_SUCCESS, and EXIT_FAILURE as
>>>>> meaningful values.  0 and EXIT_SUCCESS both denote success; typically
>>>>> EXIT_SUCCESS==0, but that's not guaranteed.  It's not entirely
>>>>> clear that a conforming implementation is required to distinguish
>>>>> between success and failure, but since this applies only to hosted
>>>>> implementations I'd be surprised if there were any that don't.
>>>>
>>>>
>>>> While I don't know if a "proper" C for IBM's mainframe operating
>>>> system VSE (nee DOS)  existed at the time, but the OS's ability to
>>>> accept return codes didn't exist until one of the late VSE/SP versions
>>>> (I think - it could have been an early VSE/ESA), in the late 1980s.
>>>> But there was at least one partial C port to VSE at the time, and it
>>>> would have been unable to return a result code to the OS (as would any
>>>> other program).
>>>>
>>>
>>> Actually, both DOS and MVS were able to accept return codes, and could
>>> even in the 70's.  For instance, compilers regularly returned 0, 4, 8
>>> for OK, Warnings and Errors.  Some even returned 12 for severe errors.
>>>
>>> Other programs regularly returned values which could be checked in JCL,
>> 
>> 
>> While MVS has supported return codes from applications forever (since
>> the first OS/360 days), it was not something VSE (DOS) did until
>> around 1985 (my memory of the release dates was a bit off*).  Here's
>> the text of the General Information publication for VSE/SP 2.1.0:
>> 
>> https://archive.org/stream/bitsavers_ibm370DOSVnformationVSESystemPackageJun84_3578200/GC33-6176-0_General_Information_VSE_System_Package_Jun84_djvu.txt
>> 
>> There are a number of reference to the new support for "conditional
>> Job Control Language".
>> 
>> Macros, system services and subprograms had the ability to pass back
>> return codes to their callers before then, but there was no way to do
>> so to the OS.  So no conditional JCL, etc.
>> 
>> 
>> *I suspect that the partial C compiler I saw was in a shop that was
>> running a bit back level on VSE.
>> 
>
>That's very interesting, considering I was a programmer at IBM in 1982
>and we used return codes.  No, there was no conditional job control
>language, because DOS didn't really have any JCL - at least not any
>intelligent JCL.  But it still allowed return codes.
>
>Those return codes could be checked by driver programs which executed
>other programs.


Hence my inclusion of subprograms.

OTOH, that didn't work, at least without a nucleus modification, for
programs in general.  Even now the documented way to exit a program (I
just checked the current z/VSE Macro User's Guide) is to use the EOJ
macro.  That will bypass any driver program and return directly to the
OS.  And *many*, probably most, programs are coded like that.  For
example, all Cobol programs that end with a STOP RUN (as opposed to a
GOBACK).  Heck, in that era you could get *CICS* to stop on a dime if
your Cobol program accidentally fell through to a STOP RUN.

Even if your program return via a BR 14 and set R15, under normal
circumstances the OS would not actually save that anywhere, so no
subsequent step could check it.

Now if you have a driver program, and you LOAD (or CDLOAD, not sure I
remember the timing on CDLOAD), and *not* FETCH (which didn't save the
RC), the target program, and then set up the R1 parameter list and
call the loaded program, and then the loaded program exits via the
normal calling convention (as opposed to EOJ), and sets a return code
in R15, you could capture the value, and then presumably do something
with it.  If the program loaded ended with an EOJ, the driver program
would never get control back (except with a nucleus modification).

Other approaches were possible as well - store a return value in the
user part of COMRG or in the JOBCOM area, which would allow subsequent
steps to access the value.  But that had to be coded explicitly in any
program.

But all approaches required something outside the standard OS, special
actions by the individual programs, and could not support all programs
without a nucleus modification.

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

#109995 — Re: solved Re: obtaining a c value from a perl script

On 5/12/2017 2:51 AM, Robert Wessel wrote:
> On Thu, 11 May 2017 21:11:52 -0400, Jerry Stuckle
> <jstucklex@attglobal.net> wrote:
> 
>> On 5/11/2017 7:38 PM, Robert Wessel wrote:
>>> On Thu, 11 May 2017 18:57:50 -0400, Jerry Stuckle
>>> <jstucklex@attglobal.net> wrote:
>>>
>>>> On 5/11/2017 4:57 PM, Robert Wessel wrote:
>>>>> On Wed, 10 May 2017 16:23:00 -0700, Keith Thompson <kst-u@mib.org>
>>>>> wrote:
>>>>>
>>>>>> Manfred <invalid@invalid.add> writes:
>>>>>> [...]
>>>>>>> It may be worth noting (if not, please forgive my redundancy) that there 
>>>>>>> are in fact two outputs from the C program here:
>>>>>>> 1) the return value from main() - this (int) value is returned to the OS 
>>>>>>> as exit status of the process. Being constrained as an int value (a 
>>>>>>> single machine word in most (all?) architectures) its use is often 
>>>>>>> limited to little more than a success/failure code.
>>>>>>
>>>>>> In fact it's typically more limited than that.  On POSIX systems, for
>>>>>> example, only the low-order 8 bits of the result are passed to the
>>>>>> environment.
>>>>>>
>>>>>> The C standard only specifies 0, EXIT_SUCCESS, and EXIT_FAILURE as
>>>>>> meaningful values.  0 and EXIT_SUCCESS both denote success; typically
>>>>>> EXIT_SUCCESS==0, but that's not guaranteed.  It's not entirely
>>>>>> clear that a conforming implementation is required to distinguish
>>>>>> between success and failure, but since this applies only to hosted
>>>>>> implementations I'd be surprised if there were any that don't.
>>>>>
>>>>>
>>>>> While I don't know if a "proper" C for IBM's mainframe operating
>>>>> system VSE (nee DOS)  existed at the time, but the OS's ability to
>>>>> accept return codes didn't exist until one of the late VSE/SP versions
>>>>> (I think - it could have been an early VSE/ESA), in the late 1980s.
>>>>> But there was at least one partial C port to VSE at the time, and it
>>>>> would have been unable to return a result code to the OS (as would any
>>>>> other program).
>>>>>
>>>>
>>>> Actually, both DOS and MVS were able to accept return codes, and could
>>>> even in the 70's.  For instance, compilers regularly returned 0, 4, 8
>>>> for OK, Warnings and Errors.  Some even returned 12 for severe errors.
>>>>
>>>> Other programs regularly returned values which could be checked in JCL,
>>>
>>>
>>> While MVS has supported return codes from applications forever (since
>>> the first OS/360 days), it was not something VSE (DOS) did until
>>> around 1985 (my memory of the release dates was a bit off*).  Here's
>>> the text of the General Information publication for VSE/SP 2.1.0:
>>>
>>> https://archive.org/stream/bitsavers_ibm370DOSVnformationVSESystemPackageJun84_3578200/GC33-6176-0_General_Information_VSE_System_Package_Jun84_djvu.txt
>>>
>>> There are a number of reference to the new support for "conditional
>>> Job Control Language".
>>>
>>> Macros, system services and subprograms had the ability to pass back
>>> return codes to their callers before then, but there was no way to do
>>> so to the OS.  So no conditional JCL, etc.
>>>
>>>
>>> *I suspect that the partial C compiler I saw was in a shop that was
>>> running a bit back level on VSE.
>>>
>>
>> That's very interesting, considering I was a programmer at IBM in 1982
>> and we used return codes.  No, there was no conditional job control
>> language, because DOS didn't really have any JCL - at least not any
>> intelligent JCL.  But it still allowed return codes.
>>
>> Those return codes could be checked by driver programs which executed
>> other programs.
> 
> 
> Hence my inclusion of subprograms.
> 
> OTOH, that didn't work, at least without a nucleus modification, for
> programs in general.  Even now the documented way to exit a program (I
> just checked the current z/VSE Macro User's Guide) is to use the EOJ
> macro.  That will bypass any driver program and return directly to the
> OS.  And *many*, probably most, programs are coded like that.  For
> example, all Cobol programs that end with a STOP RUN (as opposed to a
> GOBACK).  Heck, in that era you could get *CICS* to stop on a dime if
> your Cobol program accidentally fell through to a STOP RUN.
>

Citation that "many" or "most" programs are coded like that?  And the
ability to get CICS to "stop on a dime" was fixed long ago - I should
know, having spent 5 years as a CICS Level 2 support specialist.

> Even if your program return via a BR 14 and set R15, under normal
> circumstances the OS would not actually save that anywhere, so no
> subsequent step could check it.
> 

Again, incorrect.  DOS would return the return code (Register 15, IIRC,
but it's been a while) to the calling program.

> Now if you have a driver program, and you LOAD (or CDLOAD, not sure I
> remember the timing on CDLOAD), and *not* FETCH (which didn't save the
> RC), the target program, and then set up the R1 parameter list and
> call the loaded program, and then the loaded program exits via the
> normal calling convention (as opposed to EOJ), and sets a return code
> in R15, you could capture the value, and then presumably do something
> with it.  If the program loaded ended with an EOJ, the driver program
> would never get control back (except with a nucleus modification).
> 

That is true.  And it is because DOS handled the return code and passed
it back to the calling program.

> Other approaches were possible as well - store a return value in the
> user part of COMRG or in the JOBCOM area, which would allow subsequent
> steps to access the value.  But that had to be coded explicitly in any
> program.
> 

It was not necessary.

> But all approaches required something outside the standard OS, special
> actions by the individual programs, and could not support all programs
> without a nucleus modification.
> 

Nope, DOS handled it quite well in its own.  The restriction here was
that the DOS JCL had no way of testing return codes - not that DOS
didn't handle them.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#109595

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Monday, May 8, 2017 at 10:45:31 AM UTC+1, fred flintstone wrote:
>> On 05/03/2017 09:02 AM, Malcolm McLean wrote:
>>>
>>> fred flintstone speaks English.
>>> I've also faced similar problems, and used similar words.  Ben was
>>> possibly misled because "capture" is a term used with a specific
>>> meaning for lambda functions and closures.
>>
>> I didn't mean this, but now that you brought it up, is there a standard
>> implementation of closures?
>
> When declaring a function that accepts a function pointer in C, it is
> good practice to always add a void * as a parameter, and accept a void *
> to pass back.  Usually this is called something like the "context"
> pointer.  If caller doesn't need it, it is simply null.  But it can point
> to a structure containing detailed information, and it means you don't
> need a global (which can be almost unworkable if you've got more than one
> instance of the function pointer live).
>
> The context pointer is effectively a closure, [...]

This statement is simply wrong.  The word closure is used to refer to
both elements:  a function to be called, and an environment or context
in which the called function will operate.  In C a closure could be an
instance of a struct type

    struct example_closure {
        struct example_closure_data *data;
        int (*function)( struct example_closure_data *, ... );
    };

    #define CALL_CLOSURE( c, ... ) ((c).function( (c).data, __VA_ARGS__ ))

There are details about the types of things that make closures
difficult to define in C, which often leads people to use (void *) as
a loophole.  But the key point is that the term "closure" refers to
both elements -- not just the function by itself, and not just the
context or environment by itself, but always both.

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

#109111

On Wednesday, 3 May 2017 16:55:28 UTC+1, Keith Thompson  wrote:
> Malcolm McLean <malcolm....@gmail.com> writes:

> > I means that the C program invokes the Perl interpreter on the Perl script,
> > and then reads the value of a Perl variable for manipulation as a C object.
> 
> Malcolm, how do you know what fred flintstone means?

Divine intervention, I can only presume. Fred's problem specification
pretty opaque, rather reminiscent of the legend that is Bill Cunningham.

I'd suggest fred flintstone reads <http://www.catb.org/esr/faqs/smart-
questions.html> and tries to learn from it, if he actually wishes to
benefit from participation here, or pretty much anywhere that involves
human dialogue.

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

#109118

In article <6cc8528e-b08d-40a0-ae4e-f132b343f9ed@googlegroups.com>,
 <mark.bluemel@gmail.com> wrote:
>On Wednesday, 3 May 2017 16:55:28 UTC+1, Keith Thompson  wrote:
>> Malcolm McLean <malcolm....@gmail.com> writes:
>
>> > I means that the C program invokes the Perl interpreter on the Perl
>> > script, and then reads the value of a Perl variable for manipulation
>> > as a C object.
>> 
>> Malcolm, how do you know what fred flintstone means?
>
>Divine intervention, I can only presume. Fred's problem specification
>pretty opaque, rather reminiscent of the legend that is Bill Cunningham.
>
>I'd suggest fred flintstone reads <http://www.catb.org/esr/faqs/smart-
>questions.html> and tries to learn from it, if he actually wishes to
>benefit from participation here, or pretty much anywhere that involves
>human dialogue.

It is a classic error to assume that because *you* don't understand
something, that *nobody* can or does understand it.

It is also a bit of gaslighting to post, yet again, that stupid catb URL.

-- 
If you think you have any objections to anything I've said above, please
navigate to this URL:
    http://www.xmission.com/~gazelle/Truth
This should clear up any misconceptions you may have.

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

#109474

On 05/03/2017 09:06 AM, mark.bluemel@gmail.com wrote:


> Divine intervention, I can only presume. Fred's problem specification
> pretty opaque, rather reminiscent of the legend that is Bill Cunningham.
>
> I'd suggest fred flintstone reads <http://www.catb.org/esr/faqs/smart-
> questions.html> and tries to learn from it, if he actually wishes to
> benefit from participation here, or pretty much anywhere that involves
> human dialogue.
>

plonk

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web