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

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

disadvantages of using old parameter syntax?

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

Contents

  disadvantages of using old parameter syntax? Anonymous Shadow <rocket.penguin@riseup.net> - 2015-09-04 20:46 +0800
    Re: disadvantages of using old parameter syntax? Anonymous Shadow <rocket.penguin@riseup.net> - 2015-09-04 20:49 +0800
      Re: disadvantages of using old parameter syntax? raltbos@xs4all.nl (Richard Bos) - 2015-09-04 16:19 +0000
    Re: disadvantages of using old parameter syntax? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-04 10:10 -0400
      Re: disadvantages of using old parameter syntax? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-08 17:07 -0700
        Re: disadvantages of using old parameter syntax? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-09 01:57 +0100
          Re: disadvantages of using old parameter syntax? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-08 18:09 -0700
            Re: disadvantages of using old parameter syntax? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-09 02:47 +0100
              Re: disadvantages of using old parameter syntax? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-08 19:34 -0700
                Re: disadvantages of using old parameter syntax? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-09 12:07 +0100
            Re: disadvantages of using old parameter syntax? David Brown <david.brown@hesbynett.no> - 2015-09-09 13:18 +0200
    Re: disadvantages of using old parameter syntax? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-04 07:23 -0700
      Re: disadvantages of using old parameter syntax? mark.bluemel@gmail.com - 2015-09-04 07:45 -0700
      Re: disadvantages of using old parameter syntax? David Brown <david.brown@hesbynett.no> - 2015-09-05 14:59 +0200
        Re: disadvantages of using old parameter syntax? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-07 13:26 -0700
          Re: disadvantages of using old parameter syntax? David Brown <david.brown@hesbynett.no> - 2015-09-08 08:51 +0200
        Re: (Not) discussing C-like toy languages Noob <root@127.0.0.1> - 2015-09-08 13:35 +0200
          Re: (Not) discussing C-like toy languages David Brown <david.brown@hesbynett.no> - 2015-09-08 13:59 +0200
            Re: (Not) discussing C-like toy languages gazelle@shell.xmission.com (Kenny McCormack) - 2015-09-08 12:35 +0000
              Re: (Not) discussing C-like toy languages Noob <root@127.0.0.1> - 2015-09-08 17:55 +0200
                Re: (Not) discussing C-like toy languages James Kuyper <jameskuyper@verizon.net> - 2015-09-08 13:11 -0400
                  Re: (Not) discussing C-like toy languages "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-08 10:19 -0700
                  Re: (Not) discussing C-like toy languages Noob <root@127.0.0.1> - 2015-09-08 21:31 +0200
                    Re: (Not) discussing C-like toy languages Richard Heathfield <rjh@cpax.org.uk> - 2015-09-08 20:33 +0100
                      Re: (Not) discussing C-like toy languages David Brown <david.brown@hesbynett.no> - 2015-09-08 22:56 +0200
                      Re: (Not) discussing C-like toy languages raltbos@xs4all.nl (Richard Bos) - 2015-09-20 19:31 +0000
                        Re: (Not) discussing C-like toy languages James Kuyper <jameskuyper@verizon.net> - 2015-09-20 16:09 -0400
                          Re: (Not) discussing C-like toy languages Morris Dovey <mrdovey@iedu.com> - 2015-09-21 18:51 -0500
                        Re: (Not) discussing C-like toy languages Richard Heathfield <rjh@cpax.org.uk> - 2015-09-20 21:27 +0100
                  Re: (Not) discussing C-like toy languages David Brown <david.brown@hesbynett.no> - 2015-09-08 22:52 +0200
                    Re: (Not) discussing C-like toy languages Richard Heathfield <rjh@cpax.org.uk> - 2015-09-08 21:59 +0100
                    Re: (Not) discussing C-like toy languages raltbos@xs4all.nl (Richard Bos) - 2015-09-20 19:31 +0000
                      Re: (Not) discussing C-like toy languages Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-20 13:54 -0700
              Re: (Not) discussing C-like toy languages Gareth Owen <gwowen@gmail.com> - 2015-09-08 21:28 +0100
          Re: (Not) discussing C-like toy languages James Kuyper <jameskuyper@verizon.net> - 2015-09-08 10:56 -0400
            Re: (Not) discussing C-like toy languages Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-08 08:33 -0700
              Re: (Not) discussing C-like toy languages fir <profesor.fir@gmail.com> - 2015-09-08 09:12 -0700
                Re: (Not) discussing C-like toy languages "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-08 09:18 -0700
                  Re: (Not) discussing C-like toy languages fir <profesor.fir@gmail.com> - 2015-09-08 10:15 -0700
            Re: (Not) discussing C-like toy languages "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-08 08:38 -0700
            Re: (Not) discussing C-like toy languages luser droog <luser.droog@gmail.com> - 2015-09-08 16:50 -0700
              Re: (Not) discussing C-like toy languages James Kuyper <jameskuyper@verizon.net> - 2015-09-08 21:24 -0400
                Re: (Not) discussing C-like toy languages luser droog <luser.droog@gmail.com> - 2015-09-11 08:45 -0700
                  Re: (Not) discussing C-like toy languages "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-11 08:54 -0700
                    Re: (Not) discussing C-like toy languages luser droog <luser.droog@gmail.com> - 2015-09-11 21:22 -0700
                    Re: (Not) discussing C-like toy languages Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-13 06:42 +0000
                      Re: (Not) discussing C-like toy languages "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-12 23:54 -0700
                        Re: (Not) discussing C-like toy languages Les Cargill <lcargill99@comcast.com> - 2015-09-13 10:41 -0500
                          Re: (Not) discussing C-like toy languages "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-13 09:52 -0700
                            Re: (Not) discussing C-like toy languages Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-13 20:27 +0000
                            Re: (Not) discussing C-like toy languages Les Cargill <lcargill99@comcast.com> - 2015-09-14 21:32 -0500
                          Re: (Not) discussing C-like toy languages "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-13 09:55 -0700
                            Re: (Not) discussing C-like toy languages Ian Collins <ian-news@hotmail.com> - 2015-09-14 09:07 +1200
                              Re: (Not) discussing C-like toy languages "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-09-13 14:23 -0700
                                Re: (Not) discussing C-like toy languages Ian Collins <ian-news@hotmail.com> - 2015-09-14 09:31 +1200
                                  Re: (Not) discussing C-like toy languages "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-09-13 14:33 -0700
                                    Re: (Not) discussing C-like toy languages Ian Collins <ian-news@hotmail.com> - 2015-09-14 09:40 +1200
                                      Re: (Not) discussing C-like toy languages "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-09-13 15:05 -0700
                                    Re: (Not) discussing C-like toy languages David Brown <david.brown@hesbynett.no> - 2015-09-14 00:10 +0200
                                    Re: (Not) discussing C-like toy languages Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-13 17:16 -0700
                                Re: (Not) discussing C-like toy languages Les Cargill <lcargill99@comcast.com> - 2015-09-14 21:36 -0500
                              Re: (Not) discussing C-like toy languages "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-13 14:29 -0700
                                Re: (Not) discussing C-like toy languages David Brown <david.brown@hesbynett.no> - 2015-09-13 23:47 +0200
                                  Re: (Not) discussing C-like toy languages "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-13 17:55 -0700
                                    Re: (Not) discussing C-like toy languages David Brown <david.brown@hesbynett.no> - 2015-09-14 10:20 +0200
                                      Re: (Not) discussing C-like toy languages Richard Heathfield <rjh@cpax.org.uk> - 2015-09-14 11:01 +0100
                                        Re: (Not) discussing C-like toy languages Ian Collins <ian-news@hotmail.com> - 2015-09-14 22:07 +1200
                                        Re: (Not) discussing C-like toy languages David Brown <david.brown@hesbynett.no> - 2015-09-14 12:41 +0200
                                        Re: (Not) discussing C-like toy languages Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-14 03:47 -0700
                                          Re: (Not) discussing C-like toy languages "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-14 04:05 -0700
                                            Re: (Not) discussing C-like toy languages "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-14 04:20 -0700
                                            Re: (Not) discussing C-like toy languages Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-14 05:51 -0700
                                              Re: (Not) discussing C-like toy languages "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-14 06:06 -0700
                                                Re: (Not) discussing C-like toy languages Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-14 06:26 -0700
                                                  Re: (Not) discussing C-like toy languages gazelle@shell.xmission.com (Kenny McCormack) - 2015-09-14 13:43 +0000
                                                    Re: (Not) discussing C-like toy languages Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-14 07:26 -0700
                                                  Re: (Not) discussing C-like toy languages "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-14 06:47 -0700
                                      Re: (Not) discussing C-like toy languages "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-14 03:31 -0700
                                      Re: (Not) discussing C-like toy languages James Kuyper <jameskuyper@verizon.net> - 2015-09-14 06:40 -0400
                                        Re: (Not) discussing C-like toy languages David Brown <david.brown@hesbynett.no> - 2015-09-14 14:27 +0200
                                          Re: (Not) discussing C-like toy languages Richard Heathfield <rjh@cpax.org.uk> - 2015-09-14 13:39 +0100
                                            Re: (Not) discussing C-like toy languages "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-14 05:55 -0700
                                          Re: (Not) discussing C-like toy languages "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-14 05:50 -0700
                                            Re: (Not) discussing C-like toy languages David Brown <david.brown@hesbynett.no> - 2015-09-14 15:58 +0200
                                              Re: (Not) discussing C-like toy languages "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-14 07:37 -0700
                                                Re: (Not) discussing C-like toy languages fir <profesor.fir@gmail.com> - 2015-09-14 07:43 -0700
                                                  Re: (Not) discussing C-like toy languages David Brown <david.brown@hesbynett.no> - 2015-09-14 17:21 +0200
                                                    Re: (Not) discussing C-like toy languages Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-14 08:53 -0700
                                                      Re: (Not) discussing C-like toy languages David Brown <david.brown@hesbynett.no> - 2015-09-14 18:23 +0200
                                                      Re: (Not) discussing C-like toy languages fir <profesor.fir@gmail.com> - 2015-09-14 10:57 -0700
                                                        Re: (Not) discussing C-like toy languages fir <profesor.fir@gmail.com> - 2015-09-17 17:43 -0700
                                                      Re: (Not) discussing C-like toy languages raltbos@xs4all.nl (Richard Bos) - 2015-09-20 20:50 +0000
                                        Re: (Not) discussing C-like toy languages raltbos@xs4all.nl (Richard Bos) - 2015-09-20 20:48 +0000
                                      Re: (Not) discussing C-like toy languages Keith Thompson <kst-u@mib.org> - 2015-09-14 07:58 -0700
                            Re: (Not) discussing C-like toy languages Les Cargill <lcargill99@comcast.com> - 2015-09-14 21:35 -0500
              Re: (Not) discussing C-like toy languages Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-08 23:56 -0700
          Re: (Not) discussing C-like toy languages fir <profesor.fir@gmail.com> - 2015-09-08 08:07 -0700
      Re: disadvantages of using old parameter syntax? luser droog <luser.droog@gmail.com> - 2015-09-08 17:40 -0700
        Re: disadvantages of using old parameter syntax? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-08 17:59 -0700
    Re: disadvantages of using old parameter syntax? James Kuyper <jameskuyper@verizon.net> - 2015-09-04 10:48 -0400
    Re: disadvantages of using old parameter syntax? Paul N <gw7rib@aol.com> - 2015-09-07 12:48 -0700
    Re: disadvantages of using old parameter syntax? Anonymous Shadow <rocket.penguin@riseup.net> - 2015-09-12 15:35 +0800
      Re: disadvantages of using old parameter syntax? Keith Thompson <kst-u@mib.org> - 2015-09-12 14:25 -0700
        Re: disadvantages of using old parameter syntax? supercat@casperkitty.com - 2015-09-12 14:53 -0700
          Re: disadvantages of using old parameter syntax? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-12 18:21 -0400
    Re: disadvantages of using old parameter syntax? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-14 11:41 -0700
      Re: disadvantages of using old parameter syntax? Rosario19 <Ros@invalid.invalid> - 2015-09-16 09:02 +0200
        Re: disadvantages of using old parameter syntax? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-16 01:12 -0700

Page 1 of 6  [1] 2 3 4 5 6  Next page →

#69302 — disadvantages of using old parameter syntax?

Are there any important differences I should know about when writing 
code like this:

int
main(argc, argv)
	int argc;
	char* argv[];
{
	do_stuff(argc, argv);
	return EXIT_SUCCESS;
}

as opposed to this:

int
main(int argc, char *argv[])
{
	do_stuff(argc, argv);
	return EXIT_SUCCESS;
}

I know that the first one is used in some old code, like the bsd games, 
but now nobody uses it anymore. If there isn't a big problem with doing 
this, I would like to use it, as it saves a lot of space when dealing 
with multiple arguments with types such as /unsigned short int/, which 
use up a lot of space on an 80-column tty.

--
Anonymous Shadow

[toc] | [next] | [standalone]

#69303

On Friday, September 04, 2015 08:46 PM, Anonymous Shadow wrote:
> Are there any important differences I should know about when writing
> code like this:
>
> int
> main(argc, argv)
>      int argc;
>      char* argv[];
> {
>      do_stuff(argc, argv);
>      return EXIT_SUCCESS;
> }
>
> as opposed to this:
>
> int
> main(int argc, char *argv[])
> {
>      do_stuff(argc, argv);
>      return EXIT_SUCCESS;
> }
>
> I know that the first one is used in some old code, like the bsd games,
> but now nobody uses it anymore. If there isn't a big problem with doing
> this, I would like to use it, as it saves a lot of space when dealing
> with multiple arguments with types such as /unsigned short int/, which
> use up a lot of space on an 80-column tty.
>
> --
> Anonymous Shadow

Also, I just remembered: you need to put the function prototypes 
somewhere else. However, I think that is not a hassle anyway, because if 
I put all my prototypes at the top of a file, it will save me adding a 
comment explaining which functions are in it.

--
Anonymous Shadow

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

#69327

Anonymous Shadow <rocket.penguin@riseup.net> wrote:

> Also, I just remembered: you need to put the function prototypes 
> somewhere else. However, I think that is not a hassle anyway, because if 
> I put all my prototypes at the top of a file, it will save me adding a 
> comment explaining which functions are in it.

Erm... have you heard of #include?

Richard

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

#69312

On 9/4/2015 8:46 AM, Anonymous Shadow wrote:
> Are there any important differences I should know about when writing
> code like this:
>
> int
> main(argc, argv)
>      int argc;
>      char* argv[];
> {
>      do_stuff(argc, argv);
>      return EXIT_SUCCESS;
> }
>
> as opposed to this:
>
> int
> main(int argc, char *argv[])
> {
>      do_stuff(argc, argv);
>      return EXIT_SUCCESS;
> }
>
> I know that the first one is used in some old code, like the bsd games,
> but now nobody uses it anymore. If there isn't a big problem with doing
> this, I would like to use it, as it saves a lot of space when dealing
> with multiple arguments with types such as /unsigned short int/, which
> use up a lot of space on an 80-column tty.

     Use the newer form, not the older.

     The older form does not provide a prototype to "advertise" the
parameters to the rest of the program.  When the compiler sees a call
to a non-prototyped function, it will not necessarily check the number
and types of the argument expressions for agreement with the parameters.
Worse, the compiler *will* not convert arguments to the parameters'
types; it will instead apply the "default argument promotions," even
if these are inappropriate for the function being called.  Example:

	#include <stdio.h>

	void new(double a)
	{
	    printf("new says %g!\n", a);
	}

	void old(a)
	    double a;
	{
	    printf("old says %g!\n", a);
	}

	int main(void)
	{
	    new(42);  // `int' expression is converted to `double'
	    old(42);  // `int' expression is *not* converted
	    return 0;
	}

     Sometimes it is possible to write a prototype for an old-style
function, but there are traps and it cannot always be done correctly.
Here's a fairly obvious trap, based on one of your examples:

	// Function definition:
	void shortFunc(a)
	    short a;
	{ ... }

	// Incorrect declaration:
	void shortFunc(short a);

This is wrong, because the actual definition takes an `int' that it
then converts to `short' for internal use.  The proper declaration
would be:

	// Corrected declaration:
	void shortFunc(int a);

That is, the parameter type in the prototype must *not* be the same
as the one seen in the definition!  Can you say "maintenance nightmare?"

     It gets worse:

	// Function definition:
	void charFunc(a)
	    char a;
	{ ... }

	// Choose the correct declaration:
	void charFunc(char a);  // (1)
	void charFunc(int a);   // (2)
	void charFunc(unsigned int a);  // (3)

We know that (1) is never correct because a `char' argument expression
will promote -- but to what?  On most machines nowadays (2) will be
correct, but the C language allows "exotic" architectures where (3)
would be the right choice.  You'd need to write something like:

	#include <limits.h>
	#if INT_MIN <= CHAR_MIN && CHAR_MAX <= INT_MAX
	    void charFunc(int a);
	#else
	    void charFunc(unsigned int a);
	#endif

... and your goal of brevity is, er, somewhat compromised.

     It gets even worse than that!  There are expressions that promote
in ways the compiler need not document at all.  Example:

	enum suit { SPADE, HEART, DIAMOND, CLUB };

	// Function definition:
	void suitFunc(a)
	    enum suit a;
	{ ... }

To the best of my knowledge, there is *no* way to write a prototype
for this function and be sure of getting it right.  When the compiler
chooses a "backing type" for the enum, it is free to choose *any*
integer type that supports all the values -- 0 through 3, in this
case.  It may choose `int' or `unsigned int' or `unsigned char' or
`long' or ...  Furthermore, it does not advertise its choice in any
way you could test, certainly not in any way you could test with
the preprocessor.  Note also that without a prototype

	enum suit s = ...;
	suitFunc(s);  // Correct
	suitFunc(SPADE);  // Quite possibly incorrect

