Discussion:
obtaining a c value from a perl script
(too old to reply)
fred flintstone
2017-04-30 11:36:04 UTC
Permalink
Hello ng,

I don my asbestos suit and eye-protecting glasses* to bring up a topic
with the gurus of c. I get a particular value from a perl script that I
would like to see captured by C. It's C right under the hood, so I know
it can be done. The relevant value is the ultimate value for julian day:

https://github.com/TBlazer66/ephemeris/blob/master/2.pluto.pl

It's a C_double float. (terminology yikes) I'd like simply to print out
this value in C.

One may assume that I am on the linux platform using gcc, but it is not
necessary.

Also, this is the third time I've posted this year. It hurts my feelings
to call me things like "chat bot" or "troll." If you were grossly
unsatisfied by reading my last 2 threads, please take this opportunity
to take a long walk off a short building....

Thank you for your comment,

--

fred

*that part is for real for these events...I'm pissed I left mine in abq....
Noob
2017-04-30 12:48:25 UTC
Permalink
Post by fred flintstone
Hello ng,
I don my asbestos suit and eye-protecting glasses* to bring up a topic
with the gurus of c. I get a particular value from a perl script that I
would like to see captured by C. It's C right under the hood, so I know
it can be done.
Do you mean you have a Perl script, and a program compiled
from C, and you want to pass information from one to the
other, through a pipe perhaps?

Are you saying your Perl interpreter is C under the hood?

It seems you would be better served in a Perl forum?
Are the comp.lang.perl.* NGs still active?

Regards.
fred flintstone
2017-05-01 09:25:26 UTC
Permalink
Post by Noob
Post by fred flintstone
Hello ng,
I don my asbestos suit and eye-protecting glasses* to bring up a topic
with the gurus of c. I get a particular value from a perl script that I
would like to see captured by C. It's C right under the hood, so I know
it can be done.
Do you mean you have a Perl script, and a program compiled
from C, and you want to pass information from one to the
other, through a pipe perhaps?
Pipes are nonstandard, as per keith.
Post by Noob
Are you saying your Perl interpreter is C under the hood?
Yes. Wall to Wall.
Post by Noob
It seems you would be better served in a Perl forum?
Are the comp.lang.perl.* NGs still active?
I'm pursuing the perl aspects of this there. If anyone can predict an
eclipse in C, I'd be curious to see what they have.
Post by Noob
Regards.
Likewise,
--
fred
Keith Thompson
2017-05-01 15:46:24 UTC
Permalink
[...]
Post by fred flintstone
Post by Noob
It seems you would be better served in a Perl forum?
Are the comp.lang.perl.* NGs still active?
I'm pursuing the perl aspects of this there. If anyone can predict an
eclipse in C, I'd be curious to see what they have.
C does not have features for interacting with Perl. Perl has features
for interacting with C. The people who know about those features hang
out in Perl forums. comp.lang.perl.misc is active -- in fact I see
you've posted there yourself.
--
Keith Thompson (The_Other_Keith) kst-***@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"
fred flintstone
2017-05-03 09:12:34 UTC
Permalink
Post by Keith Thompson
[...]
Post by fred flintstone
Post by Noob
It seems you would be better served in a Perl forum?
Are the comp.lang.perl.* NGs still active?
I'm pursuing the perl aspects of this there. If anyone can predict an
eclipse in C, I'd be curious to see what they have.
C does not have features for interacting with Perl. Perl has features
for interacting with C. The people who know about those features hang
out in Perl forums. comp.lang.perl.misc is active -- in fact I see
you've posted there yourself.
Yeah, that's the perl part. There's a C part, but I need to hold up
right here and ask for that starter killfile again. I can't read this
newsgroup at all on this partition.

I use thunderbird on mint. *That* is implementation talk, but we don't
like to resort to implementation-specific solutions around here until
our hand is pressed. It's important to me that I know that however i
"capture" the value that it be a standard C solution. I wouldn't darken
the door here but that that were my purpose.

Alright, let me air the laundry, tho. The perl folks have a skill set
that differs from the people who can understand the data they capture.
(There I use the word capture again.)

A sufficient means to capture is to use the iso c binding.

So I'm fishing for

a) that starter killfile again

and

b) a standard means to do a simple pass by value from perl output to c
input.

Do you agree that there are better solutions than taking the value in on
argv?
--
fred
Ben Bacarisse
2017-05-03 10:48:22 UTC
Permalink
fred flintstone <***@server.invalid> writes:
<snip>
Post by fred flintstone
A sufficient means to capture is to use the iso c binding.
I don't know what that is, but (from what follows) I suspect you mean
passing the value as text via argv.
Post by fred flintstone
So I'm fishing for
<snip>
Post by fred flintstone
b) a standard means to do a simple pass by value from perl output to c input.
Do you agree that there are better solutions than taking the value in
on argv?
What are you trying to do overall? Since passing the output of a Perl
program to either the input or the command-line arguments of a C program
is simple, easy to understand and easy to maintain, there would have to
be a very strong motivation to do anything else.

