Fundamental C question about "if" statements

Op 22-Sep-15 om 8:39 PM schreef John Devereux:
> Wouter van Ooijen <wouter@voti.nl> writes:
>
>>> Oh come on, it is time we stop commenting on wanting to use a DIP
>>> processor. I have not used one since the 6809 days, i.e. since the 80-s.
>>> There is no sensible reason to use one in whatever design.
>>
>> That depends on your purpose. I like the ability to wiggle a fried
>> LPC1114 out of my students boards and insert a fresh one for a few
>> $. And to have them put an LPC810 in a solderless breadboard and
>> connect all the wires themselves.
>>
>> Wouter
>
> Hi Wouter
>
> There are also any number of SMT:DIP adapters that can be used, cost is
> ~$1.
>
> <http://www.ebay.co.uk/sch/i.html?_odkw=dip+adapter+-socket&_osacat=0&_from=R40&_trksid=p2045573.m570.l1313.TR0.TRC0.H0.Xdip+adapter+-socket+-sockets+-sop8.TRS0&_nkw=dip+adapter+-socket+-sockets+-sop8&_sacat=0>

I know, I sell such PCBs myself :)

But the right comparison (at least for my case of students using 
solderless breadboards) is

1) DIP chip

2) SMD chip + PCB + pins strips + solder it together

I still stringly prefer 1), especially due to the last part (soldering 
it together)

Wouter

On 15-09-22 20:40 , Tim Wescott wrote:
> On Tue, 22 Sep 2015 08:53:28 +0200, David Brown wrote:
>
>> On 21/09/15 19:24, Tim Wescott wrote:
>>
>>> But it is a point -- who IS the Egyptian god of computing?
>>>
>>>
>> I don't know that one - but some candidates could be:
>>
>> Am-heh – A dangerous underworld god Apep – A serpent deity who
>> personified malevolent chaos Heka – Personification of magic
>>
>> (I justify including Heka on the list from what customers expect of us.)
>>
>> When I develop my own programming language to be the perfect replacement
>> for C and all it's quirks, I shall call it Apep.
>
> There's a large population of programmers out there who believe it's been
> done -- they call the language "Ada".

I feel called to comment on this, as I'm almost in that group of 
programmers -- the difference is that I would not call it the "perfect" 
replacement, only the "best so far".

> I've never programmed in Ada, but I've debugged it.  We had a multi-
> million dollar contract stall because our box (programmed in C) and the
> prime's box (programmed in Ada) could not talk to each other.

    [snip]

> Two things became apparent to me, in the order that I present them here.
>
> One, these weren't just Ada programmers, they were (as many Ada
> programmers seem to be), devout members of the Ada cult.  Their simple
> rule for localizing bugs in a project that contained Ada code and C code
> was that the bug had to be in the C code -- end of story.  On top of
> that, they had a complete and completely contemptuous ignorance of C

That attitude is of course wrong and deplorable, even if there is much 
statistical support (as sometimes has been discussed in this newsgroup) 
for the opinion that C is more error-prone than Ada, other things being 
equal (which they seldom are).

I wonder if the attitude you encountered, on this occasion, was only 
partly Ada-vs-C, and partly also prime-vs-subcontractor?

    [snip]

> While this all was going on I sort of disengaged and started reading
> their code, line by line.  Now, the problem was that a message was
> getting bit-reversed.  I won't get , and I saw the following lines:
>
> <something or other> this_message[0..31];
> <something or other> that_message[1..31];
> <something or other> trouble_message[31..0]

It is not central to your tale, but the reversed order of the low and 
high bounds in 31..0 would not directly bit-reverse a message. The range 
31..0 is a null range in Ada, so if this code is from a declaration, it 
would declare a null (zero-length) array; if it is from an expression 
that takes a slice of an array, the slice would be a null array (but in 
both cases Ada would use round parentheses "()", not "[]"). Of course, 
if the Ada coder's intent was to write 0..31, to get 32 elements into 
the message, the actual result from 31..0 would be wrong in some other 
way. Or perhaps the whole of the processing was more complex and this 
null array/slice really did lead to bit-reversal for some complicated 
reason.

