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

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

Return statement: anything goes?

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

Contents

  Return statement: anything goes? BartC <bc@freeuk.com> - 2017-03-10 19:13 +0000
    Re: Return statement: anything goes? John Bode <jfbode1029@gmail.com> - 2017-03-10 11:59 -0800
      Re: Return statement: anything goes? Keith Thompson <kst-u@mib.org> - 2017-03-10 12:34 -0800
    Re: Return statement: anything goes? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-10 20:17 +0000
      Re: Return statement: anything goes? bart4858@gmail.com - 2017-03-10 13:17 -0800
        Re: Return statement: anything goes? Ian Collins <ian-news@hotmail.com> - 2017-03-11 10:30 +1300
        Re: Return statement: anything goes? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-11 01:25 +0000
          Re: Return statement: anything goes? BartC <bc@freeuk.com> - 2017-03-11 12:11 +0000
            Re: Return statement: anything goes? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-11 14:57 +0000
              Re: Return statement: anything goes? BartC <bc@freeuk.com> - 2017-03-11 16:31 +0000
                Re: Return statement: anything goes? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-11 17:47 +0000
                  Re: Return statement: anything goes? BartC <bc@freeuk.com> - 2017-03-11 17:57 +0000
                    Re: Return statement: anything goes? jameskuyper@verizon.net - 2017-03-11 10:59 -0800
                      Re: Return statement: anything goes? BartC <bc@freeuk.com> - 2017-03-11 19:34 +0000
                        Re: Return statement: anything goes? jameskuyper@verizon.net - 2017-03-11 11:59 -0800
                          Re: Return statement: anything goes? supercat@casperkitty.com - 2017-03-11 12:26 -0800
                      Re: Return statement: anything goes? supercat@casperkitty.com - 2017-03-11 12:22 -0800
                        Re: Return statement: anything goes? jameskuyper@verizon.net - 2017-03-11 12:42 -0800
                          Re: Return statement: anything goes? supercat@casperkitty.com - 2017-03-11 13:01 -0800
                    Re: Return statement: anything goes? Gordon Burditt <gordon@hammy.burditt.org> - 2017-03-13 16:25 -0500
              Re: Return statement: anything goes? Gareth Owen <gwowen@gmail.com> - 2017-03-11 16:43 +0000
                Re: Return statement: anything goes? BartC <bc@freeuk.com> - 2017-03-11 18:13 +0000
                  Re: Return statement: anything goes? BartC <bc@freeuk.com> - 2017-03-11 18:27 +0000
            Re: Return statement: anything goes? gordonb.rlpr3@burditt.org (Gordon Burditt) - 2017-03-13 16:18 -0500
          Re: Return statement: anything goes? supercat@casperkitty.com - 2017-03-11 12:44 -0800
        Re: Return statement: anything goes? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-11 07:43 -0800
          Re: Return statement: anything goes? BartC <bc@freeuk.com> - 2017-03-11 18:34 +0000
            Re: Return statement: anything goes? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-11 10:43 -0800
    Re: Return statement: anything goes? Keith Thompson <kst-u@mib.org> - 2017-03-10 12:27 -0800
    Re: Return statement: anything goes? Noob <root@127.0.0.1> - 2017-03-10 22:06 +0100
      Re: Return statement: anything goes? bart4858@gmail.com - 2017-03-10 13:26 -0800
        Re: Return statement: anything goes? antispam@math.uni.wroc.pl - 2017-03-12 05:29 +0000
          Re: Return statement: anything goes? BartC <bc@freeuk.com> - 2017-03-12 10:52 +0000
            Re: Return statement: anything goes? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-12 12:19 +0000
              Re: Return statement: anything goes? BartC <bc@freeuk.com> - 2017-03-12 12:51 +0000

Page 2 of 2 — ← Prev page 1 [2]

#105797

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> But this raises the question of why you would implement C at all.

He's not going to implement c. He may eventually implement his weird
idea of what C might be -- though I seriously doubt it. Mainly he's just
hypothesising in order to justify his endless desire to piss and moan.

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

#105802

On 11/03/2017 16:43, Gareth Owen wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> But this raises the question of why you would implement C at all.
>
> He's not going to implement c. He may eventually implement his weird
> idea of what C might be -- though I seriously doubt it.

I've done this before. At the minute, the result of compiling this input:

#include <stdio.h>

int main(void) {
     printf("Hello World!\n");
}

is this intermediate code:

