Comment On But...Anything Can Happen!

Every developer eventually breaks something in production. Whether by negligence, ignorance, or just plain bad luck, it happens even to the best of us. "Oops" moments like these are the ones we learn and grow from. The broken thing gets fixed, some data may or may not get cleaned up, and everybody moves on a bit for the wiser. [expand full text]
« PrevPage 1 | Page 2 | Page 3Next »

Re: But...Anything Can Happen!

2012-11-14 21:36 • by Scarlet Manuka
394910 in reply to 394907
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.

Re: But...Anything Can Happen!

2012-11-14 22:02 • by PiisAWheeL
394911 in reply to 394910
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.

Re: But...Anything Can Happen!

2012-11-14 22:09 • by Gigaplex (unregistered)
394912 in reply to 394903
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.

Re: But...Anything Can Happen!

2012-11-14 22:17 • by Andrew (unregistered)
394913 in reply to 394845
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");
}

Re: But...Anything Can Happen!

2012-11-14 22:40 • by Andrew (unregistered)
394914 in reply to 394913
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.

Re: But...Anything Can Happen!

2012-11-14 22:58 • by Norman Diamond (unregistered)
394915 in reply to 394913
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 {

Re: But...Anything Can Happen!

2012-11-14 23:03 • by Maurits
394916 in reply to 394858
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".

Re: But...Anything Can Happen!

2012-11-15 04:07 • by 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

Re: But...Anything Can Happen!

2012-11-15 04:26 • by Krzysiek (unregistered)
394920 in reply to 394805
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.

Re: But...Anything Can Happen!

2012-11-15 04:50 • by 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.

Re: But...Anything Can Happen!

2012-11-15 05:50 • by renewest
if (a)
{
doSomething();
}

or else
{
youHaventHeardTheLastOfThis();
}

Re: But...Anything Can Happen!

2012-11-15 05:53 • by vlnx (unregistered)
394925 in reply to 394811
yeah, bury that poor fucker alive :-D

Re: But...Anything Can Happen!

2012-11-15 07:10 • by 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'"....

Re: But...Anything Can Happen!

2012-11-15 07:16 • by 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!");
}

Re: But...Anything Can Happen!

2012-11-15 07:18 • by Hegel (unregistered)
394929 in reply to 394928
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!");
}

Re: But...Anything Can Happen!

2012-11-15 08:23 • by foo (unregistered)
394940 in reply to 394907
Norman Diamond:
If a plane crashes on the border between the United States and Canada, where will the survivors be buried?
Gitmo (if Arab).

Re: But...Anything Can Happen!

2012-11-15 08:47 • by Abico (unregistered)
394946 in reply to 394909
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.

Re: But...Anything Can Happen!

2012-11-15 08:50 • by JimLahey
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.

Re: But...Anything Can Happen!

2012-11-15 08:57 • by 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();
}

Re: But...Anything Can Happen!

2012-11-15 09:29 • by 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();
}

Re: But...Anything Can Happen!

2012-11-15 09:46 • by annonomous (unregistered)
Obviously he was just trying to account for the tri-state boolean.

Re: But...Anything Can Happen!

2012-11-15 10:05 • by 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.

Re: But...Anything Can Happen!

2012-11-15 10:41 • by foo2 (unregistered)
394981 in reply to 394909
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?

Re: But...Anything Can Happen!

2012-11-15 11:02 • by Paul Neumann (unregistered)
394989 in reply to 394896
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.

Re: But...Anything Can Happen!

2012-11-15 11:17 • by Maurits
394993 in reply to 394927
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."

Re: But...Anything Can Happen!

2012-11-15 14:16 • by Spider Flyer (unregistered)
395012 in reply to 394950
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.

Re: But...Anything Can Happen!

2012-11-15 14:21 • by jay (unregistered)
395013 in reply to 394993
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));
}
}


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.

Re: But...Anything Can Happen!

2012-11-15 14:24 • by Oh, the humanity! (unregistered)
395014 in reply to 394919
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?

Re: But...Anything Can Happen!

2012-11-15 14:28 • by jay (unregistered)
395015 in reply to 394912
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.

Re: But...Anything Can Happen!

2012-11-15 14:42 • by jay (unregistered)
395017 in reply to 394847
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.

Re: But...Anything Can Happen!

2012-11-15 14:46 • by 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.

Re: But...Anything Can Happen!

2012-11-15 19:54 • by Musaran
Doug was probably told "Do not repeat yourself".

So he repeated the opposite.

Brilant.

Re: But...Anything Can Happen!

2012-11-15 20:17 • by Norman Diamond (unregistered)
395036 in reply to 395013
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));
}
}


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.]

Re: But...Anything Can Happen!

2012-11-16 01:51 • by Wak (unregistered)
395042 in reply to 395014
> 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.

Re: But...Anything Can Happen!

2012-11-16 03:24 • by Cbuttius
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..)



Re: But...Anything Can Happen!

2012-11-16 10:48 • by Ale (unregistered)
Someone said that the complete name of Doug is "Doug DeMorgan"!

Re: But...Anything Can Happen!

2012-11-16 17:38 • by Matt Westwood
395099 in reply to 394858
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

Re: But...Anything Can Happen!

2012-11-16 19:23 • by Gibbon1 (unregistered)
395102 in reply to 394863
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.

Re: But...Anything Can Happen!

2012-11-17 11:19 • by Oh, the humanity! (unregistered)
395107 in reply to 395042
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.

Re: But...Anything Can Happen!

2012-11-20 17:48 • by wt (unregistered)
395307 in reply to 394852
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.

Re: But...Anything Can Happen!

2012-11-21 10:34 • by Neil (unregistered)
I'm just glad that Doug hadn't heard of ?:

Re: But...Anything Can Happen!

2012-11-25 03:20 • by MisterFanwank (unregistered)
395504 in reply to 394844
allo:
if(i++ == 1){
doSomething();
}else if(i++ == 1){
doSomethingElse();
}


...

No, dude... Just... No. That's horribly offensive.
« PrevPage 1 | Page 2 | Page 3Next »

Add Comment