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

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

C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion.

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

Contents

  C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Christos Kokaliaris <chrisk.msor@gmail.com> - 2014-06-09 12:12 -0700
    Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Christos Kokaliaris <chrisk.msor@gmail.com> - 2014-06-09 12:41 -0700
      Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Barry Schwarz <schwarzb@dqel.com> - 2014-06-09 13:16 -0700
      Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Tim Rentsch <txr@alumni.caltech.edu> - 2014-06-12 09:08 -0700
        Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. raltbos@xs4all.nl (Richard Bos) - 2014-06-12 16:35 +0000
          Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Tim Rentsch <txr@alumni.caltech.edu> - 2014-06-13 07:27 -0700
            Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-06-14 00:13 +0000
              Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Tim Rentsch <txr@alumni.caltech.edu> - 2014-06-16 07:07 -0700
                Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-06-16 20:04 +0000
                  Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Tim Rentsch <txr@alumni.caltech.edu> - 2014-06-17 08:56 -0700
            Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. raltbos@xs4all.nl (Richard Bos) - 2014-06-16 12:53 +0000
              Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Tim Rentsch <txr@alumni.caltech.edu> - 2014-06-16 08:00 -0700
                Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Kaz Kylheku <kaz@kylheku.com> - 2014-06-16 16:01 +0000
                  Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Tim Rentsch <txr@alumni.caltech.edu> - 2014-06-17 08:24 -0700
                Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. raltbos@xs4all.nl (Richard Bos) - 2014-06-18 10:50 +0000
                  Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Tim Rentsch <txr@alumni.caltech.edu> - 2014-06-26 19:07 -0700
    Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Kaz Kylheku <kaz@kylheku.com> - 2014-06-09 19:51 +0000
    Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-06-09 20:15 +0000
    Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Christos Kokaliaris <chrisk.msor@gmail.com> - 2014-06-09 13:21 -0700
    Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Keith Thompson <kst-u@mib.org> - 2014-06-09 13:39 -0700
      Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-06-09 21:23 +0000
        Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Kaz Kylheku <kaz@kylheku.com> - 2014-06-09 21:43 +0000
          Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-06-10 00:17 +0000
            Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. "BartC" <bc@freeuk.com> - 2014-06-10 11:13 +0100
            Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Keith Thompson <kst-u@mib.org> - 2014-06-10 07:38 -0700
          Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. raltbos@xs4all.nl (Richard Bos) - 2014-06-10 10:23 +0000
            Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Dr Nick <nospam-4@temporary-address.org.uk> - 2014-06-10 18:55 +0100
        Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Keith Thompson <kst-u@mib.org> - 2014-06-09 15:14 -0700
          Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-06-10 00:21 +0000
            Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. James Kuyper <jameskuyper@verizon.net> - 2014-06-09 21:37 -0400
            Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Keith Thompson <kst-u@mib.org> - 2014-06-10 07:45 -0700
              Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Tim Rentsch <txr@alumni.caltech.edu> - 2014-06-11 01:32 -0700
          Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Cal Dershowitz <Cal@example.invalid> - 2014-06-09 23:14 -0700
            Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. raltbos@xs4all.nl (Richard Bos) - 2014-06-10 10:14 +0000
              Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2014-06-10 22:06 +0300
                Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. raltbos@xs4all.nl (Richard Bos) - 2014-06-11 16:16 +0000
                  Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Kaz Kylheku <kaz@kylheku.com> - 2014-06-11 16:47 +0000
                  Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2014-06-11 20:50 +0300
              Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. raltbos@xs4all.nl (Richard Bos) - 2014-06-11 16:16 +0000
            Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2014-06-10 08:23 -0600
            Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Keith Thompson <kst-u@mib.org> - 2014-06-10 10:12 -0700
            Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Tim Rentsch <txr@alumni.caltech.edu> - 2014-06-12 08:39 -0700
              Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Robert Wessel <robertwessel2@yahoo.com> - 2014-06-12 12:30 -0500
          Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Seungbeom Kim <musiphil@bawi.org> - 2014-06-10 23:34 -0700
            Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Tim Rentsch <txr@alumni.caltech.edu> - 2014-06-11 00:35 -0700
            Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Keith Thompson <kst-u@mib.org> - 2014-06-11 08:35 -0700
              Re: C Programming Language 2nd Ed, Exercise 1.9 and 1.12, Solution suggestion. Kaz Kylheku <kaz@kylheku.com> - 2014-06-11 15:49 +0000

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

