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

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

labels at the end of a function

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

Contents

  labels at the end of a function Lynn McGuire <lynnmcguire5@gmail.com> - 2022-08-29 20:35 -0500
    Re: labels at the end of a function Thiago Adams <thiago.adams@gmail.com> - 2022-08-29 18:47 -0700
      Re: labels at the end of a function Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-29 21:50 -0700
        Re: labels at the end of a function Kaz Kylheku <480-992-1380@kylheku.com> - 2022-08-30 05:52 +0000
    Re: labels at the end of a function Sam <sam@email-scan.com> - 2022-08-29 22:42 -0400
      Re: labels at the end of a function Anton Shepelev <anton.txt@g{oogle}mail.com> - 2022-08-30 12:46 +0300
        Re: labels at the end of a function Juha Nieminen <nospam@thanks.invalid> - 2022-08-30 11:20 +0000
        Re: labels at the end of a function Opus <ifonly@youknew.org> - 2022-08-30 20:15 +0200
    Re: labels at the end of a function Ike Naar <ike@sdf.org> - 2022-08-30 05:50 +0000
      Re: labels at the end of a function Elephant <diespammer@yahoo.it> - 2022-08-30 10:14 +0200
    Re: labels at the end of a function Bo Persson <bo@bo-persson.se> - 2022-08-30 09:14 +0200
    Re: labels at the end of a function scott@slp53.sl.home (Scott Lurndal) - 2022-08-30 13:21 +0000
      Re: labels at the end of a function gazelle@shell.xmission.com (Kenny McCormack) - 2022-08-30 14:44 +0000
        Re: labels at the end of a function Lynn McGuire <lynnmcguire5@gmail.com> - 2022-08-30 16:08 -0500
          Re: labels at the end of a function Anton Shepelev <anton.txt@gmail.com> - 2022-08-31 01:04 +0300
    Re: labels at the end of a function Lynn McGuire <lynnmcguire5@gmail.com> - 2022-08-30 20:29 -0500

#167313 — labels at the end of a function

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

[toc] | [next] | [standalone]

#167315

On Monday, August 29, 2022 at 10:36:05 PM UTC-3, 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

aLabel:;

empty ; 

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

#167319

Thiago Adams <thiago.adams@gmail.com> writes:
> On Monday, August 29, 2022 at 10:36:05 PM UTC-3, 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
>
> aLabel:;
>
> empty ; 

One difference between C and C++ is that C++ allows a label to precede a
declaration, but C doesn't.  This is a side effect of the way C and C++
express the ability to mix declarations and statements within a block.
In C, a compound-statement contains a list of block-items, where a
block-item is a declaration or a statement (possibly a
labeled-statement).  In C++, a compound-statement contains a list of
statements, but a declaration in a block is syntactically a
declaration-statement.

C23 (as of N3047) permits labels anywhere in a block, including on a
declaration and (unlike C++) just before the closing "}".  It redefines
a block-item to be any of a declaration, an unlabeled-statement, or a
label.

{
    LABEL1:             // Invalid in C17, valid in C23 and C++
    int n = 42;
    LABEL2:             // Valid in C and C++
    printf("n = %d\n", n);
    LABEL3:;           // Valid in C and C++
    LABEL3:            // Valid in C23, invalid in C17 and C++
}

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

#167321

On 2022-08-30, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> One difference between C and C++ is that C++ allows a label to precede a
> declaration, but C doesn't.  This is a side effect of the way C and C++
> express the ability to mix declarations and statements within a block.
> In C, a compound-statement contains a list of block-items, where a
> block-item is a declaration or a statement (possibly a
> labeled-statement).  In C++, a compound-statement contains a list of
> statements, but a declaration in a block is syntactically a
> declaration-statement.

It wouldn't be standarization if they copied a feature from one
language to another, without sticking in gratutious quirky
differences.

This sounds like something you can get working in five minutes
if there is a Yacc grammar or similar.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

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

#167317

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.

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

#167326

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]

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

#167329

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.

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

#167346

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.

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

#167320

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;
    /* ... */
  }

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

#167325

On 8/30/22 07:50, Ike Naar wrote:

> or use ``return'' instead of ``goto'':
> 
>    int aMethod()
>    {
>      /* ... */
>      return;
>      /* ... */
>    }

Preferebly with a value, since the signature says the function returns 
an int :)

Seriously, the fact that the question was asked on a non void-returning 
function is an additional code-smell over the goto in itself.

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

#167323

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

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

#167331

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.

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

#167333

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

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

#167348

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

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

#167349

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'?

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

#167353

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

[toc] | [prev] | [standalone]

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

csiph-web