> So I had to resort to intellectual violence: "hey, I know that I'm just a
> dumb-ass C programmer, and moreover that I'm Oregon born and bred.  So
> could you Really Smart Ada people 'splain this here feature of your ever-
> so-wonderful language to me, in short words?"

This part of your posting illustrates why I often find it difficult to 
discuss Ada-vs-C with programmers who have used only C. Programmers are 
proud of their knowledge and programs; if I suggest to a C user that I 
believe there is a better language than C, they often seem to feel that 
I'm calling them stupid, for having chosen a poorer language. Do you 
have a suggestion for how I could avoid that misunderstanding?

> At which point their chief Ada programmer and High Priestess of Blessed
> Code actually LOOKED at her code, slammed her printout on the table, and
> stomped out of the room.
>
> So, anyway -- Ada, because it's always bug free, and infinitely better
> than C in every possible way.

I'm not sure what you want to express here. Your tale is a cautionary 
one, of hubris and lack of humility among some Ada programmers, but in 
the end it does not say anything new about Ada or C. I don't know any 
Ada user who claims your closing sentence as fact, even if most think 
that Ada is better than C in many ways. The sentence seems like an 
attempt to use obviously false, ironical hyperbole to belittle or 
dismiss the real differences between Ada and C.

I do find your tale both interesting and comical, in a sad way, but not 
all Ada programmers are like that, and even if some are, it does not 
affect the technical comparison between Ada and C.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

On 22/09/15 19:40, Tim Wescott wrote:
> On Tue, 22 Sep 2015 08:53:28 +0200, David Brown wrote:
>
>> On 21/09/15 19:24, Tim Wescott wrote:
>>
>>> But it is a point -- who IS the Egyptian god of computing?
>>>
>>>
>> I don't know that one - but some candidates could be:
>>
>> Am-heh – A dangerous underworld god Apep – A serpent deity who
>> personified malevolent chaos Heka – Personification of magic
>>
>> (I justify including Heka on the list from what customers expect of us.)
>>
>> When I develop my own programming language to be the perfect replacement
>> for C and all it's quirks, I shall call it Apep.
>
> There's a large population of programmers out there who believe it's been
> done -- they call the language "Ada".
>
> I've never programmed in Ada, but I've debugged it.  We had a multi-
> million dollar contract stall because our box (programmed in C) and the
> prime's box (programmed in Ada) could not talk to each other.  We went
> back and forth on it for months, until finally the prime decided that
> they needed to fly half a dozen people all the way across the continent
> to smack us stupid Oregonians until we saw the light and fixed our bug.
>
> I ended up getting sucked into it at the last minute (in retrospect I
> think it was because the project manager on our side knew that, when
> handled right, I can act like a demented terrier who's just coming down
> with second stage rabies -- and mange).  So there I am, in a meeting room
> with half a dozen software engineers from two companies, plus half a
> dozen sales and project management types to lend weight and credence to
> the whole "this is serious business" air of the thing.
>
> Two things became apparent to me, in the order that I present them here.
>
> One, these weren't just Ada programmers, they were (as many Ada
> programmers seem to be), devout members of the Ada cult.  Their simple
> rule for localizing bugs in a project that contained Ada code and C code
> was that the bug had to be in the C code -- end of story.  On top of
> that, they had a complete and completely contemptuous ignorance of C --
> trying to actually show them code was roughly equivalent to a devout
> pagan trying to explain what Aphrodite was really about to Jimmy Swaggart
> in his pre-caught days.
>
> Two, the bug had to be in the Ada code.  It came about because things had
> devolved into a very genteel argument, with the Disciples of Ada
> adamantly insisting that all problems are C problems, with their
> management team backing them up and making veiled threats to our
> management team, and our management team fighting a courageous rearguard
> action.
>
> While this all was going on I sort of disengaged and started reading
> their code, line by line.  Now, the problem was that a message was
> getting bit-reversed.  I won't get , and I saw the following lines:
>
> <something or other> this_message[0..31];
> <something or other> that_message[1..31];
> <something or other> trouble_message[31..0]
>
> So right in the middle of the discussion, which had been growing ever
> more heated in an ever more quiet and genteel way, I blurted "Hey!  I
> think I found it!"
>
> You may imagine the sorts of looks I got.
>
> I explained the whole 0..31 vs. 31..0 business, and the Ada people _would
> not listen_ -- because Ada code is automatically bug-free, right?
> Particularly when you've cot C code in the vicinity acting like fresh,
> extra-sticky fly paper.
>
> I tried explaining again -- have you ever tried to hold an intelligent
> conversation with a rock?  A pissed-off rock?  I got nowhere.
>
> So I had to resort to intellectual violence: "hey, I know that I'm just a
> dumb-ass C programmer, and moreover that I'm Oregon born and bred.  So
> could you Really Smart Ada people 'splain this here feature of your ever-
> so-wonderful language to me, in short words?"
>
> Then I went over it "so this line says zero to thirty-one.  And THIS line
> says 1 to thirty one."  Then, resisting the urge to drool a bit "and THIS
> HERE line says thirty one to 0 and DAMN but stupid little old me just
> can't unnerstand what it all MEANS!"
>
> At which point their chief Ada programmer and High Priestess of Blessed
> Code actually LOOKED at her code, slammed her printout on the table, and
> stomped out of the room.
>
> So, anyway -- Ada, because it's always bug free, and infinitely better
> than C in every possible way.
>