In what sense could anything more complicated be "better"? (That's not
a rhetorical question -- the answer would explain why you are still
looking for a better solution.)
--
Ben.
Ben Bacarisse
2017-04-30 15:16:35 UTC
Permalink
Post by fred flintstone
I don my asbestos suit and eye-protecting glasses* to bring up a topic
with the gurus of c. I get a particular value from a perl script that
I would like to see captured by C.
What do you mean by "captured by C"? The phrase makes me think you want
to somehow pass a value from your Perl program to a C function. Even if
I'm right about this, the details of what "somehow" means for your
situation still need to be described.
Post by fred flintstone
It's C right under the hood, so I
know it can be done. The relevant value is the ultimate value for
https://github.com/TBlazer66/ephemeris/blob/master/2.pluto.pl
It's a C_double float. (terminology yikes) I'd like simply to print
out this value in C.
Simply is probably the wrong word here. Printing floating point values
in C is indeed simple, but nothing you have posted suggests you have the
right floating point value in C.

<snip>
--
Ben.
fred flintstone
2017-05-01 11:18:26 UTC
Permalink
Post by Ben Bacarisse
Post by fred flintstone
I don my asbestos suit and eye-protecting glasses* to bring up a topic
with the gurus of c. I get a particular value from a perl script that
I would like to see captured by C.
What do you mean by "captured by C"? The phrase makes me think you want
to somehow pass a value from your Perl program to a C function. Even if
I'm right about this, the details of what "somehow" means for your
situation still need to be described.
Sure. end of typical output:

right ascension of moon 10h 3m 55s
right ascension of sun 10h 4m 0s
moon seconds is 36235
sun seconds is 36240
to server is 11 2457987.25953264 2457987.25774584 2457987.25848217
right ascension of moon 10h 3m 57s
right ascension of sun 10h 4m 0s
moon seconds is 36237
sun seconds is 36240
to server is 12 2457987.25953264 2457987.25848217 2457987.25897738
right ascension of moon 10h 3m 59s
right ascension of sun 10h 4m 0s
moon seconds is 36239
sun seconds is 36240
to server is 13 2457987.25953264 2457987.25897738 2457987.25921532
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.25921532
equal seconds is 36240
Post by Ben Bacarisse
Post by fred flintstone
It's C right under the hood, so I
know it can be done. The relevant value is the ultimate value for
https://github.com/TBlazer66/ephemeris/blob/master/2.pluto.pl
It's a C_double float. (terminology yikes) I'd like simply to print
out this value in C.
Simply is probably the wrong word here. Printing floating point values
in C is indeed simple, but nothing you have posted suggests you have the
right floating point value in C.
<snip>
Let's say I had a value in perl that I knew was a c double. It's a premise.

If the only output of this script were:

say "$equal";

, then I think there is a wide road for C interop.
--
fred
Ben Bacarisse
2017-05-01 12:41:20 UTC
Permalink
Post by fred flintstone
Post by Ben Bacarisse
Post by fred flintstone
I don my asbestos suit and eye-protecting glasses* to bring up a topic
with the gurus of c. I get a particular value from a perl script that
I would like to see captured by C.
What do you mean by "captured by C"? The phrase makes me think you want
to somehow pass a value from your Perl program to a C function. Even if
I'm right about this, the details of what "somehow" means for your
situation still need to be described.
right ascension of moon 10h 3m 55s
right ascension of sun 10h 4m 0s
moon seconds is 36235
sun seconds is 36240
to server is 11 2457987.25953264 2457987.25774584 2457987.25848217
right ascension of moon 10h 3m 57s
right ascension of sun 10h 4m 0s
moon seconds is 36237
sun seconds is 36240
to server is 12 2457987.25953264 2457987.25848217 2457987.25897738
right ascension of moon 10h 3m 59s
right ascension of sun 10h 4m 0s
moon seconds is 36239
sun seconds is 36240
to server is 13 2457987.25953264 2457987.25897738 2457987.25921532
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.25921532
equal seconds is 36240
I think you prefer to talk in metaphors but I can't help because I still
don't know what "captured by C" means. Showing me the output of the
script does not help with that.

Maybe if you explained what you are trying to do and in what way the
Perl script you currently have is not suitable.

<snip>
Post by fred flintstone
Let's say I had a value in perl that I knew was a c double. It's a premise.
say "$equal";
, then I think there is a wide road for C interop.
Yes, you can inter-operate between C and Perl in countless ways but I
don't have the time to describe them all.
--
Ben.
Malcolm McLean
2017-05-03 12:10:52 UTC
Permalink
Post by Ben Bacarisse
I think you prefer to talk in metaphors but I can't help because I still
don't know what "captured by C" means. Showing me the output of the
script does not help with that.
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.
Ben Bacarisse
2017-05-03 14:00:05 UTC
Permalink
Post by Malcolm McLean
Post by Ben Bacarisse
I think you prefer to talk in metaphors but I can't help because I still
don't know what "captured by C" means. Showing me the output of the
script does not help with that.
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.
Subsequent replies suggest otherwise. The default "capture" the OP is
thinking about seems to be executing the C program from Perl, passing
the value as a command-line argument. But since I did not understand
the original post, I may have not understood the subsequent posts.
--
Ben.
Keith Thompson
2017-05-03 15:55:19 UTC
Permalink
Post by Malcolm McLean
Post by Ben Bacarisse
I think you prefer to talk in metaphors but I can't help because I still
don't know what "captured by C" means. Showing me the output of the
script does not help with that.
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?
--
Keith Thompson (The_Other_Keith) kst-***@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"
Malcolm McLean
2017-05-03 16:02:42 UTC
Permalink
Post by Keith Thompson
Post by Malcolm McLean
Post by Ben Bacarisse
I think you prefer to talk in metaphors but I can't help because I still
don't know what "captured by C" means. Showing me the output of the
script does not help with that.
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?
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.
Ben Bacarisse
2017-05-03 16:22:56 UTC
Permalink
Post by Malcolm McLean
Post by Keith Thompson
Post by Malcolm McLean
Post by Ben Bacarisse
I think you prefer to talk in metaphors but I can't help because I still
don't know what "captured by C" means. Showing me the output of the
script does not help with that.
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?
fred flintstone speaks English.
I've also faced similar problems, and used similar words.
Why don't you help out with an answer then?
Post by Malcolm McLean
Ben was possibly misled because "capture" is a term used with a
specific meaning for lambda functions and closures.
No, it was clear the meaning had nothing to do with that. It's
obviously about somehow getting a Perl number into a C floating-point
object, but there are so many ways to go about that (and most are not
topical here) that is seemed daft to try to answer without knowing the
real goal.
--
Ben.
fred flintstone
2017-05-08 08:43:02 UTC
Permalink
Post by Ben Bacarisse
Post by Malcolm McLean
Post by Keith Thompson
Post by Malcolm McLean
Post by Ben Bacarisse
I think you prefer to talk in metaphors but I can't help because I still
don't know what "captured by C" means. Showing me the output of the
script does not help with that.
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?
fred flintstone speaks English.
I've also faced similar problems, and used similar words.
Why don't you help out with an answer then?
Post by Malcolm McLean
Ben was possibly misled because "capture" is a term used with a
specific meaning for lambda functions and closures.
No, it was clear the meaning had nothing to do with that. It's
obviously about somehow getting a Perl number into a C floating-point
object, but there are so many ways to go about that (and most are not
topical here) that is seemed daft to try to answer without knowing the
real goal.
Is there such a thing as C17? Does it implement a lambda calculus?
--
fred
Keith Thompson
2017-05-08 16:06:35 UTC
Permalink
fred flintstone <***@server.invalid> writes:
[...]
Post by fred flintstone
Is there such a thing as C17? Does it implement a lambda calculus?
No (and, by implication, no).
--
Keith Thompson (The_Other_Keith) kst-***@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"
fred flintstone
2017-05-09 07:35:16 UTC
Permalink
Post by Keith Thompson
[...]
Post by fred flintstone
Is there such a thing as C17? Does it implement a lambda calculus?
No (and, by implication, no).
What's the current standard?
--
fred
David Brown
2017-05-09 11:59:37 UTC
Permalink
Post by fred flintstone
Post by Keith Thompson
[...]
Post by fred flintstone
Is there such a thing as C17? Does it implement a lambda calculus?
No (and, by implication, no).
What's the current standard?
C11.

(C++ has C++17, and it has had lambda functions since C++11. No lambda
calculus - that's a different thing.)
fred flintstone
2017-05-08 09:45:22 UTC
Permalink
Post by Malcolm McLean
Post by Keith Thompson
Post by Malcolm McLean
Post by Ben Bacarisse
I think you prefer to talk in metaphors but I can't help because I still
don't know what "captured by C" means. Showing me the output of the
script does not help with that.
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?
How many times is Malcolm right in the middle of the scrum that moved
the topic forward and then it was decided that he had said nothing
relevant by the people who sound like pamphleteers to me?
Post by Malcolm McLean
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?
--
fred
Malcolm McLean
2017-05-08 11:39:43 UTC
Permalink
Post by fred flintstone
Post by Malcolm McLean
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.
fred flintstone
2017-05-09 09:43:41 UTC
Permalink
Post by Malcolm McLean
Post by fred flintstone
Post by Malcolm McLean
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 );
}
Ben Bacarisse
2017-05-09 14:06:29 UTC
Permalink
<snip>
Post by fred flintstone
Post by Malcolm McLean
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>
Post by fred flintstone
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>
Post by fred flintstone
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.
fred flintstone
2017-05-10 08:03:22 UTC
Permalink
Post by Ben Bacarisse
<snip>
Post by fred flintstone
Post by Malcolm McLean
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>
Post by fred flintstone
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>
Post by fred flintstone
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*
#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;
}
$ 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
Stefan Ram
2017-05-10 09:57:21 UTC
Permalink
Post by fred flintstone
#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....
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«.
fred flintstone
2017-05-12 10:49:49 UTC
Permalink
Post by Stefan Ram
Post by fred flintstone
#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
Ben Bacarisse
2017-05-10 10:18:23 UTC
Permalink
fred flintstone <***@server.invalid> writes:
<snip>
Post by fred flintstone
$ 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.
fred flintstone
2017-05-12 09:26:49 UTC
Permalink
On 05/10/2017 03:18 AM, Ben Bacarisse wrote:

[OP feels better
Post by Ben Bacarisse
Post by fred flintstone
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
Ben Bacarisse
2017-05-12 10:51:25 UTC
Permalink
Post by fred flintstone
[OP feels better
Post by Ben Bacarisse
Post by fred flintstone
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.
Manfred
2017-05-10 21:21:10 UTC
Permalink
Post by Ben Bacarisse
<snip>
Post by fred flintstone
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*
#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;
}
$ 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.
Keith Thompson
2017-05-10 23:23:00 UTC
Permalink
Manfred <***@invalid.add> writes:
[...]
Post by Manfred
It may be worth noting (if not, please forgive my redundancy) that there
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-***@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"
Robert Wessel
2017-05-11 20:57:02 UTC
Permalink
Post by Keith Thompson
[...]
Post by Manfred
It may be worth noting (if not, please forgive my redundancy) that there
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).
Jerry Stuckle
2017-05-11 22:57:50 UTC
Permalink
Post by Robert Wessel
Post by Keith Thompson
[...]
Post by Manfred
It may be worth noting (if not, please forgive my redundancy) that there
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
***@attglobal.net
==================
Robert Wessel
2017-05-11 23:38:49 UTC
Permalink
On Thu, 11 May 2017 18:57:50 -0400, Jerry Stuckle
Post by Jerry Stuckle
Post by Robert Wessel
Post by Keith Thompson
[...]
Post by Manfred
It may be worth noting (if not, please forgive my redundancy) that there
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.
Robert Wessel
2017-05-11 23:46:02 UTC
Permalink
On Thu, 11 May 2017 18:38:49 -0500, Robert Wessel
Post by Robert Wessel
On Thu, 11 May 2017 18:57:50 -0400, Jerry Stuckle
Post by Jerry Stuckle
Post by Robert Wessel
Post by Keith Thompson
[...]
Post by Manfred
It may be worth noting (if not, please forgive my redundancy) that there
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
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".
Jerry Stuckle
2017-05-12 01:11:52 UTC
Permalink
Post by Robert Wessel
On Thu, 11 May 2017 18:57:50 -0400, Jerry Stuckle
Post by Jerry Stuckle
Post by Robert Wessel
Post by Keith Thompson
[...]
Post by Manfred
It may be worth noting (if not, please forgive my redundancy) that there
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
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
***@attglobal.net
==================
Robert Wessel
2017-05-12 06:51:12 UTC
Permalink
On Thu, 11 May 2017 21:11:52 -0400, Jerry Stuckle
Post by Jerry Stuckle
Post by Robert Wessel
On Thu, 11 May 2017 18:57:50 -0400, Jerry Stuckle
Post by Jerry Stuckle
Post by Robert Wessel
Post by Keith Thompson
[...]
Post by Manfred
It may be worth noting (if not, please forgive my redundancy) that there
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
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.
Jerry Stuckle
2017-05-15 03:49:21 UTC
Permalink
Post by Robert Wessel
On Thu, 11 May 2017 21:11:52 -0400, Jerry Stuckle
Post by Jerry Stuckle
Post by Robert Wessel
On Thu, 11 May 2017 18:57:50 -0400, Jerry Stuckle
Post by Jerry Stuckle
Post by Robert Wessel
Post by Keith Thompson
[...]
Post by Manfred
It may be worth noting (if not, please forgive my redundancy) that there
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
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.
Post by Robert Wessel
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.
Post by Robert Wessel
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.
Post by Robert Wessel
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.
Post by Robert Wessel
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
***@attglobal.net
==================
Tim Rentsch
2017-05-09 14:46:37 UTC
Permalink
Post by Malcolm McLean
Post by fred flintstone
Post by Malcolm McLean
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.
m***@gmail.com
2017-05-03 16:06:48 UTC
Permalink
Post by Keith Thompson
Post by Malcolm McLean
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.
Kenny McCormack
2017-05-03 17:02:08 UTC
Permalink
Post by m***@gmail.com
Post by Keith Thompson
Post by Malcolm McLean
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.
fred flintstone
2017-05-08 08:51:35 UTC
Permalink
Post by m***@gmail.com
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
Manfred
2017-05-04 16:21:23 UTC
Permalink
Post by fred flintstone
Post by Ben Bacarisse
Post by fred flintstone
I don my asbestos suit and eye-protecting glasses* to bring up a topic
with the gurus of c. I get a particular value from a perl script that
I would like to see captured by C.
What do you mean by "captured by C"? The phrase makes me think you want
to somehow pass a value from your Perl program to a C function. Even if
I'm right about this, the details of what "somehow" means for your
situation still need to be described.
I am trying to give some answer below, although severely based on
guesswork, because as other have correctly pointed out, the question is
pretty much unclear.
Post by fred flintstone
right ascension of moon 10h 3m 55s
right ascension of sun 10h 4m 0s
moon seconds is 36235
sun seconds is 36240
to server is 11 2457987.25953264 2457987.25774584 2457987.25848217
right ascension of moon 10h 3m 57s
right ascension of sun 10h 4m 0s
moon seconds is 36237
sun seconds is 36240
to server is 12 2457987.25953264 2457987.25848217 2457987.25897738
right ascension of moon 10h 3m 59s
right ascension of sun 10h 4m 0s
moon seconds is 36239
sun seconds is 36240
to server is 13 2457987.25953264 2457987.25897738 2457987.25921532
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.25921532
equal seconds is 36240
Do you mean that when you say "to server" you wish those values to be
sent to some program written in C?
Post by fred flintstone
Post by Ben Bacarisse
Post by fred flintstone
It's C right under the hood, so I
know it can be done.
My first remark is that it may well be the case that a Perl interpreter
is written in C, but this says nothing about interoperability between C
and Perl. C is strictly a /compiled programming language/ which is meant
to produce machine code executables, it is not an /environment/ (like
e.g some interpreters) where scripts may share context.
Post by fred flintstone
Let's say I had a value in perl that I knew was a c double. It's a premise.
say "$equal";
, then I think there is a wide road for C interop.
I may point out the two easiest answers here, sure others may tell more
and/or correct me:

