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 3 of 3 — ← Prev page 1 2 [3]

#109221

On 5/1/2017 1:18 PM, fred flintstone wrote:
> On 04/30/2017 08:16 AM, Ben Bacarisse wrote:
>> fred flintstone <fred@server.invalid> writes:
>>
>>> 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.

> 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
>
>

Do you mean that when you say "to server" you wish those values to be 
sent to some program written in C?

>>
>>> 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.


>
> 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.

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.

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

#109486

On 05/04/2017 09:21 AM, Manfred wrote:

[OP now doubts what he thought he knew about C doubles]

>> 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.
>
> 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)

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;
        ^
$
>
> 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

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

#109491

On 5/8/2017 6:52 AM, fred flintstone wrote:
> On 05/04/2017 09:21 AM, Manfred wrote:
> 
> [OP now doubts what he thought he knew about C doubles]
> 
>>> 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.
>>
>> 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)
> 
> 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)
>

"=" 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)
    ^
> 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.

> 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.

> $
>>
>> 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
jstucklex@attglobal.net
==================

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

#109508

fred flintstone <fred@server.invalid> writes:
> On 05/04/2017 09:21 AM, Manfred wrote:
[snip]
> 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]);

argv[0] points to a string that represents the name of the program.

>    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).

>      {
>         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>.)

[...]

> 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-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]

#109511

On 05/08/2017 06:52 AM, fred flintstone wrote:
...
> 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;

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.

>    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)

>      {
>         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
           }

>         printf("Value from perl : %f\n", d );
>      }
>    else
>      {
>        printf("The program was called wrong.\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)
>     ^

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.

...
> 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.

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

#109512

"James R. Kuyper" <jameskuyper@verizon.net> writes:
> On 05/08/2017 06:52 AM, fred flintstone wrote:
[...]
>>         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).

>                                     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-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]

#109519

On Monday, May 8, 2017 at 12:27:01 PM UTC-4, Keith Thompson wrote:
> "James R. Kuyper" <jameskuyper@verizon.net> writes:
...
> >                                     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.

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

#109524

jameskuyper@verizon.net writes:
> On Monday, May 8, 2017 at 12:27:01 PM UTC-4, Keith Thompson wrote:
>> "James R. Kuyper" <jameskuyper@verizon.net> writes:
> ...
>> >                                     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-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]

#109593

Keith Thompson <kst-u@mib.org> writes:

> "James R.  Kuyper" <jameskuyper@verizon.net> writes:
>> On 05/08/2017 06:52 AM, fred flintstone wrote:
>
> [...]
>
>>>         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.

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

#109598

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> "James R.  Kuyper" <jameskuyper@verizon.net> writes:
>>> On 05/08/2017 06:52 AM, fred flintstone wrote:
>> [...]
>>>>         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-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]

#109641

On 05/09/2017 08:18 AM, Keith Thompson wrote:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> "James R.  Kuyper" <jameskuyper@verizon.net> writes:
>>>> On 05/08/2017 06:52 AM, fred flintstone wrote:
>>> [...]
>>>>>         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

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

#109657

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> "James R.  Kuyper" <jameskuyper@verizon.net> writes:
>>>> On 05/08/2017 06:52 AM, fred flintstone wrote:
>>>
>>> [...]
>>>
>>>>>         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.

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

#109516

"James R. Kuyper" <jameskuyper@verizon.net> writes:

> On 05/08/2017 06:52 AM, fred flintstone wrote:
<snip>
>>    double d;
<snip>
>>         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.

[toc] | [prev] | [standalone]

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

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

csiph-web