• (cs) in reply to Norman Diamond
    Norman Diamond:
    If a plane crashes on the border between the United States and Canada, where will the survivors be buried?
    Presumably in graveyards, eventually. Though some of them will probably be cremated rather than buried.

    Just because they didn't die in the crash doesn't make them immortal, after all.

  • (cs) in reply to Scarlet Manuka
    Scarlet Manuka:
    Norman Diamond:
    If a plane crashes on the border between the United States and Canada, where will the survivors be buried?
    Presumably in graveyards, eventually. Though some of them will probably be cremated rather than buried.

    Just because they didn't die in the crash doesn't make them immortal, after all.

    Depends. The survivors on the canadian side will probably go on to lead happy healthy lives. The ones on the American side will probably be sent back to their families' funeral home of choice.

  • Gigaplex (unregistered) in reply to havokk
    havokk:
    Gigaplex:
    I disagree to some extent. NULL to me means "known to be invalid", not "unknown".
    Then you need to re-read Codd's 12 Rules. In a RDBMS, null markers indicate missing or inapplicable data. Example of missing data: Birthdate of someone whose birth records were lost. They do have a birthday but they don't know which day of the year it was. Example of inapplicable: Weight of a mp3 file. Hair colour of a bald man.
    I've never read Codd's 12 rules, nor do I deal with databases. My perspective is from a programming point of view, and since the example in this article is about code not databases I'm going to respond from that perspective.
    havokk:
    Thought experiment: Stick your right hand into a bowl of lollies, grab a handful, and then remove your closed fist from the bowl. How many lollies are in your right hand? Unknown. There is an actual value - you just don't know it at this point in time (without opening your fist and couting the lollies). Now put three lollies in your left hand. Is the number of lollies in your left hand equal to the number of lollies in your right hand? Well, since the number of lollies in your right hand is unknown then you can't know if they are equal or not. KnownValue = NULL --> NULL.
    The number of lollies in your right hand is either a null pointer/reference or an uninitialised variable, leading to a null reference exception, compilation error, or undefined behaviour depending on programming language.
    havokk:
    Next thought experiment: Stick both hands into the bowl and grab a handful of lollies. Is the number of lollies in your left hand equal to the number of lollies in your right hand? Since you don't know the number of lollies in either hand then you can't know if they are equal or not. NULL = NULL --> NULL.
    Again, the variables are either null pointer/references or uninitialised variables, leading to the same issues as I mentioned above.
    havokk:
    Hint: Use the phrase "null marker" rather than "null value". It will help reduce misunderstandings. For "missing", use words like "maybe", "perhaps", "possibly", "dunno". P.S. null markers in a RDBMS have nothing to do with null pointers in programming languages.
    It sounds like null markers are equivalent to an amalgamation of null references and uninitialised variables.
  • Andrew (unregistered) in reply to Anoldhacker

    I guess that's the whole point of the negated condition check, although personally I think it is not well implemented.

    Suppose the code is written on day1 with this intention

    if (condition1) { doSomething(); } else if (!condition1) { doSomethingElse(); }

    It could be that the doSomethingElse() only work if !condition1, and it could be castrophic if doSomethingElse() is executed if condition1 is true.

    e.g. if (alive) { doMonitorHeartBeat(); } else { injectFormalin(); }

    Now consider a feature request to introduce a new switch to monitor heart beat, now an inexperienced developer could write code like.

    if (alive && switch == "On") { doMonitorHeartBeat(); } else { doInjectFormalin(); }

    Now he kills everyone when the switch is off!Now you see the value of insisting the else block check? Consider the doMonitorHeartBeat() is expanded into something like 300 - 400 lines - it is really easy for one to miss that.

    I feel like the right solution is Assert [Assuming you turn on assert during testing, and there are enough test cases]

    if (alive) { doMonitorHeartBeat(); } else { Debug.Assert(!alive); doInjectFormalin(); }

    or to be extra safe - to ensure the code doSomethingElse, despite a careless programmer comes in - can be executed.

    if (alive) { doMonitorHeartBeat(); } else if (!alive) { Debug.Assert(!alive); doInjectFormalin(); } else { Debug.Assert("Should never reach here"); }

  • Andrew (unregistered) in reply to Andrew

    Look - the subject of the article applies!

    Anything can happens! That "Anything" also include someone can change your code. Having robust code is nothing wrong.

  • Norman Diamond (unregistered) in reply to Andrew
    Andrew:
    e.g. if (alive) { doMonitorHeartBeat(); } else { injectFormalin(); }

    Now consider a feature request to introduce a new switch to monitor heart beat, now an inexperienced developer could write code like.

    if (alive && switch == "On") { doMonitorHeartBeat(); } else { doInjectFormalin(); }

    Now he kills everyone when the switch is off!Now you see the value of insisting the else block check? Consider the doMonitorHeartBeat() is expanded into something like 300 - 400 lines - it is really easy for one to miss that.

    Splendid example. +infinity.

    Too bad you proceeded to fuck it up:

    Andrew:
    I feel like the right solution is Assert [Assuming you turn on assert during testing, and there are enough test cases]

    if (alive) { doMonitorHeartBeat(); } else { Debug.Assert(!alive); doInjectFormalin(); }

    or to be extra safe - to ensure the code doSomethingElse, despite a careless programmer comes in - can be executed.

    if (alive) { doMonitorHeartBeat(); } else if (!alive) { Debug.Assert(!alive); doInjectFormalin(); } else { Debug.Assert("Should never reach here"); }

    You need the redundant test inside doInjectFormalin(), not here in the if statement.

    And you need the redundant test in release builds. You DON'T need this:

    } else if (!alive) { #if debug alert("fatal bug"); abort(); #else // kill(patient) in 3 ... 2 ... 1 ... #endif doInjectFormalin(); } else {

  • (cs) in reply to Mythran
    Mythran:
    William F:
    CAPTCHA: ague - what I get from some of these stories

    How do you pronounce "ague"? "A jew" or "ag you" or "a goo" or "a gua" or ? Different pictures pop into my head depending on how it's pronounced :P

    I always assumed it rhymed with "plague". But http://dictionary.reference.com/browse/ague tells me it is "ay-gyoo".

  • Wak (unregistered)

    Hey, there are languages where Doug's pattern makes sense. For example in (System) Verilog:

    module top;
    reg x;
    initial
        if( x )
    	$display(1);
        else if( !x )
    	$display(2);
        else
    	$display(3);
    endmodule
    
  • Krzysiek (unregistered) in reply to Michael P
    Michael P:
    Some coding standards (...) specifically require an if/else if chain to be terminated with either an "else" handler or a comment that explains why there is no else. That seems like good practice for any software with significant safety implications.

    FTFY: "That seems like good practice for any software."

    BTW, MISRA also enforces that.

  • CodeWatcher (unregistered)

    I see this had a happy ending: no patients being fried with 4 times the radiation they needed!

    It's better many times to get a developer that is green that can be trained than the 'experienced' developer.

  • (cs)

    if (a) { doSomething(); }

    or else { youHaventHeardTheLastOfThis(); }

  • vlnx (unregistered) in reply to long johnson

    yeah, bury that poor fucker alive :-D

  • andytech (unregistered)

    This code reminds me of a guy named Bob I used to work with - he also had an interesting conditional pattern used everywhere throughout his code:

    while(x) {
       if(x) {
          // do something
       }
    }
    

    with the same (sometimes not quite right) duplication of the conditional check as Doug's code. Also sometimes the conditional had side effects, which got applied twice...

    Apparently all this was necessary because "you never know - it might change between the 'while' and the 'if'"....

  • Hegel (unregistered)

    The infamous negation operation may indeed cause interesting side-effects. Long time ago as an intern I had to bang my head against wall in a certain VB6 (sigh) project. A function in a certain COM component returned strange, ill-behaving "Boolean" values, which were not quite defined in a standard way.

    #define TRUE 1 #define FALSE 0 #define FILE_NOT_FOUND !TRUE

    fileExists=FILE_NOT_FOUND;

    if(sfileExists) { copyFile(); } else if (!foo) { showError("File not found!"); }

  • Hegel (unregistered) in reply to Hegel

    Of course I ment to write the code as following.

    Hegel:
    #define TRUE 1 #define FALSE 0 #define FILE_NOT_FOUND !TRUE

    fileExists=FILE_NOT_FOUND;

    if(fileExists) { copyFile(); } else if (!fileExists) { showError("File not found!"); }

  • foo (unregistered) in reply to Norman Diamond
    Norman Diamond:
    If a plane crashes on the border between the United States and Canada, where will the survivors be buried?
    Gitmo (if Arab).
  • Abico (unregistered) in reply to Scarlet Manuka
    Scarlet Manuka:
    Abico:
    Here's how people like Doug happen: {VB6} {years of honing one piece of code} {false sense of understanding and confidence} {thinks he knows better than everyone else} Yes, I could submit a week's worth of TDWTFs about the Doug I knew.
    Let me guess, he wrote a file text searcher cum media player?
    I wish. Try dynamometer controller.
  • (cs)

    We've got a "what if something happens" person on our team. She knows literally fuck all about SQL or ORMs but can claim that "remote paging and sorting is really inefficient because you keep hitting the database. it would be much more efficient to select all the rows from the table, keep them in memory and do the paging and sorting from there".

    Despite the fact that there's this thing called "Structured Query Language", databases must only rarely be queried, because it will impact negatively on performance..

    When I asked her about concurrency in case records are added, deleted or updated she went all quiet, then countered with "opening DB connections is an expensive operation, you don't want to do that on every request". Then I asked her if she knew anything about connection pooling..

    Putting the F in WTF.

  • Alex (unregistered)

    What about that:

    if (a)
    {
      doSomething();
      a = false;
    }
    else if (!a)
    {
      doSomethingElse();
    }
    

    Not that I would endorse this kind of programming, because of it being pretty unpredictable, but still. Also, C++ operator overloading could actually yield different results for (bool)(a) and (bool)(!a). Not that I would endorse that kind of programming either, but the following would actually be able to execute all three code paths, depending on operator overloading:

    if (a)
    {
      doSomething();
    }
    else if (!a)
    {
      doSomethingElse();
    }
    else
    {
      doWTF();
    }
    
  • Anon (unregistered)
    Alex:
    if (a)
    {
      doSomething();
      a = false;
    }
    else if (!a)
    {
      doSomethingElse();
    }
    

    If a is true doSomethingElse(); would not be executed, because it doesn't check for the second if.

    This instead would execute both:

    if (a)
    {
      doSomething();
      a = false;
    }
    if (!a)
    {
      doSomethingElse();
    }
    
  • annonomous (unregistered)

    Obviously he was just trying to account for the tri-state boolean.

  • AmokCrow (unregistered)

    Let's face it. It's another victim of Visual Basic, the only language where a boolean may be something else than just true or false. It gives a whole new meaning to the "else {" structure.

  • foo2 (unregistered) in reply to Scarlet Manuka
    Scarlet Manuka:
    Let me guess, he wrote a file text searcher cum media player?
    And then he went on to update Irfanview to do the same!

    Seriously Irfanview, WTF?

  • Paul Neumann (unregistered) in reply to Gigaplex
    Gigaplex:
    I disagree to some extent. NULL to me means "known to be invalid", not "unknown". Something logically can be valid but unknown given the context. If two things are known to be invalid they can logically be considered equivalent.
    And when you've designed a language which is as pervasive, maybe we will care what you think about it.
  • (cs) in reply to andytech
    andytech:
    This code reminds me of a guy named Bob I used to work with - he also had an interesting conditional pattern used everywhere throughout his code:
    while(x) {
       if(x) {
          // do something
       }
    }
    

    with the same (sometimes not quite right) duplication of the conditional check as Doug's code. Also sometimes the conditional had side effects, which got applied twice...

    Apparently all this was necessary because "you never know - it might change between the 'while' and the 'if'"....

    I would suggest asking Bob "what happens if it changes between the 'if' and the 'do something'? Better put another 'if' in there."

  • Spider Flyer (unregistered) in reply to Alex
    Alex:
    What about that:
    if (a)
    {
      doSomething();
      a = false;
    }
    else if (!a)
    {
      doSomethingElse();
    }
    

    Not that I would endorse this kind of programming, because of it being pretty unpredictable, but still. Also, C++ operator overloading could actually yield different results for (bool)(a) and (bool)(!a). Not that I would endorse that kind of programming either, but the following would actually be able to execute all three code paths, depending on operator overloading:

    if (a)
    {
      doSomething();
    }
    else if (!a)
    {
      doSomethingElse();
    }
    else
    {
      doWTF();
    }
    

    Which is where the person's 'decades of experience' kicks in, he's had to deal with 'compiler idiosyncrasies' before, and wanted to guard against that.

    Image your C++ example was built into the compiler itself, and then you went and changed your Boolean logic to fit a coding standard...

    I've actually had experience with a compiler that would allow certain types of Boolean operations in an 'if' conditional and not others.

    Also, if you are getting in complex Boolean logic, then I would recommend an online Boolean simplifier to make sure that you're getting the inversion logic correct. And, to make the code easier to read, I would recommend factoring out just the Boolean conditional to a separate function with an easy to understand name.

  • jay (unregistered) in reply to Maurits
    Maurits:
    andytech:
    This code reminds me of a guy named Bob I used to work with - he also had an interesting conditional pattern used everywhere throughout his code:
    while(x) {
       if(x) {
          // do something
       }
    }
    

    with the same (sometimes not quite right) duplication of the conditional check as Doug's code. Also sometimes the conditional had side effects, which got applied twice...

    Apparently all this was necessary because "you never know - it might change between the 'while' and the 'if'"....

    I would suggest asking Bob "what happens if it changes between the 'if' and the 'do something'? Better put another 'if' in there."

    I can't count how many times I've seen:

    if (collection.size()>0)
    {
      for (int x = 0;x<collection.size(); ++x)
      {
        doSomething(collection.getMember(x));
      }
    }
    </pre>
    

    Or variations thereof. Like the programmer doesn't trust the test on loop counter to work in the case where the loop would execute zero times, but he apparently trusts it to work correctly in all other cases.

  • Oh, the humanity! (unregistered) in reply to Wak
    Wak:
    Hey, there are languages where Doug's pattern makes sense. For example in (System) Verilog:
    module top;
    reg x;
    initial
        if( x )
    	$display(1);
        else if( !x )
    	$display(2);
        else
    	$display(3);
    endmodule
    

    Your example is wrong on so many levels, you know.

    I guess the point you are trying to make is: In a single bit variable, there could be more states than zero or one. That is true.

    Your "initial" happens at sim-time zero. Who is defining the state of 'x'? Also at sim-time zero? You got a race condition on your hand!

    Your variable 'x' is local scope to "top". Maybe there is someone accessing 'x' via 'top.x'. However "top" suggests to be the toplevel of your design/simulation (whatever you are trying to do here).

    What are you passing into $display()? Is this even valid syntax? It takes a string, no? All 8bit ASCII characters? Then your 1, 2 or 3 are non-printable values. Right?

      always @(x)
        if (x === 1'b1) 
          $display("1");
        else if (x === 1'b0)
          $display("2");
        else
          $display("3");
    

    ... might make some more sense.

    Yes, tripple = if you compare includes 'Z's or 'X's! (An unitialized reg - the datatype of "x" - will be X, as in state unknown. If it is an undriven wire, you'll see a Z.)

    Or you could simply do this:

      always @(x)
        $display("x is %b at %t",x,$time);
    

    I am replying to a troll, ain't I?

  • jay (unregistered) in reply to Gigaplex
    Gigaplex:
    havokk:
    Gigaplex:
    I disagree to some extent. NULL to me means "known to be invalid", not "unknown".
    Then you need to re-read Codd's 12 Rules. In a RDBMS, null markers indicate missing or inapplicable data. Example of missing data: Birthdate of someone whose birth records were lost. They do have a birthday but they don't know which day of the year it was. Example of inapplicable: Weight of a mp3 file. Hair colour of a bald man.
    I've never read Codd's 12 rules, nor do I deal with databases. My perspective is from a programming point of view, and since the example in this article is about code not databases I'm going to respond from that perspective.
    havokk:
    Thought experiment: Stick your right hand into a bowl of lollies, grab a handful, and then remove your closed fist from the bowl. How many lollies are in your right hand? Unknown. There is an actual value - you just don't know it at this point in time (without opening your fist and couting the lollies). Now put three lollies in your left hand. Is the number of lollies in your left hand equal to the number of lollies in your right hand? Well, since the number of lollies in your right hand is unknown then you can't know if they are equal or not. KnownValue = NULL --> NULL.
    The number of lollies in your right hand is either a null pointer/reference or an uninitialised variable, leading to a null reference exception, compilation error, or undefined behaviour depending on programming language.
    havokk:
    Next thought experiment: Stick both hands into the bowl and grab a handful of lollies. Is the number of lollies in your left hand equal to the number of lollies in your right hand? Since you don't know the number of lollies in either hand then you can't know if they are equal or not. NULL = NULL --> NULL.
    Again, the variables are either null pointer/references or uninitialised variables, leading to the same issues as I mentioned above.
    havokk:
    Hint: Use the phrase "null marker" rather than "null value". It will help reduce misunderstandings. For "missing", use words like "maybe", "perhaps", "possibly", "dunno". P.S. null markers in a RDBMS have nothing to do with null pointers in programming languages.
    It sounds like null markers are equivalent to an amalgamation of null references and uninitialised variables.

    Hmm, you seem to be confusing a C/C++ null pointer with a SQL null. In SQL, "null" is defined to mean "unknown" or "inapplicable". (Some insist that it should not be used to mean "inapplicable", but that's another story.) In C/C++, a null pointer is invalid, and exactly what that means is up to your program. You may interpret it to mean "unknown" -- I often do. Or you may interpret it to mean "invalid" or "Thursday" or whatever else you want it to mean. Or you may interpret it to mean "oops I forgot to set a value and now we're about to blow". Anyway, if you try to think of SQL nulls in terms of C null pointers, you're just going to confuse yourself. They're not the same concept.

  • jay (unregistered) in reply to chris
    chris:
    IIRC it's the ANSI standard: null != null. Its the same in T-SQL (SQL Server) by default. One hell of an annoying convention.

    Just to be pedantic, in SQL "null!=null" is not a true staement. Comparisons in SQL have three possible results: true, false, and file-not-found ... I mean true, false, and null. Null in this case meaning "unknown". So "null=null" gives null, unknown. "null!=null" also gives null.

    Actually this is not entirely pedantic. Consider:

        create table t (x integer);
        insert into t(x) values (null), (42);
        select x from t where x=null;
        select x from t where x!=null;
    

    What is the output? Neither query returns any records.

    If it were true that null!=null, then the second query should return two records, because 42!=null and null!=null. But in fact it returns no records, because null!=null is not true, it is null.

    The technically correct statement would be that "null=null" is not true.

  • jay (unregistered)

    The real catch to code like this is, suppose you came along months later and found:

    if (a>30 && b<10)
    {
      doSomething();
    }
    else if (a<30 && b>=10)
    {
      doSomethingElse();
    }
    

    Now you're left wondering: Does this code INTENTIONALLY do nothing when a==30? Or is that a mistake? If I saw such a statement in a program that did not have the pattern of negating all the IFs, I'd probably assume it was deliberate. But with all the negated IFs ... it's hard to say. You'd have to study the code and figure it out.

  • (cs)

    Doug was probably told "Do not repeat yourself".

    So he repeated the opposite.

    Brilant.

  • Norman Diamond (unregistered) in reply to jay
    jay:
    I can't count how many times I've seen:
    if (collection.size()>0)
    {
      for (int x = 0;x<collection.size(); ++x)
      {
        doSomething(collection.getMember(x));
      }
    }
    </pre>
    

    Or variations thereof. Like the programmer doesn't trust the test on loop counter to work in the case where the loop would execute zero times, but he apparently trusts it to work correctly in all other cases.

    That pattern is common in programs that were translated from [censored] because in [censored] loops did execute at least one time and programs had to have if statements ahead of the loop. As for why that pattern remains common in new programs written in languages that don't need it, that's probably just cargo cult programming. But guess what, oddly enough, it doesn't hurt anything.

    [* censored because I'm watching my language. The F at the beginning of that language doesn't stand for fuck.]

  • Wak (unregistered) in reply to Oh, the humanity!

    Your example is wrong on so many levels, you know. Not really.

    In a single bit variable, there could be more states than zero or one. That is true. No it is not. In a single bit variable (scalar to be exactly) there could be two states - zero and true. Bit is a 2valued type. Right? In a scalar reg variable there can be 4 states: 1'b0, 1'b1, 1'bx and 1'bz.

    Your "initial" happens at sim-time zero. Who is defining the state of 'x'? IEEE Standard 1800-2009 I-6.8

    Also at sim-time zero? Yes.

    You got a race condition on your hand! It is hard to have a race condition with only one process.

    Your variable 'x' is local scope to "top". Maybe there is someone accessing 'x' via 'top.x'. However "top" suggests to be the toplevel of your design/simulation (whatever you are trying to do here). I cannot see any other modules, console forces, pli functions etc.

    What are you passing into $display()? Is this even valid syntax? Yes - IEEE Standard 1800-2009 I.21.2.

    It takes a string, no? It does not have to.

    All 8bit ASCII characters? No. 32-bit numbers.

    Then your 1, 2 or 3 are non-printable values. Right? No.

    I am replying to a troll, ain't I? No, you are not.

  • (cs)

    In C++, a null pointer can be safely compared to a pointer for equality:

    You can assert( NULL == NULL ); and you can assert ( NULL != p ) if p is not NULL.

    (p < NULL) and (NULL < p) are technically "undefined behaviour". They shouldn't crash / core-dump you but it's undefined whether they will return true or false (or file not found..)

  • Ale (unregistered)

    Someone said that the complete name of Doug is "Doug DeMorgan"!

  • (cs) in reply to Mythran
    Mythran:
    William F:
    CAPTCHA: ague - what I get from some of these stories

    How do you pronounce "ague"? "A jew" or "ag you" or "a goo" or "a gua" or ? Different pictures pop into my head depending on how it's pronounced :P

    ay gyoo

  • Gibbon1 (unregistered) in reply to Abico
    Abico:
    Here's how people like Doug happen:

    An engineer teaches himself to program, probably in VB.

    Um... as an engineer that often writes code, um... no. Your 'Doug' programs because he wasn't a solid engineer either. I also notice plenty of 'Dougs' from a CS background as well, inflexible, superstitious, socially inept, keepers of the cargo cult.

  • Oh, the humanity! (unregistered) in reply to Wak
    Wak:
    > In a single bit variable, there could be more states than zero or one. That is true. No it is not. In a single bit variable (scalar to be exactly) there could be two states - zero and true. Bit is a 2valued type. Right? In a scalar reg variable there can be 4 states: 1'b0, 1'b1, 1'bx and 1'bz.

    Great, lets mince words then. We are talking VERILOG here, right? How do you define a single bit variable? You either use 'reg' or 'wire'. And here you have (at least) the 4 states you mention. In VERILOG, is there any other way to declare a single bit variable? Apart from 'reg' or 'wire'?

    Look, in my initial statement, I am not disagreeing with you about the sentiment: "More than 2 states may exist and one might need to test for each of them." All I object to, is your choice of example. I have fallen victim of people deploying non-real-world (accademic) examples as a decoy before. That is why the "biting-reflex" engaged so readily.

    Wak:
    > Your "initial" happens at sim-time zero. Who is defining the state of 'x'? IEEE Standard 1800-2009 I-6.8

    Yes, the initial value of reg 'x' will be indeed 1'bx, as it has no assignment to it.

    I am a bit wary about people who are quick in citing the "STANDARD". Many of them - in my personal experience, YMMV - do not really know what they were talking about.

    I will give you the benefit of the doubt.

    Wak:
    > I am replying to a troll, ain't I? No, you are not.

    OK, fair enough, I apologize for calling you a troll. These days, no one knows who is real and who is faking it!

    I may be replying to a grad-student, a dedicated lecturer from a university or a veteran of many years of digital design - however the last I believe is unlikely. I do not know - the blessings of the internet.

    I have run the code you posted. (I did not even need to use any System-Verilog capable simulator to do that. Why the mention of System-Verilog in the first place? This is just plain VERILOG 101.)

    Well, I'll be damned:

    Veriwell version 2.8.7,
    Copyright (C) 1993-2008 Elliot Mednick and Mark Hummel
    
    Veriwell comes with ABSOLUTELY NO WARRANTY; This is free
    software, and you are welcome to redistribute it under the
    terms of the GNU General Public License as published by
    the Free Software Foundation; either version 2 of the License,
    or (at your option) any later version.
    
    lxt  support compiled in
    lxt2 support compiled in
    
    Entering Phase I...
    Compiling source file : trial0.v
    
    Entering Phase II...
    Entering Phase III...
    No errors in compilation
    Top-level modules:
       top
    
              3
    0 Errors, 0 Warnings, Compile time = 0.0, Load time = 0.0, Simulation time = 0.0
    
    Normal exit
    Thank you for using Veriwell
    

    It outputs '3' and hence took the branch wich is neither true or false. So maybe this example really tells us something?

    And OK, $display also takes an integer as argument. I did not know that. So this I learned - but I certainly won't apply that knowledge in the future. I'd like more meaningfull messages in my simulations, such as:

    $display("state 'x' detected");

    I might have done it this way:

    module top;
    
    reg x;
    
    initial
    begin
    
      #1;
      x = 1'b0;
      #1;
      x = 1'b1;
      #1;
      x = 1'bx;
      #1;
      x = 1'bz;
    
    end
    
      always @(x)
    
        if( x )
    
    	$display("'x' is true (%b at time %t)",x,$time);
    
        else if( !x )
    
    	$display("'x' is false (%b at time %t)",x,$time);
    
        else
    
    	$display("'x' is undefined (%b at time %t)",x,$time);
    
    endmodule
    

    Which has a more verbose output:

    Top-level modules:
       top
    
    'x' is false (0 at time                    1)
    'x' is true (1 at time                    2)
    'x' is undefined (x at time                    3)
    'x' is undefined (z at time                    4)
    0 Errors, 0 Warnings, Compile time = 0.0, Load time = 0.0, Simulation time = 0.0
    

    But then try to explain the finer points of HDL to the audience. So maybe your post had a point after all.

  • wt (unregistered) in reply to iusto
    iusto:
    foo:
    Reminds me of another "experienced" developer, who'd always use the mouse to select items and then do copy&paste through the context menu. Another one of those valued developers with over a decade of experience ...

    Now you're exaggerating a little. If you had said, a guy scrolls up 2 pages of text to copy a short word so that he can paste it where he was below (to avoid typing it), then I'd understand. I noticed a couple of devs doing that for as little as 4-characters. Not to mention that IDE at the time was Visual Studio, where intellisense is present.

    Actually, I've sen that too at my own eyes, so it is no exaggeration at all. When one very senior developer has explaining some things to me (I was a newbie), he used exactly the same method (copying by mouse through menu). When I saw that, I really wanted to take the keyboard off him and do it by myself (but I didn't, obviously). Needed to say, that he grew up on mainframes, was very good on that and didn't care much about some strange windowed systems :). But I must admit, that the code he wrote was a mess - he basically wrote in C++ like if it was assembler.

  • Neil (unregistered)

    I'm just glad that Doug hadn't heard of ?:

  • MisterFanwank (unregistered) in reply to allo
    allo:
    if(i++ == 1){ doSomething(); }else if(i++ == 1){ doSomethingElse(); }

    ...

    No, dude... Just... No. That's horribly offensive.

Leave a comment on “But...Anything Can Happen!”

Log In or post as a guest

Replying to comment #:

« Return to Article