1) using program arguments is not shameful, they are there for a
purpose, so if you have your variables to feed to a C program, you can
use command line arguments for the task. Besides data size, one relevant
constraint here is that program arguments must be passed in a /textual/
representation.
So the type of your parameters becomes relevant for the choice. Floating
point doubles can in principle be passed converted as text as long as
you ensure sufficient precision.
(if the doubles are an encoding of date/times, as in some Windows data
types, it would probably be better to convert them in a more suitable
format)

2) The second easiest input is via input stream (stdin). In this case
you have to establish a common data format between your output and the C
program (it may be noted that C streams are raw sequences of bytes, you
have to specify all details of its format).
This does also allow for binary data transfer (which I do not know how
Perl can deal with), in which case you have to ensure proper format
(endianness, size, etc) of data, like e.g IEEE 754 (now IEC 60559) for
floating point values.
fred flintstone
2017-05-08 10:52:19 UTC
Permalink
On 05/04/2017 09:21 AM, Manfred wrote:

[OP now doubts what he thought he knew about C doubles]
Post by Manfred
Post by fred flintstone
Let's say I had a value in perl that I knew was a c double. It's a premise.
say "$equal";
, then I think there is a wide road for C interop.
I may point out the two easiest answers here, sure others may tell more
1) using program arguments is not shameful, they are there for a
purpose, so if you have your variables to feed to a C program, you can
use command line arguments for the task. Besides data size, one relevant
constraint here is that program arguments must be passed in a /textual/
representation.
So the type of your parameters becomes relevant for the choice. Floating
point doubles can in principle be passed converted as text as long as
you ensure sufficient precision.
(if the doubles are an encoding of date/times, as in some Windows data
types, it would probably be better to convert them in a more suitable
format)
Thanks, manfred, your reply made me not distrust the way you get the
ball rolling in C:

https://github.com/TBlazer66/gcc/blob/master/1.receive.c

I use this script to drive the process:

https://github.com/TBlazer66/gcc/blob/master/5.toolchain.sh

But is that the only fig leaf we need? Well no, as per your reply. I
seem to be a bit rusty. Indeed, I found a post about how everything I
used to know about how to print a double just went back to %f. Anyways,
here was my attempt to write legal, contemporary C (cringe):