/My/ language won't allow bugs like that - that would be a compile-time 
error!

The lesson from your story is, of course, that one can write bugs in any 
language.  Ada has features that can help write correct code, and it 
reduces the risk of some errors that are not uncommon in C - but a good 
Ada programmer and a good C programmer, sticking to a good coding 
standard, will produce similar quality code.  (C++ has many features 
that can help write good code, and many features that can help write 
appallingly bad code - but when you know what features to use, it can 
give solid results.)

There is one good, clear justification for claiming that Ada leads to 
fewer bugs and higher quality code - there are no amateur Ada 
programmers.  People learn and use Ada because they care about code 
quality and correctness.  Sure, there can be corporate cultural or 
personal reasons for not doing a good job of it, but you can be 
confident that they will at least understand the importance of quality 
coding.  In the C world, there are countless people (coders and 
managers) who just do not see the point of quality - they are happy with 
something that seems to work okay during a quick test.  So there is 
nothing wrong with good C (or C++) development - it's the low-end that 
brings down the average.

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:d6drdhFre9lU1@mid.individual.net...

...

> I do find your tale both interesting and comical, in a sad way, but 
> not all Ada programmers are like that, and even if some are, it does 
> not affect the technical comparison between Ada and C.

The tale sounded to me a combination of a perception by the 'Ada people' 
of C as unsafe (one that the Ada programmers and management bods could 
easily have picked up, given the press C sometimes gets) with positions 
and tempers having become entrenched and, as was pointed out, no one 
looking at the detail of the code.

It seems quite odd that there was no mention of a dump of the data as it 
flowed between the two domains, given that they knew that bits were 
being reversed.

But then again I have worked at places where someone gets an idea of 
what's wrong and goes rushing off to fix it only to find out later that 
that was not the problem at all. Once people get an idea in their heads, 
IMO even engineers don't always look at the details to try to prove 
their theories.

For example, a network which was reported to be running slowly had a 
switch or bridge installed to break up the traffic but it didn't help. 
Yet just 15 minutes of looking showed that the network was being flooded 
with broadcast storms; the switch/bridge made no difference whatsoever.

In another case a server admin set up a server but then got told that 
users could not write to their home directories. He apparently fixed it 
quickly but when we came to look at it some time later it turned out 
that he had given everyone read/write access to every directory so what 
should have been private, er, wasn't. :-(

James

On Tue, 22 Sep 2015 23:18:57 +0300, Niklas Holsti wrote:

