why are missing return statements from non-void functions not a
in [C++]
|
From: Goran Pusic on 29 Jul 2010 00:05 compilation error Organization: http://groups.google.com References: <af3b997e-24fd-4ef0-9e00-5fa6926d60d9(a)c16g2000vbp.googlegroups.com> Content-Type: text/plain; charset=ISO-8859-1 X-Clcppm-Sequence: 34100 X-Original-Date: Thu, 29 Jul 2010 01:02:09 -0700 (PDT) X-Submission-Address: c++-submit(a)netlab.cs.rpi.edu > So my question is, "why is this not a fatal compilation error?". Because that's how things were in C originally, and changing that would mean making some amount of C code bad for C++ compilation. But compatibility with C is important in C++. On the other hand, compilers (especially today) do warn you about these situations, so.. Use your tools. Why C didn't do anything about this, then? I'd guess because it was easier to write a compiler without checks, which was important for early C compilers ;-). Also, note that at the call site, you are not required to use return value, so ultimately e.g. this: int f(int g) { if (g==5) return 7; // and else? } int main(int, const char*[]) { int i = f(5); f(6); // don't care about result, nor is there one, too! } will work. Which is not to say that it's a good idea, but hey... Would you say that even K&R knew what would a good idea be when they wrote first C (same goes for many-a-language author)? For example, K&R thought worthwhile putting void strcpy(char* dest, const char* src) { while (*dest++ = *src++); } into their C book, but he who wrote this today would probably be called code red on in a code review. ;-) Goran. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Daniel Krügler on 29 Jul 2010 04:01 On 29 Jul., 17:05, Goran Pusic <gor...(a)cse-semaphore.com> wrote: > Also, note that at the call site, you are not required to use return > value, so ultimately e.g. this: > > int f(int g) > { > if (g==5) > return 7; > // and else? > } > > int main(int, const char*[]) > { > int i = f(5); > f(6); // don't care about result, nor is there one, too! > } > > will work. Sorry, this is nonsense. The above code produces undefined behavior, see 6.6.3/2: "Flowing off the end of a function is equivalent to a return with no value; this results in undefined behavior in a value-returning function." > Which is not to say that it's a good idea, but hey... Would you say > that even K&R knew what would a good idea be when they wrote first C > (same goes for many-a-language author)? For example, K&R thought > worthwhile putting > > void strcpy(char* dest, const char* src) > { > while (*dest++ = *src++); > } > > into their C book, but he who wrote this today would probably be > called code red on in a code review. ;-) I don't see anything wrong with that code. Greetings from Bremen, Daniel Kr�gler -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Goran Pusic on 29 Jul 2010 23:04 On Jul 29, 9:01 pm, Daniel Kr�gler <daniel.krueg...(a)googlemail.com> wrote: > On 29 Jul., 17:05, Goran Pusic <gor...(a)cse-semaphore.com> wrote: > > > > > Also, note that at the call site, you are not required to use return > > value, so ultimately e.g. this: > > > int f(int g) > > { > > if (g==5) > > return 7; > > // and else? > > } > > > int main(int, const char*[]) > > { > > int i = f(5); > > f(6); // don't care about result, nor is there one, too! > > } > > > will work. > > Sorry, this is nonsense. The above code produces undefined > behavior, see 6.6.3/2: > > "Flowing off the end of a function is equivalent to a return with > no value; this results in undefined behavior in a value-returning > function." Whoops... So this only worked on implementations I tried (blushes). BTW, is the situation the same for C language? > > void strcpy(char* dest, const char* src) > > { > > while (*dest++ = *src++); > > } > > > into their C book, but he who wrote this today would probably be > > called code red on in a code review. ;-) > > I don't see anything wrong with that code. Syntactically and functionally, me neither ;-). But my point was, to be explicit, this is an exercise in term evaluation and operator precedence that's IMO better left out of production code. Goran. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: A. McKenney on 30 Jul 2010 03:53 On Jul 29, 11:05 am, Goran Pusic <gor...(a)cse-semaphore.com> wrote: > compilation error > ... For example, K&R thought > worthwhile putting > > void strcpy(char* dest, const char* src) > { > while (*dest++ = *src++); > > } > > into their C book, but he who wrote this today would probably be > called code red on in a code review. ;-) At the time (1970's), that was excellent coding practice. On a PDP-11, that loop is two 16-bit instructions, and on an 11/45, it fits into the instruction pipe, so there aren't even any instruction fetches. A number of the oddities of the language design and common practice of C make perfect sense if you see it as a high-level assembler for a PDP-11 (the original target machine for Unix and C.) -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: nmm1 on 30 Jul 2010 04:54
In article <887d4191-2f3c-47b2-9489-b4bff994d131(a)u26g2000yqu.googlegroups.com>, A. McKenney <alan_mckenney1(a)yahoo.com> wrote: >On Jul 29, 11:05 am, Goran Pusic <gor...(a)cse-semaphore.com> wrote: >> compilation error > >> ... For example, K&R thought >> worthwhile putting >> >> void strcpy(char* dest, const char* src) >> { >> while (*dest++ = *src++); >> } >> >> into their C book, but he who wrote this today would probably be >> called code red on in a code review. ;-) > >At the time (1970's), that was excellent coding practice. Not at all. In most communities that took software quality seriously, it would have been regarded as very bad practice. Remember that C and Unix originated as a computer scientists' workbench, and its objectives were things like flexibility and modifiability - RAS and maintenance were scarcely considered, except as they impacted the main objectives. >On a PDP-11, that loop is two 16-bit instructions, and >on an 11/45, it fits into the instruction pipe, >so there aren't even any instruction fetches. > >A number of the oddities of the language design and >common practice of C make perfect sense if you see >it as a high-level assembler for a PDP-11 (the original >target machine for Unix and C.) That is very true. Regards, Nick Maclaren. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |