I just found out that a label at the end of a c/c++ function must have
an executable statement after it.

int aMethod ()
{ int aFakeVar = 0;

goto aLabel;

aLabel:

aFakeVar++;
}

Is there any way to get around the requirement of the executable
statement after the label ?

Thanks,
Lynn

On Monday, August 29, 2022 at 6:35:54 PM UTC-7, Lynn McGuire wrote:
> I just found out that a label at the end of a c/c++ function must have
> an executable statement after it.
>
> int aMethod ()
> {
> int aFakeVar = 0;
>
> goto aLabel;
>
> aLabel:
>
> aFakeVar++;
> }
>
> Is there any way to get around the requirement of the executable
> statement after the label ?
>
> Thanks,
> Lynn

Use an empty statement, i.e. "label:;".

On 8/29/2022 8:58 PM, Peter Klausler US wrote:
> On Monday, August 29, 2022 at 6:35:54 PM UTC-7, Lynn McGuire wrote:
>> I just found out that a label at the end of a c/c++ function must have
>> an executable statement after it.
>>
>> int aMethod ()
>> {
>> int aFakeVar = 0;
>>
>> goto aLabel;
>>
>> aLabel:
>>
>> aFakeVar++;
>> }
>>
>> Is there any way to get around the requirement of the executable
>> statement after the label ?
>>
>> Thanks,
>> Lynn
>
> Use an empty statement, i.e. "label:;".

Thanks for the advice. Sorry, I only meant to post to the C and C++ groups.

Lynn

Lynn McGuire writes:

> I just found out that a label at the end of a c/c++ function must have an
> executable statement after it.
>
> int aMethod ()
> {
> int aFakeVar = 0;
>
> goto aLabel;
>
> aLabel:
>
> aFakeVar++;
> }
>
> Is there any way to get around the requirement of the executable statement
> after the label ?

There are two options:

1) get rid of the label and the goto. The more goto-s get written, the more
likely is it for Chulhu to appear and bring humanity to an end. Very messy.

2) a single semicolon should be executable enough. I'm too lazy to check. In
any case

if (0)
;

will definitely work.

On Monday, August 29, 2022 at 6:58:43 PM UTC-7, Peter Klausler US wrote:

(snip)

> > Is there any way to get around the requirement of the executable
> > statement after the label ?

> Use an empty statement, i.e. "label:;".

It is called a null statement, but otherwise yes, it should work.

Since the function returns int, you will get a warning about no return statement.

You could put the return 0; or some other value, there.

On 2022-08-30, Lynn McGuire <lynnmcguire5@gmail.com> wrote:
> I just found out that a label at the end of a c/c++ function must have
> an executable statement after it.
>
> int aMethod ()
> {
> int aFakeVar = 0;
>
> goto aLabel;
>
> aLabel:
>
> aFakeVar++;
> }
>
> Is there any way to get around the requirement of the executable
> statement after the label ?

Put an empty statement after the label:

int aMethod()
{
/* ... */
goto aLabel;
/* ... */
aLabel:
;
}

or use ``return'' instead of ``goto'':

int aMethod()
{
/* ... */
return;
/* ... */
}

On 2022-08-30 at 03:35, Lynn McGuire wrote:
> I just found out that a label at the end of a c/c++ function must have
> an executable statement after it.
>
> int aMethod ()
> {
>     int aFakeVar = 0;
>
>     goto aLabel;
>
>     aLabel:
>
>     aFakeVar++;
> }
>
> Is there any way to get around the requirement of the executable
> statement after the label ?
>

Not right now, but it will be allowed in C++23. :-)

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2324r2.pdf

Sam:

> The more goto-s get written, the more likely is it for
> Chulhu to appear and bring humanity to an end.

I disagree. Structured use of GOTO's (the topic of a Knuch
article!), especially when they jump down and nest stack-
like can greately simplify certain code structures. They
help to avoid returns from mid-function, and let the
programmer execute common deinitialisation code. My standard
pattern of error-handling is based on GOTO's:

https://nedbatchelder.com/text/exceptions-vs-status.html#comment_15239

--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]

In comp.lang.c++ Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:
>> The more goto-s get written, the more likely is it for
>> Chulhu to appear and bring humanity to an end.
>
> I disagree. Structured use of GOTO's (the topic of a Knuch
> article!), especially when they jump down and nest stack-
> like can greately simplify certain code structures. They
> help to avoid returns from mid-function, and let the
> programmer execute common deinitialisation code.

That may be true in C, but C++ throws a spanner in the works because
of one fun feature: Exceptions.

If running the deinitialization code is crucial (or else for example
resources will be leaked, such as file handles left open), it won't
be run no matter how many gotos you use if anything along the line
throws an exception and it's not caught.

This is one of the main reasons to use RAII instead of gotos: Object
destructors will always be run no matter how the function is exited,
be it an early return, be it an exception.

As a bonus, if you implement it properly, the code will actually become
cleaner.