> On 15-09-22 20:40 , Tim Wescott wrote:
>> On Tue, 22 Sep 2015 08:53:28 +0200, David Brown wrote:
>>
>>> On 21/09/15 19:24, Tim Wescott wrote:
>>>
>>>> But it is a point -- who IS the Egyptian god of computing?
>>>>
>>>>
>>> I don't know that one - but some candidates could be:
>>>
>>> Am-heh – A dangerous underworld god Apep – A serpent deity who
>>> personified malevolent chaos Heka – Personification of magic
>>>
>>> (I justify including Heka on the list from what customers expect of
>>> us.)
>>>
>>> When I develop my own programming language to be the perfect
>>> replacement for C and all it's quirks, I shall call it Apep.
>>
>> There's a large population of programmers out there who believe it's
>> been done -- they call the language "Ada".
> 
> I feel called to comment on this, as I'm almost in that group of
> programmers -- the difference is that I would not call it the "perfect"
> replacement, only the "best so far".
> 
>> I've never programmed in Ada, but I've debugged it.  We had a multi-
>> million dollar contract stall because our box (programmed in C) and the
>> prime's box (programmed in Ada) could not talk to each other.
> 
>     [snip]
> 
>> Two things became apparent to me, in the order that I present them
>> here.
>>
>> One, these weren't just Ada programmers, they were (as many Ada
>> programmers seem to be), devout members of the Ada cult.  Their simple
>> rule for localizing bugs in a project that contained Ada code and C
>> code was that the bug had to be in the C code -- end of story.  On top
>> of that, they had a complete and completely contemptuous ignorance of C
> 
> That attitude is of course wrong and deplorable, even if there is much
> statistical support (as sometimes has been discussed in this newsgroup)
> for the opinion that C is more error-prone than Ada, other things being
> equal (which they seldom are).
> 
> I wonder if the attitude you encountered, on this occasion, was only
> partly Ada-vs-C, and partly also prime-vs-subcontractor?
> 
>     [snip]
> 
>> While this all was going on I sort of disengaged and started reading
>> their code, line by line.  Now, the problem was that a message was
>> getting bit-reversed.  I won't get , and I saw the following lines:
>>
>> <something or other> this_message[0..31];
>> <something or other> that_message[1..31];
>> <something or other> trouble_message[31..0]
> 
> It is not central to your tale, but the reversed order of the low and
> high bounds in 31..0 would not directly bit-reverse a message. The range
> 31..0 is a null range in Ada, so if this code is from a declaration, it
> would declare a null (zero-length) array; if it is from an expression
> that takes a slice of an array, the slice would be a null array (but in
> both cases Ada would use round parentheses "()", not "[]"). Of course,
> if the Ada coder's intent was to write 0..31, to get 32 elements into
> the message, the actual result from 31..0 would be wrong in some other
> way. Or perhaps the whole of the processing was more complex and this
> null array/slice really did lead to bit-reversal for some complicated
> reason.

It was somehow defining a bitfield, or an order of bits in a word.

>> So I had to resort to intellectual violence: "hey, I know that I'm just
>> a dumb-ass C programmer, and moreover that I'm Oregon born and bred. 
>> So could you Really Smart Ada people 'splain this here feature of your
>> ever-
>> so-wonderful language to me, in short words?"
> 
> This part of your posting illustrates why I often find it difficult to
> discuss Ada-vs-C with programmers who have used only C. Programmers are
> proud of their knowledge and programs; if I suggest to a C user that I
> believe there is a better language than C, they often seem to feel that
> I'm calling them stupid, for having chosen a poorer language. Do you
> have a suggestion for how I could avoid that misunderstanding?
> 
>> At which point their chief Ada programmer and High Priestess of Blessed
>> Code actually LOOKED at her code, slammed her printout on the table,
>> and stomped out of the room.
>>
>> So, anyway -- Ada, because it's always bug free, and infinitely better
>> than C in every possible way.
> 
> I'm not sure what you want to express here. Your tale is a cautionary
> one, of hubris and lack of humility among some Ada programmers, but in
> the end it does not say anything new about Ada or C. I don't know any
> Ada user who claims your closing sentence as fact, even if most think
> that Ada is better than C in many ways. The sentence seems like an
> attempt to use obviously false, ironical hyperbole to belittle or
> dismiss the real differences between Ada and C.
> 
> I do find your tale both interesting and comical, in a sad way, but not
> all Ada programmers are like that, and even if some are, it does not
> affect the technical comparison between Ada and C.

