Floating point linkage

Discussion in 'C Programming' started by C learner, Oct 13, 2013.

  1. C learner

    C learner Guest

    Point out the error in the following program.

    #include<stdio.h>
    int main()
    {
    struct emp
    {
    char name[20];
    float sal;
    };
    struct emp e[10];
    int i;
    for(i=0; i<=9; i++)
    scanf("%s %f", e.name, &e.sal);
    return 0;
    }
    [A]. Suspicious pointer conversion
    .
    Floating point formats not linked (Run time error) @
    [C]. Cannot use scanf() for structures
    [D]. Strings cannot be nested inside structures


    Answere is B






    My question is what is Floatin point linkage and how it is applicable here.
    Please elaborate.
    C learner, Oct 13, 2013
    #1
    1. Advertising

  2. C learner

    Eric Sosman Guest

    On 10/13/2013 6:25 AM, C learner wrote:
    >[...]
    >
    > My question is what is Floatin point linkage and how it is applicable here.
    > Please elaborate.


    http://www.c-faq.com/fp/fpnotlinked.html

    --
    Eric Sosman
    d
    Eric Sosman, Oct 13, 2013
    #2
    1. Advertising

  3. C learner <> writes:

    > Point out the error in the following program.
    >
    > #include<stdio.h>
    > int main()
    > {
    > struct emp
    > {
    > char name[20];
    > float sal;
    > };
    > struct emp e[10];
    > int i;
    > for(i=0; i<=9; i++)
    > scanf("%s %f", e.name, &e.sal);
    > return 0;
    > }
    > [A]. Suspicious pointer conversion
    > .
    > Floating point formats not linked (Run time error) @
    > [C]. Cannot use scanf() for structures
    > [D]. Strings cannot be nested inside structures
    >
    >
    > Answere is B


    But that answer is wrong because it is not an error in the program. It
    may be that a system gives such an error, but it does not reflect any
    problem with the program itself.

    The program does have an error (ignoring the fact it does nothing). The
    %s format can overflow the char array e.name. The format should be
    %19s.

    <snip>
    --
    Ben.
    Ben Bacarisse, Oct 13, 2013
    #3
  4. In article <>,
    Ben Bacarisse <> wrote:
    ....
    >But that answer is wrong because it is not an error in the program. It
    >may be that a system gives such an error, but it does not reflect any
    >problem with the program itself.


    Not if you, as a sensible person would, consider "the program" to be the
    entire edit/compile/run cycle. Obviously, there's a problem somewhere.

    >The program does have an error (ignoring the fact it does nothing). The
    >%s format can overflow the char array e.name. The format should be
    >%19s.


    On your logic, you would say that that is not an error in the program, but
    rather a user error (supplying bad input - should be on the head of the
    user, not the program).

    --
    Nov 4, 2008 - the day when everything went
    from being Clinton's fault to being Obama's fault.
    Kenny McCormack, Oct 13, 2013
    #4
  5. C learner

    Rob Guest

    On Sun, 13 Oct 2013 03:25:40 -0700, C learner wrote:



    > Point out the error in the following program.


    [snip]

    > scanf("%s %f", e.name, &e.sal);




    The problem that I see is that an ampersand (&) is missing in
    front of the first variable.
    Rob, Oct 16, 2013
    #5
  6. Rob <> writes:
    > On Sun, 13 Oct 2013 03:25:40 -0700, C learner wrote:
    >
    >
    >> Point out the error in the following program.

    >
    > [snip]
    >
    >> scanf("%s %f", e.name, &e.sal);

    >
    >
    > The problem that I see is that an ampersand (&) is missing in
    > front of the first variable.


    Nope. e.name is of type char[20], which decays to char* in that
    context, so no & is necessary (and in fact adding an & would cause the
    argument to be of the wrong type).

    Which would have been more obvious if you'd quoted more of the code.

    --
    Keith Thompson (The_Other_Keith) <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"
    Keith Thompson, Oct 16, 2013
    #6
  7. C learner <> wrote:
    > Point out the error in the following program.


    > #include<stdio.h>
    > int main()
    > {
    > struct emp
    > {
    > char name[20];
    > float sal;
    > };
    > struct emp e[10];
    > int i;
    > for(i=0; i<=9; i++)
    > scanf("%s %f", e.name, &e.sal);
    > return 0;
    > }
    > [A]. Suspicious pointer conversion
    > .
    > Floating point formats not linked (Run time error) @
    > [C]. Cannot use scanf() for structures
    > [D]. Strings cannot be nested inside structures


    My answer would be "Don't use floating point for monetary values."

    I believe it was Knuth you said that finance and typesetting should
    be done in fixed point (not long after he worked on TeX).

    (snip)

    > My question is what is Floatin point linkage and how it is
    > applicable here. Please elaborate.


    I don't see that anyone answered this yet.

    In the early days of the 8086 and 8088 (if not other processors)
    floating point operations were done by software subroutine calls.

    I am not sure now the exact case, but if no actual floating point
    operations were done, the routines needed to do floating point
    calculations weren't linked in. (That was before the 8087, or at
    least before it was popular.) The routines were big enough, and
    computers small enough, that it was worthwhile to not link them if
    not needed. Compilers didn't look inside the format string for
    scanf() and printf() (and associated calls). If the only floating
    point operations were those done by the I/O conversion routines,
    the floating point library wasn't there, and they would fail with
    the indicated message.

    One fix would be to do some actual floating point operation,
    even if not actually needed.

    -- glen
    glen herrmannsfeldt, Oct 17, 2013
    #7
  8. C learner

    Rob Guest

    On Wed, 16 Oct 2013 15:13:19 -0700, Keith Thompson wrote:

    > Nope. e.name is of type char[20], which decays to char* in that
    > context, so no & is necessary (and in fact adding an & would cause the
    > argument to be of the wrong type).
    >
    > Which would have been more obvious if you'd quoted more of the code.


    You are totally right. Thank you for the correction.

    This is why I lurk here most of the time. :)
    Rob, Oct 17, 2013
    #8
  9. glen herrmannsfeldt <> writes:
    > C learner <> wrote:

    [...]
    >> My question is what is Floatin point linkage and how it is
    >> applicable here. Please elaborate.

    >
    > I don't see that anyone answered this yet.


    Eric Sosman did, by citing question 14.13 in the comp.lang.c FAQ
    <http://www.c-faq.com/>.

    [...]

    --
    Keith Thompson (The_Other_Keith) <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"
    Keith Thompson, Oct 17, 2013
    #9
  10. C learner

    Eric Sosman Guest

    On 10/17/2013 11:11 AM, Keith Thompson wrote:
    > glen herrmannsfeldt <> writes:
    >> C learner <> wrote:

    > [...]
    >>> My question is what is Floatin point linkage and how it is
    >>> applicable here. Please elaborate.

    >>
    >> I don't see that anyone answered this yet.

    >
    > Eric Sosman did, by citing question 14.13 in the comp.lang.c FAQ
    > <http://www.c-faq.com/>.


    Actually, Glen's explanation is slightly different
    from the FAQ's. Either -- or neither -- might bear on
    the O.P.'s problem.

    --
    Eric Sosman
    d
    Eric Sosman, Oct 17, 2013
    #10
  11. C learner

    Öö Tiib Guest

    On Thursday, 17 October 2013 06:16:25 UTC+3, glen herrmannsfeldt wrote:
    > One fix would be to do some actual floating point operation,
    > even if not actually needed.


    It seems that this is already floating point operation (unary minus):

    const float minus_one = -1.0f;

    Rationale is that there are no negative floating constants in C by
    (6.4.4.2). Is it actually enough?
    Öö Tiib, Oct 17, 2013
    #11
  12. Öö Tiib <> wrote:
    > On Thursday, 17 October 2013 06:16:25 UTC+3, glen herrmannsfeldt wrote:
    >> One fix would be to do some actual floating point operation,
    >> even if not actually needed.


    > It seems that this is already floating point operation (unary minus):


    > const float minus_one = -1.0f;


    > Rationale is that there are no negative floating constants in C by
    > (6.4.4.2). Is it actually enough?


    Maybe not. The languages is defined that way, but as well as I
    know, all compilers will generate a negative constant. Many will do
    a lot more with constant expressions.

    When the Pentium FDIV bug was discovered, there were C source
    programs to demonstrate it by dividing two constants. Many compilers
    would evaluate the constant expression at compile time using software
    emulated floating point, and so not actually use FDIV at all.

    As optimizers get better, it is harder to generate something that
    is guaranteed not to happen at compile time. How about:

    float one,two;
    sscanf("1.0",&one);
    two=one+one;

    -- glen
    glen herrmannsfeldt, Oct 17, 2013
    #12
  13. Öö Tiib <> writes:
    > On Thursday, 17 October 2013 06:16:25 UTC+3, glen herrmannsfeldt wrote:
    >> One fix would be to do some actual floating point operation,
    >> even if not actually needed.

    >
    > It seems that this is already floating point operation (unary minus):
    >
    > const float minus_one = -1.0f;
    >
    > Rationale is that there are no negative floating constants in C by
    > (6.4.4.2). Is it actually enough?


    It depends on the compiler, but probably not.

    As far as the language is concerned, the value 1.0f has the unary "-"
    operator applied to it. But any compiler worth what you paid for
    it (even if it's free) will evaluate the negation at compile time,
    which would most likely bypass the compiler's check for whether
    the floating-point implementation needs to be linked.

    The compiler in question is *already* violating the C standard by
    not handling conforming code correctly (by applying an optimization
    in cases where it's incorrect to do so). We can't rely on the
    standard to tell us how it will behave.

    --
    Keith Thompson (The_Other_Keith) <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"
    Keith Thompson, Oct 17, 2013
    #13
  14. On 16-Oct-13 22:16, glen herrmannsfeldt wrote:
    > C learner <> wrote:
    >> My question is what is Floatin point linkage and how it is
    >> applicable here. Please elaborate.

    >
    > I don't see that anyone answered this yet.
    >
    > In the early days of the 8086 and 8088 (if not other processors)
    > floating point operations were done by software subroutine calls.
    >
    > I am not sure now the exact case, but if no actual floating point
    > operations were done, the routines needed to do floating point
    > calculations weren't linked in. (That was before the 8087, or at
    > least before it was popular.) The routines were big enough, and
    > computers small enough, that it was worthwhile to not link them if
    > not needed. Compilers didn't look inside the format string for
    > scanf() and printf() (and associated calls). If the only floating
    > point operations were those done by the I/O conversion routines,
    > the floating point library wasn't there, and they would fail with
    > the indicated message.


    Note that even though printf() and scanf() used floating-point
    operations themselves, a "clever" optimization prevented FP support from
    being linked in to every program that used stdio. The assumption was
    that if you didn't explicitly call any FP functions in your own code,
    then the FP parts of the stdio code wouldn't get used. The example code
    here violates that assumption, hence the linker error.

    That this situation persists to this day, though, is surprising; given
    all the other junk that gets linked in by default, the prevalence of
    hardware FP support, ubiquitous dynamic shared libraries and explosive
    growth in available memory, it seems like this optimization has long
    outlived its usefulness.

    S

    --
    Stephen Sprunk "God does not play dice." --Albert Einstein
    CCIE #3723 "God is an inveterate gambler, and He throws the
    K5SSS dice at every possible opportunity." --Stephen Hawking
    Stephen Sprunk, Oct 17, 2013
    #14
  15. Stephen Sprunk <> wrote:

    (snip, I wrote)
    >> In the early days of the 8086 and 8088 (if not other processors)
    >> floating point operations were done by software subroutine calls.


    >> I am not sure now the exact case, but if no actual floating point
    >> operations were done, the routines needed to do floating point
    >> calculations weren't linked in.


    (snip)
    > Note that even though printf() and scanf() used floating-point
    > operations themselves, a "clever" optimization prevented FP
    > support fromeing linked in to every program that used stdio.
    > The assumption was that if you didn't explicitly call any FP
    > functions in your own code, then the FP parts of the stdio
    > code wouldn't get used. The example code here violates that
    > assumption, hence the linker error.


    I am not sure exactly how it was implemented. The IBM OS/360
    linker has weak external references that will be resolved if the
    called routine is linked, but won't pull a routine from a library.
    I don't remember which linkers provide that feature.

    > That this situation persists to this day, though, is surprising;
    > given all the other junk that gets linked in by default,
    > the prevalence of hardware FP support, ubiquitous dynamic
    > shared libraries and explosive growth in available memory,
    > it seems like this optimization has long outlived its usefulness.


    Yes, but old compilers might still run on currently available systems.
    I believe 16 bit DOS/Windows code will run on XP.

    Now, why is it that we still need -lm to link the math library
    on unix and unix-like systems? Why not just put them into
    the same library with the rest of libc?

    -- glen
    glen herrmannsfeldt, Oct 17, 2013
    #15
  16. C learner

    Thomas Jahns Guest

    On 10/18/13 00:00, glen herrmannsfeldt wrote:
    > Now, why is it that we still need -lm to link the math library
    > on unix and unix-like systems? Why not just put them into
    > the same library with the rest of libc?


    I'd say typically because

    - libm doesn't have to be dynamically linked (for libc there's no static version
    on many platforms)

    - it makes sense to replace libm with something having the same ABI but extended
    precision/error checking/whatnot without any change to libc functions

    Regards, Thomas
    Thomas Jahns, Oct 18, 2013
    #16
  17. On 18-Oct-13 03:21, Thomas Jahns wrote:
    > On 10/18/13 00:00, glen herrmannsfeldt wrote:
    >> Now, why is it that we still need -lm to link the math library on
    >> unix and unix-like systems? Why not just put them into the same
    >> library with the rest of libc?

    >
    > I'd say typically because
    >
    > - libm doesn't have to be dynamically linked (for libc there's no
    > static version on many platforms)


    Since (nearly) every program (and other library) on a typical Unix
    platform is going to be linked to libc by default, it would be utterly
    wasteful to statically link against it. libc is the canonical example
    of why dynamic linking is needed.

    In contrast, few programs (and other libraries) use libm, so while
    static linking would probably still be wasteful, it'd be a relatively
    minor problem in practice.

    > - it makes sense to replace libm with something having the same ABI
    > but extended precision/error checking/whatnot without any change to
    > libc functions


    IIRC, if you explicitly link to your own library, that will override the
    functions in libc, so that option wouldn't be lost by including the math
    functions in libc.

    (It would still be wise to provide an empty libm, to avoid causing
    unnecessary linking problems for builds that assume they need it.)

    S

    --
    Stephen Sprunk "God does not play dice." --Albert Einstein
    CCIE #3723 "God is an inveterate gambler, and He throws the
    K5SSS dice at every possible opportunity." --Stephen Hawking
    Stephen Sprunk, Oct 18, 2013
    #17
  18. C learner

    Seebs Guest

    On 2013-10-18, Stephen Sprunk <> wrote:
    > Since (nearly) every program (and other library) on a typical Unix
    > platform is going to be linked to libc by default, it would be utterly
    > wasteful to statically link against it. libc is the canonical example
    > of why dynamic linking is needed.


    I feel I should point out a distinction, at some risk of going off-topic:

    Dynamic and static linking are NOT the same question as shared or unshared.

    At least one operating system I know of implemented static linking for
    shared libraries like libc, so you could get a noticeable speed improvement
    over a typical dynamic linker, but still have the massive address space
    savings of letting multiple programs use the same blocks of memory for the
    shared text segments.

    -s
    --
    Copyright 2013, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    Autism Speaks does not speak for me. http://autisticadvocacy.org/
    I am not speaking for my employer, although they do rent some of my opinions.
    Seebs, Oct 18, 2013
    #18
  19. On 17-Oct-13 17:00, glen herrmannsfeldt wrote:
    > Stephen Sprunk <> wrote:
    >> Note that even though printf() and scanf() used floating-point
    >> operations themselves, a "clever" optimization prevented FP support
    >> fromeing linked in to every program that used stdio. The assumption
    >> was that if you didn't explicitly call any FP functions in your own
    >> code, then the FP parts of the stdio code wouldn't get used. The
    >> example code here violates that assumption, hence the linker
    >> error.

    >
    > I am not sure exactly how it was implemented. The IBM OS/360 linker
    > has weak external references that will be resolved if the called
    > routine is linked, but won't pull a routine from a library. I don't
    > remember which linkers provide that feature.


    Ah. I wasn't sure how it was implemented either, but it's a common
    enough complaint that I remember the general issue.

    >> That this situation persists to this day, though, is surprising;
    >> given all the other junk that gets linked in by default, the
    >> prevalence of hardware FP support, ubiquitous dynamic shared
    >> libraries and explosive growth in available memory, it seems like
    >> this optimization has long outlived its usefulness.

    >
    > Yes, but old compilers might still run on currently available
    > systems. I believe 16 bit DOS/Windows code will run on XP.


    64-bit Windows dropped support for DOS/Win16 code.

    It's not just "old" compilers, though; modern 64-bit tool chains have
    inherited the same "feature".

    > Now, why is it that we still need -lm to link the math library on
    > unix and unix-like systems? Why not just put them into the same
    > library with the rest of libc?


    That's what I said above :)

    S

    --
    Stephen Sprunk "God does not play dice." --Albert Einstein
    CCIE #3723 "God is an inveterate gambler, and He throws the
    K5SSS dice at every possible opportunity." --Stephen Hawking
    Stephen Sprunk, Oct 19, 2013
    #19
  20. On 18-Oct-13 17:26, Seebs wrote:
    > On 2013-10-18, Stephen Sprunk <> wrote:
    >> Since (nearly) every program (and other library) on a typical Unix
    >> platform is going to be linked to libc by default, it would be
    >> utterly wasteful to statically link against it. libc is the
    >> canonical example of why dynamic linking is needed.

    >
    > I feel I should point out a distinction, at some risk of going
    > off-topic:
    >
    > Dynamic and static linking are NOT the same question as shared or
    > unshared.
    >
    > At least one operating system I know of implemented static linking
    > for shared libraries like libc, so you could get a noticeable speed
    > improvement over a typical dynamic linker, but still have the massive
    > address space savings of letting multiple programs use the same
    > blocks of memory for the shared text segments.


    How is that even possible? When you statically link a library, the
    parts that you need are added to your executable and the rest is thrown
    away, and even the parts that are included are subject to link-time
    relocation, so they can't be shared with other programs.

    S

    --
    Stephen Sprunk "God does not play dice." --Albert Einstein
    CCIE #3723 "God is an inveterate gambler, and He throws the
    K5SSS dice at every possible opportunity." --Stephen Hawking
    Stephen Sprunk, Oct 20, 2013
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. H aka N
    Replies:
    15
    Views:
    15,621
    Ben Jones
    Mar 2, 2006
  2. Motaz Saad
    Replies:
    7
    Views:
    6,461
  3. Replies:
    1
    Views:
    581
    Michael DOUBEZ
    Sep 12, 2008
  4. Saraswati lakki
    Replies:
    0
    Views:
    1,298
    Saraswati lakki
    Jan 6, 2012
  5. teeshift
    Replies:
    2
    Views:
    242
    Chris Pearl
    Dec 1, 2006
Loading...

Share This Page