Lynn McGuire <lynnmcguire5@gmail.com> writes:
>I just found out that a label at the end of a c/c++ function must have
>an executable statement after it.
>
>int aMethod ()
>{
> int aFakeVar = 0;
>
> goto aLabel;
>
> aLabel:
>
> aFakeVar++;
>}
>
>Is there any way to get around the requirement of the executable
>statement after the label ?

Your function is missing a return statement.

In article <99oPK.21145$6Il8.5192@fx14.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>Lynn McGuire <lynnmcguire5@gmail.com> writes:
>>I just found out that a label at the end of a c/c++ function must have
>>an executable statement after it.
>>
>>int aMethod ()
>>{
>> int aFakeVar = 0;
>>
>> goto aLabel;
>>
>> aLabel:
>>
>> aFakeVar++;
>>}
>>
>>Is there any way to get around the requirement of the executable
>>statement after the label ?
>
>Your function is missing a return statement.

Or they misspelled "void" as "int".

P.S. Why is this also posted to a Fortran group?

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/InsaneParty

Le 30/08/2022 à 11:46, Anton Shepelev a écrit :
> Sam:
>
>> The more goto-s get written, the more likely is it for
>> Chulhu to appear and bring humanity to an end.
>
> I disagree. Structured use of GOTO's (the topic of a Knuch
> article!), especially when they jump down and nest stack-
> like can greately simplify certain code structures. They
> help to avoid returns from mid-function, and let the
> programmer execute common deinitialisation code. My standard
> pattern of error-handling is based on GOTO's:
>
> https://nedbatchelder.com/text/exceptions-vs-status.html#comment_15239

This is a relatively common pattern in C, and I also use it occasionally
(meaning, not in all cases.)

I find it quirky though, and it works for lack of better flow control in
C. Something that is sometimes implemented as "defer" in other languages.

On Tuesday, August 30, 2022 at 7:44:23 AM UTC-7, Kenny McCormack wrote:

(snip)

> P.S. Why is this also posted to a Fortran group?

I believe it was accidental, but since you could call it
with the C interoperability feature, it might be applicable.

On 8/30/2022 9:44 AM, Kenny McCormack wrote:
> In article <99oPK.21145$6Il8.5192@fx14.iad>,
> Scott Lurndal <slp53@pacbell.net> wrote:
>> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>>> I just found out that a label at the end of a c/c++ function must have
>>> an executable statement after it.
>>>
>>> int aMethod ()
>>> {
>>> int aFakeVar = 0;
>>>
>>> goto aLabel;
>>>
>>> aLabel:
>>>
>>> aFakeVar++;
>>> }
>>>
>>> Is there any way to get around the requirement of the executable
>>> statement after the label ?
>>
>> Your function is missing a return statement.
>
> Or they misspelled "void" as "int".
>
> P.S. Why is this also posted to a Fortran group?

Because I typed comp.lang.c into Thunderbird and Thunderbird graciously
also put comp.lang.fortran in there for me which I did not notice.

Lynn

gah4 <gah4@u.washington.edu> schrieb:
> On Tuesday, August 30, 2022 at 7:44:23 AM UTC-7, Kenny McCormack wrote:
>
> (snip)
>
>> P.S. Why is this also posted to a Fortran group?
>
> I believe it was accidental, but since you could call it
> with the C interoperability feature, it might be applicable.

Fortran has no problem with labels at the end of subroutines
or functions. This is legal:

subroutine a
goto 100
100 end subroutine a

although good style would seem to advise

subroutine a
goto 100
100 continue
end subroutine a

(The "continue" statement is a do-nothing placeholder).

On Tuesday, August 30, 2022 at 2:24:18 PM UTC-7, Thomas Koenig wrote:

(snip)

> Fortran has no problem with labels at the end of subroutines
> or functions. This is legal:
> subroutine a
> goto 100
> 100 end subroutine a
> although good style would seem to advise
> subroutine a
> goto 100
> 100 continue
> end subroutine a
> (The "continue" statement is a do-nothing placeholder).

It didn't always do that.

In Fortran 66, and I believe 77, END is a non-executable statement.
You are supposed to have STOP or RETURN (or GOTO) before it.

I suspect many allowed one to skip the STOP or RETURN, but
still no label on END.

In any case, the C function with type other than void should have a
return with appropriate type. Compilers will usually give warning
or error if you don't. And then you can label the return.

Lynn McGuire to Kenny McCormack:

> > P.S. Why is this also posted to a Fortran group?
>
> Because I typed comp.lang.c into Thunderbird and
> Thunderbird graciously also put comp.lang.fortran in there
> for me which I did not notice.

Amazing grace. Did you mean `gratuitiously'?

On 8/29/2022 8:35 PM, Lynn McGuire wrote:
> I just found out that a label at the end of a c/c++ function must have
> an executable statement after it.
>
> int aMethod ()
> {
>     int aFakeVar = 0;
>
>     goto aLabel;
>
>     aLabel:
>
>     aFakeVar++;
> }
>
> Is there any way to get around the requirement of the executable
> statement after the label ?
>
> Thanks,
> Lynn

Thanks to all ! I now understand a little bit better. I've been
programming in Fortran for 47 years, C for 35 years, and C++ for 20
years. I always like learning a little bit more about each.

Lynn