Epic (goto) fail is epic.

[firewalker]

I was just having a look to the serious bug discovered in Apple Ios and OSX.     

http://gizmodo.com/the-os-x-apps-affected-by-apples-unpatched-security-fl-1529152561

https://www.imperialviolet.org/2014/02/22/applebug.html

Check your Safari browser here: https://gotofail.com/

Alexander.

[Psi]

Why on earth is anyone still using goto

[firewalker]

[AlfBaz]

Why on earth is anyone still using goto

That may be a valid question but it seems to me the lack of bracketing ensuing statements after a conditional statement is the cause here.

Personally I have a soft spot for goto, one of the first programming things I ever learnt

10 PRINT "HELLO"
20 GOTO 10
 

[firewalker]

Why on earth is anyone still using goto

"Goto" is useful when error handling. It is a way to break out from deeply nested if-for loops.

Alexander.

[Psi]

Why on earth is anyone still using goto

"Goto" is useful when error handling. It is a way to break out from deeply nested if-for loops.

Alexander.

That's what Try/Except & Try/Finally is for.

[firewalker]

[12:10 - firewalker@laptop linux-git]$ git grep goto|wc -l
111734

Alexander.

[AlfBaz]

That's what Try/Except & Try/Finally is for.

Not much chop in C

[firewalker]

That's what Try/Except & Try/Finally is for.

It is "C" we are talking about.

Alexander.

[Psi]

ah, i wasn't aware C was missing that.

[firewalker]

I was thinking how could the have missed the compiler warning. But -Wall doesn't include  -Wunreachable-code (gcc has removed this switch entirely).

Alexander.

[justanothercanuck]

I certainly don't see this as a case of "incorrect code usage", but rather an accidental line duplication cobbled with a broken compiler.  I know I've done my share of editing where I forget that I already typed something.  I know I've done my share of editing where I forget that I already typed something.  Wait, what? 

If I compile with -Wall (enable all warnings), neither GCC 4.8.2 or Clang 3.3 from Xcode make a peep about the dead code. That's surprising to me. A better warning could have stopped this but perhaps the false positive rate is too high over real codebases? (Thanks to Peter Nelson for pointing out the Clang does have -Wunreachable-code to warn about this, but it's not in -Wall.)

C isn't the only language to use "goto"s. 

Code: [Select]

.org 0000H
EI ; Enable interrupts, becuase I feel like it
JP MEMTEST_LOW ; Start the memory test

.org 0010H
MEM_ERROR:
HALT ; Stop the CPU if there is a memory error

.org 0038H
INT1:
RETI ; Return from interrupt 1, because we don't have anything to do here

.org 0066H
NMI:
RETN ; Return from NMI, because we don't have anything to do here

.org 1000H
MEMTEST_LOW:
LD A,0FFH ; Set accumulator to FF
LD BC,4000H ; Set BC to 4000 (Width of Low RAM (16K))
LD DE,4000H ; Set DE to $4000 (Starting address of Low RAM)

FILL_LOOP_LOW:
LD (DE),A ; Output A to DE
INC DE ; Increment DE
DEC BC ; Decrement BC
LD H,A ; Copy A to H
LD A,B
OR C
JP NZ, FILL_LOOP_LOW_NOT_DONE ; If BC !=0, keep looping
JP VERIFY_LOW_MEM_FF ; When memory is filled, verify it

FILL_LOOP_LOW_NOT_DONE:
LD A,H ; Copy H back to A
LD H,000H ; Set H to 0
JP FILL_LOOP_LOW ; Go back to loop

VERIFY_LOW_MEM_FF:
LD A,0FFH ; Set accumulator to FF
LD BC,4000H ; Set BC to 4000 (Width of Low RAM (16K))
LD DE,4000H ; Set DE to $4000 (Starting address of Low RAM)

VERIFY_LOOP_LOW:
LD H,A ; Copy accumulator to H
LD A,(DE) ; Load DE into accumulator
CP H ; Compare H to A
JP NZ, MEM_ERROR ; If Z flag is set, then bit is fine
LD A,H ; Copy H to A
LD H,000H ; Set H to 00
INC DE ; Increment DE
DEC BC ; Decrement BC
LD H,A ; Copy A to H
LD A,B
OR C
JP NZ, VERIFY_LOOP_LOW_NOT_DONE ; If BC !=0, keep looping
JP ZERO_LOW_MEM ; Memory is verified to be FF, now 00 it

VERIFY_LOOP_LOW_NOT_DONE:
LD A,H ; Copy H back to A
LD H,000H ; Set H to 0
JP VERIFY_LOOP_LOW ; Go back to loop

ZERO_LOW_MEM:
LD A,000H ; Set accumulator to 00
LD BC,4000H ; Set BC to 4000 (Width of Low RAM (16K))
LD DE,4000H ; Set DE to $4000 (Starting address of Low RAM)

ZERO_LOOP_LOW:
LD (DE),A ; Output A to DE
INC DE ; Increment DE
DEC BC ; Decrement BC
LD H,A ; Copy A to H
LD A,B
OR C
JP NZ, ZERO_LOOP_LOW_NOT_DONE ; If BC !=0, keep looping
JP VERIFY_ZLOOP_LOW ; When memory is zeroed, verify it

ZERO_LOOP_LOW_NOT_DONE:
LD A,H ; Copy H back to A
LD H,000H ; Set H to 00
JP ZERO_LOOP_LOW ; Go back to loop

VERIFY_ZLOOP_LOW:
LD A,000H ; Set accumulator to 00
LD BC,4000H ; Set BC to 4000 (Width of Low RAM (16K))
LD DE,4000H ; Set DE to $4000 (Starting address of Low RAM)

VERIFY_ZLOOP_LOW_LOOP:
LD H,A ; Copy accumulator to H
LD A,(DE) ; Load DE into accumulator
CP H ; Compare H to A
JP NZ, MEM_ERROR ; If Z flag is set, then bit is fine
LD A,H ; Copy H to A
LD H,000H ; Set H to 00
INC DE ; Increments DE
DEC BC ; Decrements BC
LD H,A ; Copies A to H
LD A,B
OR C
JP NZ, VERIFY_ZLOOP_LOW_NOT_DONE ; If BC !=0, keep looping
JP LOW_TEST_DONE ; Memory is verified to be zeroed, low test is done

VERIFY_ZLOOP_LOW_NOT_DONE:
LD A,H ; Copy H back to A
LD H,000H ; Set H to 00
JP VERIFY_ZLOOP_LOW_LOOP ; Go back to loop

LOW_TEST_DONE:
LD A,000H ; Set A to 00
LD BC,0000H ; Set BC to 0000
LD DE,0000H ; Set DE to 0000
LD H,000H ; Set H to 00
HALT ; Stop the CPU because I have nothing else better to do

[AlfBaz]

But -Wall doesn't include  -Wunreachable-code (gcc has removed this switch entirely).

Maybe apple should consider using Microsoft compilers

[justanothercanuck]

But -Wall doesn't include  -Wunreachable-code (gcc has removed this switch entirely).

Maybe apple should consider using Microsoft compilers

I wouldn't joke about that. 

http://forums.gentoo.org/viewtopic.php?t=122145  (See section 3)

[AlfBaz]

I wouldn't joke about that. 

http://forums.gentoo.org/viewtopic.php?t=122145  (See section 3)

Weird!
I don't program much in windows any more but remember once turning the error/warnings all the way up to anal once and was shocked to see how bad a programmer I actually was

[Kjelt]

I don't get the bug, if the code goes to fail then there should be no further communication.
They should abort the keyexchange and start completely from scratch, it looks like there is much more broken.

[firewalker]

Code: [Select]

/* Hello World program */

#include<stdio.h>

int main()
{
        return 0;

        printf("Hello World");
}

Clang 3.4.

Code: [Select]

[12:34 - firewalker@laptop tmp]$ clang -Wall hello.c
No warning.

Code: [Select]

[12:34 - firewalker@laptop tmp]$ clang -Wall -Wunreachable-code hello.c
hello.c:9:2: warning: will never be executed [-Wunreachable-code]
        printf("Hello World");
        ^~~~~~
1 warning generated.
Gcc 4.8.2.

Code: [Select]

[12:34 - firewalker@laptop tmp]$ gcc -Wall hello.c
No warning.

Code: [Select]

[12:34 - firewalker@laptop tmp]$ gcc -Wall -Wunreachable-code hello.c
No warning.

GCC allows you to use -Wunreachable-code, but it is disabled internally. It should really produce a Warning for the disabled warning switch!

[justanothercanuck]

GCC allows you to use -Wunreachable-code, but it is disabled internally. It should really produce a Warning for the disabled warning switch!

It looks like that's partially intentional, and at least temporary.

The -Wunreachable-code has been removed, because it was unstable: it
relied on the optimizer, and so different versions of gcc would warn
about different code.  The compiler still accepts and ignores the
command line option so that existing Makefiles are not broken.  In some
future release the option will be removed entirely.