... because an `enum suit' is some unspecified integer type, while
`SPADE' has the type `int', possibly different.  The two types may
or may not promote the same way; have fun with that.

     Finally, the use of old-form definitions is officially "an
obsolescent feature" according to the current language Standard,
which means "they may be considered for withdrawal in future
revisions of this International Standard ... their use in new
implementations or new programs is discouraged."

     Don't do it.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

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

#70009

On Friday, September 4, 2015 at 10:10:33 AM UTC-4, Eric Sosman wrote:
> On 9/4/2015 8:46 AM, Anonymous Shadow wrote:
> > Are there any important differences I should know about when writing
> > code like this:
> >
> > int
> > main(argc, argv)
> >      int argc;
> >      char* argv[];
> > {
> >      do_stuff(argc, argv);
> >      return EXIT_SUCCESS;
> > }
> >
> > as opposed to this:
> >
> > int
> > main(int argc, char *argv[])
> > {
> >      do_stuff(argc, argv);
> >      return EXIT_SUCCESS;
> > }
> 
>      Use the newer form, not the older.
> 
>      The older form does not provide a prototype to "advertise" the
> parameters to the rest of the program.  When the compiler sees a call
> to a non-prototyped function, it will not necessarily check the number
> and types of the argument expressions for agreement with the parameters.

This seems like something that could be changed about the compiler,
allowing the old syntax form to operate like the new one.  In addition,
what's to prevent the old syntax from being prototyped in a .h file?
Do modern C compilers ignore forward declarations when they encounter
the old style syntax?

Best regards,
Rick C. Hodgin

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

#70015

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> On Friday, September 4, 2015 at 10:10:33 AM UTC-4, Eric Sosman wrote:
>> On 9/4/2015 8:46 AM, Anonymous Shadow wrote:
>> > Are there any important differences I should know about when writing
>> > code like this:
>> >
>> > int
>> > main(argc, argv)
>> >      int argc;
>> >      char* argv[];
>> > {
>> >      do_stuff(argc, argv);
>> >      return EXIT_SUCCESS;
>> > }
>> >
>> > as opposed to this:
>> >
>> > int
>> > main(int argc, char *argv[])
>> > {
>> >      do_stuff(argc, argv);
>> >      return EXIT_SUCCESS;
>> > }
>> 
>>      Use the newer form, not the older.
>> 
>>      The older form does not provide a prototype to "advertise" the
>> parameters to the rest of the program.  When the compiler sees a call
>> to a non-prototyped function, it will not necessarily check the number
>> and types of the argument expressions for agreement with the parameters.
>
> This seems like something that could be changed about the compiler,
> allowing the old syntax form to operate like the new one.

In many cases it can't because the old syntax is simply lacking the
information required.  Sometimes, if the compiler has seen a definition
(rather than just a declaration) of a function, it could use that to
give a hint about argument type or number mismatches, but even then it
can't be sure.  In the more common case of using a function with only a
declaration ins scope, there is nothing to go on:

  int printf();
  double sin();

> In addition,
> what's to prevent the old syntax from being prototyped in a .h file?

I don't know what that means.  You can't give prototypes for old-syntax
function declarations, if that's what you mean, because you'll change
the meaning of the code in some cases.

> Do modern C compilers ignore forward declarations when they encounter
> the old style syntax?

They have to handle it as old compilers did.  It's important for old
code that the semantics remain the same.

  void f(float f) { ... }
  void f(f) float f; { ... }

do not mean quite the same thing.  The declaration is not ignored but
must be take to mean what K&R intended.  (I'm not giving details because
there is no earthly reason to use this syntax now.  Prototypes were
probably the single best change to C that has happened since I've been
using it.  No one should have to go back.)

-- 
Ben.

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

#70017

On Tuesday, September 8, 2015 at 8:57:47 PM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> > On Friday, September 4, 2015 at 10:10:33 AM UTC-4, Eric Sosman wrote:
> >> On 9/4/2015 8:46 AM, Anonymous Shadow wrote:
> >> > Are there any important differences I should know about when writing
> >> > code like this:
> >> >
> >> > int
> >> > main(argc, argv)
> >> >      int argc;
> >> >      char* argv[];
> >> > {
> >> >      do_stuff(argc, argv);
> >> >      return EXIT_SUCCESS;
> >> > }
> >> >
> >> > as opposed to this:
> >> >
> >> > int
> >> > main(int argc, char *argv[])
> >> > {
> >> >      do_stuff(argc, argv);
> >> >      return EXIT_SUCCESS;
> >> > }
> >> 
> >>      Use the newer form, not the older.
> >> 
> >>      The older form does not provide a prototype to "advertise" the
> >> parameters to the rest of the program.  When the compiler sees a call
> >> to a non-prototyped function, it will not necessarily check the number
> >> and types of the argument expressions for agreement with the parameters.
> >
> > This seems like something that could be changed about the compiler,
> > allowing the old syntax form to operate like the new one.
> 
> In many cases it can't because the old syntax is simply lacking the
> information required.

Is there a form which is unlike the example above, because that one
seems to have all the information in the new form, it's just arranged
differently?  I assume there is, hence your comment here. :-)

> In the more common case of using a function with only a
> declaration ins scope, there is nothing to go on:
> 
>   int printf();
>   double sin();

Yes, I would think that should've either been done away with, or
equated to this formal declaration:

    int printf(void);
    double sin(void);

> > In addition,
> > what's to prevent the old syntax from being prototyped in a .h file?
> 
> I don't know what that means.  You can't give prototypes for old-syntax
> function declarations, if that's what you mean, because you'll change
> the meaning of the code in some cases.

Well ... I don't see how that would be possible.  I would think the
C compiler would find the second instance, which did not have its
parameters specified by types, and use the prototype, or, if they
were specified by types and they varied, then it would generate an
error that something was wrong.

> > Do modern C compilers ignore forward declarations when they encounter
> > the old style syntax?
> 
> They have to handle it as old compilers did.  It's important for old
> code that the semantics remain the same.
> 
>   void f(float f) { ... }
>   void f(f) float f; { ... }
> 
> do not mean quite the same thing.  The declaration is not ignored but
> must be take to mean what K&R intended.