#45763

Cal Dershowitz <Cal@example.invalid> writes:
> On 6/9/2014 3:14 PM, Keith Thompson wrote:
[...]
>> This program:
>>
>>      int main() {
>>          main(42);
>>      }
>
> Wouldn't the new main interpret 42 as argv[0] in this instance?

As far as the C standard is concerned, the behavior is undefined.

Depending on the calling convention, main(42) *might* do something
equivalent to setting argc (probably not argv[0]) to 42, and probably
putting garbage into the argv pointer -- but since main's definition
doesn't declare argc, it can't refer to it anyway.  There is no
argc or argv in this case.

[...]

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

#45859

Cal Dershowitz <Cal@example.invalid> writes:

> On 6/9/2014 3:14 PM, Keith Thompson wrote:
>> Recursive calls to main are not common, but they're permitted.
>> The same argument applies to parameterless functions other than
>> main.
>
> Am I right that calling main within main is universally shunned?

The problem with calling main recursively is not that it's always
wrong but almost never right.  There are cases where a recursive
call to main is (IMO) reasonable and appropriate, but these are
rare, so for most developers it's natural to view a recursive
calling of main with suspicion.

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

#45867

On Thu, 12 Jun 2014 08:39:32 -0700, Tim Rentsch
<txr@alumni.caltech.edu> wrote:

>Cal Dershowitz <Cal@example.invalid> writes:
>
>> On 6/9/2014 3:14 PM, Keith Thompson wrote:
>>> Recursive calls to main are not common, but they're permitted.
>>> The same argument applies to parameterless functions other than
>>> main.
>>
>> Am I right that calling main within main is universally shunned?
>
>The problem with calling main recursively is not that it's always
>wrong but almost never right.  There are cases where a recursive
>call to main is (IMO) reasonable and appropriate, but these are
>rare, so for most developers it's natural to view a recursive
>calling of main with suspicion.


I actually saw it done once.  A program had been changed to accept a
new style of command line parameters.  If the program detected the old
style, it built a new argv/argc with the old style parameters
translated into the new style, and then called main().  main() then
grew various bits of conditional code to avoid doing certain
initializations and cleanups twice.  It was something of a mess.  We
changed it so the real main did the initialization, translated the
parameters if necessary, and then used those to call internal_main()*
with the consistent parameters.  It removed a fair bit of conditional
code, and frankly made much more sense.

It would have probably been better to avoid the translation, and parse
both styles of input to a common internal format, but that code was
already done and working.


*Not the most creative name, but...

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

#45776

On 2014-06-09 15:14, Keith Thompson wrote:
> 
> The () form in a declaration says that the function takes a fixed but
> unspecified number and type(s) of arguments.  In a definition, it says
> that the function has no parameters, but it still provides a declaration
> with the above meaning.

Can you explain what you mean by the second sentence above?
If it says that the function has no parameters, doesn't it constitute a
declaration that says the same thing? If there exists something that says
a function has no parameters but that is not a declaration, what is it?

The only relevant part I could find in the standard was N1570:6.7.6.3/14:
"An empty list in a function declarator that is part of a definition
of that function specifies that the function has no parameters", but
it doesn't seem to imply that it still provides a declaration that
allows anything but no parameters.

-- 
Seungbeom Kim

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

#45779

Seungbeom Kim <musiphil@bawi.org> writes:

> On 2014-06-09 15:14, Keith Thompson wrote:
>> 
>> The () form in a declaration says that the function takes a fixed
>> but unspecified number and type(s) of arguments.  In a definition,
>> it says that the function has no parameters, but it still provides
>> a declaration with the above meaning.
>
> Can you explain what you mean by the second sentence above?  If it
> says that the function has no parameters, doesn't it constitute a
> declaration that says the same thing?  If there exists something
> that says a function has no parameters but that is not a
> declaration, what is it?  [snip citation 6.7.6.3 p14]

A declaration like this

    int f();

declares a function whose type holds no information about either
the number or types of any parameters (fine point:  except that
we know the function cannot be variadic, since declarations of
variadic functions always need a prototype).

A function definition like this

    int f(){ ... }

defines a function that /in fact/ takes no parameters, but whose
declarator still specifies a type that holds no information about
either the number of types of any parameters.

It may seem strange that even though the function definition
"knows" that the function takes no parameters, it still is the
case that what is declared is a function /whose type/ holds no
information about either the number or types of any parameters,
as clearly the information is available.  But that is in fact
what the C standard prescribes.

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

#45791

Seungbeom Kim <musiphil@bawi.org> writes:
> On 2014-06-09 15:14, Keith Thompson wrote:
>> The () form in a declaration says that the function takes a fixed but
>> unspecified number and type(s) of arguments.  In a definition, it says
>> that the function has no parameters, but it still provides a declaration
>> with the above meaning.
>
> Can you explain what you mean by the second sentence above?
> If it says that the function has no parameters, doesn't it constitute a
> declaration that says the same thing? If there exists something that says
> a function has no parameters but that is not a declaration, what is it?
>
> The only relevant part I could find in the standard was N1570:6.7.6.3/14:
> "An empty list in a function declarator that is part of a definition
> of that function specifies that the function has no parameters", but
> it doesn't seem to imply that it still provides a declaration that
> allows anything but no parameters.

Strange as it seems, the empty parentheses in

    void foo() { /* ... */ }

specify that foo has no parameters, but they don't specify that it takes
no arguments.  (This strangeness is easily avoided by using prototypes
consistently.)

N1570 6.9.1p7:

    The declarator in a function definition specifies the name of the
    function being defined and the identifiers of its parameters. If the
    declarator includes a parameter type list, the list also specifies
    the types of all the parameters; such a declarator also serves as a
    function prototype for later calls to the same function in the same
    translation unit. If the declarator includes an identifier list,
    the types of the parameters shall be declared in a following
    declaration list.

The second sentence says that a definition that includes a parameter
type list, such as:

    void foo(void) { ... }

provides a prototype, equivalent to:

    void foo(void);

which means that, if that definition is visible, any call that passes
one or more arguments is a constraint violation.  Without a parameter
type list, no such prototype is provided, and an incorrect call has
undefined behavior (and needn't be diagnosed).

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

#45792

On 2014-06-11, Keith Thompson <kst-u@mib.org> wrote:
> Seungbeom Kim <musiphil@bawi.org> writes:
>> On 2014-06-09 15:14, Keith Thompson wrote:
>>> The () form in a declaration says that the function takes a fixed but
>>> unspecified number and type(s) of arguments.  In a definition, it says
>>> that the function has no parameters, but it still provides a declaration
>>> with the above meaning.
>>
>> Can you explain what you mean by the second sentence above?
>> If it says that the function has no parameters, doesn't it constitute a
>> declaration that says the same thing? If there exists something that says
>> a function has no parameters but that is not a declaration, what is it?
>>
>> The only relevant part I could find in the standard was N1570:6.7.6.3/14:
>> "An empty list in a function declarator that is part of a definition
>> of that function specifies that the function has no parameters", but
>> it doesn't seem to imply that it still provides a declaration that
>> allows anything but no parameters.
>
> Strange as it seems, the empty parentheses in
>
>     void foo() { /* ... */ }
>
> specify that foo has no parameters, but they don't specify that it takes
> no arguments.

What? No.

It defines a function entity with no parameters, which consequently takes no
arguments.

But the name foo is not *declared* as such: not to the scope within the
braces, nor the subsequent portion of the file scope.

These regions of the program are only informed about the existence of
the name foo which refers to a function.

[toc] | [prev] | [standalone]

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

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

csiph-web