http://gcc.gnu.org/ml/gcc-help/2011-05/msg00360.html

[Marco]

I don't get the bug, if the code goes to fail then there should be no further communication.
They should abort the keyexchange and start completely from scratch, it looks like there is much more broken.

They return the err variable in the fail section, but err is never set.

[HackedFridgeMagnet]

The case where the bug causes trouble is when you would've satisfied the first two conditionals but failed the third. If you fail any of these conditionals the function should return a failure code.

The code skips the third conditional in every case.
So if you satisfy the first two conditionals the function returns 0 even though the third conditional hasn't been done.

Maybe Apple hired a Python programmer for this. They use indentation instead of curly braces.

Can I just say I always use braces on one liners.

Wonder how they got access to Apple source code. Anyone know?

[firewalker]

Wonder how they got access to Apple source code. Anyone know?

It's open source code.

http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c

Alexander.

[apelly]

One entry. One exit.

At least in public code 

[amyk]

I was thinking how could the have missed the compiler warning. But -Wall doesn't include  -Wunreachable-code (gcc has removed this switch entirely).

Alexander.

I think unreachable code warnings should be enabled by default, since it's basically a "why are you getting me to compile useless code?" and your code shouldn't have any unreachable bits.

[Rigby]

Why on earth is anyone still using goto

That may be a valid question but it seems to me the lack of bracketing ensuing statements after a conditional statement is the cause here.

Yep.  If's without { and } have caused so many problems in code I've worked on.  Always add them.

Static analysis tools can help a great deal with things like this and other shockingly common bugs.  They're worth the price.

[c4757p]

It's not even the lack of brackets that is the problem. For god's sake, we have editors with auto-indent. Very good editors with auto-indent. Why it's even possible to leave a line mis-indented like that is beyond me.

[Marco]

I think unreachable code warnings should be enabled by default, since it's basically a "why are you getting me to compile useless code?" and your code shouldn't have any unreachable bits.

A default fall through is something which is used quite often which might never be reached but is still left in the code precisely because errors like these are easy to make. The GNU guys gave up on wunreachable because it caused so many "false" positives.

[firewalker]

Especially when someone uses threads.

Alexander.

[AlfBaz]

It's not even the lack of brackets that is the problem. For god's sake, we have editors with auto-indent. Very good editors with auto-indent. Why it's even possible to leave a line mis-indented like that is beyond me.

I have to admit, I don't use braces unless the following conditional statements are more than one line. I have yet to see an editor that wont put the second line one indent back if you don't use them

[tszaboo]

I was thinking how could the have missed the compiler warning. But -Wall doesn't include  -Wunreachable-code (gcc has removed this switch entirely).

Alexander.

I think unreachable code warnings should be enabled by default, since it's basically a "why are you getting me to compile useless code?" and your code shouldn't have any unreachable bits.

Not necessarily. When I start working on other peoples code there are usually some cases where I use the "IF 0" or "IF xy&0", just to get rid of their code temporarily. It would drive me insane to see this code on the output window.

[Rigby]

How is that easier than /* ... */ ?  I mean, that's what comments are FOR.

[tszaboo]

How is that easier than /* ... */ ?  I mean, that's what comments are FOR.

No, it is not. IF you already have comment with /* */ there, it will mess up everything pretty much. Also, #if 0 is even more useful.

[Rigby]

I use /* ... */ liberally.

if there is an existing */ that prematurely ends my intended comment size, I comment it out: // */

I can search for that pattern later and delete the double slash.

I can also comment out the opening multiline comment symbol by adding a single slash in front of it: //* then magically the entire comment is commented and uncommented with a single keypress.

I guess it's just what I'm used to.  Wrapping it up with an if or modifying an existing if just seems like a lot more work to me.

[linux-works]

It's not even the lack of brackets that is the problem. For god's sake, we have editors with auto-indent. Very good editors with auto-indent. Why it's even possible to leave a line mis-indented like that is beyond me.

I have to admit, I don't use braces unless the following conditional statements are more than one line. I have yet to see an editor that wont put the second line one indent back if you don't use them

C programmer for 25 yrs, here.

I always use braces even for one-liners.

why?

you may need to add more lines, later on, and the braces really make things crystal clear.  once your eye gets used to seeing an open brace, you know what to look for on the closing side.  seems like extra typing and white space but trust me, its the better way to write SUPPORTABLE code that has to be touched by many people over a long period of time.

[linux-works]

How is that easier than /* ... */ ?  I mean, that's what comments are FOR.

No, it is not. IF you already have comment with /* */ there, it will mess up everything pretty much. Also, #if 0 is even more useful.

yup, the safest way to comment-out code is with ifdef stuff.

#ifdef NOT

or

#ifdef FIX_ME_LATER

and so on.

using comment chars to 'comment out' a block of code is really wrong and such a newbie thing to do

[linux-works]

btw, the goto statement has been replaced, in most modern languages, with the comefrom statement.

(no, I'm not serious)

[Rigby]

using comment chars to 'comment out' a block of code is really wrong and such a newbie thing to do

That's the oddest thing I've read all day.  What if you use a language that lacks a preprocessor, and doesn't support ifdef, but does support multi-line comments?  Not everyone writes C...

Using an ifdef as a commenting tool is bizarre, to me, and I'm most definitely not a newbie.

[linux-works]

I didn't state it was about C programming, but this thread is mostly talking about C, no?

and if you have not seen or used ifdef's to comment out C, you have not been doing it very long.

its extremely common practice in every software job I've been at.

[Marco]

you may need to add more lines, later on, and the braces really make things crystal clear.  once your eye gets used to seeing an open brace, you know what to look for on the closing side.  seems like extra typing and white space but trust me, its the better way to write SUPPORTABLE code that has to be touched by many people over a long period of time.

I don't mind the convention, but it does start to make the arguments against whitespace indentation look kind of silly IMO. You have a visual cue in python with 2 less lines.

PS. if python just had not allowed you to mix spaces and tabs in leading white space from the very beginning I doubt the anti whitespace indentation hype would ever have gotten started.

[Rigby]

I don't mind Python, but Python enthusiasts annoy the hell out of me.

No, I've never written C or C++.  I am an experienced Java developer and C# developer.  There is no need for C in my work, so there is no point to to me using it or learning it.  C# does have a preprocessor and supports ifdef, though I've never used it to comment code, lol.  The tooling makes it far too easy to comment and uncomment multiple lines of code with a key combination that doing it manually (or with ifdef) is just a waste of time.

[linux-works]

"experienced in java but never written C code."

sigh...

makes me think of modern EE's who do all their work on simulators and computers but can't solder worth shite.

[Rigby]

"experienced in java but never written C code."

sigh...

makes me think of modern EE's who do all their work on simulators and computers but can't solder worth shite.

why the sigh?  C is literally a useless language to me.  So I should learn it anyway?  I have better things to do with my time.  Even the low point of my day, so far, discussing this ad nauseam, is more useful to me than learning C.

Lots of people in lots of areas of expertise don't bother to learn things that older generations used.  For example, I did not build my own home, I did not get married via arrangement, I did not walk uphill both ways to school, and I will admit that I have never used a copper wire and a rock to make a radio receiver.  Likewise, I have never needed to learn C for any reason.

If you think my ability to reason or develop in other languages is related in any way to a knowledge of C, or lack thereof, then you are simply mistaken and you would do well to escape your prejudices and preconceptions about people, because they will not serve you well at all.

[linux-works]

lets see, unix is written in C, the usual ip-stacks are in C, most of the cli utils for unix are in C.  router and networking code is almost entirely in C.  servers use C code for speed (not java).

yeah, I can see no valid reason to learn C, as a software engineer.

(rolls eyes)

[Phaedrus]

To be fair, if he isn't writing speed critical code then C isn't exactly a necessary skill. Plus C isn't exactly platform-agnostic the way Java is. I think it would be beneficial to know it, to have an extra tool in the tool kit, but if he doesn't need it for his work then he doesn't need it for his work.

Speed and memory critical tasks in GPU drivers are written in Assembly; clearly anyone who doesn't know Assembly for every processor their code runs on is not a serious programmer. 

[linux-works]

C is more portable than java.

java 1.6, 1.7, 1.x

very incompatible in key ways.

my last company did server code in java.  it sucked.  we had to have watchdog processes to keep the java daemons alive.  and even the watchdog needed a watchdog (I kid you not).  color me unimpressed.

on android, java is known to be dog slow and you need to use native api's to get any decent speed from the thing.  our android app was first in java and had to be redone in C for that very reason.

java is also too much of a moving target.  it changes too much over time.  C has settled down and has been essentially unchanged for a long time, now.  compilers are mature, run time libs are mature, debuggers are mature.

there was (maybe still is) a company who did java 'pauseless garbage collection' at the hardware level.  kind of funny that you have to do this kind of schtick just to make java run fast and reliably.  when I asked my friend at that company what the big draw with java is, his reply was that, at least in business coding, java requires much less skill level and for business apps, they insist on the most unskilled labor (ie, cheapest) they can find.  to allow unskilled programmers to write code, they need 'help' from the language.

just not impressed with java.  sorry if that offends anyone.

[Macbeth]

I certainly don't see this as a case of "incorrect code usage", but rather an accidental line duplication cobbled with a broken compiler.  I know I've done my share of editing where I forget that I already typed something.  I know I've done my share of editing where I forget that I already typed something.  Wait, what? 

If I compile with -Wall (enable all warnings), neither GCC 4.8.2 or Clang 3.3 from Xcode make a peep about the dead code. That's surprising to me. A better warning could have stopped this but perhaps the false positive rate is too high over real codebases? (Thanks to Peter Nelson for pointing out the Clang does have -Wunreachable-code to warn about this, but it's not in -Wall.)