That's what my comment meant that compilers could be changed to have
them mean the same thing.

> (I'm not giving details because
> there is no earthly reason to use this syntax now.  Prototypes were
> probably the single best change to C that has happened since I've been
> using it.  No one should have to go back.)

I'm just curious here, by the way.  I have no plans to use it, or to
resurrect the idea.  It just doesn't make sense to me.  It makes more
sense if forward prototype definitions are not allowed at all.  It makes
no sense to me if they are, and the void f(f) float f; { ... } syntax
above is allowed.  I think it should be allowed, and it should convey
the same meaning as void f(float f) { ... }, with or without a forward
prototype.

But, it's not important.  You don't need to respond.

Best regards,
Rick C. Hodgin

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

#70019

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> On Tuesday, September 8, 2015 at 8:57:47 PM UTC-4, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> 
>> > On Friday, September 4, 2015 at 10:10:33 AM UTC-4, Eric Sosman wrote:
>> >> On 9/4/2015 8:46 AM, Anonymous Shadow wrote:
>> >> > Are there any important differences I should know about when writing
>> >> > code like this:
>> >> >
>> >> > int
>> >> > main(argc, argv)
>> >> >      int argc;
>> >> >      char* argv[];
>> >> > {
>> >> >      do_stuff(argc, argv);
>> >> >      return EXIT_SUCCESS;
>> >> > }
>> >> >
>> >> > as opposed to this:
>> >> >
>> >> > int
>> >> > main(int argc, char *argv[])
>> >> > {
>> >> >      do_stuff(argc, argv);
>> >> >      return EXIT_SUCCESS;
>> >> > }
>> >> 
>> >>      Use the newer form, not the older.
>> >> 
>> >>      The older form does not provide a prototype to "advertise" the
>> >> parameters to the rest of the program.  When the compiler sees a call
>> >> to a non-prototyped function, it will not necessarily check the number
>> >> and types of the argument expressions for agreement with the parameters.
>> >
>> > This seems like something that could be changed about the compiler,
>> > allowing the old syntax form to operate like the new one.
>> 
>> In many cases it can't because the old syntax is simply lacking the
>> information required.
>
> Is there a form which is unlike the example above, because that one
> seems to have all the information in the new form, it's just arranged
> differently?  I assume there is, hence your comment here. :-)

I suspect I'm wading into another zone where you don't know which terms
are technical ones and which just have vague meanings.  The two forms
shown convey different information, though the differences are subtle
and, as I've said, simply not worth resurrecting.  The most striking
thing about old C are function declarations that are not definitions.
When the compiler sees a call to

   f(2, 3.5, 1.2);

all it has probably seen is a declaration which is not a prototype

   extern f();

It simply lacks the information to say of the call is correct or not.
More subtly, it can't convert any of the arguments.

In some other file we find the definition:

  int f(a, b, c)
  double a, b, c;
  { ... }

and things look bad.  A value of completely the wrong type (and
probably size) is being passed.  The compiler can't either diagnose the
error help correct it.  With modern C, the function would be declared
with a prototype

  int f(double a, double b, double c);

and the first argument, "3", would be converted to a double.  And if the
number of arguments was wrong, you'll get a message.  A K&R C compiler
must accept both the call above and one like f(1).  It has no idea
which is correct (and both might be).

>> In the more common case of using a function with only a
>> declaration ins scope, there is nothing to go on:
>> 
>>   int printf();
>>   double sin();
>
> Yes, I would think that should've either been done away with, or
> equated to this formal declaration:
>
>     int printf(void);
>     double sin(void);
>
>> > In addition,
>> > what's to prevent the old syntax from being prototyped in a .h file?
>> 
>> I don't know what that means.  You can't give prototypes for old-syntax
>> function declarations, if that's what you mean, because you'll change
>> the meaning of the code in some cases.
>
> Well ... I don't see how that would be possible.

I've written enough already about what is an obsolete syntax.  Can you
just take my word for it?  There are old C functions for which it is not
possible to write a modern C prototype without altering the meaning.

> I would think the
> C compiler would find the second instance, which did not have its
> parameters specified by types, and use the prototype, or, if they
> were specified by types and they varied, then it would generate an
> error that something was wrong.

I've no idea what this is about.

>> > Do modern C compilers ignore forward declarations when they encounter
>> > the old style syntax?
>> 
>> They have to handle it as old compilers did.  It's important for old
>> code that the semantics remain the same.
>> 
>>   void f(float f) { ... }
>>   void f(f) float f; { ... }
>> 
>> do not mean quite the same thing.  The declaration is not ignored but
>> must be take to mean what K&R intended.
>
> That's what my comment meant that compilers could be changed to have
> them mean the same thing.

Do you mean you'd be happy to have a compiler that just changed what
previously correct existing programs mean?  C has wisely not done that.
The old form still means what it meant and the new form means what C90
(and later) says it means.

<snip>
-- 
Ben.

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

#70021

On Tuesday, September 8, 2015 at 9:47:44 PM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> > On Tuesday, September 8, 2015 at 8:57:47 PM UTC-4, Ben Bacarisse wrote:
> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >> 
> >> > On Friday, September 4, 2015 at 10:10:33 AM UTC-4, Eric Sosman wrote:
> >> >> On 9/4/2015 8:46 AM, Anonymous Shadow wrote:
> >> >> > Are there any important differences I should know about when writing
> >> >> > code like this:
> >> >> >
> >> >> > int
> >> >> > main(argc, argv)
> >> >> >      int argc;
> >> >> >      char* argv[];
> >> >> > {
> >> >> >      do_stuff(argc, argv);
> >> >> >      return EXIT_SUCCESS;
> >> >> > }
> >> >> >
> >> >> > as opposed to this:
> >> >> >
> >> >> > int
> >> >> > main(int argc, char *argv[])
> >> >> > {
> >> >> >      do_stuff(argc, argv);
> >> >> >      return EXIT_SUCCESS;
> >> >> > }
> >> >> 
> >> >>      Use the newer form, not the older.
> >> >> 
> >> >>      The older form does not provide a prototype to "advertise" the
> >> >> parameters to the rest of the program.  When the compiler sees a call
> >> >> to a non-prototyped function, it will not necessarily check the number
> >> >> and types of the argument expressions for agreement with the parameters.
> >> >
> >> > This seems like something that could be changed about the compiler,
> >> > allowing the old syntax form to operate like the new one.
> >> 
> >> In many cases it can't because the old syntax is simply lacking the
> >> information required.
> >
> > Is there a form which is unlike the example above, because that one
> > seems to have all the information in the new form, it's just arranged
> > differently?  I assume there is, hence your comment here. :-)
> 
> I suspect I'm wading into another zone where you don't know which terms
> are technical ones and which just have vague meanings.  The two forms
> shown convey different information, though the differences are subtle
> and, as I've said, simply not worth resurrecting.  The most striking
> thing about old C are function declarations that are not definitions.
> When the compiler sees a call to
> 
>    f(2, 3.5, 1.2);
> 
> all it has probably seen is a declaration which is not a prototype
> 
>    extern f();