#include <stdio.h>

int main (int argc, char *argv[])
{
int count;
double d;

printf ("This program was called with \"%s\".\n",argv[0]);

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

return 0;
}

gcc s


if (argc > 1)
{
for (count = 1; count < argc; count++)
{
printf("argv[%d] = %s\n", count, argv[count]);
}
}
else
{
printf("The command had no other arguments.\n");
}

return 0;
}


I don't understand the first error, which is reason enough for me not to
have to wonder why there more:

$ create.sh 1.receive.c
1
2
2.receive.c
substitute 2 into output files
$ sh 6.toolchain.sh
2.receive.c: In function ‘main’:
2.receive.c:10:3: warning: suggest parentheses around assignment used as
truth value [-Wparentheses]
if (argc = 1)
^
2.receive.c:12:8: error: pointer value used where a floating point value
was expected
d = (double) argv[1];
^
2.receive.c:5:7: warning: unused variable ‘count’ [-Wunused-variable]
int count;
^
$ sh 6.toolchain.sh
2.receive.c: In function ‘main’:
2.receive.c:10:3: warning: suggest parentheses around assignment used as
truth value [-Wparentheses]
if (argc = 2)
^
2.receive.c:12:8: error: pointer value used where a floating point value
was expected
d = (double) argv[1];
^
2.receive.c:5:7: warning: unused variable ‘count’ [-Wunused-variable]
int count;
^
$
Post by Manfred
2) The second easiest input is via input stream (stdin). In this case
you have to establish a common data format between your output and the C
program (it may be noted that C streams are raw sequences of bytes, you
have to specify all details of its format).
This does also allow for binary data transfer (which I do not know how
Perl can deal with), in which case you have to ensure proper format
(endianness, size, etc) of data, like e.g IEEE 754 (now IEC 60559) for
floating point values.
That's not the direction this is heading. I need to have that legal C
value before I want to show anybody what that value is.

If I'm tormenting this newsgroup by my very presence, just give me what
I want, and no one gets hurt....
--
fred
Jerry Stuckle
2017-05-08 12:38:37 UTC
Permalink
Post by fred flintstone
[OP now doubts what he thought he knew about C doubles]
Post by Manfred
Post by fred flintstone
Let's say I had a value in perl that I knew was a c double. It's a premise.
say "$equal";
, then I think there is a wide road for C interop.
I may point out the two easiest answers here, sure others may tell more
1) using program arguments is not shameful, they are there for a
purpose, so if you have your variables to feed to a C program, you can
use command line arguments for the task. Besides data size, one relevant
constraint here is that program arguments must be passed in a /textual/
representation.
So the type of your parameters becomes relevant for the choice. Floating
point doubles can in principle be passed converted as text as long as
you ensure sufficient precision.
(if the doubles are an encoding of date/times, as in some Windows data
types, it would probably be better to convert them in a more suitable
format)
Thanks, manfred, your reply made me not distrust the way you get the
https://github.com/TBlazer66/gcc/blob/master/1.receive.c
https://github.com/TBlazer66/gcc/blob/master/5.toolchain.sh
But is that the only fig leaf we need? Well no, as per your reply. I
seem to be a bit rusty. Indeed, I found a post about how everything I
used to know about how to print a double just went back to %f. Anyways,
#include <stdio.h>
int main (int argc, char *argv[])
{
int count;
double d;
printf ("This program was called with \"%s\".\n",argv[0]);
if (argc = 2)
{
d = (double) argv[1];
printf("Value from perl : %f\n", d );
}
else
{
printf("The program was called wrong.\n");
}
return 0;
}
gcc s
if (argc > 1)
{
for (count = 1; count < argc; count++)
{
printf("argv[%d] = %s\n", count, argv[count]);
}
}
else
{
printf("The command had no other arguments.\n");
}
return 0;
}
I don't understand the first error, which is reason enough for me not to
$ create.sh 1.receive.c
1
2
2.receive.c
substitute 2 into output files
$ sh 6.toolchain.sh
2.receive.c:10:3: warning: suggest parentheses around assignment used as
truth value [-Wparentheses]
if (argc = 1)
^
2.receive.c:12:8: error: pointer value used where a floating point value
was expected
d = (double) argv[1];
^
2.receive.c:5:7: warning: unused variable ‘count’ [-Wunused-variable]
int count;
^
$ sh 6.toolchain.sh
2.receive.c:10:3: warning: suggest parentheses around assignment used as
truth value [-Wparentheses]
if (argc = 2)
"=" is assignment. "==" is comparison. Your expression assigns the
value "2" into argc then tests argc for zero/non-zero. The syntax you
want is