C isn't the only language to use "goto"s. 

Code: [Select]

.org 0000H
EI ; Enable interrupts, becuase I feel like it
JP MEMTEST_LOW ; Start the memory test

.org 0010H
MEM_ERROR:
HALT ; Stop the CPU if there is a memory error

.org 0038H
INT1:
RETI ; Return from interrupt 1, because we don't have anything to do here

.org 0066H
NMI:
RETN ; Return from NMI, because we don't have anything to do here

.org 1000H
MEMTEST_LOW:
LD A,0FFH ; Set accumulator to FF
LD BC,4000H ; Set BC to 4000 (Width of Low RAM (16K))
LD DE,4000H ; Set DE to $4000 (Starting address of Low RAM)

FILL_LOOP_LOW:
LD (DE),A ; Output A to DE
INC DE ; Increment DE
DEC BC ; Decrement BC
LD H,A ; Copy A to H
LD A,B
OR C
JP NZ, FILL_LOOP_LOW_NOT_DONE ; If BC !=0, keep looping
JP VERIFY_LOW_MEM_FF ; When memory is filled, verify it

FILL_LOOP_LOW_NOT_DONE:
LD A,H ; Copy H back to A
LD H,000H ; Set H to 0
JP FILL_LOOP_LOW ; Go back to loop

VERIFY_LOW_MEM_FF:
LD A,0FFH ; Set accumulator to FF
LD BC,4000H ; Set BC to 4000 (Width of Low RAM (16K))
LD DE,4000H ; Set DE to $4000 (Starting address of Low RAM)

VERIFY_LOOP_LOW:
LD H,A ; Copy accumulator to H
LD A,(DE) ; Load DE into accumulator
CP H ; Compare H to A
JP NZ, MEM_ERROR ; If Z flag is set, then bit is fine
LD A,H ; Copy H to A
LD H,000H ; Set H to 00
INC DE ; Increment DE
DEC BC ; Decrement BC
LD H,A ; Copy A to H
LD A,B
OR C
JP NZ, VERIFY_LOOP_LOW_NOT_DONE ; If BC !=0, keep looping
JP ZERO_LOW_MEM ; Memory is verified to be FF, now 00 it

VERIFY_LOOP_LOW_NOT_DONE:
LD A,H ; Copy H back to A
LD H,000H ; Set H to 0
JP VERIFY_LOOP_LOW ; Go back to loop

ZERO_LOW_MEM:
LD A,000H ; Set accumulator to 00
LD BC,4000H ; Set BC to 4000 (Width of Low RAM (16K))
LD DE,4000H ; Set DE to $4000 (Starting address of Low RAM)

ZERO_LOOP_LOW:
LD (DE),A ; Output A to DE
INC DE ; Increment DE
DEC BC ; Decrement BC
LD H,A ; Copy A to H
LD A,B
OR C
JP NZ, ZERO_LOOP_LOW_NOT_DONE ; If BC !=0, keep looping
JP VERIFY_ZLOOP_LOW ; When memory is zeroed, verify it

ZERO_LOOP_LOW_NOT_DONE:
LD A,H ; Copy H back to A
LD H,000H ; Set H to 00
JP ZERO_LOOP_LOW ; Go back to loop

VERIFY_ZLOOP_LOW:
LD A,000H ; Set accumulator to 00
LD BC,4000H ; Set BC to 4000 (Width of Low RAM (16K))
LD DE,4000H ; Set DE to $4000 (Starting address of Low RAM)

VERIFY_ZLOOP_LOW_LOOP:
LD H,A ; Copy accumulator to H
LD A,(DE) ; Load DE into accumulator
CP H ; Compare H to A
JP NZ, MEM_ERROR ; If Z flag is set, then bit is fine
LD A,H ; Copy H to A
LD H,000H ; Set H to 00
INC DE ; Increments DE
DEC BC ; Decrements BC
LD H,A ; Copies A to H
LD A,B
OR C
JP NZ, VERIFY_ZLOOP_LOW_NOT_DONE ; If BC !=0, keep looping
JP LOW_TEST_DONE ; Memory is verified to be zeroed, low test is done

VERIFY_ZLOOP_LOW_NOT_DONE:
LD A,H ; Copy H back to A
LD H,000H ; Set H to 00
JP VERIFY_ZLOOP_LOW_LOOP ; Go back to loop

LOW_TEST_DONE:
LD A,000H ; Set A to 00
LD BC,0000H ; Set BC to 0000
LD DE,0000H ; Set DE to 0000
LD H,000H ; Set H to 00
HALT ; Stop the CPU because I have nothing else better to do

Is that Z-80? Sure looks like the Z-80 I coded back in the '80s. Only I had to change all the mnemonics to hexadecimal code in DATA statements and POKE them into RAM, as I didn't have an assembler.

When I got my beeb, one of my favourite things with BBC BASIC was it allowed inline assembly of 6502. Fantastic. Also that BASIC was full of functions and procs and GOTO was a bit of a nono, only used for error handling really.

Nostalgia!

[linux-works]

looks like zilog mnemonics for the z80, alright.

trivia question: what is the purpose of the "OR A" statement in z80?

[AlfBaz]

using comment chars to 'comment out' a block of code is really wrong and such a newbie thing to do

If I met you and you told me you used #ifdef's to comment code, I'd punch you in the head
The overuse of pre-processor directives in code should merit the death penalty

[Rigby]

C is more portable than java.

java 1.6, 1.7, 1.x

very incompatible in key ways.

my last company did server code in java.  it sucked.  we had to have watchdog processes to keep the java daemons alive.  and even the watchdog needed a watchdog (I kid you not).  color me unimpressed.

on android, java is known to be dog slow and you need to use native api's to get any decent speed from the thing.  our android app was first in java and had to be redone in C for that very reason.

java is also too much of a moving target.  it changes too much over time.  C has settled down and has been essentially unchanged for a long time, now.  compilers are mature, run time libs are mature, debuggers are mature.

there was (maybe still is) a company who did java 'pauseless garbage collection' at the hardware level.  kind of funny that you have to do this kind of schtick just to make java run fast and reliably.  when I asked my friend at that company what the big draw with java is, his reply was that, at least in business coding, java requires much less skill level and for business apps, they insist on the most unskilled labor (ie, cheapest) they can find.  to allow unskilled programmers to write code, they need 'help' from the language.

just not impressed with java.  sorry if that offends anyone.

So what if all those things are written in C?  Analogy: You better go learn Latin before you talk to a doctor because medical terms are taken from Latin. 

You know less about Java than you think you do.  That's ok, though, as most people know less about Java than they think they do.  You're in good company with those Java misconceptions.  Doesn't make you correct, though.  For example, Java is faster at memory access than C.  Java does one large malloc() for every hundred a C program might do, (depends on the program, of course) and each malloc() has overhead...  I encourage you to benchmark it if you do not believe me.  Too many people are bound by the misconception that Java performance has not improved in the 18 years it's been around.  The runtime optimizer and garbage collection system, among many others, have both gotten EXTREMELY good in terms of performance.  Yes, startup is slower, but most Java apps that I'm familiar with startup maybe once a week at most.  A two-second penalty in startup for using Java is not a concern.

Anyone (almost) can write a Java app that is architecturally unsound, performs poorly, and requires constant supervision.  It's more difficult to find someone that knows what they're doing, primarily because object orientation is very difficult to teach to someone that is used to procedural programming, and it is often even more difficult to get those folks to learn to use objects effectively.  This is true with anything that has even a modicum of complexity, as all software development does.  C# takes it all further than Java. 

I'm guessing you're a Linux advocate with that username, and these attitudes you are expressing, which seem to come down to "Not C?  Worthless," and may or may not include "Not Linux?  Worthless."  These things are simply not that simple.  Virtually nothing is cut and dried like that, and I do hope you gain the ability and the willingness to see positions that are not your own as potentially valid and worthy of investigation sometime soon.  Maybe you already do, I don't know, but you're not acting like it.

