Author Topic: Epic (goto) fail is epic.  (Read 38269 times)

0 Members and 1 Guest are viewing this topic.

Offline Marco

  • Super Contributor
  • ***
  • Posts: 6716
  • Country: nl
Re: Epic (goto) fail is epic.
« Reply #25 on: February 24, 2014, 01:48:57 pm »
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.
« Last Edit: February 24, 2014, 01:51:09 pm by Marco »
 

Offline firewalkerTopic starter

  • Super Contributor
  • ***
  • Posts: 2450
  • Country: gr
Re: Epic (goto) fail is epic.
« Reply #26 on: February 24, 2014, 02:06:18 pm »
Especially when someone uses threads.

Alexander.
Become a realist, stay a dreamer.

 

Offline AlfBaz

  • Super Contributor
  • ***
  • Posts: 2184
  • Country: au
Re: Epic (goto) fail is epic.
« Reply #27 on: February 24, 2014, 02:50:37 pm »
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. |O
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
 

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 7366
  • Country: nl
  • Current job: ATEX product design
Re: Epic (goto) fail is epic.
« Reply #28 on: February 24, 2014, 03:12:43 pm »
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.
 

Offline Rigby

  • Super Contributor
  • ***
  • Posts: 1476
  • Country: us
  • Learning, very new at this. Righteous Asshole, too
Re: Epic (goto) fail is epic.
« Reply #29 on: February 24, 2014, 03:36:52 pm »
How is that easier than /* ... */ ?  I mean, that's what comments are FOR.
 

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 7366
  • Country: nl
  • Current job: ATEX product design
Re: Epic (goto) fail is epic.
« Reply #30 on: February 24, 2014, 03:47:26 pm »
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.
 

Offline Rigby

  • Super Contributor
  • ***
  • Posts: 1476
  • Country: us
  • Learning, very new at this. Righteous Asshole, too
Re: Epic (goto) fail is epic.
« Reply #31 on: February 24, 2014, 04:01:02 pm »
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.

 

Offline linux-works

  • Super Contributor
  • ***
  • Posts: 1995
  • Country: us
    • netstuff
Re: Epic (goto) fail is epic.
« Reply #32 on: February 24, 2014, 05:21:51 pm »
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. |O
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.

Offline linux-works

  • Super Contributor
  • ***
  • Posts: 1995
  • Country: us
    • netstuff
Re: Epic (goto) fail is epic.
« Reply #33 on: February 24, 2014, 05:23:33 pm »
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 ;)

Offline linux-works

  • Super Contributor
  • ***
  • Posts: 1995
  • Country: us
    • netstuff
Re: Epic (goto) fail is epic.
« Reply #34 on: February 24, 2014, 05:27:43 pm »
btw, the goto statement has been replaced, in most modern languages, with the comefrom statement.

(no, I'm not serious) ;)

Offline Rigby

  • Super Contributor
  • ***
  • Posts: 1476
  • Country: us
  • Learning, very new at this. Righteous Asshole, too
Re: Epic (goto) fail is epic.
« Reply #35 on: February 24, 2014, 05:54:29 pm »
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.
 

Offline linux-works

  • Super Contributor
  • ***
  • Posts: 1995
  • Country: us
    • netstuff
Re: Epic (goto) fail is epic.
« Reply #36 on: February 24, 2014, 05:57:34 pm »
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.

Offline Marco

  • Super Contributor
  • ***
  • Posts: 6716
  • Country: nl
Re: Epic (goto) fail is epic.
« Reply #37 on: February 24, 2014, 06:08:19 pm »
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.
« Last Edit: February 24, 2014, 06:10:06 pm by Marco »
 

Offline Rigby

  • Super Contributor
  • ***
  • Posts: 1476
  • Country: us
  • Learning, very new at this. Righteous Asshole, too
Re: Epic (goto) fail is epic.
« Reply #38 on: February 24, 2014, 06:19:59 pm »
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.
 

Offline linux-works

  • Super Contributor
  • ***
  • Posts: 1995
  • Country: us
    • netstuff
Re: Epic (goto) fail is epic.
« Reply #39 on: February 24, 2014, 06:25:44 pm »
"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.

Offline Rigby

  • Super Contributor
  • ***
  • Posts: 1476
  • Country: us
  • Learning, very new at this. Righteous Asshole, too
Re: Epic (goto) fail is epic.
« Reply #40 on: February 24, 2014, 07:14:01 pm »
"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.
 

Offline linux-works

  • Super Contributor
  • ***
  • Posts: 1995
  • Country: us
    • netstuff
Re: Epic (goto) fail is epic.
« Reply #41 on: February 24, 2014, 07:28:11 pm »
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)


Offline Phaedrus

  • Frequent Contributor
  • **
  • Posts: 714
  • Country: us
Re: Epic (goto) fail is epic.
« Reply #42 on: February 24, 2014, 07:39:12 pm »
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.  ::)
"More quotes have been misattributed to Albert Einstein than to any other famous person."
- Albert Einstein
 

Offline linux-works

  • Super Contributor
  • ***
  • Posts: 1995
  • Country: us
    • netstuff
Re: Epic (goto) fail is epic.
« Reply #43 on: February 24, 2014, 07:55:31 pm »
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.

Offline Macbeth

  • Super Contributor
  • ***
  • Posts: 2571
  • Country: gb
Re: Epic (goto) fail is epic.
« Reply #44 on: February 24, 2014, 08:26:15 pm »
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?  :-DD

Quote
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!
 

Offline linux-works

  • Super Contributor
  • ***
  • Posts: 1995
  • Country: us
    • netstuff
Re: Epic (goto) fail is epic.
« Reply #45 on: February 24, 2014, 08:34:40 pm »
looks like zilog mnemonics for the z80, alright.

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


Offline AlfBaz

  • Super Contributor
  • ***
  • Posts: 2184
  • Country: au
Re: Epic (goto) fail is epic.
« Reply #46 on: February 24, 2014, 08:34:56 pm »
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 :box:
 

Offline Rigby

  • Super Contributor
  • ***
  • Posts: 1476
  • Country: us
  • Learning, very new at this. Righteous Asshole, too
Re: Epic (goto) fail is epic.
« Reply #47 on: February 24, 2014, 08:36:15 pm »
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 :box:

Thank you.
 

Offline AlfBaz

  • Super Contributor
  • ***
  • Posts: 2184
  • Country: au
Re: Epic (goto) fail is epic.
« Reply #48 on: February 24, 2014, 08:36:47 pm »
Select text, right click, comment block... It's so hard  ::)
 

Offline linux-works

  • Super Contributor
  • ***
  • Posts: 1995
  • Country: us
    • netstuff
Re: Epic (goto) fail is epic.
« Reply #49 on: February 24, 2014, 08:37:35 pm »
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.


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf