It is sometimes possible to use that style, but generally you will need nesting if you want to handle errors. I can't think of a decent embedded example that doesn't require reams of context, but here's an illustration using shared memory under Windows. Try to translate the following code snippet to the style you suggest:

errno_t get_shared_status( LPCTSTR fileName ) {
    errno_t result = E_UNKNOWN;
    HANDLE f = INVALID_HANDLE_VALUE;
    HANDLE fMap = NULL;
    LPVOID shm = NULL;
    MEMORY_BASIC_INFORMATION meminfo;
    SIZE_T shmLen = 0;

    f = CreateFile( fileName, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING,
        FILE_ATTRIBUTE_NORMAL, NULL );
    if ( f == INVALID_HANDLE_VALUE ) {
        result = E_SHM_ACCESS;
        log( "get_shared_status: CreateFile() failed with error %08x", GetLastError() );
        goto cleanupNone;
    }

    fMap = CreateFileMapping( f, NULL, PAGE_READONLY, 0, 0, NULL );
    if ( fMap == NULL ) {
        result = E_SHM_ACCESS;
        log( "get_shared_status: CreateFileMapping() failed with error %08x", GetLastError() );
        goto cleanupCreateFile;
    }

    shm = MapViewOfFile( fMap, FILE_MAP_READ, 0, 0, 0 );
    if ( shm == NULL ) {
        result = E_SHM_ACCESS;
        log( "get_shared_status: MapViewOfFile() failed with error %08x", GetLastError() );
        goto cleanupCreateFmap;
    }

    shmLen = VirtualQuery( shm, &meminfo, sizeof(meminfo) );
    if ( shmLen == 0 ) {
        result = E_SHM_ACCESS;
        log( "get_shared_status: VirtualQuery() failed with error %08x", GetLastError() );
        goto cleanupMapView;
    }
    if ( shmLen sizeof(meminfo) ) {
        result = E_SHM_ACCESS;
        log( "get_shared_status: VirtualQuery() returned too few bytes" );
        goto cleanupMapView;
    }

    if ( meminfo.RegionSize SHM_V1_SIZE ) {
        result = E_SHM_ACCESS;
        log( "get_shared_status: Shared memory file too small to interpret" );
        goto cleanupMapView;
    } //FIXME do stuff

cleanupMapView:
    if ( 0 == UnmapViewOfFile( shm ) ) {
        log( "get_shared_status: UnmapViewOfFile() failed with error %08x", GetLastError() );
    }
    shm = NULL;

cleanupFmap:
    if ( 0 == CloseHandle( fMap ) ) {
        log( "get_shared_status: CloseHandle(fMap) failed with error %08x", GetLastError() );
    }
    fMap = NULL;

cleanupCreateFile
    if ( 0 == CloseHandle( f ) ) {
        log( "get_shared_status: CloseHandle(f) failed with error %08x", GetLastError() );
    }
    f = INVALID_HANDLE_VALUE;

cleanupNone:
    return result;
}

Here's the start:

    f = CreateFile( fileName, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING,
        FILE_ATTRIBUTE_NORMAL, NULL );
    if ( f != INVALID_HANDLE_VALUE ) {
        fMap = CreateFileMapping( f, NULL, PAGE_READONLY, 0, 0, NULL );
    } else {
        result = E_SHM_ACCESS;
        log( "get_shared_status: CreateFile() failed with error %08x", GetLastError() );
    }

    if ( fMap != NULL ) {
        shm = MapViewOfFile( fMap, FILE_MAP_READ, 0, 0, 0 );
    } else { /*
** Oops - if CreateFile() failed we end up here! */
        result = E_SHM_ACCESS;
        log( "get_shared_status: CreateFileMapping() failed with error %08x", GetLastError() );
    }

As soon as you have a code path for exceptions you need nesting to match the error path with the code that led to it, or you will execute multiple error paths unintentionally. The 'goto' style has the same code order as try...finally would, with the 'goto' itself acting like 'throw'.

This is 2012. C is still used for on-the-metal programming of pretty much any embedded micro other than the Arduino. And C doesn't have try...finally. It has nested if statements, goto, or roll-your-own-goto using switch/for/while/do (which is just a style guide compliant obfuscated form of goto).

Yes. We used to do that in some of our source code bases. I always like how "important programmers" at "big companies" think 'goto' is verboten, but don't notice switch statements with fall-through cases. Because they're sooo much safer ;)

So I reversed that situation, and our incidence of resource handling errors went down markedly. As did our incidence of logic bugs from failing to break out of a switch.

In my opinion, obscuring the logic you're trying to express by using a workaround involving an arbitrarily "approved" keyword, obscures the logic.

Mmm. Yes. Very good class. Let's try again shall we?

Judicious use of GOTO can dramatically simplify resource cleanup when exception handling is not supported

And what is finally? That's right, it's part of the exception handling system. The concept of a "finally block" only makes sense if there are multiple paths by which the block can be reached (the normal path and the exceptional path); otherwise it would just be a statement at the end of the normal path.

Now, what about C? This is an important question because there are still (shock, horror!) some embedded environments that don't have a Java runtime environment. Why not, you may ask? Because they have 2kb code space and 512b memory!

So, what about C? Well, it doesn't have exception handling built in (more shock, more horror!). Instead, C programmers must check the result of each function call and branch to cleanup block if the result indicated an error.

</condescending >

Suit yourself, but I'll take Knuth over Dijkstra: http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf.

[citations needed]

Citations won't be found, because the explanation is incorrect. There is no technical issue with compilers implementing 'goto' so long as the destination is in the same lexical scope (C has this limitation). Nor is it worth considering execution context at the level of the CPU, as any high-level loop or branch instruction must be translated into one of a limited number of conditional or non-conditional, relative or absolute jumps. Ultimately whether you use 'goto' or some other control construct you are attempting to express the same programmatic flow, and the compiled instruction stream will be sufficiently similar that it's not worth splitting hairs over.

The reason 'goto' is "considered harmful" is because structured programming theorizes that any computable function can be expressed by combining simpler programs using sequence, selection and iteration; and this provides the opportunity for a constructive approach to program correctness. Dijkstra argues that we are cognitively limited and can benefit from code that is structured so that we can tell at any point where we are and where we have come from (a gross paraphrasing of what Dijkstra calls "coordinates"). But "[t]he unbridled use of the go to statement has as an immediate consequence that it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress". In other words careless use of 'goto' makes it hard to reason about your code.

Knuth contended that one could created structured programs with 'goto' statements, and provided examples of how 'goto' make the program more elegant.

It is important to realise that the claimed advantages of structured programming are undone by the use of break, continue, or exception handling. There are limited forms of goto, and using them prevents proofs of correctness (under the assumptions of structured programming; other techniques may be available) and reasoning using Dijkstra's "coordinates".

Judicious use of GOTO can dramatically simplify resource cleanup when exception handling is not supported. A function that must grab N resources in order (and free them in reverse order on success or failure) requires N nested blocks if you don't use GOTO (and no nesting if you do use GOTO). Often the only way to refactor such logic into sub-functions is by using continuation passing style, which is clear as mud.

Unless the composer, say, negotiates with multiple groups simultaneously. Or contractually binds the first one not to perform until he has sold the work to other groups.

Either of which reduce the value of the right of first performance.

It is also economically sensible for the composer to only sell the work for enough to support him while he creates and sells the next one.

According to what theory of economics? There is undoubtedly both intrinsic and extrinsic motivation in the production of creative works, but there exist at least some potential creators who are rational, self-interested actors who will pursue alternatives that have a higher expected return than the maximum recognisable value of their creation.

An economic incentive such as copyright monopoly raises the maximum recognisable value of a creation. In its absence there will be some actors that choose an alternative vocation, and society/culture will never receive those potential creations.

You are too stupid to see how it would work

You have not provided a single example of a system which cannot be fatally undermined by a single self-interested party.

Just because you think that there must be a workable system that others are too stupid to see, doesn't mean you're right.

I can do that now legally (depending on one's reading of the law, downloading is legal and not a single case was ever filed against someone for "downloading" and instead they lie and tell the media that downloading is illegal when no downloader has ever been taken to court)

Capitol v Thomas: 'the jury was instructed to find the owners' copyrights were infringed provided the ownership claims were valid and provided there was an infringement of either the reproduction right (via Thomas-Rasset "downloading copyrighted sound recordings on a peer-to-peer network, without license from the copyright owners") or the distribution right'.

In fact A M Records Inc v Napster found that a user infringes copyright by either download or uploading, and that Napster could be help liable for contributory infringement.

(a law never applied means it is legal).

Um, wow. Yeah, you keep on believing that.

Please, do continue. Every ad hominem hurts you more than it does me.

The technological changes that saw the development of duplication tools dramatically altered the economic landscape for creative works. While the market became substantially larger, new forms of consumption were introduced (music could be heard via recording as well as live performance), as were new forms of competition (a recording could replace a live performance).

It is logically invalid to extrapolate from history the possibility of a future without copyright, unless you correct for the changed variables (described above).