using comment chars to 'comment out' a block of code is really wrong and such a newbie thing to do

If I met you and you told me you used #ifdef's to comment code, I'd punch you in the head
The overuse of pre-processor directives in code should merit the death penalty

Thank you.

[AlfBaz]

Select text, right click, comment block... It's so hard 

[linux-works]

sorry if it offends, but its industry standard practice.

it just is.

some companies do complain (via static code checkers) about excessive ifdef's, and sometimes they want you to strip out this devel/testing stuff before committing your code, but I swear to you, this ifdef stuff for commenting out code is quite standard and everyone I know who writes C uses this to quickly remove some code without permanently removing it from the source.

what else are you going to do?  comments don't nest reliably and its a sin to actually remove code if you are not 100% sure that its not needed.

[Kjelt]

We are not allowed to check in any code that has any code commented out with // or /* */  or #ifdef.
If you don't use it, delete it.  It only adds confusion to any other colleague reading your code.

If you temporary want to disable some code that's fine, but if you comment it out for ever and leave it just for historic purposes    that's so 20th century, let SVN or other software versioning, revision control system take care of that. Just my two cents.

[AlfBaz]

sorry if it offends, but its industry standard practice.

It's major use is in commenting optional code, enabled with #defines (that are usually commented out)

what else are you going to do?  comments don't nest reliably...

Please show me an IDE that doesn't comment a code block with // and I'll show you an IDE designed for a strict C89 compilers from the sixties

and its a sin to actually remove code if you are not 100% sure that its not needed.

Oh please, the code is removed in exactly the same way as #ifdef's. That is, an ascii sequence that tells the pre-processor to ignore the following

[linux-works]

lol

once you have a ton of svn (cvs, etc) checkins, you really want to trawl back thru time to find the bit of code you were SURE you needed to be deleted?  really?

I would hate that.  extra baggage in the source is harmless, but removing it and relying on the source mgmt system seems like more trouble-prone way of doing it.

if it took work to write a block of code, I respect it and won't delete it unless I'm quite sure it will never be useful again.  that does not mean I clutter up the source with tons of ifdefs but until I'm positive that this block won't ever be useful, it stays in the source.

different companies do follow different rules; but many companies just plain get it wrong.

[Kjelt]

you really want to trawl back thru time to find the bit of code you were SURE you needed to be deleted?  really?

Standard practice:  never ever comment out or delete any code you are not sure about it is ever needed. Ask the original codewriter in doubt or any other colleague.
If you comment it out and test your code and build your product and everything works fine, why would you like to keep the old code as comment?
How unreadable will the code be after two years of development with a team of 10 people that do that?

I would hate that.  extra baggage in the source is harmless

No it is not, esp. when there is some weird #ifdef around it. Couple of years from now people are searching the configuration files to look what that #ifdef does. If everyone on the team uses a different #ifdef for these purposes your code is FUBAR in a couple of years.

different companies do follow different rules; but many companies just plain get it wrong.

I agree 

[Macbeth]

If I'm developing Windows applications then I use C#.NET or old fashioned Visual Basic (VBScript or the VBA used in all the Office apps).

The vast majority of my commercial experience earning megabucks was coding VB6 along OO lines, with COM, DCOM, MTS, IIS and some behind the scenes libraries to IBM mainframes inluding MQ, DB2, IMS, etc.

But I love the old fashioned hit the hardware beauty of good old K&R 'C'. I never got into C++, I just love the simplicity of C.

It is what all the coders of embedded controllers use after all. Not knowing how to code C is a serious disadvantage as far as I can C.

[Rigby]

If your job is to code for embedded platforms and you don't know C, well then yes, you have an issue.

I've never needed C, and I'm not likely to in the next 5 years.  I understand that others need it, but others don't seem to understand that I don't need it.

[linux-works]

you really want to trawl back thru time to find the bit of code you were SURE you needed to be deleted?  really?

Standard practice:  never ever comment out or delete any code you are not sure about it is ever needed. Ask the original codewriter in doubt or any other colleague.
If you comment it out and test your code and build your product and everything works fine, why would you like to keep the old code as comment?
How unreadable will the code be after two years of development with a team of 10 people that do that?

lol.  after 2 years, the product is EOL anyway, in today's modern world.  I hate that, but it ends up being true for so many software projects.  don't get me started on that!

I would hate that.  extra baggage in the source is harmless

No it is not, esp. when there is some weird #ifdef around it. Couple of years from now people are searching the configuration files to look what that #ifdef does. If everyone on the team uses a different #ifdef for these purposes your code is FUBAR in a couple of years.
[/quote]

I would not use a lot of conditionals in ifdef'ing.  usually I'll just #if 0 or #ifdef NOT.  in rare occasions, if I need to give more info about why I'm temp removing this block, I'll do an #ifdef NOT_FOR_V1 but I agree if you go nuts with the conditional compilation statements it becomes unreadable.

I'm simply saying that it takes an amazing programmer to be so sure that he won't need this or that, that he can remove code without any guilt at all.  you think you won't need this, but until its been thru a couple of QA tests and revs (and customer betas) I would not remove code that took hard work to create.  its trivial to ifdef-out things but its very hard to put things back once they are gone.  and again, I don't like using source code mgmt tools as a way to 'bring back' code that you thought you didn't need.

[Macbeth]

If your job is to code for embedded platforms and you don't know C, well then yes, you have an issue.

I've never needed C, and I'm not likely to in the next 5 years.  I understand that others need it, but others don't seem to understand that I don't need it.

Surely you will get to code an Arduino, AVR, or PIC within 5 years?

[Rigby]

I'm simply saying that it takes an amazing programmer to be so sure that he won't need this or that, that he can remove code without any guilt at all.

  Jeez you crack me up.  You remove it and you test the app.  If something broke, then you know that code is needed.  Or, you use something more modern than vi and you run static analysis tools to find out what (if anything) references the code in question.  If nothing references it, then you delete it.  You don't leave it in and hope, you apply some experimentation, testing, and results observation and then the computer will tell you if it's required or not.

[linux-works]

I've never needed C, and I'm not likely to in the next 5 years.  I understand that others need it, but others don't seem to understand that I don't need it.

just seems like a basic skill that all programmers should have.

you need to learn some art, some history, some other basic subjects too in school; and C is just part of any core comp-sci program, whether you think you'll write in it or not.  if they deprecated it, they (schools) should be ashamed of themselves.

when I was in school, C was a 'lab' subject since it was so new.  it was not a full course (fortran and vax-11 macro were, lol).  these days, its really amazing to see people graduate with a comp-sci degree and still want to shy away from C.

[linux-works]

I'm simply saying that it takes an amazing programmer to be so sure that he won't need this or that, that he can remove code without any guilt at all.

  Jeez you crack me up.  You remove it and you test the app.  If something broke, then you know that code is needed.  Or, you use something more modern than vi and you run static analysis tools to find out what (if anything) references the code in question.  If nothing references it, then you delete it.  You don't leave it in and hope, you apply some experimentation, testing, and results observation and then the computer will tell you if it's required or not.

all I can tell you is that, after doing this for many decades, deleting work is a sin I try to avoid.  no matter how good you think you are, that bit of work you did may come in handy in a use-case you didn't consider at first.  or, your seemingly good code stops working in a corner case and you could find that the extra bit of code that was there really did matter.

just curious, how long have you been writing software professionally?  I started in the early 80's, myself.

[free_electron]

Why on earth is anyone still using goto

why not ? every single cpu in the worls has this as one of its basic instructions.
JMP xxxx  where xxx is a target address.

Any and all code you compile is eventually using JMP instructions. So why should you be blocked from using them ?
Blame the programmers ! not the language or the Cpu.

Any compiler worth that name should have thrown a warning that there is unreachable code. But do coders read the warnings ? no , of course not. they are just warnings. it compiled and produced a binary. let's flog it.

[tszaboo]

I'm simply saying that it takes an amazing programmer to be so sure that he won't need this or that, that he can remove code without any guilt at all.

  Jeez you crack me up.  You remove it and you test the app.  If something broke, then you know that code is needed.  Or, you use something more modern than vi and you run static analysis tools to find out what (if anything) references the code in question.  If nothing references it, then you delete it.  You don't leave it in and hope, you apply some experimentation, testing, and results observation and then the computer will tell you if it's required or not.

Not to mention, there are tons of libraries, which contain bloatware code, and you usually want to get rid of it, but with the ability to use it five year later if I need it. But hay, you developed Java and C# any you cannot even imagine why you would need C. Just a hint. With java, you can develop on 1 platform, which doesnt even exist, with C 95% of the programmable devices are in reach. Not everyone makes farting apps for phones.
In this field, you might end up with a code for that "legacy system" which was running for 20 years, and now it suddenly crashes, the comments are in german and every single person working with the code already left. It is not like there is a magic "test my stuff for everything" button. There are also codes which are executed on "live" systems every once a week.

[linux-works]

ah, you have a good point I didn't think about: OUTSIDE of any source control system, if the block of code is deleted in the current version and only in the source control version, what does a guy do when he gets a copy of that code but does not have SC rights?  or the company went under or EOL'd the product and released the code?  surely no one releases whole svn tarballs when they release code (lol).

keeping things HERE, in the source, is so important.  not 'over there' in the cvs or svn or perforce blob.

[linux-works]

Why on earth is anyone still using goto

why not ? every single cpu in the worls has this as one of its basic instructions.
JMP xxxx  where xxx is a target address.

goto's are not evil in themselves.  to get out of a deep nesting, gotos are PERFECTLY fine.

the alternative is often uglier and tries to work around the very simple goto-concept.  set flags, check flags, don't do this bit of code if the flag is set.  blech!  just goto BAIL_ME_OUT and be done with it

[apelly]

goto's are not evil in themselves.  to get out of a deep nesting, gotos are PERFECTLY fine.

the alternative is often uglier and tries to work around the very simple goto-concept.  set flags, check flags, don't do this bit of code if the flag is set.  blech!  just goto BAIL_ME_OUT and be done with it

That is an edge case, and only a last resort. I still always comment the beginning of the routine, and the goto (loudly) so I know there is an unexpected exit when I look at it again in two years. ALWAYS code for readability.

And yes. I agree. DO NOT delete your unused code. Comment it out and say why it is unused. Having the old code and the comment might save the next guy (who could be you) coding the same mistake again in a year.

[linux-works]

except in rare situations, coding for readability is the most important thing!  I would prefer a simple algorithm with comments over some elegant text-book version that takes more effort to digest and debug.  cpu and memory is cheap.  manpower is not.

[T3sl4co1l]

...Goto, yes all fine and dandy...

...Don't tell me I'm the only one bothered more by the assignment within a conditional statement than by the goto?

looks like zilog mnemonics for the z80, alright.

trivia question: what is the purpose of the "OR A" statement in z80?

Probably just for getting flags?  Compare "TEST AX, AX" on x86, etc..

Tim (done a bit of Z80 myself)

[linux-works]

yup, OR A was the fastest way to set the flags.  and each time you use that trick, you better add a comment at the end explaining it or some 'helpful soul' will optimize that out.

(or maybe even just comment it out).  lol

[linux-works]

except in rare situations, coding for readability is the most important thing!  I would prefer a simple algorithm with comments over some elegant text-book version that takes more effort to digest and debug.  cpu and memory is cheap.  manpower is not.

What about an elegant textbook version with comments? What is the definition of "elegant" if not simple, efficient and easily understood? Or if not all three then a worthwhile compromise of the three. At the risk of arguing by "reductio ad absurdum" you surely are not advocating a bubble sort is generally preferable.

if its a thing like a sort, that would better belong in some 'utils' file or library and you just call it from the main bit of code.  its when people feel the need to show off what they learned in school, in production code - that really annoys me.  its common that recent entrants to the field will do all they can to show they are capable, but they miss the simpler solutions when they mostly look for the more complicated ones.  production code is not a school project and simplicity wins, here.  code as if the reader is stuck up at 3am and having to fix code while a customer is standing over them.  make their lives as easy as possible, even if some cpu cycles are burned in the process, at runtime.

avoid exotic languages and keep to a core minimum, again assuming the guy supporting this code, later on, may not know this fancy new language that this routine is written in.  and that's one reason why I was tweaked that someone who works in the computer programming field does not know C.  it has to be one of the core languages that EVERYONE knows, who works in software.  I'd have to say bash (the shell) is another that everyone should know who writes software.  there may be a few others, but keep to a small set and don't assume that your favorate fad language is going to be supportable by someone coming onboard later on.  you won't always be there to support the thing you wrote.

really, its all about the KISS principle.

[baljemmett]

...Don't tell me I'm the only one bothered more by the assignment within a conditional statement than by the goto?

Probably - that's idiomatic C, so it's a construct that any C programmer should recognise and be comfortable with, even if they don't like to use it themselves.  See also "while ((c = getchar()) != EOF)", which I think is used in examples in K&R.

[Dave Turner]

My first computer language was mainframe run Algol (mid sixties) and whilst goto was available it was frowned on, except in switch statements, mostly for readability issues.

Goto was almost de rigeur in Dartmouth Basic and anathema in Pascal.

From my simplistic point of view goto was understandable in relatively short interpreted programs, but when used in compiled programs consideration of memory control is even more important; particularly allocation and deallocation. Some compilers and linkers were better than others in dealing with this where the programmer wasn't perfect. eg jumping out and bypassing a memory deallocation. In the early PC days memory 'leakage' wasn't uncommon.

[linux-works]

and now, for some reason, we think its ok to allocate and let a robot walk behind us and guess when its ok to free.

boggle...

not progress at all!

[Rigby]

and now, for some reason, we think its ok to allocate and let a robot walk behind us and guess when its ok to free.

boggle...

not progress at all!

Well, I tell ya, we think it's ok to have garbage collection because it is ok to have garbage collection.  Those claiming otherwise simply aren't informed.  The garbage collector doesn't guess, by the way.  (This is evidence of your misinformation.)  Java and C# are bloody excellent at garbage collection, too.  I don't know a C developer that hasn't had a memory leak, but not one of my Java programs ever has.  It is possible to create a memory leak in Java, though, but not because of a forgotten a 'free'.

Clearly you're enthusiastic.  I understand; every computing advance since C is useless.  If you didn't use it when you were young, no one else needs it now, and everyone needs what you needed when you were young.  Hey, I get that.  I'm not going to argue with you anymore.  You're right.  On all points.  I'm just a young nobody that doesn't know shit.  Fair enough.

[AlfBaz]

I don't know a C developer that hasn't had a memory leak

Hi Rigby, I don't believe we've met

[tom66]

I think Java is a bad first programming language. I'm not a fan of it for a normal programming language either, but I think teaching it is as a first language is a particularly bad idea. By not forcing the programmer to justify memory usage, allocations and frees and hiding all the types away behind various interfaces and classes, you lose a fundamentally important part of programming when on embedded systems. Another complaint is how verbose it is - having everything in a namespace sounds kinda neat until you realise how repetitive and messy your code gets.

[HackedFridgeMagnet]

Here is my rewrite.
Ok Not really changed anything, but no gotos and the nesting (which it was meant to have) is made more obvious.

Code: [Select]

static OSStatusm SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,  uint8_t *signature, UInt16 signatureLen)
{
    OSStatus        err;
...

err = SSLHashSHA1.update(&hashCtx, &serverRandom)
if (err != 0)
{
err = SSLHashSHA1.update(&hashCtx, &signedParams)
if (err != 0)
{
err = SSLHashSHA1.final(&hashCtx, &hashOut)
if (err != 0)
{
...
}
}
}
SSLFreeBuffer(&signedHashes);[quote author=AlfBaz link=topic=27329.msg394572#msg394572 date=1393289526]
[quote author=Rigby link=topic=27329.msg394570#msg394570 date=1393289317]
I don't know a C developer that hasn't had a memory leak[/quote]
Hi Rigby, I don't believe we've met :)
[/quote]
SSLFreeBuffer(&hashCtx);
return err;
}


ps. Prefer Java and C# to C++ and C.  in case that wasn't obvious.
But obviously for embedded there are limited options, and good reasons for that.

[linux-works]

I don't know a C developer that hasn't had a memory leak

Hi Rigby, I don't believe we've met

same here.  I use various mem check tools and make sure that I don't have leaks when I release production code to customers.

at least on unix, its not rocket science and I'd rather pay the programmer tax and get code right than pay a RUNTIME tax (*cough cough*, java) and pay every damned time you run the bloody thing.

life for programmers is supposed to be hard.  that shifts the burden to us instead of users.

[HackedFridgeMagnet]

Code: [Select]

at least on unix, its not rocket science and I'd rather pay the programmer tax and get code right than pay a RUNTIME tax (*cough cough*, java) and pay every damned time you run the bloody thing.

life for programmers is supposed to be hard.  that shifts the burden to us instead of users.
So let me attempt to put this analogy into context, to see if it holds.

Under the current software tax regime Apple's users have been paying the programmer tax to get the code right, but avoiding the runtime tax?

Maybe a bit more runtime tax would be worth paying, just in case.

[linux-works]

I can't comment on apple's code quality.  for one, almost none of us can see their actual source.

but my point is that you pay the programmer tax once and get efficient to run code 'n' times for the user.

that's proper scaling!

the other way is when the programmer lazes out and forces users to have slower running code and pauses due to GC from java.

I'd much prefer we pay programmers to do a proper job than to outsource to the lowest bidder and have 'watchdogs' keep daemon processes on unix properly running, background GC tasks, etc etc.

we used to believe in paying for quality work.  now, all that has changed (sadly).  we want to ship code FAST and the hell if it works well or not.  get the customer's money, fix bugs later (if ever) and if we drag it out long enough, a new model will be released and we'll EOL the old one.

software is not at all what it once was.

(yeah, get off my lawn)

[Rigby]

previous message removed.  I'm done arguing technical matters with someone that doesn't understand what they're barking about.

[tjaeger]

Here is my rewrite.
Ok Not really changed anything, but no gotos and the nesting (which it was meant to have) is made more obvious.

I can't tell if you're serious.

Code: [Select]

static OSStatusm SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,  uint8_t *signature, UInt16 signatureLen)
{
    OSStatus        err;
...

err = SSLHashSHA1.update(&hashCtx, &serverRandom)
if (err != 0)
{
err = SSLHashSHA1.update(&hashCtx, &signedParams)
if (err != 0)
{
err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
if (err != 0)
{
...
}
}
}
SSLFreeBuffer(&signedHashes);
SSLFreeBuffer(&hashCtx);
return err;
}


ps. Prefer Java and C# to C++ and C.  in case that wasn't obvious.
But obviously for embedded there are limited options, and good reasons for that.

[Kjelt]

lol.  after 2 years, the product is EOL anyway, in today's modern world.  I hate that, but it ends up being true for so many software projects.  don't get me started on that!

You're probably working in another field than I am. Two years ago I had to add a feature to an old product sold around 1998 because the client refused to upgrade the control system (which was hardwired in the brick wall). It was on an ST7 device with 1kB ROM and 64B Ram (yeah 64 bytes that is) and I had 20 bytes ROM and 2 bytes RAM left for the feature 
It sounds crazy for present day systems but it was a fun asignment, I ended up rewriting the whole ADC conversion from C to assembler to save a couple of extra bytes.
In that case I did leave the old code in because I can not guarantee that my next colleague is fluent in assembly and that is I think one of the exceptions to leave old code as comment (or deffed out if you prefer) what I am concerned. I hope this is the last of that product I will see before another marketing guy comes to my desk asking for more features 

Anyway that was a real exception today the lifetime of a product might be EOL in two/three years but the platform it is based on is not. The platforms will live for 10 years and all that dead code in there does not make it more prettier.

I would not use a lot of conditionals in ifdef'ing.  usually I'll just #if 0 or #ifdef NOT.  in rare occasions, if I need to give more info about why I'm temp removing this block, I'll do an #ifdef NOT_FOR_V1 but I agree if you go nuts with the conditional compilation statements it becomes unreadable.

I think if we were colleagues we would probably agree and as you know working for a company is working with 50 different programmers each having their own style and way of working and that's why there are coding standards and WOW that you agree on.

[tszaboo]

Java and C# are bloody excellent at garbage collection, too.

Yes. The prime example is Minecraft, which is able to allocate 500Mb of memory in the matter of seconds, just to free it seconds later, and cause the famous "lag spike of death". And if you write an "int" it will allocate at least 4KB of memory for you. Not cool.

[HackedFridgeMagnet]

I can't tell if you're serious.

I did delete a typo but yeah I was serious.

Just wondering, is my code so bad that you weren't sure?

[tjaeger]

I can't tell if you're serious.

I did delete a typo but yeah I was serious.

Just wondering, is my code so bad that you weren't sure?

The 'goto fail' idiom is a standard way of doing error handling in C (roughly equivalent to exceptions if done right [which is very hard IMO]). What you're suggesting here is adding an extra indentation level for every function call that could possibly fail, which is of course a maintainability nightmare.

[Kjelt]

Here we go again the good 'ol goto discussion. Let's take K&R and they say you should avoid goto's as much as possible and only give one exception:
were you have to break out of two or more loops at once, since a break statement cannot be used there.
They finish with "Although we are not dogmatic about the matter, it does seem that goto statements should be used rarely, if at all"

[HackedFridgeMagnet]

The 'goto fail' idiom is a standard way of doing error handling in C (roughly equivalent to exceptions if done right [which is very hard IMO]).

Yeah I do realise it is a standard way of doing things in C. Not convinced about the equivalence to exceptions though.
But I must admit I don't like a lot of the standard ways people do things in C.

What you're suggesting here is adding an extra indentation level for every function call that could possibly fail, which is of course a maintainability nightmare.

I don't know, in this day and age we have wide screens. I don't think it needs to be a maintainability nightmare. Some people think gotos are a maintainability nightmare.
Maybe if you want to make 20 calls to functions that have error return values you could group them into a few functions grouped in some meaningful way to improve encapsulation. By doing this you wouldn't have to indent 20 tabs worth.

I guess I always liked the structured programming paradigm( in which gotos were frowned upon). 

[tjaeger]

The 'goto fail' idiom is a standard way of doing error handling in C (roughly equivalent to exceptions if done right [which is very hard IMO]).

Yeah I do realise it is a standard way of doing things in C. Not convinced about the equivalence to exceptions though.
But I must admit I don't like a lot of the standard ways people do things in C.

You don't have to like the way things are done in C (and they're necessarily at a lower level than what you're used to), but you should at least make an effort to understand why things are done the way they are before offering non-solutions.

What you're suggesting here is adding an extra indentation level for every function call that could possibly fail, which is of course a maintainability nightmare.

I don't know, in this day and age we have wide screens. I don't think it needs to be a maintainability nightmare. Some people think gotos are a maintainability nightmare.
Maybe if you want to make 20 calls to functions that have error return values you could group them into a few functions grouped in some meaningful way to improve encapsulation. By doing this you wouldn't have to indent 20 tabs worth.

I guess I always liked the structured programming paradigm( in which gotos were frowned upon).

Think about how functions growing diagonally would interact with source control.  And no, horizontal screen space is just as precious as vertical screen space.  Deeply nested code is hard for humans to parse.

Here's the thing:  Writing code that handles every error explicitly is tedious and error-prone, but this has nothing to do whatsoever with something as superficial as whether or not you use gotos.  They can make your code clearer under certain circumstances and are readily understood by C programmers, so I don't see why you would want to forbid them, but you can of course avoid them if you are so inclined.

[HackedFridgeMagnet]

You don't have to like the way things are done in C (and they're necessarily at a lower level than what you're used to), but you should at least make an effort to understand why things are done the way they are before offering non-solutions.

Well before you call solutions "non-solutions" and before you tell me what I am used to, you should at least make an effort to understand why I proposed this solution and why I find it a better way to work and why there are some advantages of coding this way. Even in C.

The concepts aren't difficult but I will spell them out for you anyway.
  One line per instruction. Conceptually easier.
  Nesting to highlight that fact that you are deep in a bunch of conditionals. It sort of shows that to get this deep in you needed to pass a lot of tests. If you feel the depth is too deep then it highlights the point that maybe you could've coded it differently.
  Always use curly braces even for one line of scope.
  Also means you don't have to use goto statements or labels. I admit I don't find them particularly troublesome but don't really need to use them either.

The disadvantages I see are:
  more typing (not a problem)
  more screen space used. (not a problem anymore, got rid of that vga graphics card.)
  but the biggy is that it breaks convention with what most others are doing. (okay problem)

For me anyway, the reason this bug was created but undetected for the time that it was, was partly due to the coding convention.
The 'goto fail' idiom may be the standard way error handling is done in C, but it can hide bugs.

[tanstaafl]

goto in code is perfectly fine as long as you jump forward, jumping backwards should be avoided in most cases (only place I really seen backward gotos used is in the linux kernel ).

I like this way of doing stack unwinding on errors in c

Code: [Select]

if (do_something1() == ERR) 
    goto error1;           
if (do_something2() == ERR)
    goto error2;             
if (do_something3() == ERR)
    goto error3;             
if (do_something4() == ERR)
    goto error4;
goto ok;
error4:
// reverse change from do_something4()
error3:
// reverse change from do_something3()
error2:
// reverse change from do_something2()
error1:
// reverse change from do_something1()
return some_error;
ok:


[Rigby]

Java and C# are bloody excellent at garbage collection, too.

Yes. The prime example is Minecraft, which is able to allocate 500Mb of memory in the matter of seconds, just to free it seconds later, and cause the famous "lag spike of death".

That could just as easily be the operating system requesting RAM back from the JVM, you know.  This is sometimes caused by the operating system and sometimes caused by having too little RAM in general, or it can be just a matter of failing to tell the JVM that it's OK for it to use more RAM.  You can instruct Java to use a certain amount of RAM with the -Xms and -Xmx flags.  In Minecraft these are reachable via the launcher.

Besides, using Minecraft as proof that Java is slow is the equivalent of using Java as proof that C is slow, because the JVM is written in C.  Minecraft alone isn't evidence of anything other than Minecraft itself.

And if you write an "int" it will allocate at least 4KB of memory for you. Not cool.

