return values

Discussion in 'C Programming' started by Uno, Jan 23, 2011.

  1. Uno

    Uno Guest

    I swear to God that I didn't invite clc to my party, but here you are.

    So, now that the lingua franca is the yatik of ritchie, I'd like to
    contrast many features to syntaxes that were formed primarily with an
    eye toward C, as opposed to being C itself.

    I'm reading _Learning Perl_ right now, and I think to understand that
    perl "always returns something" is what perlfolks think is an important
    feature to their language.

    What doesn't return a value in C?

    Peace. Love. MLK
    --
    Uno
    Uno, Jan 23, 2011
    #1
    1. Advertising

  2. Uno

    Uno Guest

    On 1/22/2011 9:12 PM, Sherm Pendley wrote:
    > Uno<> writes:
    >
    >> What doesn't return a value in C?

    >
    > Functions that are explicitly declared as returning void.



    Right.
    >
    > Your C compiler will emit a warning if a non-void function lacks a return
    > statement.
    >
    > sherm--
    >


    Ok. Dankenstein.
    --
    Uno
    Uno, Jan 23, 2011
    #2
    1. Advertising

  3. On Jan 23, 3:53 am, Uno <> wrote:

    <snip>

    > So, now that the lingua franca is the yatik of ritchie, I'd like to
    > contrast many features to syntaxes that were formed primarily with an
    > eye toward C, as opposed to being C itself.
    >
    > I'm reading _Learning Perl_ right now, and I think to understand that
    > perl "always returns something" is what perlfolks think is an important
    > feature to their language.
    >
    > What doesn't return a value in C?


    anything marked as "returning" void?

    Some languages (eg. pascal) distinguish between functions that return
    something and procedures that don't. Traditionally in mathematics a
    function doesn't have side effects as there is nothing to have side
    effects on. I think the aim of the Pascal function/procedure
    distinction was that functions should be without side effects (ie.
    don't modify the program state or do i/o). Whilst procedures modified
    the environment and/or do i/o. But I don't believe Pascal enforces
    this distinction. It's supposed to be a lot easier to prove things
    about programs that lack side effects. But practically its hard to
    write useful programs that lack side effects. Take a look at a
    functional language (that doesn't just mean "has functions") or
    prolog.
    Nick Keighley, Jan 23, 2011
    #3
  4. Uno

    Guest

    Sherm Pendley <> wrote:
    > Uno <> writes:
    >
    > > What doesn't return a value in C?

    >
    > Functions that are explicitly declared as returning void.


    Statements.

    (Technically, operators don't return values, they yield results, but
    that's probably not a significant difference in this context.)
    --
    Larry Jones

    I've got to start listening to those quiet, nagging doubts. -- Calvin
    , Jan 23, 2011
    #4
  5. On Jan 23, 5:26 pm, Nick Keighley <>
    wrote:
    >
    > Some languages (eg. pascal) distinguish between functions that return
    > something and procedures that don't. Traditionally in mathematics a
    > function doesn't have side effects as there is nothing to have side
    > effects on. I think the aim of the Pascal function/procedure
    > distinction was that functions should be without side effects (ie.
    > don't modify the program state or do i/o).
    >

    There's not an important distinction between

    void foo(int *xret)

    and

    int foo(void)

    except at the level of grammar - we can say

    if(foo())

    in the second case but not in the first. So really it's not helpful
    from a software engineering perspective to think in terms of functions
    as procedures with a non-void return type.

    The side-effect distinction, however, is very important, but hard to
    nail down. For instance sqrt() is the paradigm of a function, but in C
    it sets errno if passed a negative, so not a pure function. Most code
    will never test errno, however, so we can't usefully say a function
    becomes a procedure because it calls sqrt().
    Malcolm McLean, Jan 24, 2011
    #5
  6. Uno

    Hans Vlems Guest

    On 23 jan, 16:26, Nick Keighley <>
    wrote:
    > On Jan 23, 3:53 am, Uno <> wrote:
    >
    > <snip>
    >
    > > So, now that the lingua franca is the yatik of ritchie, I'd like to
    > > contrast many features to syntaxes that were formed primarily with an
    > > eye toward C, as opposed to being C itself.

    >
    > > I'm reading _Learning Perl_ right now, and I think to understand that
    > > perl "always returns something" is what perlfolks think is an important
    > > feature to their language.

    >
    > > What doesn't return a value in C?

    >
    > anything marked as "returning" void?
    >
    > Some languages (eg. pascal) distinguish between functions that return
    > something and procedures that don't. Traditionally in mathematics a
    > function doesn't have side effects as there is nothing to have side
    > effects on. I think the aim of the Pascal function/procedure
    > distinction was that functions should be without side effects (ie.
    > don't modify the program state or do i/o). Whilst procedures modified
    > the environment and/or do i/o. But I don't believe Pascal enforces
    > this distinction. It's supposed to be a lot easier to prove things
    > about programs that lack side effects. But practically its hard to
    > write useful programs that lack side effects. Take a look at a
    > functional language (that doesn't just mean "has functions") or
    > prolog.


    Algol recognizes the reserved word procedure, and a procedure may
    return a value.
    I can't remember whether Fortran IV had subroutines that returned a
    value (IIRC they couldn't).
    In Algol the difference is obvious to the compiler. So there was no
    linguistic need to use different reserved words
    to make that clear to the compiler. Pascal makes the difference
    because it specifies the object type at the end of a declaration.

    Algol Pascal C
    INTEGER PROCEDURE SUM(..); function sum(..):integer; int
    sum(..)
    PROCEDURE DOTHIS(..); procedure dothis(..); void
    dothis(..)
    INTEGER GETAL; var getal:int; int
    getal;

    I guess that the decision to put the type of a variable at the end of
    the declaration in Pascal forced the need
    to alert the compiler what was coming. C followed Algol and put the
    type in fornt of the variable list. Which is
    IMHO a more natural way of doing things.
    Other than that there is no other difference. It is perfectly alright
    to perform IO in functions. And procedures
    can return fascinating results via parameters, e.g. Jensen's device.
    Basically the motto of Algol60 explains it all: Was sich überhaupt
    sagen lässt, lässt sich klar sagen (Wittgenstein).
    Which probably explains why Algol remains my favourite language ;-)
    Hans
    Hans Vlems, Jan 24, 2011
    #6
  7. Uno

    Guest

    On Jan 24, 2:04 am, Hans Vlems <> wrote:
    > On 23 jan, 16:26, Nick Keighley <>
    > wrote:
    > > Some languages (eg. pascal) distinguish between functions that return
    > > something and procedures that don't. Traditionally in mathematics a
    > > function doesn't have side effects as there is nothing to have side
    > > effects on. I think the aim of the Pascal function/procedure
    > > distinction was that functions should be without side effects (ie.
    > > don't modify the program state or do i/o). Whilst procedures modified
    > > the environment and/or do i/o. But I don't believe Pascal enforces
    > > this distinction. It's supposed to be a lot easier to prove things
    > > about programs that lack side effects. But practically its hard to
    > > write useful programs that lack side effects. Take a look at a
    > > functional language (that doesn't just mean "has functions") or
    > > prolog.

    >
    > Algol recognizes the reserved word procedure, and a procedure may
    > return a value.
    > I can't remember whether Fortran IV had subroutines that returned a
    > value (IIRC they couldn't).



    Statement functions and functions subprograms could return values.
    Statement functions being more similar to a Basic DEF FNx than
    "proper" subroutines:

    DOMULTIPLY(A,B)=A*B
    ...
    X=DOMULTIPLY(Y,Z)

    And function subprograms:

    FUNCTION DOMULTIPLY(A,B)
    C Yes, this doesn't handle fractional B's as you'd expect
    DOMULTIPLY=0
    DO 10 I=1,B
    10 DOMULTIPLY=DOMULTIPLY+A
    RETURN
    END
    ...
    X=DOMULTIPLY(Y,Z)
    , Jan 24, 2011
    #7
  8. Uno

    Uno Guest

    On 1/24/2011 11:54 AM, wrote:
    > On Jan 24, 2:04 am, Hans Vlems<> wrote:
    >> On 23 jan, 16:26, Nick Keighley<>
    >> wrote:
    >>> Some languages (eg. pascal) distinguish between functions that return
    >>> something and procedures that don't. Traditionally in mathematics a
    >>> function doesn't have side effects as there is nothing to have side
    >>> effects on. I think the aim of the Pascal function/procedure
    >>> distinction was that functions should be without side effects (ie.
    >>> don't modify the program state or do i/o). Whilst procedures modified
    >>> the environment and/or do i/o. But I don't believe Pascal enforces
    >>> this distinction. It's supposed to be a lot easier to prove things
    >>> about programs that lack side effects. But practically its hard to
    >>> write useful programs that lack side effects. Take a look at a
    >>> functional language (that doesn't just mean "has functions") or
    >>> prolog.

    >>
    >> Algol recognizes the reserved word procedure, and a procedure may
    >> return a value.
    >> I can't remember whether Fortran IV had subroutines that returned a
    >> value (IIRC they couldn't).

    >
    >
    > Statement functions and functions subprograms could return values.
    > Statement functions being more similar to a Basic DEF FNx than
    > "proper" subroutines:
    >
    > DOMULTIPLY(A,B)=A*B
    > ...
    > X=DOMULTIPLY(Y,Z)
    >
    > And function subprograms:
    >
    > FUNCTION DOMULTIPLY(A,B)
    > C Yes, this doesn't handle fractional B's as you'd expect
    > DOMULTIPLY=0
    > DO 10 I=1,B
    > 10 DOMULTIPLY=DOMULTIPLY+A
    > RETURN
    > END
    > ...
    > X=DOMULTIPLY(Y,Z)


    thx, Robert, that's syntax I know.

    I guess what I wonder is why the feature of
    "always returning a value"
    might be considered to be better than a bug.
    --
    Uno
    Uno, Jan 26, 2011
    #8
  9. Uno

    Guest

    On Jan 26, 2:32 am, Uno <> wrote:
    > On 1/24/2011 11:54 AM, wrote:
    >
    >
    >
    >
    >
    > > On Jan 24, 2:04 am, Hans Vlems<>  wrote:
    > >> On 23 jan, 16:26, Nick Keighley<>
    > >> wrote:
    > >>> Some languages (eg. pascal) distinguish between functions thatreturn
    > >>> something and procedures that don't. Traditionally in mathematics a
    > >>> function doesn't have side effects as there is nothing to have side
    > >>> effects on. I think the aim of the Pascal function/procedure
    > >>> distinction was that functions should be without side effects (ie.
    > >>> don't modify the program state or do i/o). Whilst procedures modified
    > >>> the environment and/or do i/o. But I don't believe Pascal enforces
    > >>> this distinction. It's supposed to be a lot easier to prove things
    > >>> about programs that lack side effects. But practically its hard to
    > >>> write useful programs that lack side effects. Take a look at a
    > >>> functional language (that doesn't just mean "has functions") or
    > >>> prolog.

    >
    > >> Algol recognizes the reserved word procedure, and a procedure may
    > >>returnavalue.
    > >> I can't remember whether Fortran IV had subroutines that returned a
    > >>value(IIRC they couldn't).

    >
    > > Statement functions and functions subprograms couldreturnvalues.
    > > Statement functions being more similar to a Basic DEF FNx than
    > > "proper" subroutines:

    >
    > >    DOMULTIPLY(A,B)=A*B
    > >    ...
    > >    X=DOMULTIPLY(Y,Z)

    >
    > > And function subprograms:

    >
    > >    FUNCTION DOMULTIPLY(A,B)
    > > C Yes, this doesn't handle fractional B's as you'd expect
    > >      DOMULTIPLY=0
    > >      DO 10 I=1,B
    > >    10 DOMULTIPLY=DOMULTIPLY+A
    > >      RETURN
    > >    END
    > >    ...
    > >    X=DOMULTIPLY(Y,Z)

    >
    > thx, Robert, that's syntax I know.
    >
    > I guess what I wonder is why the feature of
    > "always returning avalue"
    > might be considered to be better than a bug.



    Don't know. If there's nothing to return, how would it be better to
    return something meaningless or arbitrary? At least for an imperative
    language like C. A stronger case is obvious for purely functional
    languages, where functions don't have any side effects (and a function
    not returning anything isn't actually doing anything either - although
    there the definition of "returned" ends up being a little different).

    OTOH, always returning a value allows you to call the function from
    within a statement, as opposed to a standalone call, although in C the
    comma operator often allows you to do that anyway. But I'm not sure
    how much utility that actually has.
    , Jan 27, 2011
    #9
    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. PvdK
    Replies:
    0
    Views:
    2,978
  2. wl
    Replies:
    2
    Views:
    581
    Dimitri Maziuk
    Mar 5, 2004
  3. Ganesh Gella
    Replies:
    4
    Views:
    359
    Stuart Gerchick
    Nov 12, 2004
  4. Greenhorn
    Replies:
    15
    Views:
    811
    Keith Thompson
    Mar 6, 2005
  5. Chris Rebert
    Replies:
    1
    Views:
    676
    Bobby
    May 28, 2009
Loading...

Share This Page