Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #24707 > unrolled thread
| Started by | lovecreatesbeauty <lovecreatesbeauty@gmail.com> |
|---|---|
| First post | 2012-08-22 10:34 -0700 |
| Last post | 2012-08-27 22:41 -0400 |
| Articles | 20 on this page of 192 — 45 participants |
Back to article view | Back to comp.lang.c
GCC is re-implementing in C++ and C discarded lovecreatesbeauty <lovecreatesbeauty@gmail.com> - 2012-08-22 10:34 -0700
Re: GCC is re-implementing in C++ and C discarded Thomas Richter <thor@math.tu-berlin.de> - 2012-08-22 19:50 +0200
Re: GCC is re-implementing in C++ and C discarded fmassei@gmail.com - 2012-08-22 11:04 -0700
Re: GCC is re-implementing in C++ and C discarded James Kuyper <jameskuyper@verizon.net> - 2012-08-22 14:22 -0400
Re: GCC is re-implementing in C++ and C discarded Angel <angel+news@spamcop.net> - 2012-08-22 18:43 +0000
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-22 12:08 -0700
Re: GCC is re-implementing in C++ and C discarded Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-22 12:32 -0700
Re: GCC is re-implementing in C++ and C discarded "BartC" <bc@freeuk.com> - 2012-08-22 20:45 +0100
Re: GCC is re-implementing in C++ and C discarded Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-22 22:20 +0200
Re: GCC is re-implementing in C++ and C discarded Chicken McNuggets <chicken@mcnuggets.com> - 2012-08-23 10:43 +0100
Re: GCC is re-implementing in C++ and C discarded Melzzzzz <mel@zzzzz.invalid> - 2012-08-23 21:14 +0200
[OT] Re: GCC is re-implementing in C++ and C discarded William Ahern <william@wilbur.25thandClement.com> - 2012-08-23 13:27 -0700
Re: [OT] Re: GCC is re-implementing in C++ and C discarded Melzzzzz <mel@zzzzz.invalid> - 2012-08-23 22:38 +0200
Re: GCC is re-implementing in C++ and C discarded William Ahern <william@wilbur.25thandClement.com> - 2012-08-22 13:40 -0700
Re: GCC is re-implementing in C++ and C discarded lovecreatesbeauty <lovecreatesbeauty@gmail.com> - 2012-08-23 00:15 -0700
Re: GCC is re-implementing in C++ and C discarded 88888 Dihedral <dihedral88888@googlemail.com> - 2012-08-23 00:40 -0700
Re: GCC is re-implementing in C++ and C discarded Mark Bluemel <mark_bluemel@pobox.com> - 2012-08-23 09:48 +0100
Re: GCC is re-implementing in C++ and C discarded Robert Wessel <robertwessel2@yahoo.com> - 2012-08-22 15:56 -0500
Re: GCC is re-implementing in C++ and C discarded Chicken McNuggets <chicken@mcnuggets.com> - 2012-08-23 10:49 +0100
Re: GCC is re-implementing in C++ and C discarded Robert Wessel <robertwessel2@yahoo.com> - 2012-08-23 08:32 -0500
Re: GCC is re-implementing in C++ and C discarded Chicken McNuggets <chicken@mcnuggets.com> - 2012-08-23 14:49 +0100
Re: GCC is re-implementing in C++ and C discarded Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-23 17:23 +0200
Re: GCC is re-implementing in C++ and C discarded fmassei@gmail.com - 2012-08-23 08:43 -0700
Re: GCC is re-implementing in C++ and C discarded Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-23 17:52 +0200
Re: GCC is re-implementing in C++ and C discarded Rui Maciel <rui.maciel@gmail.com> - 2012-08-23 18:41 +0100
Re: GCC is re-implementing in C++ and C discarded gazelle@shell.xmission.com (Kenny McCormack) - 2012-08-23 17:42 +0000
Re: GCC is re-implementing in C++ and C discarded gazelle@shell.xmission.com (Kenny McCormack) - 2012-08-23 17:43 +0000
Re: GCC is re-implementing in C++ and C discarded Robert Wessel <robertwessel2@yahoo.com> - 2012-08-23 18:54 -0500
Re: GCC is re-implementing in C++ and C discarded David Brown <david@westcontrol.removethisbit.com> - 2012-08-24 09:51 +0200
Re: GCC is re-implementing in C++ and C discarded Les Cargill <lcargill99@comcast.com> - 2012-08-24 06:21 -0500
Re: GCC is re-implementing in C++ and C discarded Chicken McNuggets <chicken@mcnuggets.com> - 2012-09-03 16:55 +0100
Re: GCC is re-implementing in C++ and C discarded Kenneth Brody <kenbrody@spamcop.net> - 2012-08-24 13:36 -0400
Re: GCC is re-implementing in C++ and C discarded Andrew Smallshaw <andrews@sdf.lonestar.org> - 2012-08-27 06:05 +0000
Re: GCC is re-implementing in C++ and C discarded Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-23 12:56 -0700
Re: GCC is re-implementing in C++ and C discarded Rui Maciel <rui.maciel@gmail.com> - 2012-08-29 21:10 +0100
Re: GCC is re-implementing in C++ and C discarded Melzzzzz <mel@zzzzz.invalid> - 2012-08-23 21:23 +0200
Re: GCC is re-implementing in C++ and C discarded Rui Maciel <rui.maciel@gmail.com> - 2012-08-23 18:37 +0100
Re: GCC is re-implementing in C++ and C discarded Melzzzzz <mel@zzzzz.invalid> - 2012-08-23 21:19 +0200
Re: GCC is re-implementing in C++ and C discarded 88888 Dihedral <dihedral88888@googlemail.com> - 2012-08-25 02:40 -0700
Re: GCC is re-implementing in C++ and C discarded Melzzzzz <mel@zzzzz.invalid> - 2012-08-23 21:15 +0200
Re: GCC is re-implementing in C++ and C discarded David Brown <david@westcontrol.removethisbit.com> - 2012-08-24 09:52 +0200
Re: GCC is re-implementing in C++ and C discarded Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-08-25 07:51 +0000
Re: GCC is re-implementing in C++ and C discarded David Brown <david@westcontrol.removethisbit.com> - 2012-08-26 23:09 +0200
Re: GCC is re-implementing in C++ and C discarded Kenneth Brody <kenbrody@spamcop.net> - 2012-08-22 17:43 -0400
Re: GCC is re-implementing in C++ and C discarded Anonymous <nobody@remailer.paranoici.org> - 2012-08-23 20:17 +0000
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-24 15:09 +0200
Re: GCC is re-implementing in C++ and C discarded jacob navia <jacob@spamsink.net> - 2012-08-24 17:53 +0200
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-24 19:02 +0200
Re: GCC is re-implementing in C++ and C discarded jacob navia <jacob@spamsink.net> - 2012-08-24 20:53 +0200
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-24 21:33 +0200
Re: GCC is re-implementing in C++ and C discarded Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-25 02:33 -0700
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 11:41 +0200
Re: GCC is re-implementing in C++ and C discarded Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-08-26 08:04 +0000
Re: GCC is re-implementing in C++ and C discarded jacob navia <jacob@spamsink.net> - 2012-08-24 21:08 +0200
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-24 21:37 +0200
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-22 15:13 -0700
Re: GCC is re-implementing in C++ and C discarded David Brown <david@westcontrol.removethisbit.com> - 2012-08-23 10:09 +0200
Re: GCC is re-implementing in C++ and C discarded Kenneth Brody <kenbrody@spamcop.net> - 2012-08-23 13:00 -0400
Re: GCC is re-implementing in C++ and C discarded Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 06:33 -0700
Re: GCC is re-implementing in C++ and C discarded Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-08-25 09:06 +0000
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 11:31 +0200
Re: GCC is re-implementing in C++ and C discarded Les Cargill <lcargill99@comcast.com> - 2012-08-25 13:45 -0500
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 21:16 +0200
Re: GCC is re-implementing in C++ and C discarded James Kuyper <jameskuyper@verizon.net> - 2012-08-25 15:37 -0400
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 21:40 +0200
Re: GCC is re-implementing in C++ and C discarded Les Cargill <lcargill99@comcast.com> - 2012-08-25 15:01 -0500
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 22:03 +0200
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-25 17:11 -0700
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-26 11:46 +0200
Re: GCC is re-implementing in C++ and C discarded Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-25 03:07 -0700
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 12:22 +0200
Re: GCC is re-implementing in C++ and C discarded James Kuyper <jameskuyper@verizon.net> - 2012-08-25 09:35 -0400
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 17:28 +0200
Re: GCC is re-implementing in C++ and C discarded James Kuyper <jameskuyper@verizon.net> - 2012-08-25 15:00 -0400
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 21:17 +0200
Re: GCC is re-implementing in C++ and C discarded Les Cargill <lcargill99@comcast.com> - 2012-08-25 14:23 -0500
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 21:26 +0200
Re: GCC is re-implementing in C++ and C discarded Les Cargill <lcargill99@comcast.com> - 2012-08-25 15:02 -0500
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 22:00 +0200
Re: GCC is re-implementing in C++ and C discarded James Kuyper <jameskuyper@verizon.net> - 2012-08-25 15:50 -0400
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-25 12:09 -0700
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 21:20 +0200
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-25 17:32 -0700
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-25 17:55 +0200
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 18:49 +0200
Re: GCC is re-implementing in C++ and C discarded James Kuyper <jameskuyper@verizon.net> - 2012-08-25 15:23 -0400
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 21:30 +0200
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-26 02:19 +0200
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-26 02:23 +0200
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-25 18:02 -0700
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-26 09:18 +0200
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-26 02:04 -0700
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-26 13:35 +0200
Re: GCC is re-implementing in C++ and C discarded eq mail <eq.mail.id@gmail.com> - 2012-08-31 02:10 -0700
Re: GCC is re-implementing in C++ and C discarded Gareth Owen <gwowen@gmail.com> - 2012-08-25 15:59 +0100
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 17:26 +0200
Re: GCC is re-implementing in C++ and C discarded Les Cargill <lcargill99@comcast.com> - 2012-08-25 13:50 -0500
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 21:21 +0200
Re: GCC is re-implementing in C++ and C discarded James Kuyper <jameskuyper@verizon.net> - 2012-08-25 15:27 -0400
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 21:36 +0200
Re: GCC is re-implementing in C++ and C discarded Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-09-06 14:41 +0300
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-09-07 17:50 +0200
Re: GCC is re-implementing in C++ and C discarded Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-09-07 19:13 +0300
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-09-07 19:17 +0200
Re: GCC is re-implementing in C++ and C discarded Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-09-09 11:12 +0300
Re: GCC is re-implementing in C++ and C discarded Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-09-07 19:37 +0300
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-09-07 19:22 +0200
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-25 12:14 -0700
Re: GCC is re-implementing in C++ and C discarded Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-08-25 23:13 +0000
Re: GCC is re-implementing in C++ and C discarded Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-26 00:28 -0700
Re: GCC is re-implementing in C++ and C discarded Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-08-26 11:15 +0000
Re: GCC is re-implementing in C++ and C discarded Rui Maciel <rui.maciel@gmail.com> - 2012-08-26 17:33 +0100
Re: GCC is re-implementing in C++ and C discarded Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-08-26 18:59 +0000
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-26 14:07 -0700
Re: GCC is re-implementing in C++ and C discarded Andrew Cooper <amc96@cam.ac.uk> - 2012-08-22 22:37 +0100
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-22 15:16 -0700
Re: GCC is re-implementing in C++ and C discarded pacman@kosh.dhis.org (Alan Curry) - 2012-08-22 22:26 +0000
Re: GCC is re-implementing in C++ and C discarded Nobody <nobody@nowhere.com> - 2012-08-23 02:07 +0100
Re: GCC is re-implementing in C++ and C discarded James Kuyper <jameskuyper@verizon.net> - 2012-08-22 22:42 -0400
Re: GCC is re-implementing in C++ and C discarded Les Cargill <lcargill99@comcast.com> - 2012-08-23 00:54 -0500
Re: GCC is re-implementing in C++ and C discarded nroberts <roberts.noah@gmail.com> - 2012-08-24 16:16 -0700
Re: GCC is re-implementing in C++ and C discarded Aaron W. Hsu <arcfide@sacrideo.us> - 2012-08-23 13:10 -0500
Re: GCC is re-implementing in C++ and C discarded Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-24 02:15 -0700
Re: GCC is re-implementing in C++ and C discarded Kenneth Brody <kenbrody@spamcop.net> - 2012-08-24 13:58 -0400
Re: GCC is re-implementing in C++ and C discarded "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2012-08-24 23:12 +0000
Re: GCC is re-implementing in C++ and C discarded Anonymous <nobody@remailer.paranoici.org> - 2012-08-25 21:35 +0000
Re: GCC is re-implementing in C++ and C discarded William Ahern <william@wilbur.25thandClement.com> - 2012-08-25 14:59 -0700
Re: GCC is re-implementing in C++ and C discarded Nomen Nescio <nobody@dizum.com> - 2012-08-26 12:34 +0200
Re: GCC is re-implementing in C++ and C discarded "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2012-08-25 23:52 +0000
Re: GCC is re-implementing in C++ and C discarded Fritz Wuehler <fritz@spamexpire-201208.rodent.frell.theremailer.net> - 2012-08-30 03:18 +0200
Re: GCC is re-implementing in C++ and C discarded Kenneth Brody <kenbrody@spamcop.net> - 2012-08-27 13:41 -0400
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-27 15:23 -0700
Re: GCC is re-implementing in C++ and C discarded Kenneth Brody <kenbrody@spamcop.net> - 2012-08-29 10:55 -0400
Re: GCC is re-implementing in C++ and C discarded Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-25 03:14 -0700
Re: GCC is re-implementing in C++ and C discarded Rui Maciel <rui.maciel@gmail.com> - 2012-08-25 11:18 +0100
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-25 12:18 -0700
Re: GCC is re-implementing in C++ and C discarded lovecreatesbeauty <lovecreatesbeauty@gmail.com> - 2012-08-26 20:06 -0700
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-26 21:04 -0700
Re: GCC is re-implementing in C++ and C discarded lovecreatesbeauty <lovecreatesbeauty@gmail.com> - 2012-08-27 00:19 -0700
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-27 01:33 -0700
Re: GCC is re-implementing in C++ and C discarded James Kuyper <jameskuyper@verizon.net> - 2012-08-27 08:26 -0400
Re: GCC is re-implementing in C++ and C discarded lovecreatesbeauty <lovecreatesbeauty@gmail.com> - 2012-08-27 07:36 -0700
Re: GCC is re-implementing in C++ and C discarded Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-27 17:48 +0200
Re: GCC is re-implementing in C++ and C discarded Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-28 06:15 -0700
Re: GCC is re-implementing in C++ and C discarded James Kuyper <jameskuyper@verizon.net> - 2012-08-27 12:27 -0400
Re: GCC is re-implementing in C++ and C discarded Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-27 19:11 +0200
Re: GCC is re-implementing in C++ and C discarded James Kuyper <jameskuyper@verizon.net> - 2012-08-27 13:38 -0400
Re: GCC is re-implementing in C++ and C discarded Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-27 21:48 +0200
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-27 21:54 +0200
Re: GCC is re-implementing in C++ and C discarded Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-27 21:56 +0200
Re: GCC is re-implementing in C++ and C discarded James Kuyper <jameskuyper@verizon.net> - 2012-08-27 16:09 -0400
Re: GCC is re-implementing in C++ and C discarded Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-27 22:14 +0200
Re: GCC is re-implementing in C++ and C discarded lovecreatesbeauty <lovecreatesbeauty@gmail.com> - 2012-08-27 18:25 -0700
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-27 18:34 -0700
Re: GCC is re-implementing in C++ and C discarded eq mail <eq.mail.id@gmail.com> - 2012-08-27 18:45 -0700
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-27 19:24 -0700
Re: GCC is re-implementing in C++ and C discarded Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 07:00 -0700
Re: GCC is re-implementing in C++ and C discarded lovecreatesbeauty <lovecreatesbeauty@gmail.com> - 2012-08-27 23:47 -0700
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-28 01:27 -0700
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-27 15:20 -0700
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 00:55 +0200
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-27 16:43 -0700
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 09:01 +0200
Re: GCC is re-implementing in C++ and C discarded ais523 <ais523@bham.ac.uk> - 2012-08-27 23:16 +0000
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-27 17:34 -0700
Re: GCC is re-implementing in C++ and C discarded Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-28 03:16 +0200
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 09:07 +0200
Re: GCC is re-implementing in C++ and C discarded Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-28 13:47 +0200
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 16:17 +0200
Re: GCC is re-implementing in C++ and C discarded lawrence.jones@siemens.com - 2012-08-31 17:40 -0400
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-09-02 00:59 +0200
Re: GCC is re-implementing in C++ and C discarded Szabolcs Nagy <nsz@port70.net> - 2012-09-03 00:31 +0000
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-09-03 08:31 +0200
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-09-03 09:13 +0200
Re: GCC is re-implementing in C++ and C discarded Ike Naar <ike@iceland.freeshell.org> - 2012-09-03 15:38 +0000
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-09-03 18:38 +0200
Re: GCC is re-implementing in C++ and C discarded Ike Naar <ike@iceland.freeshell.org> - 2012-09-03 17:04 +0000
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-09-03 23:19 +0200
Re: GCC is re-implementing in C++ and C discarded Herbert Rosenau <os2guy@pc-rosenau.de> - 2012-09-03 21:48 +0200
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-09-03 23:41 +0200
Re: GCC is re-implementing in C++ and C discarded Richard Damon <news.x.richarddamon@xoxy.net> - 2012-09-03 19:37 -0400
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-09-04 10:14 +0200
Re: GCC is re-implementing in C++ and C discarded Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 07:18 -0700
Re: GCC is re-implementing in C++ and C discarded ais523 <ais523@bham.ac.uk> - 2012-08-28 01:40 +0000
Re: GCC is re-implementing in C++ and C discarded Kenneth Brody <kenbrody@spamcop.net> - 2012-08-29 11:02 -0400
Re: GCC is re-implementing in C++ and C discarded James Kuyper <jameskuyper@verizon.net> - 2012-08-27 22:29 -0400
Re: GCC is re-implementing in C++ and C discarded Rui Maciel <rui.maciel@gmail.com> - 2012-08-28 21:11 +0100
Re: GCC is re-implementing in C++ and C discarded Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-29 01:38 +0200
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-28 17:12 -0700
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-27 18:41 +0200
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-27 15:08 -0700
Re: GCC is re-implementing in C++ and C discarded James Kuyper <jameskuyper@verizon.net> - 2012-08-27 22:41 -0400
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-28 00:55 +0200 |
| Message-ID | <503BFAD7.30202@loria.fr> |
| In reply to | #25144 |
Am 28.08.2012 00:20, schrieb Keith Thompson:
> Jens Gustedt <jens.gustedt@loria.fr> writes:
>> Am 27.08.2012 21:48, schrieb Vincenzo Mercuri:
>>> That's the point. If you say that "int main(void)" is equivalent to
>>> "int main()" then you are saying that it is also equivalent to
>>> "int main(int argc, char **argv, char **env)" or "int main(int argc)",
>>> but I'm not convinced that compilers are obliged to support all these
>>> definitions.
>>
>> No "int main()" is equivalent to "int main(void)" for
>> definitions. There is this extra rule for definitions (versus just
>> declarations) such that these two are equivalent.
>
> Definitions also provide declarations.
Yes. But the declaration that is given through the definition does not
necessarily follow the same rules as one provided by a
declaration-only.
As James has already cited upthread
6.7.6.3p14: "An empty list in a function declarator that is part of a
definition of that function specifies that the function has no parameters."
> This program contains a constraint violation:
>
> int main(void) {
> if (0) main(42);
> return 0;
> }
>
> This one, I argue, is strictly conforming (its behavior would be
> undefined if the call were executed).
>
> int main() {
> if (0) main(42);
> return 0;
> }
so this function is specified as not receiving any parameters, just as
the one with void. The definition in the standard for function
prototype is
A *function prototype* is a declaration of a function that declares
the types of its parameters.
(ARAIK there is no syntax specification for prototypes.)
So this is a prototype: as you said it is a declaration, and it
specifies the types of its parameters, here in particular that there
are none. So really this is equivalent to the "(void)"
definition/declaration.
> On the other hand, I believe it was *intended* for `int main()` to be
> valid; requiring the `void` keyword would have broken existing pre-ANSI
> code.
It is intended to be valid and it is valid.
> But `int main(void)` (if you don't need argc and argv) is better for
> newly written C programs.
agreed
Jens
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-08-27 16:43 -0700 |
| Message-ID | <ln8vczc34h.fsf@nuthaus.mib.org> |
| In reply to | #25148 |
Jens Gustedt <jens.gustedt@loria.fr> writes:
> Am 28.08.2012 00:20, schrieb Keith Thompson:
[...]
>> This program contains a constraint violation:
>>
>> int main(void) {
>> if (0) main(42);
>> return 0;
>> }
>>
>> This one, I argue, is strictly conforming (its behavior would be
>> undefined if the call were executed).
>>
>> int main() {
>> if (0) main(42);
>> return 0;
>> }
>
> so this function is specified as not receiving any parameters, just as
> the one with void. The definition in the standard for function
> prototype is
>
> A *function prototype* is a declaration of a function that declares
> the types of its parameters.
>
> (ARAIK there is no syntax specification for prototypes.)
Does a definition with empty parenthese provide a declaration
that causes a call with parameters to be a constraint violation?
Does the second program require a diagnostic on the `main(42)` call?
Of the several compilers I've tried, only one complains about the
call, and it issues the same warning when the call is correct:
`main()` rather than `main(42)`. In all cases, I used command-line
options intended to enforce standard compliance. That doesn't prove
anything except that a number of C compiler implementers disagree
with your interpretation, at least implicitly. Did they all get
it wrong?
The compilers I tried were gcc, Solaris cc, lcc-win, and clang.
lcc-win warned "Missing prototype for 'main'" on the call --
regardless of whether the call includes an argument.
> So this is a prototype: as you said it is a declaration, and it
> specifies the types of its parameters, here in particular that there
> are none. So really this is equivalent to the "(void)"
> definition/declaration.
Consider this:
void foo() { }
void bar(n) int n; { }
The definition of `foo` specifies that it has no parameters.
The definition of `bar` specifies that it has one parameter of
type int. I believe that neither definition provides a prototype or
requires a diagnostic for a call with the wrong number of arguments.
At the very least, the current wording in the standard *can
reasonably be interpreted* so that `int main() { }` and `int
main(void) { }` are not equivalent. I'd like to see this clarified
by the committee. I've specifically proposed, in comp.std.c, adding
an explicit statement that `int main() { }` is valid -- though I'd
actually prefer removing function declarations and definitions with
empty parentheses from the language altogether, after they've been
"obsolescent" since 1989. (Existing code without prototypes can
be handled by older compilers, or by non-conforming options in
newer compilers.)
And if `void foo() { }` does provide a prototype, then *that*
needs to be made clearer; there are a lot of compilers that fail
to warn about calls like `foo(42)`.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-28 09:01 +0200 |
| Message-ID | <503C6CD9.3050509@loria.fr> |
| In reply to | #25155 |
Am 28.08.2012 01:43, schrieb Keith Thompson:
> Jens Gustedt <jens.gustedt@loria.fr> writes:
> And if `void foo() { }` does provide a prototype, then *that*
> needs to be made clearer; there are a lot of compilers that fail
> to warn about calls like `foo(42)`.
Please re-read what I have stated in my previous post. The definition
of the term function prototype is not given syntactically but
semantically: a declaration of a function that declares the types of
its parameters, that's it.
void foo() { }
perfectly fits this definition, so this declaration includes a
prototype.
The only nitpick that you could find here is the use of "specifies"
versus "declares", so one could want to do a corrigendum
6.7.6.3p14: "An empty list in a function declarator that is part of a
definition of that function *declares* that the function has no
parameters."
But you'd have to do a lot of hairsplitting to actually see the
difference between a "declaration that specifies something" and a
"declaration that declares something".
Jens
[toc] | [prev] | [next] | [standalone]
| From | ais523 <ais523@bham.ac.uk> |
|---|---|
| Date | 2012-08-27 23:16 +0000 |
| Message-ID | <k1gv4k$cdt$1@dont-email.me> |
| In reply to | #25144 |
Keith Thompson wrote:
> This one, I argue, is strictly conforming (its behavior would be
> undefined if the call were executed).
>
> int main() {
> if (0) main(42);
> return 0;
> }
Which language is this? There's some doubt about whether "int main()" is
valid in a hosted C implementation (although it seems to work well in
practice), and although it's legal in C++, the recursive call to main is
illegal in C++, so the program still doesn't conform properly.
--
ais523
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-08-27 17:34 -0700 |
| Message-ID | <lnk3wj26sd.fsf@nuthaus.mib.org> |
| In reply to | #25152 |
ais523 <ais523@bham.ac.uk> writes:
> Keith Thompson wrote:
>> This one, I argue, is strictly conforming (its behavior would be
>> undefined if the call were executed).
>>
>> int main() {
>> if (0) main(42);
>> return 0;
>> }
>
> Which language is this? There's some doubt about whether "int main()" is
> valid in a hosted C implementation (although it seems to work well in
> practice), and although it's legal in C++, the recursive call to main is
> illegal in C++, so the program still doesn't conform properly.
It's C, of course; I rarely post C++ code in comp.lang.c.
Recursive calls to main() are legal in C.
What do you mean by "valid"? If you mean that it's a constraint
violation, requiring a diagnostic, I disagree, and I'll ask you
to cite the standard to support your claim. If you mean that the
behavior is undefined, that's the point we're debating.
Though now that you mention it, I've stated my position incorrectly.
I've argued that just defining `int main() { ... }` has undefined
behavior, since it's not equivalent to `int main(void) { ... }`;
in that case, the above program is obviously not strictly conforming.
Let me restate my position more consistently.
I think we can all agree that this program is strictly conforming:
int main(void) { } /* program 1 */
Let us assume for the sake of argument that this program:
int main() { } /* program 2 */
is strictly conforming, because the two forms (`()` vs. `(void)`) are
"equivalent" as required by N1570 5.1.2.2.1p1.
I think we can agree that this program:
int main(void) { /* program 3 */
if (0) main(42);
}
violates a constraint, due to the call `main(42)`. But then this
program:
int main() { /* program 4 */
if (0) main(42);
}
would also violate a constraint, given that `int main(){}` and
`int main(void){}` are equivalent definitions.
My argument is that `int main(){}` and `int main(void){}` are *not*
equivalent definitions, since the latter provides a prototype and
the former does not. And therefore any program that defines `main`
as `int main()` has undefined behavior according to the current
wording (but perhaps not the intent) of the C standard -- unless the
implementation explicitly documents that it permits `int main(){}`,
as provided by the phrase "or in some other implementation-defined
manner" at the end of 5.1.1.2.2.1p1.
Even if the behavior is undefined, a compiler is free to accept
`int main() { }` without complaint, and every compiler I've tried
does so.
Removing `main` from the debate for a moment, clearly the following
function definition is valid:
void foo() { }
But does this function definition:
void foo() {
if (0) foo(42);
}
require a diagnostic?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> |
|---|---|
| Date | 2012-08-28 03:16 +0200 |
| Message-ID | <kZU_r.202688$GZ3.22168@tornado.fastwebnet.it> |
| In reply to | #25158 |
Il 28/08/2012 02:34, Keith Thompson ha scritto:
[..]
> Removing `main` from the debate for a moment, clearly the following
> function definition is valid:
>
> void foo() { }
>
> But does this function definition:
>
> void foo() {
> if (0) foo(42);
> }
>
> require a diagnostic?
>
I agree with what you said. I believe that there is no way to answer to
this question, unless the Standard explicitly says that, in such cases,
"void foo() { }" also provides a prototype for `foo()'.
--
Vincenzo Mercuri
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-28 09:07 +0200 |
| Message-ID | <503C6E35.3090905@loria.fr> |
| In reply to | #25160 |
Am 28.08.2012 03:16, schrieb Vincenzo Mercuri:
> Il 28/08/2012 02:34, Keith Thompson ha scritto:
> [..]
>> Removing `main` from the debate for a moment, clearly the following
>> function definition is valid:
>>
>> void foo() { }
>>
>> But does this function definition:
>>
>> void foo() {
>> if (0) foo(42);
>> }
>>
>> require a diagnostic?
>>
>
> I agree with what you said. I believe that there is no way to answer to
> this question, unless the Standard explicitly says that, in such cases,
> "void foo() { }" also provides a prototype for `foo()'.
But it says so implicitly. Prototypes are defined semantically
(6.2.1p2), not through syntax: a declaration of a function that
declares the types of its parameters. "void foo() { }" perfectly fits
in here, it is a definition and it specifies the number and type of
its parameters, namely none.
Jens
[toc] | [prev] | [next] | [standalone]
| From | Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> |
|---|---|
| Date | 2012-08-28 13:47 +0200 |
| Message-ID | <Dd2%r.202776$GZ3.120981@tornado.fastwebnet.it> |
| In reply to | #25194 |
Il 28/08/2012 09:07, Jens Gustedt ha scritto:
> Am 28.08.2012 03:16, schrieb Vincenzo Mercuri:
>> Il 28/08/2012 02:34, Keith Thompson ha scritto:
>> [..]
>>> Removing `main` from the debate for a moment, clearly the following
>>> function definition is valid:
>>>
>>> void foo() { }
>>>
>>> But does this function definition:
>>>
>>> void foo() {
>>> if (0) foo(42);
>>> }
>>>
>>> require a diagnostic?
>>>
>>
>> I agree with what you said. I believe that there is no way to answer to
>> this question, unless the Standard explicitly says that, in such cases,
>> "void foo() { }" also provides a prototype for `foo()'.
>
> But it says so implicitly. Prototypes are defined semantically
> (6.2.1p2), not through syntax: a declaration of a function that
> declares the types of its parameters. "void foo() { }" perfectly fits
> in here, it is a definition and it specifies the number and type of
> its parameters, namely none.
>
I'd have preferred the Standard to be more clear about that.
My "beloved clang" warns about "no previous prototype" even if such a
function is correctly defined before its call. If a definition with empty
parentheses provides a "degenerate case of prototype" should at least
be stated once and for all (even if I'd say that it would be a step
backward for the Standard: definitions/declarations with empty parentheses
have been "marked" as obsolescent since ANSI C). We also should correct
ourselves for the many times we have said that a prototype is a kind of
declaration but not all the function declarations are prototypes: now
we have to say that this is true for declarations themselves and false
for declarations provided by definitions? This would be much more
confusing.
I think the goal of a Standard should be to make things clearer, then
I'd expect the Standard to remove what it called "obsolescent" for more
than two decades :)
--
Vincenzo Mercuri
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-28 16:17 +0200 |
| Message-ID | <503CD2F0.9000401@loria.fr> |
| In reply to | #25225 |
Am 28.08.2012 13:47, schrieb Vincenzo Mercuri: > (even if I'd say that it would be a step > backward for the Standard: definitions/declarations with empty parentheses > have been "marked" as obsolescent since ANSI C). I only find the following: 6.11.6 Function declarators The use of function declarators with empty parentheses (not prototype-format parameter type declarators) is an obsolescent feature. 6.11.7 Function definitions The use of function definitions with separate parameter identifier and declaration lists (not prototype-format parameter type and identifier declarators) is an obsolescent feature. with what I said early this only makes declarations with empty list that are not definitions an obsolescent feature. And as we see from the start of the discussions, these should really be kept, for the sake of compatibility with C++. But I agree that all of this could be stated more directly :) Jens
[toc] | [prev] | [next] | [standalone]
| From | lawrence.jones@siemens.com |
|---|---|
| Date | 2012-08-31 17:40 -0400 |
| Message-ID | <rin7h9-3pd.ln1@jones.homeip.net> |
| In reply to | #25194 |
Jens Gustedt <jens.gustedt@loria.fr> wrote:
>
> But it says so implicitly. Prototypes are defined semantically
> (6.2.1p2), not through syntax: a declaration of a function that
> declares the types of its parameters. "void foo() { }" perfectly fits
> in here, it is a definition and it specifies the number and type of
> its parameters, namely none.
It's always been understood that a declaration of a function has to use
a parameter-type-list to declare the types of its parameters; being part
of an old-style definition that uses an (optional) identifier-list is
not sufficient, even though the definition does go on to declare them.
There are lots of tidbits scattered through the rest of the standard
that make it obvious that that was the committee's intent, but it could
have been stated more explicitly.
--
Larry Jones
I think football is a sport the way ducks think hunting is a sport. -- Calvin
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-09-02 00:59 +0200 |
| Message-ID | <50429362.8050300@loria.fr> |
| In reply to | #25677 |
Am 31.08.2012 23:40, schrieb lawrence.jones@siemens.com:
> Jens Gustedt <jens.gustedt@loria.fr> wrote:
>>
>> But it says so implicitly. Prototypes are defined semantically
>> (6.2.1p2), not through syntax: a declaration of a function that
>> declares the types of its parameters. "void foo() { }" perfectly fits
>> in here, it is a definition and it specifies the number and type of
>> its parameters, namely none.
>
> It's always been understood that a declaration of a function has to use
> a parameter-type-list to declare the types of its parameters;
Out of curiosity, why did the term prototype then never make it to a
syntactical definition? Do you agree with me that if we stick together
the current text as it stands we have that
- "void foo() { }" is a defintion of "foo"
- it is also a declaration
- it declares that "foo" has no parameters
- so it also declares the types of these parameters (namely none)
- so it is a declaration of "foo" that declares the type of its parameters
- according to 6.2.1p2 it is a prototype
> being part of an old-style definition that uses an (optional)
> identifier-list is not sufficient, even though the definition does
> go on to declare them. There are lots of tidbits scattered through
> the rest of the standard that make it obvious that that was the
> committee's intent, but it could have been stated more explicitly.
Honestly I didn't find much information that would really suggest
that. If I haves seen correctly, there are two examples in the
standard of "int main() { ... }". Doesn't suggest much that the
committee really wants everybody to move to the "int main(void) { ... }"
form.
I don't even think that is very productive to stick to that idea. Old
style function declarations with empty list that are not prototypes
should have disappeared since long. What is left is just a gratuitous
discrepancy to C++.
In any case, this deserves a DR and a clarification.
Jens
[toc] | [prev] | [next] | [standalone]
| From | Szabolcs Nagy <nsz@port70.net> |
|---|---|
| Date | 2012-09-03 00:31 +0000 |
| Message-ID | <k20toa$s89$1@speranza.aioe.org> |
| In reply to | #25710 |
Jens Gustedt <jens.gustedt@loria.fr> wrote:
> Out of curiosity, why did the term prototype then never make it to a
> syntactical definition? Do you agree with me that if we stick together
> the current text as it stands we have that
>
> - "void foo() { }" is a defintion of "foo"
> - it is also a declaration
> - it declares that "foo" has no parameters
> - so it also declares the types of these parameters (namely none)
> - so it is a declaration of "foo" that declares the type of its parameters
> - according to 6.2.1p2 it is a prototype
>
the type is not declared
> In any case, this deserves a DR and a clarification.
>
what about
http://www.open-std.org/JTC1/SC22/wg14/www/docs/dr_317.htm
so foo has no prototype, but i don't think this
contradicts the statement that
void foo() {}
and
void foo(void) {}
are equivalent function definitions
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-09-03 08:31 +0200 |
| Message-ID | <50444EDC.3070404@loria.fr> |
| In reply to | #25786 |
Am 03.09.2012 02:31, schrieb Szabolcs Nagy:
> Jens Gustedt <jens.gustedt@loria.fr> wrote:
>> Out of curiosity, why did the term prototype then never make it to a
>> syntactical definition? Do you agree with me that if we stick together
>> the current text as it stands we have that
>>
>> - "void foo() { }" is a defintion of "foo"
>> - it is also a declaration
>> - it declares that "foo" has no parameters
>> - so it also declares the types of these parameters (namely none)
>> - so it is a declaration of "foo" that declares the type of its parameters
>> - according to 6.2.1p2 it is a prototype
>>
>
> the type is not declared
I think that it is not easily apparent how an empty list could declare
the type of parameters that don't exist.
>> In any case, this deserves a DR and a clarification.
>>
>
> what about
>
> http://www.open-std.org/JTC1/SC22/wg14/www/docs/dr_317.htm
That is not what I meant by clarification. Do we want to have a state
where the standard can only be understood if you know about a body of
"judgements" by the committee that makes this or that interpretation
valid or not?
What I mean with clarification is to add something to the standard
that makes this situation clearer, the same way as it had been done
for the type-punning via unions, e.g.
What I even would prefer is to abandon all non-prototype declarations
and definitions. They have been declared obsolete since long. A first
step could be to exactly allow for the empty-list definition to be a
prototype. This would put C in accordance with C++ on that point, with
not much cost.
Jens
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-09-03 09:13 +0200 |
| Message-ID | <50445892.3060309@loria.fr> |
| In reply to | #25802 |
Am 03.09.2012 08:31, schrieb Jens Gustedt:
> Am 03.09.2012 02:31, schrieb Szabolcs Nagy:
>> Jens Gustedt <jens.gustedt@loria.fr> wrote:
>>> Out of curiosity, why did the term prototype then never make it to a
>>> syntactical definition? Do you agree with me that if we stick together
>>> the current text as it stands we have that
>>>
>>> - "void foo() { }" is a defintion of "foo"
>>> - it is also a declaration
>>> - it declares that "foo" has no parameters
>>> - so it also declares the types of these parameters (namely none)
>>> - so it is a declaration of "foo" that declares the type of its parameters
>>> - according to 6.2.1p2 it is a prototype
>>>
>>
>> the type is not declared
>
> I think that it is not easily apparent how an empty list could declare
> the type of parameters that don't exist.
And syntactically the only way to parse the parameter list of "void
foo(void);" according to the BNF of the standard is "D(
identifier-listopt )", too. So saying that the syntax distinguishes
the forms of specifying an empty list, is simply not true.
Jens
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2012-09-03 15:38 +0000 |
| Message-ID | <slrn3vfsk49jnr.74s.ike@iceland.freeshell.org> |
| In reply to | #25804 |
On 2012-09-03, Jens Gustedt <jens.gustedt@loria.fr> wrote: > And syntactically the only way to parse the parameter list of "void > foo(void);" according to the BNF of the standard is "D( > identifier-listopt )", too. So saying that the syntax distinguishes > the forms of specifying an empty list, is simply not true. (identifier-listopt) cannot expand to (void) because void is not an identifier (it's a keyword).
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-09-03 18:38 +0200 |
| Message-ID | <5044DD0A.4000807@loria.fr> |
| In reply to | #25839 |
Am 03.09.2012 17:38, schrieb Ike Naar: > On 2012-09-03, Jens Gustedt <jens.gustedt@loria.fr> wrote: >> And syntactically the only way to parse the parameter list of "void >> foo(void);" according to the BNF of the standard is "D( >> identifier-listopt )", too. So saying that the syntax distinguishes >> the forms of specifying an empty list, is simply not true. > > (identifier-listopt) cannot expand to (void) > because void is not an identifier (it's a keyword). Then it is even worse, and "void foo(void);" isn't captured by any of the documented syntax at all. So it couldn't be parsed. (But I don't think that there is a syntactical difference between identifier and keyword.) Jens
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2012-09-03 17:04 +0000 |
| Message-ID | <slrn3vfsk49oob.74s.ike@iceland.freeshell.org> |
| In reply to | #25844 |
On 2012-09-03, Jens Gustedt <jens.gustedt@loria.fr> wrote:
> Am 03.09.2012 17:38, schrieb Ike Naar:
>> On 2012-09-03, Jens Gustedt <jens.gustedt@loria.fr> wrote:
>>> And syntactically the only way to parse the parameter list of "void
>>> foo(void);" according to the BNF of the standard is "D(
>>> identifier-listopt )", too. So saying that the syntax distinguishes
>>> the forms of specifying an empty list, is simply not true.
>>
>> (identifier-listopt) cannot expand to (void)
>> because void is not an identifier (it's a keyword).
>
> Then it is even worse, and "void foo(void);" isn't captured by any of
> the documented syntax at all. So it couldn't be parsed.
(parameter-type-list)
--6.7.6--> (parameter-list)
--6.7.6--> (parameter-declaration)
--6.7.6--> (declaration-specifiers abstract-declaratoropt)
--6.7.6--> (declaration-specifiers)
--6.7--> (type-specifier)
--6.7.2--> (void)
> (But I don't think that there is a syntactical difference between
> identifier and keyword.)
There is. 6.4.1 p2,
"The above tokens (case sensitive) are reserved (in translation phases
7 and 8) for use as keywords, and shall not be used otherwise."
where void is one of the "above tokens" (6.4.1).
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-09-03 23:19 +0200 |
| Message-ID | <50451EE1.6040703@loria.fr> |
| In reply to | #25846 |
Am 03.09.2012 19:04, schrieb Ike Naar: > On 2012-09-03, Jens Gustedt <jens.gustedt@loria.fr> wrote: >> Then it is even worse, and "void foo(void);" isn't captured by any of >> the documented syntax at all. So it couldn't be parsed. > > (parameter-type-list) > --6.7.6--> (parameter-list) > --6.7.6--> (parameter-declaration) > --6.7.6--> (declaration-specifiers abstract-declaratoropt) > --6.7.6--> (declaration-specifiers) > --6.7--> (type-specifier) > --6.7.2--> (void) ah my bad, I had overlooked/forgotten that in 6.9.1p5 > If the declarator includes a parameter type list, the declaration of > each parameter shall include an identifier, there is this special exception > except for the special case of a parameter list consisting of a > single parameter of type void, in which case there shall not be an > identifier. Jens
[toc] | [prev] | [next] | [standalone]
| From | Herbert Rosenau <os2guy@pc-rosenau.de> |
|---|---|
| Date | 2012-09-03 21:48 +0200 |
| Message-ID | <k231hj$3h6$1@online.de> |
| In reply to | #25710 |
Am 02.09.2012 00:59, schrieb Jens Gustedt:
> Am 31.08.2012 23:40, schrieb lawrence.jones@siemens.com:
>> Jens Gustedt <jens.gustedt@loria.fr> wrote:
>>>
>>> But it says so implicitly. Prototypes are defined semantically
>>> (6.2.1p2), not through syntax: a declaration of a function that
>>> declares the types of its parameters. "void foo() { }" perfectly fits
>>> in here, it is a definition and it specifies the number and type of
>>> its parameters, namely none.
>>
>> It's always been understood that a declaration of a function has to use
>> a parameter-type-list to declare the types of its parameters;
>
> Out of curiosity, why did the term prototype then never make it to a
> syntactical definition? Do you agree with me that if we stick together
> the current text as it stands we have that
>
> - "void foo() { }" is a defintion of "foo"
> - it is also a declaration
> - it declares that "foo" has no parameters
No, it declares foo as a function with an unknown nuber of parameters
with onkown rypes each.
> - so it also declares the types of these parameters (namely none)
> - so it is a declaration of "foo" that declares the type of its parameters
> - according to 6.2.1p2 it is a prototype
No, it is not a prototype because a prototype needs a complete list of
parameters and theyr types.
int foo/(; ist only a declaration
int foo(void); is a prototype and also a declaration because it defines
a complete list of all the parameters (none(.
int foo(<type> (optional parameter name), ...); with at least one but
optionally more parameters. This is both a prototype and a declaration
too but with the special meaning that there after the full declaration
of the mandatory parameter(s) before the ,... is required and ,... can
be replaced at current call with a list of 0 to n parameters (see
fprintf() for example.
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-09-03 23:41 +0200 |
| Message-ID | <50452427.9020202@loria.fr> |
| In reply to | #25852 |
Am 03.09.2012 21:48, schrieb Herbert Rosenau:
> Am 02.09.2012 00:59, schrieb Jens Gustedt:
>> Am 31.08.2012 23:40, schrieb lawrence.jones@siemens.com:
>>> Jens Gustedt <jens.gustedt@loria.fr> wrote:
>>>>
>>>> But it says so implicitly. Prototypes are defined semantically
>>>> (6.2.1p2), not through syntax: a declaration of a function that
>>>> declares the types of its parameters. "void foo() { }" perfectly fits
>>>> in here, it is a definition and it specifies the number and type of
>>>> its parameters, namely none.
>>>
>>> It's always been understood that a declaration of a function has to use
>>> a parameter-type-list to declare the types of its parameters;
>>
>> Out of curiosity, why did the term prototype then never make it to a
>> syntactical definition? Do you agree with me that if we stick together
>> the current text as it stands we have that
>>
>> - "void foo() { }" is a defintion of "foo"
>> - it is also a declaration
>> - it declares that "foo" has no parameters
>
> No, it declares foo as a function with an unknown nuber of parameters
> with onkown rypes each.
How do you come to that "no". In 6.7.6.3p14 it says
> An empty list in a function declarator that is part of a definition of
> that function specifies that the function has no parameters.
so you are making the difference that a function "declarator" here
only "specifies" that the function has no parameters but the
declarator doesn't "declare" that it has no parameters?
Honestly, I am lost, linguistically.
I think term prototype should have been also defined by syntax,
perhaps in 6.2.5p20 where function types are introduced or even better
6.7.6.3p5 where a simple phrase could be added at the end:
> Only if it is of the form D( parameter-type-list ) the declaration
> provides a prototype for the function.
Jens
[toc] | [prev] | [next] | [standalone]
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web