proc:main
   1 00000: +0000 *8/4    sub         rstack,  40
   2 00004: +0032 *8      load        r10,  "Hello World!\n"
   3 00004: +0032 *8      call        printf
   4 00004: +0032 *8/4    add         rstack,  32
   5 00004: +0000    L1:
   6 00004: +0000 *8/4    add         rstack,  40
   7 00004: +0000 *4      load        r0,  0
   8 00004: +0000         ret
   9 00004: +0000         ret

[Designed to map directly to x64. Intended to be processed into 
in-memory native code, fixed up, and executed directly. 'r10' 
corresponds to 'rcx' in normal x64 code.]

> Mainly he's just
> hypothesising in order to justify his endless desire to piss and moan.

Or maybe some people like to see if they can make things better, rather 
than pissing and moaning about people who piss and moan.

-- 
Bartc

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

#105804

On 11/03/2017 18:13, BartC wrote:

> int main(void) {
>     printf("Hello World!\n");
> }
>
> is this intermediate code:
>
> proc:main
>   1 00000: +0000 *8/4    sub         rstack,  40
>   2 00004: +0032 *8      load        r10,  "Hello World!\n"
>   3 00004: +0032 *8      call        printf
>   4 00004: +0032 *8/4    add         rstack,  32
>   5 00004: +0000    L1:
>   6 00004: +0000 *8/4    add         rstack,  40

Hmm, that should be adding 8 not 40. (Trying to share the same operand 
as #1, which was 8 but then merged with a 32 in the next instruction to 
make 40, didn't work...)

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

#105938

> I've decided not to support functions declared with with () parameters, 

What C compiler uses a "with" keyword?  I thought that was a Pascal,
Python and Visual Basic construct, and in Pascal it wasn't used
with parentheses?  Or am I just misinterpreting this statement?

> nor old-style parameter declarations, nor implicit int. At some point 
> it's necessary to draw the line.

So have the compiler bill for such constructs if the invoker chooses
not to let the compiler FIX them.

It would also be interesting to see the reaction to implicit bool
or implicit struct.

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

#105822

On Friday, March 10, 2017 at 7:26:00 PM UTC-6, Ben Bacarisse wrote:
> It's more a matter of matched the language standard.  That's why
> rejecting correct programs like:
> 
>   #include <stdio.h>
>   int f(void) { puts("OK"); }
>   int main(void) { f(); }
> 
> would create a new dialect.

How about a compiler that would reject:

    void *silly(void) { return (void*)0x12345; }
    int main(void) { silly(); return 0; }

There are no circumstances in which the Standard would require a compiler
to implement uintptr_t and intptr_t, and if a compiler does not define
such types there is no requirement that there exist any value of N other
than a literal zero (which is different syntactically from a constant
expression that happens to equal zero) such that (void*)N would be a valid
pointer.

As written, the Standard would not allow a compiler to refuse to execute a
program which contained function silly() but made no attempt to actually
do anything with its return value nor perform any other action whose behavior
was not defined by the Standard.  I would question, however, the usefulness
of requiring that compilers accept a syntactic construct for which they
define no useful meaning.  Note that a requirement that compilers accept
something like the above is different from a requirement that a compiler
accept e.g.

    int test(int n)
    {
      return n ? n : 1/n;
    }

where a compiler might know that the division will have no defined behavior
in any circumstances where it might execute, but the *syntax* would suggest
a value that is defined in most circumstances.  If there are *no* values
of N, other than a literal zero, such that (void*)N could yield a valid
pointer, is there any advantage to requiring that a compiler accept such a
syntax at all?  Would a compiler that rejected such a syntax be regarded as
compiling only a subset of "Standard C"?

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

#105793

On Friday, March 10, 2017 at 9:17:46 PM UTC, bart...@gmail.com wrote:
> On Friday, 10 March 2017 20:18:05 UTC, Ben Bacarisse  wrote:
> 

> Huh? Choosing to ignore or not take seriously what are obvious errors
> (see other replies) is compiling a dialect of the language?
> 
One issue is that code isn't always intended to be finished when it is
run. That's a big weakness of Java, often you have to build an
entire class, with callbacks defined, just to try out some routine
which might not even do what you want it to.

Bunging in a "return" is often a good way of debugging code. If it 
crashes when the return is taken out, that tells you that the crash
was after the statement.
Another issue is that some coding standards demand that every 
function return an int, which is 0 for success and -1 for failure.
 
But that's not always easy to define, e.g. a function that takes an 
image and returns rectangles enclosing faces. What should it return?
Not returning anything is arguably the best policy.

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

#105806

On 11/03/2017 15:43, Malcolm McLean wrote:
> On Friday, March 10, 2017 at 9:17:46 PM UTC, bart...@gmail.com wrote:
>> On Friday, 10 March 2017 20:18:05 UTC, Ben Bacarisse  wrote:
>>
>
>> Huh? Choosing to ignore or not take seriously what are obvious errors
>> (see other replies) is compiling a dialect of the language?

> Another issue is that some coding standards demand that every
> function return an int, which is 0 for success and -1 for failure.
>
> But that's not always easy to define, e.g. a function that takes an
> image and returns rectangles enclosing faces. What should it return?
> Not returning anything is arguably the best policy.

This is why in my own languages, there is a clear dividing line between 
functions and 'procedures'.

A function /has/ to return a value, and needs to be seen doing so before 
it runs into the end of the function. (Even if analysis might show it 
will never get to that point; it is easy enough to bung a dummy return 
in there.)

While procedures /can't/ return a value. They can only have an early 
return - without a value.


-- 
bartc

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

#105807

On Saturday, March 11, 2017 at 6:34:18 PM UTC, Bart wrote:
> On 11/03/2017 15:43, Malcolm McLean wrote:
> > On Friday, March 10, 2017 at 9:17:46 PM UTC, bart...@gmail.com wrote:
> >> On Friday, 10 March 2017 20:18:05 UTC, Ben Bacarisse  wrote:
> >>
> >
> >> Huh? Choosing to ignore or not take seriously what are obvious errors
> >> (see other replies) is compiling a dialect of the language?
> 
> > Another issue is that some coding standards demand that every
> > function return an int, which is 0 for success and -1 for failure.
> >
> > But that's not always easy to define, e.g. a function that takes an
> > image and returns rectangles enclosing faces. What should it return?
> > Not returning anything is arguably the best policy.
> 
> This is why in my own languages, there is a clear dividing line between 
> functions and 'procedures'.
> 
> A function /has/ to return a value, and needs to be seen doing so before 
> it runs into the end of the function. (Even if analysis might show it 
> will never get to that point; it is easy enough to bung a dummy return 
> in there.)
> 
> While procedures /can't/ return a value. They can only have an early 
> return - without a value.
> 
that distinction is important when writing a grammar.

theta = acos(dot(v1, v2))

is a legitimate expression because dot and acos are functions.

ptr = free(ptr);

is not, because free doesn't return a null to reset the passed pointer.

But froma programing perspective, if we can pass pointers or references,
it hardly matters.

point2 cursorpos = getmouse();

getmouse(&cursorpos);

what's the real difference there?

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

#105749

BartC <bc@freeuk.com> writes:
> This is something that came up last week, and was another example of C 
> compilers all reacting differently to the same errors.
>
> In this case, whether or not a return statement is present, and whether 
> it returns the correct type of expression:

See N1570 sections 6.9.1 (Function definitions) and 6.8.6.4 (The return
statement).

>    int V;
>
>    void A1(int x) { }
Valid.
>    void A2(int x) { return;}
Valid.
>    void A3(int x) { return 123;}
Constraint violation.

>    int B1(int x) { }
Valid, UB if the caller tries to use the result.
>    int B2(int x) { return;}
C90: Valid, UB if the caller tries to use the result.
C99 and later: Constraint violation.
>    int B3(int x) { return 123;}
Valid.
>    int B4(int x) { return &V;}
Constraint violation.
>    int B5(int x) { if (1) return x;}
Valid.

>    void* C1(int x) { }
Valid, UB if the caller tries to use the result.
>    void* C2(int x) { return;}
C90: Valid, UB if the caller tries to use the result.
C99 and later: Constraint violation.
>    void* C3(int x) { return 123;}
Constraint violation.
>    void* C4(int x) { return &V;}
Valid, the int* value is implicitly converted to void*.

>    int main(void) { }                // M1
C90: Valid, returns an undefined status to the environment.
C99 and later: Valid, does an implicit "return 0;" as of C99.
>    int main(void) { return;}         // M2
C90: Valid, returns an undefined status to the environment.
C99 and later: Constraint violation.
>    int main(void) { return 123;}     // M3
Valid.  (The value 123 might not be meaningful.)
>    int main(void) { return &V;}      // M4
Constraint violation.

I've tried to make this accurate, but I can't guarantee I've succeeded.

I'll leave it to you to decide which compilers are conforming or not,
and to which edition(s) of the standard.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#105761

On 10/03/2017 20:13, BartC wrote:

> This is something that came up last week, and was another example of C 
> compilers all reacting differently to the same errors.
> 
> In this case, whether or not a return statement is present, and whether 
> it returns the correct type of expression:
> 
>    int V;
> 
>    void A1(int x) { }
>    void A2(int x) { return;}
>    void A3(int x) { return 123;}
> 
>    int B1(int x) { }
>    int B2(int x) { return;}
>    int B3(int x) { return 123;}
>    int B4(int x) { return &V;}
>    int B5(int x) { if (1) return x;}
> 
>    void* C1(int x) { }
>    void* C2(int x) { return;}
>    void* C3(int x) { return 123;}
>    void* C4(int x) { return &V;}
> 
>    int main(void) { }                // M1
>    int main(void) { return;}         // M2
>    int main(void) { return 123;}     // M3
>    int main(void) { return &V;}      // M4
> 
> (The main() variations were tested one at a time.)
> 
> A selection of Windows C compilers gave these errors and warnings with 
> default options (E = error, W = warning, dash = no error):
> 
>              A1 A2 A3  B1 B2 B3 B4 B5  C1 C2 C3 C4  M1 M2 M3 M4
> 
>   Pelles C   -  -  W   W  E  -  E  -   -  E  E  -   -  E  -  E
>   lccwin     -  -  W   W  W  -  E  W   W  W  E  -   -  W  -  W
>   DMC        -  -  -   -  E  -  E  -   -  -  E  -   -  -  -  E
>   gcc/tdm    -  -  W   -  W  -  W  -   -  W  W  -   -  W  -  W
>   Tiny C     -  -  -   -  -  -  W  -   -  -  W  -   -  -  -  W
>   MSVC'08    -  -  W   W  W  -  W  -   W  W  W  -   -  -  -  -
> 
>   (bartc     -  -  E   E  E  -  E  E   E  E  E  -   *  E  -  E)
> 
> The last row shows what I consider to be errors, where I wouldn't be 
> happy with a wrong or missing return statement making it into code that 
> is to be executed.
> 
> It does rather seem that compiling C code is something of a lucky dip! 
> Surely source code is either correct or it isn't? Or is part of the 
> problem an attempt to keep compatibility with lax code and lax compilers 
> of the past?

What version of gcc are you testing with?
You might want to try running your test with
gcc -O2 -std=c99 -Wall -Werror

You'd get errors for A3, B1, B2, B4, C1, C2, C3.
(I didn't test the M* cases.)

Why do you expect an error for B5?

> [* I assume special rules apply to main(), in that a missing return 
> statement, or return expression, is quietly replaced by 'return 0']

No need to assume. You can look it up in the standard.

http://port70.net/~nsz/c/c11/
http://port70.net/~nsz/c/c99/

Regards.

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

#105764

On Friday, 10 March 2017 21:06:54 UTC, Noob  wrote:

> Why do you expect an error for B5?

I should have used 'if (x)' rather than 'if (1)'. I'll test again once I get my machine back (currently used for gaming).

(My own code would test that an explicit 'return expr;' is encountered before running into the closing '}'. A closing 'if' would need both branches and each would need to end with 'return'.)

-- 
bartc

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

#105846

bart4858@gmail.com wrote:
> On Friday, 10 March 2017 21:06:54 UTC, Noob  wrote:
> 
> > Why do you expect an error for B5?
> 
> I should have used 'if (x)' rather than 'if (1)'. I'll test again once I get my machine back (currently used for gaming).
> 
> (My own code would test that an explicit 'return expr;' is encountered before running into the closing '}'. A closing 'if' would need both branches and each would need to end with 'return'.)
> 

What about (assuming usual declaration of 'open' and 'exit'):

int
do_open(const char * fname)
{
   int fd = open(fname, O_RDONLY);
   if (fd < 0) {
       exit(1);
   } else {
       return fd;
   }
}

What about 'while'?  'if (x) return;' and 'while (x) return;'
do the same thing.

-- 
                              Waldek Hebisch

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

#105850

On 12/03/2017 05:29, antispam@math.uni.wroc.pl wrote:
> bart4858@gmail.com wrote:
>> On Friday, 10 March 2017 21:06:54 UTC, Noob  wrote:
>>
>>> Why do you expect an error for B5?
>>
>> I should have used 'if (x)' rather than 'if (1)'. I'll test again once I get my machine back (currently used for gaming).
>>
>> (My own code would test that an explicit 'return expr;' is encountered before running into the closing '}'. A closing 'if' would need both branches and each would need to end with 'return'.)
>>
>
> What about (assuming usual declaration of 'open' and 'exit'):
>
> int
> do_open(const char * fname)
> {
>    int fd = open(fname, O_RDONLY);
>    if (fd < 0) {
>        exit(1);
>    } else {
>        return fd;
>    }
> }

I checked the equivalent in other language where I implement this check, 
and that works (exit(1) is written 'stop 1', and 'stop' is acceptable too).

> What about 'while'?  'if (x) return;' and 'while (x) return;'
> do the same thing.

These would fail the check. However, since there will be doubtless be 
existing, working code that uses such constructs at the end of function, 
then I will probably have to suppress such a check in order to get it 
compiled.

Which makes it harder to detect what could be actual oversights.

(I'm not interested in warnings as I don't want normal compilations 
swamped with such messages. In the case of existing, working code, I 
would have to ignore warnings about 'while (x) return', but then, if I 
modify the code, then makes it harder to see fresh warnings about the 
code I've just changed.)

So the compromise would be to suppress the checks (except when compiling 
my own code which), and, where possible add a return statement with an 
apt return value (0, 0.0 or NULL) just in case.

-- 
bartc

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

#105852

BartC <bc@freeuk.com> writes:

> On 12/03/2017 05:29, antispam@math.uni.wroc.pl wrote:
>> bart4858@gmail.com wrote:
>>> On Friday, 10 March 2017 21:06:54 UTC, Noob  wrote:
>>>
>>>> Why do you expect an error for B5?
>>>
>>> I should have used 'if (x)' rather than 'if (1)'. I'll test again once I get my machine back (currently used for gaming).
>>>
>>> (My own code would test that an explicit 'return expr;' is encountered before running into the closing '}'. A closing 'if' would need both branches and each would need to end with 'return'.)
>>>
>>
>> What about (assuming usual declaration of 'open' and 'exit'):
>>
>> int
>> do_open(const char * fname)
>> {
>>    int fd = open(fname, O_RDONLY);
>>    if (fd < 0) {
>>        exit(1);
>>    } else {
>>        return fd;
>>    }
>> }
>
> I checked the equivalent in other language where I implement this
> check, and that works (exit(1) is written 'stop 1', and 'stop' is
> acceptable too).

That might be to miss antispam's point.  exit happens to be known to the
compiler but any function call it (or call a function that calls it...):

  if (C)
      print_error_and_exit("hey!);
  else return 42;

C11 has the _Noreturn function specifier.

<snip>
-- 
Ben.

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

#105854

On 12/03/2017 12:19, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>
>> On 12/03/2017 05:29, antispam@math.uni.wroc.pl wrote:
>>> bart4858@gmail.com wrote:
>>>> On Friday, 10 March 2017 21:06:54 UTC, Noob  wrote:
>>>>
>>>>> Why do you expect an error for B5?
>>>>
>>>> I should have used 'if (x)' rather than 'if (1)'. I'll test again once I get my machine back (currently used for gaming).
>>>>
>>>> (My own code would test that an explicit 'return expr;' is encountered before running into the closing '}'. A closing 'if' would need both branches and each would need to end with 'return'.)
>>>>
>>>
>>> What about (assuming usual declaration of 'open' and 'exit'):
>>>
>>> int
>>> do_open(const char * fname)
>>> {
>>>    int fd = open(fname, O_RDONLY);
>>>    if (fd < 0) {
>>>        exit(1);
>>>    } else {
>>>        return fd;
>>>    }
>>> }
>>
>> I checked the equivalent in other language where I implement this
>> check, and that works (exit(1) is written 'stop 1', and 'stop' is
>> acceptable too).
>
> That might be to miss antispam's point.  exit happens to be known to the
> compiler but any function call it (or call a function that calls it...):
>
>   if (C)
>       print_error_and_exit("hey!);
>   else return 42;

This shows the advantage of being able to stipulate that a non-void 
function /has/ to end with an explicit statement, either directly, or in 
each branch of a conditional. (Loops won't qualify, and 'switch' is too 
disorganised to do a proper check on.)

In the case of your example, that could just mean adding a dummy return 
statement (something the compiler might be obliged to do anyway), or 
rewriting it as:

    if (C)
        print_error_and_exit("hey!);
    return 42;

But as it is, I may have to forget the idea of doing such a check if the 
language and existing coding practices won't cooperate.

> C11 has the _Noreturn function specifier.

I doubt that would help much as the vast majority of code won't be using 
it. Not even new code (who's going to bother? It would also limit 
portability to C11 only).


-- 
bartc

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web