Hi,
when a function doesn't specify a return type ,value what value is
returned. In the below programme, the function sample()is returning the
value passed to 'k'.
sample(int);
main()
{
int i = 0,j;
j = sample(0);
printf("%d", j);
getch();
}
sample(k)
{
return;
} 15 6587
Greenhorn wrote: Hi, when a function doesn't specify a return type ,value what value is returned. In the below programme, the function sample()is returning the value passed to 'k'.
sample(int); main() { int i = 0,j; j = sample(0); printf("%d", j);
No declaration? (Hint: what are you including?) getch();
No such thing. }
sample(k) { return; }
It's undefined behavior. Could be anything. Or nasal demons might ensue.
(The only exception is that `main()' returns 0 in C99 if no value is
explicitly returned. You're not using C99; your program would have been
rejected for trying to use implicit int.)
Turn up the warning level on your compiler!
HTH,
--ag
--
Artie Gold -- Austin, Texas http://it-matters.blogspot.com (new post 12/5) http://www.cafepress.com/goldsays
In message <38*************@individual.net>
Artie Gold <ar*******@austin.rr.com> wrote: Greenhorn wrote: sample(k) { return; } It's undefined behavior. Could be anything. Or nasal demons might ensue. (The only exception is that `main()' returns 0 in C99 if no value is explicitly returned. You're not using C99; your program would have been rejected for trying to use implicit int.)
It would also have been rejected for that return - a "return" without a value
where one is required is now a constraint violation in C99.
--
Kevin Bracey, Principal Software Engineer
Tematic Ltd Tel: +44 (0) 1223 503464
182-190 Newmarket Road Fax: +44 (0) 1728 727430
Cambridge, CB5 8HE, United Kingdom WWW: http://www.tematic.com/
Kevin Bracey wrote: In message <38*************@individual.net> Artie Gold <ar*******@austin.rr.com> wrote:
Greenhorn wrote:
sample(k) { return; }
It's undefined behavior. Could be anything. Or nasal demons might ensue. (The only exception is that `main()' returns 0 in C99 if no value is explicitly returned. You're not using C99; your program would have been rejected for trying to use implicit int.)
It would also have been rejected for that return - a "return" without a value where one is required is now a constraint violation in C99.
Would it have gotten that far? Seems to me it wouldn't even parse.
--ag
--
Artie Gold -- Austin, Texas http://it-matters.blogspot.com (new post 12/5) http://www.cafepress.com/goldsays
Artie Gold <ar*******@austin.rr.com> writes: Kevin Bracey wrote: In message <38*************@individual.net> Artie Gold <ar*******@austin.rr.com> wrote:
Greenhorn wrote:
sample(k) { return; }
It's undefined behavior. Could be anything. Or nasal demons might ensue. (The only exception is that `main()' returns 0 in C99 if no value is explicitly returned. You're not using C99; your program would have been rejected for trying to use implicit int.) It would also have been rejected for that return - a "return" without a value where one is required is now a constraint violation in C99. Would it have gotten that far? Seems to me it wouldn't even parse.
"return;" is perfectly legal in a function returning void. It's
a semantic error, not a syntax error.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Keith Thompson wrote: Artie Gold <ar*******@austin.rr.com> writes:
Kevin Bracey wrote:
In message <38*************@individual.net> Artie Gold <ar*******@austin.rr.com> wrote:
Greenhorn wrote:
>sample(k) >{ > return; >} >
It's undefined behavior. Could be anything. Or nasal demons might ensue. (The only exception is that `main()' returns 0 in C99 if no value is explicitly returned. You're not using C99; your program would have been rejected for trying to use implicit int.)
It would also have been rejected for that return - a "return" without a value where one is required is now a constraint violation in C99.
Would it have gotten that far? Seems to me it wouldn't even parse.
"return;" is perfectly legal in a function returning void. It's a semantic error, not a syntax error.
Of course. But it's either a function returning int in C89 or nonsense
(no return type) in C99. That's what I referring to in my `wouldn't even
parse' comment.
Cheers,
--ag
--
Artie Gold -- Austin, Texas http://it-matters.blogspot.com (new post 12/5) http://www.cafepress.com/goldsays
Artie Gold <ar*******@austin.rr.com> writes: Keith Thompson wrote: Artie Gold <ar*******@austin.rr.com> writes:
[...]Would it have gotten that far? Seems to me it wouldn't even parse. "return;" is perfectly legal in a function returning void. It's a semantic error, not a syntax error. Of course. But it's either a function returning int in C89 or nonsense (no return type) in C99. That's what I referring to in my `wouldn't even parse' comment.
The term "parse" refers specifically to *syntactic* analysis.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Keith Thompson wrote: Artie Gold <ar*******@austin.rr.com> writes:
Keith Thompson wrote:
Artie Gold <ar*******@austin.rr.com> writes: [...] Would it have gotten that far? Seems to me it wouldn't even parse.
"return;" is perfectly legal in a function returning void. It's a semantic error, not a syntax error.
Of course. But it's either a function returning int in C89 or nonsense (no return type) in C99. That's what I referring to in my `wouldn't even parse' comment.
The term "parse" refers specifically to *syntactic* analysis.
Exactly.
And and it seems to me that:
sample(k)
{
return;
}
would choke on either the `(' or the `{'.
Cheers,
--ag
--
Artie Gold -- Austin, Texas http://it-matters.blogspot.com (new post 12/5) http://www.cafepress.com/goldsays
Artie Gold wrote: Keith Thompson wrote:
Artie Gold <ar*******@austin.rr.com> writes:
Keith Thompson wrote:
Artie Gold <ar*******@austin.rr.com> writes:
[...]
> Would it have gotten that far? Seems to me it wouldn't even parse.
"return;" is perfectly legal in a function returning void. It's a semantic error, not a syntax error.
Of course. But it's either a function returning int in C89 or nonsense (no return type) in C99. That's what I referring to in my `wouldn't even parse' comment. The term "parse" refers specifically to *syntactic* analysis. Exactly.
And and it seems to me that:
sample(k) { return; }
would choke on either the `(' or the `{'.
Cheers, --ag
Actually, I take that back -- `sample' itself would make no sense in
that context (it's not a type).
--ag
--
Artie Gold -- Austin, Texas http://it-matters.blogspot.com (new post 12/5) http://www.cafepress.com/goldsays
Artie Gold <ar*******@austin.rr.com> writes: Keith Thompson wrote: Artie Gold <ar*******@austin.rr.com> writes:
Keith Thompson wrote:
Artie Gold <ar*******@austin.rr.com> writes: [...]
>Would it have gotten that far? Seems to me it wouldn't even parse.
"return;" is perfectly legal in a function returning void. It's a semantic error, not a syntax error.
Of course. But it's either a function returning int in C89 or nonsense (no return type) in C99. That's what I referring to in my `wouldn't even parse' comment. The term "parse" refers specifically to *syntactic* analysis. Exactly.
And and it seems to me that:
sample(k) { return; }
would choke on either the `(' or the `{'.
I feel like we're arguing over the most trivial aspect of this, but ...
Parsing is based on the language grammar. The above is an old-style
definition, but let's make it explicit:
int sample(int k)
{
return;
}
The "return;" is invalid because it doesn't return a value. But this
is perfectly legal:
void sample(int k)
{
return;
}
The *parser*, when it see the "return;", doesn't remember what type
the containing function returns. The distinction between a valid
"return;" in a void function, and an invalid "return;" in an int
function, cannot be made by the parser. It can only be made during
semantic analysis.
Conceivably the grammar could have been defined with one syntax for a
void function definition (allowing "return;") and another for a
non-void function definition (disallowing "return;"). Fortunately,
this wan't necessary, since it's easy enough to detect the error
semantically.
In C99, this restriction is expressed as a constraint in 6.8.6.4p1:
A return statement with an expression shall not appear in a
function whose return type is void. A return statement without an
expression shall only appear in a function whose return type is
void.
In C90, a "return;" in a non-void function is allowed (a throwback to
K&R C, which didn't have void functions), but an attempt to use the
function result causes undefined behavior.
Incidentally, this is a distinction that the standard does not
(clearly) make. Both syntactic and semantic analysis occur during
translation phase 7. An implementation is free to mix the two in any
way it likes.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:
:The *parser*, when it see the "return;", doesn't remember what type
:the containing function returns. The distinction between a valid
:"return;" in a void function, and an invalid "return;" in an int
:function, cannot be made by the parser. It can only be made during
:semantic analysis.
:In C99, this restriction is expressed as a constraint in 6.8.6.4p1:
: A return statement with an expression shall not appear in a
: function whose return type is void. A return statement without an
: expression shall only appear in a function whose return type is
: void.
That's mostly detectable syntactically. One can do syntactic analysis
to determine whether one is inside a function definition or not,
inside a comment or not, inside an #define. Then the presence
of the word 'void' followed by an identifier followed by
one of the argument declaration forms, followed by a '{' intead of
a ';', places one -syntactically- inside a void function. At that
point, whether 'return' is followed by something other than ';'
is a matter of syntax.
I say "mostly detectable" because one can do all kinds of perverse
things with the preprocessor that cannot be syntactically detected
until after one has undergone semantic translation of the preprocessor
directives. Even excluding #define that expand to syntactic elements,
there is the issue of #if's that do not enclose balanced {}.
Also, even without #if and #define, it cannot be syntactically
detected by a simple standard regular expression, deterministic
FSA or non-deterministic FSA (all of which are, of course, equivilent
in expressive power), because standard RE's and FSA cannot handle
the necessary {} matching or "" matching. A simple push-down
automata can handle it, though, in the absence of preprocessor
managling.
--
Beware of bugs in the above code; I have only proved it correct,
not tried it. -- Donald Knuth ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes: In article <ln************@nuthaus.mib.org>, Keith Thompson <ks***@mib.org> wrote: :The *parser*, when it see the "return;", doesn't remember what type :the containing function returns. The distinction between a valid :"return;" in a void function, and an invalid "return;" in an int :function, cannot be made by the parser. It can only be made during :semantic analysis.
:In C99, this restriction is expressed as a constraint in 6.8.6.4p1:
: A return statement with an expression shall not appear in a : function whose return type is void. A return statement without an : expression shall only appear in a function whose return type is : void.
That's mostly detectable syntactically. One can do syntactic analysis to determine whether one is inside a function definition or not, inside a comment or not, inside an #define.
Comments are eliminated in translation phase 3; #defines vanish in
phase 4. Parsing (syntactic analysis) doesn't occur until phase 7, so
the parser will never see either comments or #defines.
Certainly the parser "knows" whether it's inside a function definition
(so a statement outside a function definition, for example, is a
syntax error).
Then the presence of the word 'void' followed by an identifier followed by one of the argument declaration forms, followed by a '{' intead of a ';', places one -syntactically- inside a void function. At that point, whether 'return' is followed by something other than ';' is a matter of syntax.
If you look at the syntax definition for a function-definition:
function-definition:
declaration-specifiers declarator declaration-list(opt) compound-statement
declaration-list:
declaration
declaration-list declaration
you'll see that it doesn't distinguish between void and non-void
functions.
To illustrate how one implementation does this (though of course that
doesn't prove anything about the standard):
% cat tmp.c
int foo(void)
{
return; /* line 3 */
}
return; /* line 6 */
% gcc -c -std=c99 tmp.c
tmp.c: In function `foo':
tmp.c:3: warning: `return' with no value, in function returning non-void
tmp.c: At top level:
tmp.c:6: error: parse error before "return"
The return statement outside the function definition causes a parse
error; the one inside the function definition is a semantic error.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Keith Thompson wrote:
.... snip ... If you look at the syntax definition for a function-definition:
function-definition: declaration-specifiers declarator declaration-list(opt) compound-statement declaration-list: declaration declaration-list declaration
you'll see that it doesn't distinguish between void and non-void functions.
Which is probably due to the BNF specified in the standard (haven't
checked). However there is no reason the parsing code cannot
differentiate and yield errors, nor that the BNF cannot be written
to separate functions and 'procedures'. In practice the freedom to
reorder components in the source (static const int vs const static
int etc.) makes this awkward. C has too many ways to arrive at the
same place.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
>Keith Thompson wrote: If you look at the [C89 or C99] syntax definition for a function-definition ... you'll see that it doesn't distinguish between void and non-void functions.
[He goes on to note that this is one reason C compilers treat
"return without a value in a non-void function" as a semantic error
rather than a syntactic one.]
In article <42***************@yahoo.com>
CBFalconer <cb********@worldnet.att.net> wrote:Which is probably due to the BNF specified in the standard (haven't checked).
That is what Keith Thompson just said. :-) The syntax in the
C standards is specified that way.
However there is no reason the parsing code cannot differentiate and yield errors, nor that the BNF cannot be written to separate functions and 'procedures'. In practice the freedom to reorder components in the source (static const int vs const static int etc.) makes this awkward. C has too many ways to arrive at the same place.
Indeed, this is true for C99. For C89, however, "return without a
value" *is* allowed, even in a non-void function:
double f(int *ip) {
if (ip != NULL) {
*ip = 1;
return;
}
return 3.1415926535897932384626433832795;
}
is a legal (albeit rather pointless) C89 function, which can be
called from code such as:
void g(void) {
int x;
double y;
f(&x);
y = f(NULL);
}
If you wish to accept syntactically-valid C89 code, then, you cannot
make "return without a value in non-void function" into the kind
of error that changes code-generation (syntax errors usually suppress
it entirely, or at the least, remove a few needed nodes from the
parse tree, so that wrong code will come out of the back end of
the compiler).
(Note that C compilers are always allowed to produce diagnostics,
even spurious ones, so:
foo.c, line 3: warning: in function f(): return without a value,
in function with return type "double"
is allowed, even in C89, even though the code is technically OK,
however ugly it may be.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:
|r*******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
|> In article <ln************@nuthaus.mib.org>,
|> Keith Thompson <ks***@mib.org> wrote:
|> :The *parser*, when it see the "return;", doesn't remember what type
|> :the containing function returns. The distinction between a valid
|> :"return;" in a void function, and an invalid "return;" in an int
|> :function, cannot be made by the parser. It can only be made during
|> :semantic analysis.
|> Then the presence
|> of the word 'void' followed by an identifier followed by
|> one of the argument declaration forms, followed by a '{' intead of
|> a ';', places one -syntactically- inside a void function. At that
|> point, whether 'return' is followed by something other than ';'
|> is a matter of syntax.
|If you look at the syntax definition for a function-definition:
|you'll see that it doesn't distinguish between void and non-void
|functions.
If you look at what you wrote, you said that certain kinds of
validity checks on 'return' statements "cannot be made by the
parser" and "can only be made during semantics analysis".
I showed that this is incorrect: that once past preprocessing,
a parser *could* syntatically determine whether a void function
had a non-void return.
I did not say that a parser -must- so determine, and I didn't
say that there was a distinction at the BNF level: I just pointed
out that the recognition *could* be made by the parser.
If you had written that the distinction "is not" made by the parser
then you would be talking about implimentation, and might be correct
for all existing parsers -- but you wrote "cannot", which means
"not possible", and I showed that at least part of it is possible.
--
Studies show that the average reader ignores 106% of all statistics
they see in .signatures. ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
[...] If you had written that the distinction "is not" made by the parser then you would be talking about implimentation, and might be correct for all existing parsers -- but you wrote "cannot", which means "not possible", and I showed that at least part of it is possible.
Ok, it's possible.
My original point was to refute someone else's statement that a
"return;" in a non-void function "wouldn't even parse". In fact it
could, and almost certainly would. I got a little carried away in
implying that it *must* parse.
You're right, a C99 compiler (but not a C90 compiler) *could* use
separate grammar productions for void and non-void function
definitions, and thereby catch "return;" as a syntax error. (There's
no requirement for a compiler to use the grammar in the standard, as
long as it uses one that lets it catch errors and process correct
code.) It would require some extra work for the case of a function
whose return type is a typedef for void, but that shouldn't be any
more difficult than typedef handling in general.
It would be a perverse implementation. Semantic errors are easier to
handle within the compiler than syntax errors. For a semantic error,
the compiler can just issue a diagnostic, set a flag indicating that
the compilation will fail, and move on; for a syntax error, it has to
either reconstruct a guessed valid parse so it can continue
processing, or give up and die.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: zealotcat |
last post by:
template <class T>
inline T const& max (T const& a, T const& b)
{
// if a < b then use b else use a
return a<b?b:a;
}
thanks very much!!
|
by: Grant Nosbush |
last post by:
I have searched the newsgroups and the web trying to solve this problem
and just can't get it. Maybe someone will be able to help. I am
getting the following error when I try to view a test page...
|
by: gambler |
last post by:
let's say you have:
var games = new Array();
games = new GAME(gameNum, rotNum1, rotNum2, ... );
(
so a sparsley populate array which enables me to locate a game usin
the game number...
|
by: vl106 |
last post by:
char* foo () {
return "abc";
}
I compiled the above code both with MSVC and GCC for PPC. The string
"abc" is generated as a global entity. Thus (1) foo doesn't return a
temporary
and (2) no...
|
by: Drum2001 |
last post by:
I have created a database to track employee time. Within that, I have
also created a report off the following query:
SELECT ALLTasksFilter.ProjectName,
Sum(.NumberOfCompletions) AS...
|
by: Jorgen [DK/2600] |
last post by:
Hi,
another problem I have is that have compounded fields in my sql table.
Example
product@customer
I need a simple function to return "customer", so it should return the value
after...
|
by: Peter K |
last post by:
Hi
I am having trouble writing a webservice which is to provide access to
the functions of an existing codebase. The existing code may not be
changed at all.
For example, I obtain an...
|
by: Wayne Shu |
last post by:
Hi everyone:
I am reading Bjarne Stroustrup's The C++ Programming
Language(Special Edition).
In section 7.3, bs wrote "Like the semantics of argument passing,
the semantics of function value...
|
by: stpgmn |
last post by:
I'm executing the following procedure within Access mdb. The query that I'm trying to run works nolrmally when executed as Query.
Do anybody has any idea of reason of the error?.
Thanks a lot
...
|
by: Mushico |
last post by:
How to calculate date of retirement from date of birth
|
by: DJRhino |
last post by:
Was curious if anyone else was having this same issue or not....
I was just Up/Down graded to windows 11 and now my access combo boxes are not acting right. With win 10 I could start typing...
|
by: Aliciasmith |
last post by:
In an age dominated by smartphones, having a mobile app for your business is no longer an option; it's a necessity. Whether you're a startup or an established enterprise, finding the right mobile app...
|
by: tracyyun |
last post by:
Hello everyone,
I have a question and would like some advice on network connectivity. I have one computer connected to my router via WiFi, but I have two other computers that I want to be able to...
|
by: giovanniandrean |
last post by:
The energy model is structured as follows and uses excel sheets to give input data:
1-Utility.py contains all the functions needed to calculate the variables and other minor things (mentions...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 1 Nov 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM)
Please note that the UK and Europe revert to winter time on...
|
by: nia12 |
last post by:
Hi there,
I am very new to Access so apologies if any of this is obvious/not clear.
I am creating a data collection tool for health care employees to complete. It consists of a number of...
|
by: NeoPa |
last post by:
Introduction
For this article I'll be focusing on the Report (clsReport) class. This simply handles making the calling Form invisible until all of the Reports opened by it have been closed, when it...
|
by: isladogs |
last post by:
The next online meeting of the Access Europe User Group will be on Wednesday 6 Dec 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, Mike...
| |