malloc problem

[pete]

Re: malloc problem

Keith Thompson wrote:[color=blue]
>
> Mark McIntyre <markmcintyre@s pamcop.net> writes:[color=green]
> > On 31 Mar 2005 18:04:52 GMT, in comp.lang.c , mwojcik@newsguy .com
> > (Michael Wojcik) wrote:
> >[color=darkred]
> >>That's not how I read 9899-1990 5.1.2.2.1:
> >>
> >> int main(void) { /*...*/ }[/color]
> >
> > this is totally equivalent to
> > int main() {/*...*/}
> >
> > in a function definition.[/color]
>
> I think you're right. C99 6.7.5.3p14 says:
>
> [...] An empty list in a function declarator that is part of a
> definition of that function specifies that the function has no
> parameters. The empty list in a function declarator that is not
> part of a definition of that function specifies that no
> information about the number or types of the parameters is
> supplied.
>
> I had been thinking that int main() would allow mismatched arguments
> on a recursive call to main, but the above shows that I was mistaken.
> I just tried a test case on several compilers, and most of them appear
> to get this wrong as well, issuing no diagnostics for the following:
>
> #include <stdio.h>
>
> void foo()
> {
> printf("In foo\n");
> }
>
> int main()
> {
> foo();
> foo(42);
> return 0;
> }[/color]

Old style function types don't include the parameter types.
int main() is old style.
int main(void) is more better.

--
pete

[Keith Thompson]

Re: malloc problem

pete <pfiland@mindsp ring.com> writes:
[...][color=blue]
> Old style function types don't include the parameter types.
> int main() is old style.
> int main(void) is more better.[/color]

It appears that in the context of a function *definition*, int main()
is exactly equivalent to int main(void).

Nevertheless, I consider int main(void) to be better style. It's more
explicit, it avoid confusion with the use of int main() in function
*declarations* (which is different from int main(void)), and, as I
recently discovered, some compilers don't catch certain errors with ()
that they do catch with (void).

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Michael Wojcik]

Re: malloc problem


In article <f34p411sfsr5ga cptkhl1loig3d52 mid8v@4ax.com>, Mark McIntyre <markmcintyre@s pamcop.net> writes:[color=blue]
> On 31 Mar 2005 18:04:52 GMT, in comp.lang.c , mwojcik@newsguy .com
> (Michael Wojcik) wrote:
>[color=green]
> >That's not how I read 9899-1990 5.1.2.2.1:
> >
> > int main(void) { /*...*/ }[/color]
>
> this is totally equivalent to
> int main() {/*...*/}
>
> in a function definition.[/color]

Indeed it is. However, I'm not talking about "a function definition";
I'm talking about the two forms for main specified by 5.1.2.2.1.
[color=blue][color=green]
> >6.7.1 certainly makes the parameter list optional in general, but
> >ISTM that a conforming implementation could require one of the two
> >forms for main described in 5.1.2.2.1. I don't see anything that
> >requires an implementation to accept "int main()".[/color]
>
> The grammar of the language requires it.[/color]

It does no such thing. There are many, many things permitted by the
grammar but disallowed in conforming code, such as passing a null
pointer to strlen. The grammar permits all sorts of declarations
for main; 5.1.2.2.1 specifically restricts the conforming ones (in
a hosted implementation) to two.

--
Michael Wojcik michael.wojcik@ microfocus.com

Unlikely predition o' the day:
Eventually, every programmer will have to write a Java or distributed
object program.
-- Orfali and Harkey, _Client / Server Programming with Java and CORBA_

[Keith Thompson]

Re: malloc problem

mwojcik@newsguy .com (Michael Wojcik) writes:[color=blue]
> In article <f34p411sfsr5ga cptkhl1loig3d52 mid8v@4ax.com>, Mark
> McIntyre <markmcintyre@s pamcop.net> writes:[color=green]
>> On 31 Mar 2005 18:04:52 GMT, in comp.lang.c , mwojcik@newsguy .com
>> (Michael Wojcik) wrote:
>>[color=darkred]
>> >That's not how I read 9899-1990 5.1.2.2.1:
>> >
>> > int main(void) { /*...*/ }[/color]
>>
>> this is totally equivalent to
>> int main() {/*...*/}
>>
>> in a function definition.[/color]
>
> Indeed it is. However, I'm not talking about "a function definition";
> I'm talking about the two forms for main specified by 5.1.2.2.1.[/color]

Which says:

The function called at program startup is named main. The
implementation declares no prototype for this function. It shall
be defined with a return type of int and with no parameters:

int main(void) { /* ... */ }

or with two parameters (referred to here as argc and argv, though
any names may be used, as they are local to the function in which
they are declared):

int main(int argc, char *argv[]) { /* ... */ }

or equivalent; or in some other implementation-defined manner.

I believe the "or equivalent" covers "int main() {/*...*/}" (though I
still prefer "int main(void) {/*...*/}").

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[pete]

Re: malloc problem

Keith Thompson wrote:[color=blue]
>
> pete <pfiland@mindsp ring.com> writes:
> [...][color=green]
> > Old style function types don't include the parameter types.
> > int main() is old style.
> > int main(void) is more better.[/color]
>
> It appears that in the context of a function *definition*, int main()
> is exactly equivalent to int main(void).[/color]

There's no void in K&R C.

int main() {return 0;}
is a valid C program in K&R C, C89, and C99.

--
pete

[Keith Thompson]

Re: malloc problem

pete <pfiland@mindsp ring.com> writes:[color=blue]
> Keith Thompson wrote:[color=green]
>>
>> pete <pfiland@mindsp ring.com> writes:
>> [...][color=darkred]
>> > Old style function types don't include the parameter types.
>> > int main() is old style.
>> > int main(void) is more better.[/color]
>>
>> It appears that in the context of a function *definition*, int main()
>> is exactly equivalent to int main(void).[/color]
>
> There's no void in K&R C.
>
> int main() {return 0;}
> is a valid C program in K&R C, C89, and C99.[/color]

Sure, but C89 (unlike C99) is sufficiently widely implemented that we
can assume at least C89 for purposes of this newsgroup. (I think the
latest versions of gcc can't even be bootstrapped with a pre-C89
compiler.)

Writing int main() rather than int main(void) to satisfy K&R C
compilers is, in my opinion, no longer worth the effort.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[pete]

Re: malloc problem

Keith Thompson wrote:[color=blue]
>
> pete <pfiland@mindsp ring.com> writes:[color=green]
> > Keith Thompson wrote:[color=darkred]
> >>
> >> pete <pfiland@mindsp ring.com> writes:
> >> [...]
> >> > Old style function types don't include the parameter types.
> >> > int main() is old style.
> >> > int main(void) is more better.
> >>
> >> It appears that in the context of a function *definition*, int main()
> >> is exactly equivalent to int main(void).[/color]
> >
> > There's no void in K&R C.
> >
> > int main() {return 0;}
> > is a valid C program in K&R C, C89, and C99.[/color]
>
> Sure, but C89 (unlike C99) is sufficiently widely implemented that we
> can assume at least C89 for purposes of this newsgroup. (I think the
> latest versions of gcc can't even be bootstrapped with a pre-C89
> compiler.)
>
> Writing int main() rather than int main(void) to satisfy K&R C
> compilers is, in my opinion, no longer worth the effort.[/color]

That's what I think too.

--
pete

[Peter Nilsson]

Re: malloc problem

Keith Thompson wrote:[color=blue]
> pete <pfiland@mindsp ring.com> writes:
> [...][color=green]
> > Old style function types don't include the parameter types.
> > int main() is old style.
> > int main(void) is more better.[/color]
>
> It appears that in the context of a function *definition*, int main()
> is exactly equivalent to int main(void).
>
> Nevertheless, I consider int main(void) to be better style. It's[/color]
more[color=blue]
> explicit, it avoid confusion with the use of int main() in function
> *declarations* (which is different from int main(void)), and, as I
> recently discovered, some compilers don't catch certain errors with[/color]
()[color=blue]
> that they do catch with (void).[/color]

Personally, the sooner non-prototype function declarations are removed
from C, the better. I have no problem with () meaning _explicitly_ that
a function that takes no parameters. Certainly, C++ programmers don't.

--
Peter

[Joe Estock]

Re: malloc problem

Peter Nilsson wrote:[color=blue]
> Keith Thompson wrote:
>[color=green]
>>pete <pfiland@mindsp ring.com> writes:
>>[...]
>>[color=darkred]
>>>Old style function types don't include the parameter types.
>>>int main() is old style.
>>>int main(void) is more better.[/color]
>>
>>It appears that in the context of a function *definition*, int main()
>>is exactly equivalent to int main(void).
>>
>>Nevertheles s, I consider int main(void) to be better style. It's[/color]
>
> more
>[color=green]
>>explicit, it avoid confusion with the use of int main() in function
>>*declarations * (which is different from int main(void)), and, as I
>>recently discovered, some compilers don't catch certain errors with[/color]
>
> ()
>[color=green]
>>that they do catch with (void).[/color]
>
>
> Personally, the sooner non-prototype function declarations are removed
> from C, the better. I have no problem with () meaning _explicitly_ that
> a function that takes no parameters. Certainly, C++ programmers don't.
>[/color]
Yes, but this is not c++, this is c.

Joe Estock

[Keith Thompson]

Re: malloc problem

"Peter Nilsson" <airia@acay.com .au> writes:
[...][color=blue]
> Personally, the sooner non-prototype function declarations are removed
> from C, the better. I have no problem with () meaning _explicitly_ that
> a function that takes no parameters. Certainly, C++ programmers don't.[/color]

If the language were being designed from scratch today, certainly it
would make sense for () to mean that the function takes no parameters.
But it already has a well-defined (though perhaps obsolescent) meaning.

Removing non-prototype function declarations from the language would
break existing code. Even assuming that's tolerable, changing the
existing meaning of () could make it more difficult to generate good
diagnostics for old code.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[pete]

Re: malloc problem

pete wrote:[color=blue]
>
> Keith Thompson wrote:[color=green]
> >
> > pete <pfiland@mindsp ring.com> writes:[color=darkred]
> > > Keith Thompson wrote:
> > >>
> > >> pete <pfiland@mindsp ring.com> writes:
> > >> [...]
> > >> > Old style function types don't include the parameter types.
> > >> > int main() is old style.
> > >> > int main(void) is more better.
> > >>
> > >> It appears that in the context of a function *definition*,
> > >> int main()
> > >> is exactly equivalent to int main(void).
> > >
> > > There's no void in K&R C.
> > >
> > > int main() {return 0;}
> > > is a valid C program in K&R C, C89, and C99.[/color]
> >
> > Sure,
> > but C89 (unlike C99) is sufficiently widely implemented that we
> > can assume at least C89 for purposes of this newsgroup.
> > (I think the
> > latest versions of gcc can't even be bootstrapped with a pre-C89
> > compiler.)
> >
> > Writing int main() rather than int main(void) to satisfy K&R C
> > compilers is, in my opinion, no longer worth the effort.[/color]
>
> That's what I think too.[/color]

Here's what I was looking for:

N869
Introduction

[#2] Certain features are obsolescent, which means that they
may be considered for withdrawal in future revisions of this
International Standard. They are retained because of their
widespread use, but their use in new implementations (for
implementation features) or new programs (for language
[6.11] or library features [7.26]) is discouraged.

6.11 Future language directions

6.11.4 Function declarators
[#1] The use of function declarators with empty parentheses
(not prototype-format parameter type declarators) is an
obsolescent feature.

6.11.5 Function definitions
[#1] The use of function definitions with separate parameter
identifier and declaration lists (not prototype-format
parameter type and identifier declarators) is an obsolescent
feature.

--
pete