Gasp!

> It simply lacks the information to say of the call is correct or not.
> More subtly, it can't convert any of the arguments.

I see that.

> In some other file we find the definition:
> 
>   int f(a, b, c)
>   double a, b, c;
>   { ... }
> 
> and things look bad.  A value of completely the wrong type (and
> probably size) is being passed.  The compiler can't either diagnose the
> error help correct it.  With modern C, the function would be declared
> with a prototype
> 
>   int f(double a, double b, double c);
> 
> and the first argument, "3", would be converted to a double.  And if the
> number of arguments was wrong, you'll get a message.  A K&R C compiler
> must accept both the call above and one like f(1).  It has no idea
> which is correct (and both might be).
> 
> >> In the more common case of using a function with only a
> >> declaration ins scope, there is nothing to go on:
> >> 
> >>   int printf();
> >>   double sin();
> >
> > Yes, I would think that should've either been done away with, or
> > equated to this formal declaration:
> >
> >     int printf(void);
> >     double sin(void);
> >
> >> > In addition,
> >> > what's to prevent the old syntax from being prototyped in a .h file?
> >> 
> >> I don't know what that means.  You can't give prototypes for old-syntax
> >> function declarations, if that's what you mean, because you'll change
> >> the meaning of the code in some cases.
> >
> > Well ... I don't see how that would be possible.
> 
> I've written enough already about what is an obsolete syntax.  Can you
> just take my word for it?  There are old C functions for which it is not
> possible to write a modern C prototype without altering the meaning.
> 
> > I would think the
> > C compiler would find the second instance, which did not have its
> > parameters specified by types, and use the prototype, or, if they
> > were specified by types and they varied, then it would generate an
> > error that something was wrong.
> 
> I've no idea what this is about.

I was wrong in what I was conveying, but I assumed the old format
allowed something like the new format, just with the different
function-side syntax.  So, in the old format I envisioned having
this for a function prototype somewhere:

     int f(float a, float b, float c);

And then this in the body definition:

     int f(a, b, c)
     {
         // Code goes here
     }

It would know what a, b, and c were from its prior definition.  But,
if this were encountered in the body definition:

     int f(a, b, c)
           int a;
           int b;
           int c;
     {
         // Code goes here
     }

It would know something was wrong because the parameters don't match,
and report the error.

But, you explained it in your reply, so I convey that only to convey
to you my previous intent, which has now been rendered meaningless,
though perhaps not only "now".

> >> > Do modern C compilers ignore forward declarations when they encounter
> >> > the old style syntax?
> >> 
> >> They have to handle it as old compilers did.  It's important for old
> >> code that the semantics remain the same.
> >> 
> >>   void f(float f) { ... }
> >>   void f(f) float f; { ... }
> >> 
> >> do not mean quite the same thing.  The declaration is not ignored but
> >> must be take to mean what K&R intended.
> >
> > That's what my comment meant that compilers could be changed to have
> > them mean the same thing.
> 
> Do you mean you'd be happy to have a compiler that just changed what
> previously correct existing programs mean?

Yes, back then, through a new compiler switch.  But, I didn't know
until this post of yours I'm replying to that C allowed such things
as "extern f();" ... which seems to completely defeat the purpose
of having any kind of prototyping ability at all.

> C has wisely not done that.
> The old form still means what it meant and the new form means what C90
> (and later) says it means.

I believe in the idea of maintaining backward compatibility.  In fact,
I probably believe in this more than most people I've ever encountered.
For example, I've gone out of my way to ensure old things work, while
introducing new things atop of it where feasible.  It's one of my
specialities.

See here:

     http://www.visual-freepro.org/wiki/index.php/Main_Page#Protect_Your_Investment
     "The authors of Visual FreePro pledge to forever protect your
      investment and to never leave you hanging through future versions
      which break backward functionality. If such a requirement becomes
      necessary in the future, it will become a new product under a new
      name."

The only exceptions I noted were due to program bugs which resulted
in behavior that was not intentional, and requirements cited by court
rulings.  And I believe in this for more than just Visual FreePro, but
for everything.  Exodus 1.0 programs will forever run on any future
versions of Exodus.  RDC 1.0 programs will forever compile on any
future versions of RDC, and so on.  It's something I live by ... even
religiously. :-)

Best regards,
Rick C. Hodgin

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

#70033

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
<snip>
> I was wrong in what I was conveying, but I assumed the old format
> allowed something like the new format, just with the different
> function-side syntax.

Ah, right.  That explains why I could not follow.  As you now see they
are very different indeed.

<snip>
-- 
Ben.

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

#70034

On 09/09/15 03:09, Rick C. Hodgin wrote:
> On Tuesday, September 8, 2015 at 8:57:47 PM UTC-4, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
<snip>
>> In the more common case of using a function with only a
>> declaration ins scope, there is nothing to go on:
>>
>>   int printf();
>>   double sin();
> 
> Yes, I would think that should've either been done away with, or
> equated to this formal declaration:
> 
>     int printf(void);
>     double sin(void);