They made some very disparaging comments about C that made their attitude 
quite clear.  Some of it may have been prime vs. sub, but there was a lot 
of Ada-centric arrogance in the room.

Latterly, on USENET, I have run into, and even drawn, quite a few 
comments along the lines of "well, if you'd programmed that in Ada you 
wouldn't have that bug" -- which might be true: maybe you wouldn't have 
any bugs, or maybe you'd have other bugs, instead.

I suspect that the most vocal proponents of Ada as being not just 
technically better, but the be-all, end-all are not representative of the 
entire Ada community -- but they certainly seem to be the loudest, and 
hence, like right-wing "Christian" nuts vs. quiet and devout church-
goers, end up representing the entire community in the eyes of the public.

When Ada came out it was touted as being almost magically self-correcting 
and naturally platform independent.  It was the platform independence, in 
fact, which was a large part of the reason that the DoD started insisting 
on it.  Then, about a decade later, it came out that nearly all of the 
installed Ada code base was, in fact, highly dependent on the hardware 
for which it was written, and that -- astonishingly enough -- at times it 
seemed that the software designers had gone out of their way to make the 
code that they were writing only work on the hardware that their company 
was selling.

It was a prime example of my argument with the more simple-minded members 
of the "Ada is better" camp -- Ada may make it marginally _easier_ to 
write better code.  However, if you want good, robust, portable code you 
have to make it happen.  There is no magic language that'll make it 
happen -- only language-independent diligence and hard work.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

On Tue, 22 Sep 2015 23:01:14 +0200, David Brown wrote:

> On 22/09/15 19:40, Tim Wescott wrote:
>> On Tue, 22 Sep 2015 08:53:28 +0200, David Brown wrote:
>>
>>> On 21/09/15 19:24, Tim Wescott wrote:
>>>
>>>> But it is a point -- who IS the Egyptian god of computing?
>>>>
>>>>
>>> I don't know that one - but some candidates could be:
>>>
>>> Am-heh – A dangerous underworld god Apep – A serpent deity who
>>> personified malevolent chaos Heka – Personification of magic
>>>
>>> (I justify including Heka on the list from what customers expect of
>>> us.)
>>>
>>> When I develop my own programming language to be the perfect
>>> replacement for C and all it's quirks, I shall call it Apep.
>>
>> There's a large population of programmers out there who believe it's
>> been done -- they call the language "Ada".
>>
>> I've never programmed in Ada, but I've debugged it.  We had a multi-
>> million dollar contract stall because our box (programmed in C) and the
>> prime's box (programmed in Ada) could not talk to each other.  We went
>> back and forth on it for months, until finally the prime decided that
>> they needed to fly half a dozen people all the way across the continent
>> to smack us stupid Oregonians until we saw the light and fixed our bug.
>>
>> I ended up getting sucked into it at the last minute (in retrospect I
>> think it was because the project manager on our side knew that, when
>> handled right, I can act like a demented terrier who's just coming down
>> with second stage rabies -- and mange).  So there I am, in a meeting
>> room with half a dozen software engineers from two companies, plus half
>> a dozen sales and project management types to lend weight and credence
>> to the whole "this is serious business" air of the thing.
>>
>> Two things became apparent to me, in the order that I present them
>> here.
>>
>> One, these weren't just Ada programmers, they were (as many Ada
>> programmers seem to be), devout members of the Ada cult.  Their simple
>> rule for localizing bugs in a project that contained Ada code and C
>> code was that the bug had to be in the C code -- end of story.  On top
>> of that, they had a complete and completely contemptuous ignorance of C
>> -- trying to actually show them code was roughly equivalent to a devout
>> pagan trying to explain what Aphrodite was really about to Jimmy
>> Swaggart in his pre-caught days.
>>
>> Two, the bug had to be in the Ada code.  It came about because things
>> had devolved into a very genteel argument, with the Disciples of Ada
>> adamantly insisting that all problems are C problems, with their
>> management team backing them up and making veiled threats to our
>> management team, and our management team fighting a courageous
>> rearguard action.
>>
>> While this all was going on I sort of disengaged and started reading
>> their code, line by line.  Now, the problem was that a message was
>> getting bit-reversed.  I won't get , and I saw the following lines:
>>
>> <something or other> this_message[0..31];
>> <something or other> that_message[1..31];
>> <something or other> trouble_message[31..0]
>>
>> So right in the middle of the discussion, which had been growing ever
>> more heated in an ever more quiet and genteel way, I blurted "Hey!  I
>> think I found it!"
>>
>> You may imagine the sorts of looks I got.
>>
>> I explained the whole 0..31 vs. 31..0 business, and the Ada people
>> _would not listen_ -- because Ada code is automatically bug-free,
>> right? Particularly when you've cot C code in the vicinity acting like
>> fresh, extra-sticky fly paper.
>>
>> I tried explaining again -- have you ever tried to hold an intelligent
>> conversation with a rock?  A pissed-off rock?  I got nowhere.
>>
>> So I had to resort to intellectual violence: "hey, I know that I'm just
>> a dumb-ass C programmer, and moreover that I'm Oregon born and bred. 
>> So could you Really Smart Ada people 'splain this here feature of your
>> ever-
>> so-wonderful language to me, in short words?"
>>
>> Then I went over it "so this line says zero to thirty-one.  And THIS
>> line says 1 to thirty one."  Then, resisting the urge to drool a bit
>> "and THIS HERE line says thirty one to 0 and DAMN but stupid little old
>> me just can't unnerstand what it all MEANS!"
>>
>> At which point their chief Ada programmer and High Priestess of Blessed
>> Code actually LOOKED at her code, slammed her printout on the table,
>> and stomped out of the room.
>>
>> So, anyway -- Ada, because it's always bug free, and infinitely better
>> than C in every possible way.
>>
>>
> /My/ language won't allow bugs like that - that would be a compile-time
> error!
> 
> The lesson from your story is, of course, that one can write bugs in any
> language.  Ada has features that can help write correct code, and it
> reduces the risk of some errors that are not uncommon in C - but a good
> Ada programmer and a good C programmer, sticking to a good coding
> standard, will produce similar quality code.  (C++ has many features
> that can help write good code, and many features that can help write
> appallingly bad code - but when you know what features to use, it can
> give solid results.)

My favorite quote about C vs. C++ is that C gives you lots of rope.  C++ 
gives you lots of rope, and, in a few places in the STL, some pre-tied 
nooses.

> There is one good, clear justification for claiming that Ada leads to
> fewer bugs and higher quality code - there are no amateur Ada
> programmers.  People learn and use Ada because they care about code
> quality and correctness.  Sure, there can be corporate cultural or
> personal reasons for not doing a good job of it, but you can be
> confident that they will at least understand the importance of quality
> coding.  In the C world, there are countless people (coders and
> managers) who just do not see the point of quality - they are happy with
> something that seems to work okay during a quick test.  So there is
> nothing wrong with good C (or C++) development - it's the low-end that
> brings down the average.

I think you're largely right.  I see very few newbie/hobbyist types 
seeking to learn how to program PICs using Ada, but lots that just want 
to learn how to code in C.

I wonder if there's a way to test good responsible C or C++ code quality 
vs. Ada code quality.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Tim Wescott wrote:
> On Tue, 22 Sep 2015 08:53:28 +0200, David Brown wrote:
<snip>
>
> While this all was going on I sort of disengaged and started reading
> their code, line by line.  Now, the problem was that a message was
> getting bit-reversed.  I won't get , and I saw the following lines:
>
> <something or other> this_message[0..31];
> <something or other> that_message[1..31];
> <something or other> trouble_message[31..0]
>


So how on Earth was there no objective mechanism for showing where the 
message was being reversed? Like Wireshark or an HP
BERT or just an oscilloscope? Logic analyzer? Packet dumper?

POR QUE?!?

<snip>
>
> Then I went over it "so this line says zero to thirty-one.  And THIS line
> says 1 to thirty one."  Then, resisting the urge to drool a bit "and THIS
> HERE line says thirty one to 0 and DAMN but stupid little old me just
> can't unnerstand what it all MEANS!"
>

Ah, the Festus Hagin gambit. Always works. LBJ made quite
the career out of it...

> At which point their chief Ada programmer and High Priestess of Blessed
> Code actually LOOKED at her code, slammed her printout on the table, and
> stomped out of the room.
>

Wow. I have never encountered any programmer who refused
to believe they had a bug. Ever. This is called Epistemic Closure,
and it's not a trait we like to find in engineers.

> So, anyway -- Ada, because it's always bug free, and infinitely better
> than C in every possible way.
>

Of course.

-- 
Les Cargill

On Tue, 22 Sep 2015 18:40:44 -0500, Les Cargill wrote:

> Tim Wescott wrote:
>> On Tue, 22 Sep 2015 08:53:28 +0200, David Brown wrote:
> <snip>
>>
>> While this all was going on I sort of disengaged and started reading
>> their code, line by line.  Now, the problem was that a message was
>> getting bit-reversed.  I won't get , and I saw the following lines:
>>
>> <something or other> this_message[0..31];
>> <something or other> that_message[1..31];
>> <something or other> trouble_message[31..0]
>>
>>
> 
> So how on Earth was there no objective mechanism for showing where the
> message was being reversed? Like Wireshark or an HP BERT or just an
> oscilloscope? Logic analyzer? Packet dumper?
> 
> POR QUE?!?

It was for a MIL-STD-1553 bus, for which bus analyzers are hard to get.  
There may have been one used, to what effect I don't know -- that was 
before I was pulled into the project so that I could bark and snarl at 
prime contractors.

If I remember correctly we did have a card in a computer, which had code 
that emulated the prime's end of things -- but it was written in C, so of 
course it was suspect too.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Tim Wescott wrote:
> On Tue, 22 Sep 2015 18:40:44 -0500, Les Cargill wrote:
>
>> Tim Wescott wrote:
>>> On Tue, 22 Sep 2015 08:53:28 +0200, David Brown wrote:
>> <snip>
>>>
>>> While this all was going on I sort of disengaged and started reading
>>> their code, line by line.  Now, the problem was that a message was
>>> getting bit-reversed.  I won't get , and I saw the following lines:
>>>
>>> <something or other> this_message[0..31];
>>> <something or other> that_message[1..31];
>>> <something or other> trouble_message[31..0]
>>>
>>>
>>
>> So how on Earth was there no objective mechanism for showing where the
>> message was being reversed? Like Wireshark or an HP BERT or just an
>> oscilloscope? Logic analyzer? Packet dumper?
>>
>> POR QUE?!?
>
> It was for a MIL-STD-1553 bus, for which bus analyzers are hard to get.

Oh. I get really impatient with cruft like that now.

<reads> It's Manchester biphase, so nothing too fancy really. And
somewhere on a circuit board, it's gonna be CMOS or TTL
levels...

of course, the test setup is on the test budget, so it's
not like you can just... I dunno, test your code. And
God forbid you tack some bluewires onnit...

> There may have been one used, to what effect I don't know -- that was
> before I was pulled into the project so that I could bark and snarl at
> prime contractors.
>

Indeed. But ... so many airline tickets, hotel bills...

Oy.


> If I remember correctly we did have a card in a computer, which had code
> that emulated the prime's end of things -- but it was written in C, so of
> course it was suspect too.
>

Of course. *ALL* code is suspect. All hardware, too.

-- 
Les Cargill

Tim Wescott wrote:

> I wonder if there's a way to test good responsible C or C++ code
> quality vs. Ada code quality.

There was published a paper on the subject 20 years ago (not the
freshest data):

   http://archive.adaic.com/intro/ada-vs-c/cada_art.pdf


How engineering students fare with the two languages does not map
directly to real-world projects, but the difference is quite extreme:

   http://static1.1.sqspcdn.com/static/f/702523/9458053/1290008042427/200008-McCormick.pdf

Greetings,

Jacob
-- 
"Any, sufficiently complicated, experiment is indistinguishable from magic."