The first time you declare the first variable of an application, yes, the JVM will do a malloc() of an amount much larger than the type you've declared.  malloc() has overhead, so Java will do fewer, larger malloc() calls in order to boost performance at the cost of memory usage.  Hey, screw Java for optimizing, right?  You can fit a hell of a lot more than one int into that 4k, and the JVM won't do another malloc() until that 4k chunk is almost entirely used up.  So, yeah.  Technically you're correct, but only for a very small test case which isn't realistic.  YOU GOT ME...

[Kjelt]

I like this way of doing stack unwinding on errors in c

Code: [Select]

if (do_something1() == ERR) 
    goto error1;           
if (do_something2() == ERR)
    goto error2;             
if (do_something3() == ERR)
    goto error3;             
if (do_something4() == ERR)
    goto error4;
goto ok;
error4:
// reverse change from do_something4()
error3:
// reverse change from do_something3()
error2:
// reverse change from do_something2()
error1:
// reverse change from do_something1()
return some_error;
ok:


Well great you just proofed why you should not use gotos, if you jump to error3 you do something fall through to error 2 do something etc. So you should return after each error, which is also not recommended (return only at the end of your function). So this could be handled much easier by instead of jumping to some labels just assigning locally the errorcode and check on each consecutive call if there has no error occurred.

[tom66]

Why not? You want to reverse each call, not just that particular call. Have to free up each allocation.

[Kjelt]

Ah ok now I see he wants to rollback. Hmmm ok, works but as you can see not very clear for others right away which is what code should be 

[tom66]

It's perfectly clear to anyone who has ever done any kind of low level driver programming, or kernel work.

Linux kernel is full of these statements:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/bluetooth/btusb.c?id=refs/tags/v3.14-rc4#n632

You're telling me instead of "goto done" or "goto failed" you'd prefer the block of code to be repeated?
What about if the block needs changing?
Why put it in a separate function call - expanding the stack further - and wasting more processor time and memory?

Just use JMP #ADDR every CPU has one and it won't affect the branch predictor, won't touch the stack and it's truly the best way to break out of it.

[Rigby]

It's perfectly clear to anyone who has ever done any kind of low level driver programming, or kernel work.

No argument.  The number of developers with low level driver or kernel experience is less than the number of developers who might see that code structure, though.

As a developer, I don't care how you do it, just document what you're doing somewhere.

[Kjelt]

It's perfectly clear to anyone who has ever done any kind of low level driver programming, or kernel work.
Linux kernel is full of these statements:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/bluetooth/btusb.c?id=refs/tags/v3.14-rc4#n632

Ouch again lots of oneline if() statements withouth brackets. Not my kind of textbook example.

You're telling me instead of "goto done" or "goto failed" you'd prefer the block of code to be repeated?

No not repeated more something  like this:

Code: [Select]

#define NO_ERROR 0

Errorcode = Function1();

if(Errorcode == NO_ERROR)
{
  Errorcode = Function2();
}
if(Errorcode == NO_ERROR)
{
  Errorcode = Function3();
}

if(Errorcode != NO_ERROR)
{
  //errorhandler if necessary, do what you need to do

}
return Errorcode;

But as many programmers there are the many styles each prefers.

[zapta]

How is that easier than /* ... */ ?  I mean, that's what comments are FOR.

No, it is not. IF you already have comment with /* */ there, it will mess up everything pretty much. Also, #if 0 is even more useful.

yup, the safest way to comment-out code is with ifdef stuff.

#ifdef NOT

or

#ifdef FIX_ME_LATER

and so on.

using comment chars to 'comment out' a block of code is really wrong and such a newbie thing to do

The safest way is to comment with // using the block comment of your editor of choice.  This way it's obvious what lines are out.

Sent from my Nexus 5 using Tapatalk

[linux-works]

are you suggesting that for a 100 line block of code, you prepend each line with '//' and then to UNDO that you literally have to remove it all?

you can't be serious.  that's really not the way to do it.  do you see why?

[linux-works]

I will add this: since I use a colorizing editor (emacs, natch) commenting out a line with actual comments does change that block's color and that's a really nice thing.  when I ifdef-out a block, it does not change its color.

so, there is a minor tools-based issue that gives the edge to actual comment chars vs the ifdef way.  still, commenting out a block that has comments in there means you really should only use the ifdef method.  maybe someone has an emacs script that updates c-style to know about '#if 0' blocks. 

[Rigby]

are you suggesting that for a 100 line block of code, you prepend each line with '//' and then to UNDO that you literally have to remove it all?

you can't be serious.  that's really not the way to do it.  do you see why?

... We don't do it to each line, one at a time... tools can single-line comment multiple lines simultaneously.  Hell, even Emacs and vim can do it.

[AlfBaz]

are you suggesting that for a 100 line block of code, you prepend each line with '//' and then to UNDO that you literally have to remove it all?

you can't be serious.  that's really not the way to do it.  do you see why?

The IDE does it. You select the block of text and then click toggle comment (Ctrl + /) in eclipse. Visual Studio, IAR, Keil, MPLAB even UltraEdit does it
Far less obscure than stupid #if 0 which is far more obscure than goto
That's really the way to do it. Do you see why?

[linux-works]

no I don't see why.

again, expecting comments to nest is a newbie thing (on C).  we stopped doing this a long time ago.

I will always write a comment at the start and end of the block explaining why its commented out.  I use a lot of vertical space and its obvious that this isolated block is an entity of its own and should be taken as a whole logical block.

I do lose the coloring feature when I use the ifdef method.

not sure if I can convince you, but again - after doing this for well over 25 yrs, I have a sense of what is common in the field and what is not.

[T3sl4co1l]

are you suggesting that for a 100 line block of code, you prepend each line with '//' and then to UNDO that you literally have to remove it all?

you can't be serious.  that's really not the way to do it.  do you see why?

Select block, CTRL+/

[tjaeger]

are you suggesting that for a 100 line block of code, you prepend each line with '//' and then to UNDO that you literally have to remove it all?

you can't be serious.  that's really not the way to do it.  do you see why?

The IDE does it. You select the block of text and then click toggle comment (Ctrl + /) in eclipse. Visual Studio, IAR, Keil, MPLAB even UltraEdit does it
Far less obscure than stupid #if 0 which is far more obscure than goto
That's really the way to do it. Do you see why?

What is happening here?  First of all, commenting out code is generally a bad idea.  What you usually want to do is delete the code and bring it back using source control if need be.  That said, in the limited circumstances where it does make sense to comment out code because you know you will need the code again soon, #if 0 is vastly superior to adding a // in front of every line because it doesn't mess up your file's history.  Any decent editor will highlight an #if 0 block the same way it highlights a comment.

[linux-works]

what editor is that for?

does not work in emacs, unless you have bound your ^/ key combo to something non-standard.

I don't use eclipse (not much) and I'm not really an IDE guy.

the ifdef method requires no tool support, so even if I'm making a quickie change and running vi for that, I can still disable blocks of code like this very quickly and easily.  even better, if I do something like:

#ifdef EXPERIMENT_V1
#endif // EXPERIMENT_V1

then I can turn that test block on and off, even without doing any edits at all (ie, set the symbol on the command line when you build or edit the Makefile).

if you hard comment things out, you can't easily try the block in and out.

there is just more flexibility in the ifdef method.  its why its become the main way, in C, to do this very thing.

[linux-works]

I guess emacs with standard c-mode and c++-mode is not a 'good editor' in your terms.

it does NOT color the region on an ifdef.

I agree it would be nice if they did, but then again, maybe it would be nice if they would color the region differently based on the ifdef condition

(I'm only half serious about that last one).

[AlfBaz]

are you suggesting that for a 100 line block of code, you prepend each line with '//' and then to UNDO that you literally have to remove it all?

you can't be serious.  that's really not the way to do it.  do you see why?

The IDE does it. You select the block of text and then click toggle comment (Ctrl + /) in eclipse. Visual Studio, IAR, Keil, MPLAB even UltraEdit does it
Far less obscure than stupid #if 0 which is far more obscure than goto
That's really the way to do it. Do you see why?

What is happening here?  First of all, commenting out code is generally a bad idea.  What you usually want to do is delete the code and bring it back using source control if need be.

LOL no worries mate, you go ahead and do that. Whilst developing or debugging there's never any need to comment out code

  That said, in the limited circumstances where it does make sense to comment out code because you know you will need the code again soon, #if 0 is vastly superior to adding a // in front of every line because it doesn't mess up your file's history.  Any decent editor will highlight an #if 0 block the same way it highlights a comment.

Select and click is highly expedient. #if 0 is nonsense, programmatically, logically and an abuse of the pre-processor

[AlfBaz]

I guess emacs with standard c-mode and c++-mode is not a 'good editor' in your terms.

it does NOT color the region on an ifdef.

I agree it would be nice if they did, but then again, maybe it would be nice if they would color the region differently based on the ifdef condition

You really need to see what modern IDE's have to offer

[linux-works]

developers should be free to use the tools they know and are efficient with.

I don't mind ide's.  I have tried using eclipse and its not too bad.  but I still fall back to emacs since I've been using it for a long long time and it gets the job done for me.

what you propose has a dependancy on tools.  my method does not.

I will continue to use the ifdef method even if it annoys the newbies

[tjaeger]

What is happening here?  First of all, commenting out code is generally a bad idea.  What you usually want to do is delete the code and bring it back using source control if need be.

LOL no worries mate, you go ahead and do that. Whilst developing or debugging there's never any need to comment out code

I literally addressed that point in my next sentence.  Your smiley is extremely rude.

  That said, in the limited circumstances where it does make sense to comment out code because you know you will need the code again soon, #if 0 is vastly superior to adding a // in front of every line because it doesn't mess up your file's history.  Any decent editor will highlight an #if 0 block the same way it highlights a comment.

Select and click is highly expedient. #if 0 is nonsense, programmatically, logically and an abuse of the pre-processor

I can play this game, too. Putting code in comments is an abuse of the concept of a 'comment', whose purpose is to provide explanations to make the code easier to understand for humans, not to temporarily stash unneeded code.

[AlfBaz]

even if it annoys the newbies

That's me or at least I wish, I'd be a lot younger then
I still remember hearing about these new fangled compilers that accepted // as a single line commenting system.
Who'd of thought many years later I'd be arguing it's merits as a multi-line commenting system on a very high speed bbs where I didn't have to wait overnight to hear a response

[tjaeger]

I guess emacs with standard c-mode and c++-mode is not a 'good editor' in your terms.

it does NOT color the region on an ifdef.

I agree it would be nice if they did, but then again, maybe it would be nice if they would color the region differently based on the ifdef condition

(I'm only half serious about that last one).

Who knew?  Vim does it, I guess I just assumed it was standard.

[AlfBaz]

I can play this game, too. Putting code in comments is an abuse of the concept of a 'comment', whose purpose is to provide explanations to make the code easier to understand for humans, not to temporarily stash unneeded code.

Like it or not "comment out" has become an integral part of the C/C++ programming vernacular

[linux-works]

just tried it with vim and, sure enough, you were right.  it is a cool feature.

alright - I have to figure out why current emacs c-mode isn't up to this, or if there's a reason why they decided not to.  its NICE to see the whole block commented out.  or at least have the option via a setting.

I guess the vim guys decided this was a valid enough C'ism to give it colorizing support.

also, I just tried making my comment block '#if 0' and then changing it to '#if 1' and magically, it treated the block as if it was not commented out!  I'm impressed   I just tried it on a lark but got a big smile when the color 'came back' as I changed the if to '1'.

of course it can't know what my Makefile or cli command invocation would be, but for this simple 0/1 stuff, this is quite cool.

please don't convert me to vi.  please?

lol

[linux-works]

I can play this game, too. Putting code in comments is an abuse of the concept of a 'comment', whose purpose is to provide explanations to make the code easier to understand for humans, not to temporarily stash unneeded code.

Like it or not "comment out" has become an integral part of the C/C++ programming vernacular

with every language.  in BASIC, it was 'remming out' (lol).  I first learned computer concepts on my trs80 in the late 70's.  and we would 'rem out' lines of code all the time.

and so, the code hiding while still being -in- the file concept - its been done a long, long time.   I don't like using source code control for this.  some seem to, but I just don't like that style.  its painful to deal with source control and I try to avoid going back in the past and digging things up as much as I can.  its never a fun time.  having the 'work' be kept in the file just makes my life so much easier if I need to refer to it or toggle it on/off.

[tjaeger]

I can play this game, too. Putting code in comments is an abuse of the concept of a 'comment', whose purpose is to provide explanations to make the code easier to understand for humans, not to temporarily stash unneeded code.

Like it or not "comment out" has become an integral part of the C/C++ programming vernacular

I guess I should have been more explicit.  My point was not that you should never ever comment out code, but that it's silly to reject '#if 0' on grounds that this not what the preprocessor was made for if the exact same argument applies to comments as well.

Now my original point was that '#if 0' is preferable to comments if you care about the file's source control history.  I'm still partial to just deleting stuff temporarily and bringing it back when quickly testing things out, but then again, I use an editor that makes this sort of workflow easy.  If you prefer commenting code out in that case, there's nothing wrong with that.

[Rigby]

what editor is that for?

does not work in emacs, unless you have bound your ^/ key combo to something non-standard.

I don't use eclipse (not much) and I'm not really an IDE guy.

the ifdef method requires no tool support, so even if I'm making a quickie change and running vi for that, I can still disable blocks of code like this very quickly and easily.  even better, if I do something like:

#ifdef EXPERIMENT_V1
#endif // EXPERIMENT_V1

then I can turn that test block on and off, even without doing any edits at all (ie, set the symbol on the command line when you build or edit the Makefile).

if you hard comment things out, you can't easily try the block in and out.

there is just more flexibility in the ifdef method.  its why its become the main way, in C, to do this very thing.

commenting multiple lines at once in emacs: http://stackoverflow.com/questions/3526386/how-to-prepend-at-the-head-of-multiple-lines-with-emacs

your dislike of tool dependency may extend too far if you didn't think to Google that.

[linux-works]

you still don't get it.

its not the inability to prepend comment chars to a block.  but its just cleaner to not have to TOUCH each line in order to hide a whole block.

adding things to lines is not what I want to do.  and you don't HAVE to, that's what I'm saying.

maybe some lines are formatted in a way you don't want to lose.  maybe adding '// ' is enough to cause wrap or breakage of formating.  why even mess with touching lines when you don't have to?

and again, you can toggle this on and off at build time.  you cannot do that when you comment-hide blocks.  ifdef'ing blocks allows toggling.  its valuable and useful to have this.  and it even nests, too.

[linux-works]

I guess I should have been more explicit.  My point was not that you should never ever comment out code, but that it's silly to reject '#if 0' on grounds that this not what the preprocessor was made for if the exact same argument applies to comments as well.

agreed.  even though the preprocessor was not -designed- for this, its come to be used for this almost as much as its original intention.

when I first learned C, the preprocessor stuff seemed odd and I didn't like it.  its not a 'normal' part of most languages and if you are not used to it, it just seems odd.  I get that.  but it ends up being quite powerful.  when I was learning java, I asked about conditional compilation and I got lots of 'bambi in headlights' stares back at me.  I guess java doesn't have that concept.  pity.  big loss for java.  but then java build system(s) are also a huge joke (sorry).

[Dave Turner]

Aside from the fact that this thread is now somewhat off topic consider this:-

What is the point of using comments (however they are used), #ifdef's, #ifndef's etc.?

At root level, whichever language and/or platform you are using, it depends on who will use your code now or in the future.

If only you - then whatever works for you is fine; but if you are like me insufficient comments causes loads of wasted time due to memory loss when one looks at a project at a later date (either time lapsed or just age).

If one works in a team then there is no excuse for insufficient commenting - you won't be there forever. Furthermore in a team there needs to be an agreed standard.

It's almost pointless to attempt to go further as all situations are different. Too strict and you'll lose efficiency - too loose and you'll lose maintainability.

It's the overall result that counts.

[linux-works]

in terms of commenting (in the true sense, ie, documenting what you mean or intend), you get a bit of that for free with the ifdef method.

again:

#ifdef HARDWARE_V1_TRIAL

#ifdef REDHAT_FARKED_THEIR_IPV6_STACK_AGAIN

and so on.



you can add at least something about why you are 'trimming out' this bit of code and you can add a '#define REDHAT_FARKED_THEIR_IPV6_STACK_AGAIN' at the top of your program to toggle this.

and now, to blow your mind:

// #define REDHAT_FARKED_THEIR_IPV6_STACK_AGAIN

that toggles the toggle.

hahaha

[Rigby]

you still don't get it.

its not the inability to prepend comment chars to a block.  but its just cleaner to not have to TOUCH each line in order to hide a whole block.

adding things to lines is not what I want to do.  and you don't HAVE to, that's what I'm saying.

maybe some lines are formatted in a way you don't want to lose.  maybe adding '// ' is enough to cause wrap or breakage of formating.  why even mess with touching lines when you don't have to?

and again, you can toggle this on and off at build time.  you cannot do that when you comment-hide blocks.  ifdef'ing blocks allows toggling.  its valuable and useful to have this.  and it even nests, too.

We're never going to agree on this.  Maybe we shouldn't even try.  In your world, what you do works for you.  In my world, I would be pulled into an office and given a good "what in the holy living fuck are you doing" conversation if I used ifdefs to test code.

I would suggest that you look at testing frameworks to see how it's done in managed languages.  There's no need to use ifdefs for testing or debugging because there are FAR better mechanisms for testing code with a testing framework.  That might not be so easy for a C developer, since C programs aren't usually object oriented, but in managed languages it's really easy if you stick to OO Architectures when you're putting your application together.  C test frameworks exist, so you can see it in your language.

So, I will agree to disagree with you, or if you prefer, I disagree to agree.