That's what C++ did - but C++ is a different language, and was therefore
allowed to change the rules.  C tries its best to keep backwards
compatibility with old code and old standards - code that used to work
in a particular way with an old compiler should continue to work in the
same way with a newer compiler.  This means that newer compilers and
standards have to accept code that could now be written in a better way,
but that's the price you pay for backwards compatibility.

> 
>>> In addition,
>>> what's to prevent the old syntax from being prototyped in a .h file?
>>
>> I don't know what that means.  You can't give prototypes for old-syntax
>> function declarations, if that's what you mean, because you'll change
>> the meaning of the code in some cases.
> 
> Well ... I don't see how that would be possible.  I would think the
> C compiler would find the second instance, which did not have its
> parameters specified by types, and use the prototype, or, if they
> were specified by types and they varied, then it would generate an
> error that something was wrong.

It won't find the two instances if they are in two different compilation
units.

> 
>>> Do modern C compilers ignore forward declarations when they encounter
>>> the old style syntax?
>>
>> They have to handle it as old compilers did.  It's important for old
>> code that the semantics remain the same.
>>
>>   void f(float f) { ... }
>>   void f(f) float f; { ... }
>>
>> do not mean quite the same thing.  The declaration is not ignored but
>> must be take to mean what K&R intended.
> 
> That's what my comment meant that compilers could be changed to have
> them mean the same thing.

When you first decide to change things (which a different language, such
as C++, is able to do - but which the C committee only does in
exceptional circumstances), then it is far better to make the old, bad
way an error than to silently and subtly change it into something
/almost/ the same.  If the C committee ever feels that there is so
little legacy K&R code in use that there is no need for the next C
standard to support it, then "void f(f) float f; { ... }" will be a
syntax error.

> 
>> (I'm not giving details because
>> there is no earthly reason to use this syntax now.  Prototypes were
>> probably the single best change to C that has happened since I've been
>> using it.  No one should have to go back.)
> 
> I'm just curious here, by the way.  I have no plans to use it, or to
> resurrect the idea.  It just doesn't make sense to me.  It makes more
> sense if forward prototype definitions are not allowed at all.  It makes
> no sense to me if they are, and the void f(f) float f; { ... } syntax
> above is allowed.  I think it should be allowed, and it should convey
> the same meaning as void f(float f) { ... }, with or without a forward
> prototype.

Compilers are free to disallow such function definitions (though not by
default, as the standards say they must be allowed).  So with gcc
warnings such as "-Wmissing-parameter-type -Wold-style-declaration" will
give you this.

> 
> But, it's not important.  You don't need to respond.
> 
> Best regards,
> Rick C. Hodgin
> 

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

#69314

On Friday, September 4, 2015 at 8:47:13 AM UTC-4, Anonymous Shadow wrote:
> int
> main(argc, argv)
> 	int argc;
> 	char* argv[];
> {
> 	do_stuff(argc, argv);
> 	return EXIT_SUCCESS;
> }

Is this really the "old way" of handling parameters in C?  Because
it's very similar to what I've come up with for RDC:

    function main
    | returns int r
    | params, int argc, char* argv[]
    {
    	do_stuff(argc, argv);
    	r = EXIT_SUCCESS;
    }

RDC allows for multiple return parameters, so they can be declared
as params is above.  And in RDC, assignment replaces the need for
return, though return can also still be used.

Note:  My design allows follows the concept I have of a GUI cask.
       The idea is the portions can be collapsed, and only a
       placeholder seen in a spatial way.  This makes your source
       code not appear in a host of disparate files, but in a
       city-like or grid-like layout, and you go to that "building"
       and that "floor" and there is the source code related to
       that functionality, or however else you want to arrange it
       (a 3D layout, but generally viewed top-down).

In any event ... until people see it, it might be hard to envision
in practical use.  I've had this idea in my mind since the mid-90s.
I've worked toward it many times, but have never gotten there yet.

My current attempts with Visual FreePro, Jr.'s GUI are the closest
I have (you can download here to see the GUI if you have Windows,
though the GUI is still incomplete):

     http://www.visual-freepro.org/vjr/indexmain.html
     http://www.libsf.org/software/vjr_0.57.zip   // 32-bit only
     http://www.libsf.org/software/vjr_0.56.zip   // 32-bit and 64-bit

Supported commands:

     http://www.visual-freepro.org/wiki/index.php/VXB

Best regards,
Rick C. Hodgin

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

#69315

On Friday, 4 September 2015 15:24:14 UTC+1, Rick C. Hodgin  wrote:
> On Friday, September 4, 2015 at 8:47:13 AM UTC-4, Anonymous Shadow wrote:
> > int
> > main(argc, argv)
> > 	int argc;
> > 	char* argv[];
> > {
> > 	do_stuff(argc, argv);
> > 	return EXIT_SUCCESS;
> > }
> 
> Is this really the "old way" of handling parameters in C? 

Yes - it's the form from the original K&R C, but prototypes have been around quite some time, with the advantages that Eric outlines.

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

#69455

On 04/09/15 16:23, Rick C. Hodgin wrote:
> On Friday, September 4, 2015 at 8:47:13 AM UTC-4, Anonymous Shadow wrote:
>> int
>> main(argc, argv)
>> 	int argc;
>> 	char* argv[];
>> {
>> 	do_stuff(argc, argv);
>> 	return EXIT_SUCCESS;
>> }
> 
> Is this really the "old way" of handling parameters in C?  Because
> it's very similar to what I've come up with for RDC:
> 
>     function main
>     | returns int r
>     | params, int argc, char* argv[]
>     {
>     	do_stuff(argc, argv);
>     	r = EXIT_SUCCESS;
>     }
> 
> RDC allows for multiple return parameters, so they can be declared
> as params is above.  And in RDC, assignment replaces the need for
> return, though return can also still be used.
> 

Yes, it's the old way in C.  If you are making a completely new language
there is nothing wrong with picking a syntax where the parameters and
return type go on separate lines, or follow the function name in some way.

