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

#45713

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

(snip)

> I just checked, and K&R2 actually uses the old "main()" form in its
> examples.  I'd call that a minor flaw in an otherwise very good book,
> and I wouldn't reject K&R2 for that reason.
 
> The empty parentheses are also obsolescent, and have been since the 1989
> ANSI C standard.  The preferred way to define the main function is:
 
>    int main(void) { /* ... */ }
 
> I've never seen a compiler that would complain about "int main()", but
> "int main(void)" is more explicit (and, I've argued, more clearly valid).
 

Writing in both C and Java, I might be a little more sensitive to
the differences between them.

Since C's main is supposed to have arguments (usually argc and argv)
but it is usual not to put them in if I am not using them, I prefer
the () form, with the (void) form when there are never any arguments.

That is unlike Java, where the argument signatures (I think that
is what they call them) must match. 

To allow for varargs, most calling conventions used with C allow
for fewer arguments. As well as I know it, strictly that is only
allowed for actual varargs functions. Different calling conventions
could be used for varargs and non-varargs, but usually aren't.

I haven't looked yet how Java does System.out.format(),
though I use it more and more in my Java programs.

-- glen

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

#45718

On 2014-06-09, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> Keith Thompson <kst-u@mib.org> wrote:
>
> (snip)
>
>> I just checked, and K&R2 actually uses the old "main()" form in its
>> examples.  I'd call that a minor flaw in an otherwise very good book,
>> and I wouldn't reject K&R2 for that reason.
>  
>> The empty parentheses are also obsolescent, and have been since the 1989
>> ANSI C standard.  The preferred way to define the main function is:
>  
>>    int main(void) { /* ... */ }
>  
>> I've never seen a compiler that would complain about "int main()", but
>> "int main(void)" is more explicit (and, I've argued, more clearly valid).
>  
>
> Writing in both C and Java, I might be a little more sensitive to
> the differences between them.
>
> Since C's main is supposed to have arguments (usually argc and argv)
> but it is usual not to put them in if I am not using them, I prefer
> the () form, with the (void) form when there are never any arguments.

Then use C++ as a "better C". In C++, () means (void).

This is in part thanks to Dennis Ritchie.

You see, in the "C With Classes" language, Stroustrup introduced the (void)
hack, so that () could remain C compatible. Some users hated it, and
evidently DMR and Doug McIlroy called it an abomination:

  "I abandoned the use of void as an argument type meaning "no arguments" after
  Dennis Ritchie and Doug McIlroy strongly condemned it as "an abomination."
  Instead, I adopted the obvious notation for taking no arguments, an empty
  pair of parentheses."

  ["Sibling Rivalry: C and C++", 2.4, Stroustrup,
  http://www.stroustrup.com/sibling_rivalry.pdf ]

See, Ritchie was very sensible; he acknowledged bad things and repented.
Once we have a C like dialect with prototypes, to hell with () meaning
"no type info"!

> That is unlike Java, where the argument signatures (I think that
> is what they call them) must match.

C++ later came to support, but not required (void) in order to be compatible
with ANSI C, which adopted this convention.

> To allow for varargs, most calling conventions used with C allow
> for fewer arguments.

varargs is historic; nobody should care about about that any more.

Aldo, the type looseness in C came first, then the varargs hack!

That is to say, I don't suspect C was designed specifically to allow
things like that ("let's not have declarations of arguments so there
can be a mismatch"); coe like that just worked.

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

#45729

Kaz Kylheku <kaz@kylheku.com> wrote:

(snip, I wrote)

>> Since C's main is supposed to have arguments (usually argc and argv)
>> but it is usual not to put them in if I am not using them, I prefer
>> the () form, with the (void) form when there are never any arguments.

(snip)

>  "I abandoned the use of void as an argument type meaning 
> "no arguments" after Dennis Ritchie and Doug McIlroy strongly 
> condemned it as "an abomination." Instead, I adopted the obvious 
> notation for taking no arguments, an empty pair of parentheses."
 
>  ["Sibling Rivalry: C and C++", 2.4, Stroustrup,
>  http://www.stroustrup.com/sibling_rivalry.pdf ]
 
(snip)

> C++ later came to support, but not required (void) in order 
> to be compatible with ANSI C, which adopted this convention.

(snip, I also wrote)
 
>> To allow for varargs, most calling conventions used with C allow
>> for fewer arguments.
 
> varargs is historic; nobody should care about about that any more.
 
> Aldo, the type looseness in C came first, then the varargs hack!

It is all intel's fault.  All the calling conventions that I knew
before the 8086 ignored extra arguments. 

The 8086 has a RET n instruction that will pop bytes off the
stack at the same time as returning. Saves one instruction
(per call) and a few cycles. It worked fine with the Pascal and
Fortran compilers that were used early in the 8086 MSDOS years.

But it only works when you are sure you know how many arguments
there are.

> That is to say, I don't suspect C was designed specifically to allow
> things like that ("let's not have declarations of arguments so there
> can be a mismatch"); coe like that just worked.

As well as I know it, ANSI C allows a different calling convention
for functions that never have variable argument lists, maybe
even STDCALL, but no-one does that. Much better to have the caller
pop the arguments.

-- glen

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

#45745

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 
news:ln5iq5$1n9$1@speranza.aioe.org...
> Kaz Kylheku <kaz@kylheku.com> wrote:

>> varargs is historic; nobody should care about about that any more.
>
>> Aldo, the type looseness in C came first, then the varargs hack!
>
> It is all intel's fault.  All the calling conventions that I knew
> before the 8086 ignored extra arguments.
>
> The 8086 has a RET n instruction that will pop bytes off the
> stack at the same time as returning. Saves one instruction
> (per call) and a few cycles. It worked fine with the Pascal and
> Fortran compilers that were used early in the 8086 MSDOS years.
>
> But it only works when you are sure you know how many arguments
> there are.
>
>> That is to say, I don't suspect C was designed specifically to allow
>> things like that ("let's not have declarations of arguments so there
>> can be a mismatch"); coe like that just worked.
>
> As well as I know it, ANSI C allows a different calling convention
> for functions that never have variable argument lists, maybe
> even STDCALL, but no-one does that. Much better to have the caller
> pop the arguments.

Didn't you just say that it's better the other way because it's one less 
instruction?

99% of the time, the number of arguments will be fixed. It's only for 
calling functions such as the printf family that variable argument lists are 
needed at all (because C doesn't have special arrangements for i/o).

And there are other ways of dealing with variable numbers of arguments than 
requiring the caller to pop the stack.

(Which doesn't even work very well; try: printf("%s %s"), or printf(fmt) 
where fmt is defined elsewhere, which won't give warnings.)

(It can also be a nuisance when calling a C-function from a language where 
the argument-pushing, and the call, are independent:
      call pushparams
      call [fnaddr]
      add esp,... what?)

-- 
bartc
 

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

#45754

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
[...]
> As well as I know it, ANSI C allows a different calling convention
> for functions that never have variable argument lists, maybe
> even STDCALL, but no-one does that. Much better to have the caller
> pop the arguments.

(Your use of the word "never" could imply that some functions might
*sometimes* have variable argument lists.  A given function either
does or does not have a variable argument list, depending on whether
it's defined with ", ...".)

Yes, the standard permits variadic and non-variadic functions to
have different calling conventions.  It doesn't discuss calling
conventions, but it expresses this by saying that a call to a
variadic function without a visible and correct prototype has
undefined behavior.  And STDCALL is not mentioned in the standard.

The ", ..." syntax for variadic functions was introduced by the
1989 ANSI standard, and many calling conventions predate that, so
most calling conventions happen to have the property that calling
a variadic function with no visible prototype will happen to work.
A newly defined calling convention could easily break that, but
designers will likely try to avoid breaking existing code -- even
if that code's behavior is undefined

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

#45748

Kaz Kylheku <kaz@kylheku.com> wrote:

> Then use C++ as a "better C".

That's like using Valspeak as a "better English". Like, gag me with a
compiler.

Richard

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

#45764

raltbos@xs4all.nl (Richard Bos) writes:

> Kaz Kylheku <kaz@kylheku.com> wrote:
>
>> Then use C++ as a "better C".
>
> That's like using Valspeak as a "better English". Like, gag me with a
> compiler.

Combine the two: program in VALGOL.

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

#45720

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> wrote:
>
> (snip)
>
>> I just checked, and K&R2 actually uses the old "main()" form in its
>> examples.  I'd call that a minor flaw in an otherwise very good book,
>> and I wouldn't reject K&R2 for that reason.
>  
>> The empty parentheses are also obsolescent, and have been since the 1989
>> ANSI C standard.  The preferred way to define the main function is:
>  
>>    int main(void) { /* ... */ }
>  
>> I've never seen a compiler that would complain about "int main()", but
>> "int main(void)" is more explicit (and, I've argued, more clearly valid).
>  
>
> Writing in both C and Java, I might be a little more sensitive to
> the differences between them.
>
> Since C's main is supposed to have arguments (usually argc and argv)
> but it is usual not to put them in if I am not using them, I prefer
> the () form, with the (void) form when there are never any arguments.

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.

The () form is obsolescent, both for declarations and for definitions,
and has been since 1989.

The (void) form specifies that the function has no parameters.

This program:

    int main() {
        main(42);
    }

will typically not elicit a diagnostic from the compiler.  In this program:

    int main(void) {
        main(42);
    }

the call violates a constraint, and it must be diagnosed.

Recursive calls to main are not common, but they're permitted.  The same
argument applies to parameterless functions other than main.

What advantage do you see in using "int main()" rather than
"int main(void)"?  I see none at all.

> That is unlike Java, where the argument signatures (I think that
> is what they call them) must match. 

I'd say it's a mistake to base your C coding style on Java.  (I'm not
sure that's what you're doing.)

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

#45730

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

(snip, I wrote)

>> Writing in both C and Java, I might be a little more sensitive to
>> the differences between them.

(snip)

> 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.
 
> The () form is obsolescent, both for declarations and for definitions,
> and has been since 1989.

But not yet removed from the standard?
 
> The (void) form specifies that the function has no parameters.
 
> This program:
 
>    int main() {
>        main(42);
>    }
 
> will typically not elicit a diagnostic from the compiler.  In this program:
 
>    int main(void) {
>        main(42);
>    }
 
> the call violates a constraint, and it must be diagnosed.
 
> Recursive calls to main are not common, but they're permitted.  The same
> argument applies to parameterless functions other than main.

I have seen them, but never found a use for it.
 
> What advantage do you see in using "int main()" rather than
> "int main(void)"?  I see none at all.

A few less characters to type. Well, I started C in the K&R days,
though maybe not by much. About 1985 or so.
 
>> That is unlike Java, where the argument signatures (I think that
>> is what they call them) must match. 
 
> I'd say it's a mistake to base your C coding style on Java.  
> (I'm not sure that's what you're doing.)

I suspect my Java programs look more C-like than the other way around.

If you haven't looked at Java lately, look at System.out.format().


-- glen

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

#45732

On 06/09/2014 08:21 PM, glen herrmannsfeldt wrote:
> Keith Thompson <kst-u@mib.org> wrote:
...
>> The () form is obsolescent, both for declarations and for definitions,
>> and has been since 1989.
> 
> But not yet removed from the standard?

Yes, as he said - it's obsolescent, not obsolete.
-- 
James Kuyper

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

#45755

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> wrote:
>
> (snip, I wrote)
>
>>> Writing in both C and Java, I might be a little more sensitive to
>>> the differences between them.
>
> (snip)
>
>> 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.
>  
>> The () form is obsolescent, both for declarations and for definitions,
>> and has been since 1989.
>
> But not yet removed from the standard?

Correct, but notice is given that it could be removed from a future
version of the standard.

[...]

>> Recursive calls to main are not common, but they're permitted.  The same
>> argument applies to parameterless functions other than main.
>
> I have seen them, but never found a use for it.

Are you referring to recursive calls to main?

The argument is more general than that.  If you use empty parentheses
for parameterless functions other than main, then the issue of recursive
calls to main doesn't matter.

Using () rather than (void) on a *declaration* means that the compiler
needn't (and typically won't) diagnose calls with one or more arguments.
Using () on a *definition* is mostly harmless -- unless calls rely on
the declaration provided by the definition.  I suppose you could
consistently use () on definitions on (void) on declarations (while
being very careful to *always* provide a separate declaration), but it's
a lot easier to be consistent.

>> What advantage do you see in using "int main()" rather than
>> "int main(void)"?  I see none at all.
>
> A few less characters to type. Well, I started C in the K&R days,
> though maybe not by much. About 1985 or so.

I consider that to be no advantage at all.  In 1985, the void keyword
didn't exist.  It's time to start using it.

>>> That is unlike Java, where the argument signatures (I think that
>>> is what they call them) must match. 
>  
>> I'd say it's a mistake to base your C coding style on Java.  
>> (I'm not sure that's what you're doing.)
>
> I suspect my Java programs look more C-like than the other way around.
>
> If you haven't looked at Java lately, look at System.out.format().

Why?

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

#45780

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

> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> wrote:
>>
>> (snip, I wrote)
>>
>>>> Writing in both C and Java, I might be a little more sensitive to
>>>> the differences between them.
>>
>> (snip)
>>
>>> 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.
>>  
>>> The () form is obsolescent, both for declarations and for
>>> definitions, and has been since 1989.
>>
>> But not yet removed from the standard?
>
> Correct, but notice is given that it could be removed from a future
> version of the standard.

I think it's worth pointing out that this language feature (along
with several others) is listed as obsolescent but not currently
listed as deprecated.  Being listed as obsolescent means a feature
may be considered for withdrawal in a future revision, but IIUC
normally first goes through a revision cycle (or possibly more
than one, that may depend) where it is not yet removed but just
marked deprecated.  In practical terms none of the half dozen
or so language features listed as obsolescent is going to go
away any time soon, and pretty likely not ever.

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

#45735

On 6/9/2014 3:14 PM, Keith Thompson wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> wrote:
>>
>> (snip)
>>
>>> I just checked, and K&R2 actually uses the old "main()" form in its
>>> examples.  I'd call that a minor flaw in an otherwise very good book,
>>> and I wouldn't reject K&R2 for that reason.
>>
>>> The empty parentheses are also obsolescent, and have been since the 1989
>>> ANSI C standard.  The preferred way to define the main function is:
>>
>>>     int main(void) { /* ... */ }
>>
>>> I've never seen a compiler that would complain about "int main()", but
>>> "int main(void)" is more explicit (and, I've argued, more clearly valid).

This is where it stops for me, and I agree.
>>
>>
>> Writing in both C and Java, I might be a little more sensitive to
>> the differences between them.
>>
>> Since C's main is supposed to have arguments (usually argc and argv)
>> but it is usual not to put them in if I am not using them, I prefer
>> the () form, with the (void) form when there are never any arguments.
>
> 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.
>
> The () form is obsolescent, both for declarations and for definitions,
> and has been since 1989.
>
> The (void) form specifies that the function has no parameters.
>
> This program:
>
>      int main() {
>          main(42);
>      }

Wouldn't the new main interpret 42 as argv[0] in this instance?
>
> will typically not elicit a diagnostic from the compiler.  In this program:
>
>      int main(void) {
>          main(42);
>      }
>
> the call violates a constraint, and it must be diagnosed.
>
> 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?
>
> What advantage do you see in using "int main()" rather than
> "int main(void)"?  I see none at all.
>
>> That is unlike Java, where the argument signatures (I think that
>> is what they call them) must match.
>
> I'd say it's a mistake to base your C coding style on Java.  (I'm not
> sure that's what you're doing.)
>

Glen cobbles things together using whatever tools he has. Java might be 
on the opposite end of where C is with object orientation.
-- 
Cal Dershowitz

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

#45746

Cal Dershowitz <Cal@example.invalid> wrote:

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

What new main, and what argv[0]? There is no new main; the old main()
simply calls itself. And, clearly, that main does not even consider
anything called "argv[0]".

> > will typically not elicit a diagnostic from the compiler.  In this program:
> >
> >      int main(void) {
> >          main(42);
> >      }
> >
> > the call violates a constraint, and it must be diagnosed.
> >
> > 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?

Shunned is slightly too strong. _Slightly_. You'd have to have a very
good reason to use it. It's not _as_ bad as gets(), but certainly worse
than goto. goto can be put to good use in, e.g., a state machine, and
only Lisps advocates and Pascal users would complain, but it should be
avoided unless it's necessary. A recursive call to main() is in the same
boat, except that good uses for it are even less common. gets(), by
contrast, is _never_ the right choice, and should indeed be shunned.

Richard

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

#45765

raltbos@xs4all.nl (Richard Bos) writes:
> > Am I right that calling main within main is universally shunned?

It goes down fairly well in the IOCCC.
 
> Shunned is slightly too strong. _Slightly_. You'd have to have a very
> good reason to use it. It's not _as_ bad as gets(), but certainly worse
> than goto. goto can be put to good use in, e.g., a state machine, and
> only Lisps advocates and Pascal users would complain,

Lisp had GOTO before C's parents had even met each other.

Phil
-- 
Religion is too important a matter to its devotees to be a subject of 
ridicule. If they indulge in absurdities, they are to be pitied rather
than ridiculed. -- Immanuel Kant (1724-1804), lecture at Konigsberg, 1775

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

#45793

Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:

> raltbos@xs4all.nl (Richard Bos) writes:
> > Shunned is slightly too strong. _Slightly_. You'd have to have a very
> > good reason to use it. It's not _as_ bad as gets(), but certainly worse
> > than goto. goto can be put to good use in, e.g., a state machine, and
> > only Lisps advocates and Pascal users would complain,
> 
> Lisp had GOTO before C's parents had even met each other.

Yeah, but don't tell a Lisp advocate that. Advocate as opposed to normal
user - you know the kind, claims that there hasn't been a good
programming language since Lisp (even Scheme is a bit dodgy), you can't
do anything in C that you can't do better in Lisp, you can't do tail
recursion in an assembler language like C (don't need to, he should say,
and anyway it's wrong), and anyway GOTO is dirty. Why would you accuse
Lisp of having GOTO? Lisp is the only structured programming language in
the world! It's dirty hacks like C which use GOTO!!!!!1!

Yah. That kind. Don't cross-post...

Richard

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

#45798

On 2014-06-11, Richard Bos <raltbos@xs4all.nl> wrote:
> Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
>
>> raltbos@xs4all.nl (Richard Bos) writes:
>> > Shunned is slightly too strong. _Slightly_. You'd have to have a very
>> > good reason to use it. It's not _as_ bad as gets(), but certainly worse
>> > than goto. goto can be put to good use in, e.g., a state machine, and
>> > only Lisps advocates and Pascal users would complain,
>> 
>> Lisp had GOTO before C's parents had even met each other.
>
> Yeah, but don't tell a Lisp advocate that. Advocate as opposed to normal
> user - you know the kind, claims that there hasn't been a good
> programming language since Lisp (even Scheme is a bit dodgy), you can't
> do anything in C that you can't do better in Lisp, you can't do tail
> recursion in an assembler language like C (don't need to, he should say,
> and anyway it's wrong), and anyway GOTO is dirty.

Every decent Common Lisp advocate I know (including myself) touts
TAGBODY/PROG and GO as useful features, and in fact the best representation for
certain problems, and a necessary target target language for making certain
kinds of macros as efficient as possible.

Implementations of the ANSI CL LOOP macro usually make use of GO.

> Why would you accuse
> Lisp of having GOTO? Lisp is the only structured programming language in
> the world! It's dirty hacks like C which use GOTO!!!!!1!

Ah, that sounds more like a Scheme advocate than a Lisp advocate.

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

#45801

raltbos@xs4all.nl (Richard Bos) writes:
> Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
> 
> > raltbos@xs4all.nl (Richard Bos) writes:
> > > Shunned is slightly too strong. _Slightly_. You'd have to have a very
> > > good reason to use it. It's not _as_ bad as gets(), but certainly worse
> > > than goto. goto can be put to good use in, e.g., a state machine, and
> > > only Lisps advocates and Pascal users would complain,
> > 
> > Lisp had GOTO before C's parents had even met each other.
> 
> Yeah, but don't tell a Lisp advocate that. Advocate as opposed to normal
> user - you know the kind, claims that there hasn't been a good
> programming language since Lisp (even Scheme is a bit dodgy), you can't
> do anything in C that you can't do better in Lisp, you can't do tail
> recursion in an assembler language like C (don't need to, he should say,
> and anyway it's wrong), and anyway GOTO is dirty. Why would you accuse
> Lisp of having GOTO? Lisp is the only structured programming language in
> the world! It's dirty hacks like C which use GOTO!!!!!1!
> 
> Yah. That kind. Don't cross-post...

I think a lot of the funcy language proponents are cut from
the same mould, I've certainly seen some of the above in my
time. At least one of those statements is one I have said
myself, and would again. Then again, I only learnt that lisps
had gotos a decades after I'd last programmed in the language,
having learnt it ('t', a scheme dialect) as part of my 
mathematics degree (before I'd learnt C), where predictably
we focussed on the "purer" aspects of language. I had a rose
tinted view of the language family, and was shocked by what
I later learnt.

Phil
-- 
Religion is too important a matter to its devotees to be a subject of 
ridicule. If they indulge in absurdities, they are to be pitied rather
than ridiculed. -- Immanuel Kant (1724-1804), lecture at Konigsberg, 1775

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

#45795

ram@zedat.fu-berlin.de (Stefan Ram) wrote:

> raltbos@xs4all.nl (Richard Bos) writes:

> >>Am I right that calling main within main is universally shunned?
> >Shunned is slightly too strong. _Slightly_. You'd have to have a very
> 
>   It's alright in C, but explicitly forbidden in C++. (One more reason
>   not to claim that any valid C program is a valid C++ program.)

Well. It's _allowed_ in C. It's not exactly popular. I wouldn't shout at
someone who finds a serious use for it as I would at someone using
gets(), but I would blink a bit.

Richard

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

#45753

Cal Dershowitz <Cal@example.invalid> writes:

> On 6/9/2014 3:14 PM, Keith Thompson wrote:
>> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>> Keith Thompson <kst-u@mib.org> wrote:
>>>
>>> (snip)
>>>
>>>> I just checked, and K&R2 actually uses the old "main()" form in its
>>>> examples.  I'd call that a minor flaw in an otherwise very good book,
>>>> and I wouldn't reject K&R2 for that reason.
>>>
>>>> The empty parentheses are also obsolescent, and have been since the 1989
>>>> ANSI C standard.  The preferred way to define the main function is:
>>>
>>>>     int main(void) { /* ... */ }
>>>
>>>> I've never seen a compiler that would complain about "int main()", but
>>>> "int main(void)" is more explicit (and, I've argued, more clearly valid).
>
> This is where it stops for me, and I agree.
>>>
>>>
>>> Writing in both C and Java, I might be a little more sensitive to
>>> the differences between them.
>>>
>>> Since C's main is supposed to have arguments (usually argc and argv)
>>> but it is usual not to put them in if I am not using them, I prefer
>>> the () form, with the (void) form when there are never any arguments.
>>
>> 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.
>>
>> The () form is obsolescent, both for declarations and for definitions,
>> and has been since 1989.
>>
>> The (void) form specifies that the function has no parameters.
>>
>> This program:
>>
>>      int main() {
>>          main(42);
>>      }
>
> Wouldn't the new main interpret 42 as argv[0] in this instance?

What "new" main?  The only main() in the program is the one right there,
which doesn't have an arrgv parameter.

>> will typically not elicit a diagnostic from the compiler.  In this program:
>>
>>      int main(void) {
>>          main(42);
>>      }
>>
>> the call violates a constraint, and it must be diagnosed.
>>
>> 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?

Pretty close (if I were to say "yes", I'm sure somebody would come up
with some obscure example where it might be marginally useful).

>> What advantage do you see in using "int main()" rather than
>> "int main(void)"?  I see none at all.
>>
>>> That is unlike Java, where the argument signatures (I think that
>>> is what they call them) must match.
>>
>> I'd say it's a mistake to base your C coding style on Java.  (I'm not
>> sure that's what you're doing.)
>>
>
> Glen cobbles things together using whatever tools he has. Java might
> be on the opposite end of where C is with object orientation.

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

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

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

csiph-web