if (argc == 2)
^
Post by fred flintstone
2.receive.c:12:8: error: pointer value used where a floating point value
was expected
d = (double) argv[1];
^
argv[1] is a string. You can't just cast a string to a double. You
need to call a function such as atof() or sscanf() to convert it.
Post by fred flintstone
2.receive.c:5:7: warning: unused variable ‘count’ [-Wunused-variable]
int count;
^
It's just saying you defined a variable "count" that you don't use. You
can safely delete the definition.
Post by fred flintstone
$
Post by Manfred
2) The second easiest input is via input stream (stdin). In this case
you have to establish a common data format between your output and the C
program (it may be noted that C streams are raw sequences of bytes, you
have to specify all details of its format).
This does also allow for binary data transfer (which I do not know how
Perl can deal with), in which case you have to ensure proper format
(endianness, size, etc) of data, like e.g IEEE 754 (now IEC 60559) for
floating point values.
That's not the direction this is heading. I need to have that legal C
value before I want to show anybody what that value is.
If I'm tormenting this newsgroup by my very presence, just give me what
I want, and no one gets hurt....
The problem is your question has not been clear, so people aren't sure
what you want.
--
==================
Remove the "x" from my email address
Jerry Stuckle
***@attglobal.net
==================
Keith Thompson
2017-05-08 16:14:50 UTC
Permalink
[snip]
Post by fred flintstone
But is that the only fig leaf we need? Well no, as per your reply. I
seem to be a bit rusty. Indeed, I found a post about how everything I
used to know about how to print a double just went back to %f. Anyways,
#include <stdio.h>
int main (int argc, char *argv[])
{
int count;
double d;
printf ("This program was called with \"%s\".\n",argv[0]);
argv[0] points to a string that represents the name of the program.
Post by fred flintstone
if (argc = 2)
"=" is an assignment, so this test modifies the value of argc. An
assignment yields the value that was assigned, so the condition is
always true. If argc is 3, for example, this test will set it to 2 and
evaluate as a true condition. You want "if (argc == 2).
Post by fred flintstone
{
d = (double) argv[1];
argv[1] is a pointer of type char*. You cannot legally convert a
pointer to a floating-point type. (If it were legal, the resulting
double value would be meaningless.)

I presume you want, for example, the double value 1.5 given that argv[1]
points to the string "1.5". The simplest way to do this is

d = atof(argv[1]);

but that doesn't do any error checking. For error checking, use
strtod(). (Both are declared in <stdlib.h>.)

[...]
Post by fred flintstone
If I'm tormenting this newsgroup by my very presence, just give me what
I want, and no one gets hurt....
Changing your attitude would increase the odds of getting useful advice
here. You recently plonked someone who had just given you some very
good advice about how ask questions.
--
Keith Thompson (The_Other_Keith) kst-***@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"
James R. Kuyper
2017-05-08 16:17:39 UTC
Permalink
On 05/08/2017 06:52 AM, fred flintstone wrote:
...
Post by fred flintstone
used to know about how to print a double just went back to %f. Anyways,
#include <stdio.h>
int main (int argc, char *argv[])
{
int count;
For what purpose did you define this variable? The code below makes no
use of it, which is why the compiler warned you about it.
Post by fred flintstone
double d;
printf ("This program was called with \"%s\".\n",argv[0]);
if (argc = 2)
That sets argc to a value of 2. Since 2 is a non-zero value the
if-condition is always met. I suspect you intended

if (argc == 2)
Post by fred flintstone
{
d = (double) argv[1];
argv[1] is a pointer to a string of char. There is no defined conversion
between pointers and double values. What I think you want is

if(sscanf(argv[1], "%f", &d) != 1)
{
// error handling
}
Post by fred flintstone
printf("Value from perl : %f\n", d );
}
else
{
printf("The program was called wrong.\n");
}
return 0;
}
...
Post by fred flintstone
I don't understand the first error, which is reason enough for me not to
$ create.sh 1.receive.c
1
2
2.receive.c
substitute 2 into output files
$ sh 6.toolchain.sh
2.receive.c:10:3: warning: suggest parentheses around assignment used as
truth value [-Wparentheses]
if (argc = 1)
^
This is only a warning, not an error, because there's nothing wrong with
it as C code, it merely doesn't make sense. In other cases, where code
exhibiting the same problem might actually make sense, you can use
parentheses around the expression to disable the warning:

if( (continue_processing =
sufficient_capacity && sufficient_demand) )

However, that would not be an appropriate approach for your bug.

...
Post by fred flintstone
If I'm tormenting this newsgroup by my very presence, just give me what
I want, and no one gets hurt....
You're tormenting this newsgroup only with your poorly specified problem
statement, and it's inherently the case that we can't give you what you
want until we understand what it is you want.
Keith Thompson
2017-05-08 16:26:52 UTC
Permalink
[...]
Post by James R. Kuyper
Post by fred flintstone
d = (double) argv[1];
argv[1] is a pointer to a string of char. There is no defined conversion
between pointers and double values.
In fact casting a pointer to a floating-point type is a constraint
violation (N1570 6.5.4p4).
Post by James R. Kuyper
What I think you want is
if(sscanf(argv[1], "%f", &d) != 1)
{
// error handling
}
That will let you detect something that's not a valid representation of
a floating-point value, but it has undefined behavior on overflow.
strtod() is trickier to use, but more robust.
--
Keith Thompson (The_Other_Keith) kst-***@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"
j***@verizon.net
2017-05-08 18:02:39 UTC
Permalink
...
Post by Keith Thompson
Post by James R. Kuyper
What I think you want is
if(sscanf(argv[1], "%f", &d) != 1)
{
// error handling
}
That will let you detect something that's not a valid representation of
a floating-point value, but it has undefined behavior on overflow.
strtod() is trickier to use, but more robust.
I agree that it's more robust, but for someone who could write (double)argv[1] without realizing that it's nonsense, strtod() is probably too tricky to use.
Keith Thompson
2017-05-08 18:39:30 UTC
Permalink
Post by j***@verizon.net
...
Post by Keith Thompson
Post by James R. Kuyper
What I think you want is
if(sscanf(argv[1], "%f", &d) != 1)
{
// error handling
}
That will let you detect something that's not a valid representation of
a floating-point value, but it has undefined behavior on overflow.
strtod() is trickier to use, but more robust.
I agree that it's more robust, but for someone who could write
(double)argv[1] without realizing that it's nonsense, strtod() is
probably too tricky to use.
Which is why I suggested atof() (while pointing out its weaknesses and
suggesting strtod() as a more robust alternative).

I suppose sscanf (with the right format string, "%lf") is more robust
than atof().
--
Keith Thompson (The_Other_Keith) kst-***@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"
Tim Rentsch
2017-05-09 14:16:31 UTC
Permalink
Post by Keith Thompson
[...]
Post by fred flintstone
d = (double) argv[1];
argv[1] is a pointer to a string of char. There is no defined conversion
between pointers and double values.
In fact casting a pointer to a floating-point type is a constraint
violation (N1570 6.5.4p4).
In C11 it is. Before C11 it was not.
Keith Thompson
2017-05-09 15:18:25 UTC
Permalink
Post by Tim Rentsch
Post by Keith Thompson
[...]
Post by fred flintstone
d = (double) argv[1];
argv[1] is a pointer to a string of char. There is no defined conversion
between pointers and double values.
In fact casting a pointer to a floating-point type is a constraint
violation (N1570 6.5.4p4).
In C11 it is. Before C11 it was not.
Interesting. But before C11 I believe the behavior was undefined (by
omission, since the standard doesn't say what the behavior is).
--
Keith Thompson (The_Other_Keith) kst-***@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"
fred flintstone
2017-05-10 07:29:32 UTC
Permalink
Post by Keith Thompson
Post by Tim Rentsch
Post by Keith Thompson
[...]
Post by fred flintstone
d = (double) argv[1];
argv[1] is a pointer to a string of char. There is no defined conversion
between pointers and double values.
In fact casting a pointer to a floating-point type is a constraint
violation (N1570 6.5.4p4).
In C11 it is. Before C11 it was not.
Interesting. But before C11 I believe the behavior was undefined (by
omission, since the standard doesn't say what the behavior is).
It would be more interesting if I hadn't missed by one degree of
indirection. I just have to throw something at the backboard and hope
that others can clean it up. If people who didn't know C read the above,
they would say that your standard might be at fault.

I'm glad I got an error rather than nasal snot demons: they give me
drainage problems.
--
fred
Tim Rentsch
2017-05-10 12:26:42 UTC
Permalink
Post by Keith Thompson
Post by Tim Rentsch
Post by Keith Thompson
[...]
Post by fred flintstone
d = (double) argv[1];
argv[1] is a pointer to a string of char. There is no defined
conversion between pointers and double values.
In fact casting a pointer to a floating-point type is a constraint
violation (N1570 6.5.4p4).
In C11 it is. Before C11 it was not.
Interesting. But before C11 I believe the behavior was undefined
(by omission, since the standard doesn't say what the behavior is).
Yes, I don't see any basis for reaching any other conclusion.
Ben Bacarisse
2017-05-08 17:20:05 UTC
Permalink
<snip>
Post by James R. Kuyper
Post by fred flintstone
double d;
<snip>
Post by James R. Kuyper
Post by fred flintstone
d = (double) argv[1];
argv[1] is a pointer to a string of char. There is no defined
conversion between pointers and double values. What I think you want
is
if(sscanf(argv[1], "%f", &d) != 1)
Small point: it's %lf for (pointer to) double arguments.

<snip>
--
Ben.
Loading...