The problem with the old-style functions in C is that they don't declare
a list of parameters and types for a function signature.  The function
itself takes an unspecified number of parameters, and the list of types
in the old-style function definition say how these parameters should be
interpreted.  That's a very different thing - and it is a very /bad/
thing, because it forces the programmer to do a good deal more manual
work and a good deal more manual checking.  The "new" style of C
function declaration lets the compiler do the work - and gives the
compiler more chance for generating higher quality code.

So as long as your RDC uses the parameters types for type checking,
static error checking, automatic conversions, etc., then there is no
advantage or disadvantage of how you lay them out - it's just a matter
of what style you like.

(I like the possibility of multiple return values - it's something I use
in Python.  In C it's easy enough to use a struct return type in cases
where multiple return values are advantageous.)

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

#69844

On Saturday, September 5, 2015 at 1:59:43 PM UTC+1, David Brown wrote:
>
> The problem with the old-style functions in C is that they don't declare
> a list of parameters and types for a function signature.  The function
> itself takes an unspecified number of parameters, and the list of types
> in the old-style function definition say how these parameters should be
> interpreted.  That's a very different thing - and it is a very /bad/
> thing, because it forces the programmer to do a good deal more manual
> work and a good deal more manual checking.
>
Bad but not _very_ bad.

I'm currently hooking up a UI which I'm writing in a javascript variant
to a core program written in C++. So of course you lose all the type
safety when passing parameters across the divide - I call the script
from C by passing string in JSON, and there's a "script-variable"
object which defines the interface going the other way.

It's a nuisance but not a disaster. Type errors are caught at runtime
rather than at compile time. But almost always they will be caught 
on the first test - all the json has set fields, there's not a single
example of a dynamic interface (by which I mean when the same 
user-space function is passed a structure with fields of a different 
type). So if the first test doesn't fail then it would be extremely
unlucky.

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

#69871

On 07/09/15 22:26, Malcolm McLean wrote:
> On Saturday, September 5, 2015 at 1:59:43 PM UTC+1, David Brown wrote:
>>
>> The problem with the old-style functions in C is that they don't declare
>> a list of parameters and types for a function signature.  The function
>> itself takes an unspecified number of parameters, and the list of types
>> in the old-style function definition say how these parameters should be
>> interpreted.  That's a very different thing - and it is a very /bad/
>> thing, because it forces the programmer to do a good deal more manual
>> work and a good deal more manual checking.
>>
> Bad but not _very_ bad.
> 
> I'm currently hooking up a UI which I'm writing in a javascript variant
> to a core program written in C++. So of course you lose all the type
> safety when passing parameters across the divide - I call the script
> from C by passing string in JSON, and there's a "script-variable"
> object which defines the interface going the other way.
> 
> It's a nuisance but not a disaster. Type errors are caught at runtime
> rather than at compile time. But almost always they will be caught 
> on the first test - all the json has set fields, there's not a single
> example of a dynamic interface (by which I mean when the same 
> user-space function is passed a structure with fields of a different 
> type). So if the first test doesn't fail then it would be extremely
> unlucky.
> 

There are times where you cannot do compile-time type checking.  You've
mentioned one of them, another would be when using languages that have
dynamic typing and duck typing (such as Python).  The relegation of such
checks to run-time rather than compile time is a strong disadvantage -
it is always best to spot errors as soon as possible.  But if the
advantages are big enough, or there is no good way around it, then you
accept that cost - it's a balance design decision that you make.

In this case, however, the OP was wondering about using old-style C
function definitions.  Doing so would be to through away type
information - for type checking, and automatic conversions - for /no/
benefit.  That would be a /very/ bad thing.

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

#69894 — Re: (Not) discussing C-like toy languages

On 05/09/2015 14:59, David Brown wrote:

> On 04/09/15 16:23, RCH wrote:
> 
>> Is this really the "old way" of handling parameters in C?  Because
>> it's very similar to what I've come up with for RDC:
> 
> Yes, it's the old way in C.  If you are making a completely new language
> there is nothing wrong with picking a syntax where the parameters and
> return type go on separate lines, or follow the function name in some way.

For the love of the almighty Flying Spaghetti Monster! We already have
one kook peddling his toy languages at every turn, don't encourage an
even kookier kook to follow suit.

Regards.

-- 
https://en.wikipedia.org/wiki/Flying_Spaghetti_Monster

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

#69896 — Re: (Not) discussing C-like toy languages

On 08/09/15 13:35, Noob wrote:
> On 05/09/2015 14:59, David Brown wrote:
> 
>> On 04/09/15 16:23, RCH wrote:
>>
>>> Is this really the "old way" of handling parameters in C?  Because
>>> it's very similar to what I've come up with for RDC:
>>
>> Yes, it's the old way in C.  If you are making a completely new language
>> there is nothing wrong with picking a syntax where the parameters and
>> return type go on separate lines, or follow the function name in some way.
> 
> For the love of the almighty Flying Spaghetti Monster! We already have
> one kook peddling his toy languages at every turn, don't encourage an
> even kookier kook to follow suit.
> 

We have two regulars (that I know of) that have their own toy languages
- Rick is the most enthusiastic about it.  While I don't think it is a
good idea for him to work on it, no amount of encouraging or
discouraging from me is going to change his priorities.  But I don't
think it is unreasonable to comment on it occasionally, or give
suggestions, even though it is off-topic in this group.

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

#69899 — Re: (Not) discussing C-like toy languages

In article <msmigb$ii5$1@dont-email.me>,
David Brown  <david.brown@hesbynett.no> wrote:
...
>We have two regulars (that I know of) that have their own toy languages

Point of order: Neither RCH nor BC are "regulars" (or, "regs") in the
proper sense of the word.

-- 
Religion is what keeps the poor from murdering the rich.

	- Napoleon Bonaparte -

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

#69921 — Re: (Not) discussing C-like toy languages

On 08/09/2015 14:35, Kenny McCormack wrote:

> Point of order: Neither RCH nor BC are "regulars" (or, "regs") in the
> proper sense of the word.

Damn right! No true Scotsman would ever be considered a "reg".

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

Page 1 of 6  [1] 2 3 4 5 6  Next page →

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

csiph-web