2066-pin processors

I didn't realise how serious this was. I'd better get a DoS-proof gas kettle.

NT

wrote in news:q0fb3u$1p7a$1 @gioia.aioe.org:

They also are now claiming to have a hypersonic missile.

The problem is that the most commonly used language doesn't have any real string support. The only string feature in C is that the compiler sticks an invisible null at the end of a string constant. There is no other string operations at language level, just a badly designed standard library functions (such as strcpy).

Languages using real string support typically use counted strings or sting descriptors. It is much easier to check for overflows or truncations. In some CISC machines string instructions did the truncation as a side effect.

This has historical roots. In most architectures the stack grows downwards. For non-virtual single thread systems, put the initial stack at the top of the RAM and the static data at the bottom of RAM and the dynamic heap above this growing upwards. Thus the RAM can be fully utilized, until top of the stack and top of the heap meets. Hopefully there are some checks so that a stack push doesn't overwrite the top of the heap or that a new heap allocation does't overwritten the current stack.

In stack oriented languages it was handy to put the local data into the same stack inserted between the function return addresses. If local data is overwritten, it can take out the return addresses.

With multithreading, multiple stacks are needed, so that simple allocation strategy can't be used. If virtual memory is available, this is not a big deal.

Since multiple stack allocations are needed anyway, why not allocate two stacks for each thread, one for return addresses only and the other for local variables. This would significantly reduce the risk of return address corruption as a result of local data buffer overflow.

Yes. It is not the goto itself that is fundamentally bad, it is the abuse of it. "goto" is hard to use in a clear, structured manner, and easy to abuse in a spaghetti manner.

The work in the try block is /not/ lost. C++ exceptions are exceptions, they are not transactions (such as in SQL). Only work stored as local variables is lost.

I agree that it is easy to get things wrong here. But if you have written the flag appropriately, and use a good compiler with optimisation, then the result can be as efficient as a goto statement.

There are many other alternatives, such as:

1. Don't write such complex, heavily nested code in a single function in the first place. Break things up in functions - or perhaps operators, for C++. The result will be code that is clearer and simpler, and can often be optimised better - assuming, as always, that you have a decent compiler.

1. Use "return" to break out of the nested loops. Some people see that as being as bad as gotos (some people just can't be pleased).

2. Continue the computation regardless. For something like matrix calculations on a modern cpu, this is the best choice - it lets you use SIMD and vector processing, or even GPU code, whereas the non-loop control flow of an early exit would break the loop pattern and prevent vectorisation. It can also be the simplest pattern to write and work with, and the simplest pattern to prove correct. Who cares if code with an exceptional and unusual circumstance (such as a divide by zero error) takes slightly longer to perform, if the normal case is a good deal faster?

I am not saying that "goto" is never the best choice, but it is the best choice only very rarely. Often a little more thought can give something better.

snipped-for-privacy@decadence.org wrote in news:q0fgfc$fp7$1 @gioia.aioe.org:

Yes, but you won't find any of those around much these days. The manufacturers have wrecked that rugged reliability of the diesel vehicle and festooned it with highly vulnerable complex electronics. Great idea! :(

--
This message may be freely reproduced without limit or charge only via  
the Usenet protocol. Reproduction in whole or part through other  
protocols, whether for profit or not, is conditional upon a charge of  
GBP10.00 per reproduction. Publication in this manner via non-Usenet  
protocols constitutes acceptance of this condition.

Most commonly used languages /do/ have real string support. C is unusual in not having it.

There are a variety of ways of implementing strings, and different languages do it in different ways. C does not provide much string support, so you need to handle things manually. This is not that difficult to do correctly and safely - unfortunately, it is also not difficult to get it wrong.

Yes.

Yes.

On some architectures, this is practical. (And it is used in FORTH programming). But on many cpus, it would mean another register needed for the second stack, when registers are often a scant resource.

It is an arrangement with some advantages and disadvantages. I have worked with C compilers that had such split stacks. It adds complexity and doubles the fragmentation of your stacks. If it is just to reduce the risk of overwriting the return address on the stack, then it is not worth the effort - after all, the buffer overflow is still broken code and needs fixed anyway. If it is combined with other architectural features, such as using the return stack for code flow prediction or pre-fetching instructions, then there is more to gain.

"goto" (or "jmp", or "br", or whatever) assembly instructions are often used to implement loops, function calls, and all sorts of other control structures in high level languages. But that completely misses the point. We are not talking about implementation in assembly.

That should be impossible.

Right. Fixed and variable-length strings should be properly managed as distinct native types.

There should be a return address stack, in hardware-enforced stack space, and buffers and data should be in a separate, enforced r/w data space. c tends to mix all that up.

Stack overflow should be a fatal trap. As should be writes to code space, data writes to stack space, executing in stack or data space, or any such illogical event.

--

John Larkin         Highland Technology, Inc 

lunatic fringe electronics

Don't forget chocolate and sugar. Before those foreign stimulants came along, most people napped all day and slept all night.

(declared after two cups of strong Peets)

--

John Larkin         Highland Technology, Inc 

lunatic fringe electronics

On a sunny day (Tue, 1 Jan 2019 16:00:29 -0000 (UTC)) it happened Cursitor Doom wrote in :

I think Joerg still has one ?

You snipped the rest, with the C example, without goto. And all 'higher' level languages eventually are compiled to jumps and similar.

It seems, in a way, those languages (not so much C but a lot of the rest) are to 'protect' the clueless programmer from actually writing efficient code. C++, a crime against humanity, a perfect example.

Not so long ago I needed a driver for some chip, arduino had one, written in C++, 2 pages full IIRC. I rewrote it in C in something like 10 lines.

It is a trend, and for sure, as I have mentioned before, one day the CEO will get the 'I want' app on his desk. Then all he has to do is say: 'I want ' and it will be done. A bit like that current US president, and the world will jump. NO MATTER HOW IDIOTIC THE IDEA IS.

The education level of that CEO will not need to be any higher than that of the average Ape. And there the human species is, was, and will always be? Well in a democracy capitalist society I think. Selling bloat makes money?

Or does it? deficit? No exports of value?

When I wrote that CP/M clone, the assembler I used did not even have label names, just label numbers... WHAT is the problem?

One of the very few books I have, eeeh the only one programming related, is

Oh and K&R as pdf

See, Turing, if you need to find your way on a chart, give directions, go left, second right, then left, jump over fence, destination, and translate that to: while running in circles and you are not exhausted yet and your shoes are still OK then if you just started, go left if no left in sight then exit your running around and complain, but after a successful left... etc etc DOES THAT MAKE THING EASIER FOR ANYONE?

The 'but if' statement is a very interesting one. I mean you can make it as complicated as you want, use operator overloading on it now it is good for pedestrians, cars, tanks, and planes... oops here comes the problem, those have different capabilities.

YOU STILL NEED BRAIN AND A PLAN no matter what 'language' you program it, and that takes me to an other point that seems to be overlooked all the time, FOR PROGRAMMING YOU NEED TO KNOW AT LEAST 2 THINGS, LIKELY MORE

1) you need to be fluent in at least one programming language, 2) You need to know in depth about the stuff you program for,.

It is the same with English, maybe you can write that does not mean you can write a novel, or financial software, or software to control an airplane.

It is an eternal study adventure, electronics is just one field. The CEO with the 'I want' app, well you see people running a food firm being put in charge of tech companies etc now they speak into that app.

Well, and to some other poster, maybe you need to read up on libc.info for various string operations. If you run Linux it is on your system. Will take you a few weeks at least so prepare.

It would be a bit embarrassing if it was used. US fleet loses its way all by itself, and then there is that ego thing, listen to this sound track:

Sure, the data aren't restored to their previous state, but in the sort of case I was discussing, the work done is now useless.

But nowhere near as easy to maintain, nor as obvious. Obvious is good, boring is good.

The code isn't necessarily complex--it could be a QR decomposition or something like that.

That works too, as long as returning is the right answer. You might need to do some cleanup first.

Vectorizing division by zero doesn't help. ;) But I agree that it may be better to keep going sometimes. My electromagnetic simulator code does that, and cleans up NaNs afterwards.

I agree it's a rarely-used construct--I've probably used it a handful of times since I graduated from MS Basic for DOS 3.1. But it isn't radioactive.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
ElectroOptical Innovations LLC / Hobbs ElectroOptics 
Optics, Electro-optics, Photonics, Analog Electronics 
Briarcliff Manor NY 10510 

http://electrooptical.net 
https://hobbs-eo.com

On Jan 1, 2019, snipped-for-privacy@nospam.org wrote (in article ):

I know something of military systems, and I find this story very hard to believe.

And note that the sources are Russian. If the Russians really had such a

needed.

During the Cold War, HEMP from nuclear explosions was a big worry, and all critical US DoD systems and platforms had to be hardened against HEMP. Here is an EMP weapon, but nuclear weapons are bigger:

.

. An EMP pulse powerful enough to cripple a steel ship (despite HEMP shielding) would have also crippled the airplane. One cannot really point such weapons, and the airplane is far closer to the source than the ship.

.

Really? To believe this, one must also believe that an entire multi-ship Carrier Task Group completely lacks competent navigators, paper maps, GPS receivers, sextants, eyeballs, and so on. Thousands of people who do this for a living, and would like to continue to do so, and not one person noticed the problem.

When I first heard this story, it was an unspecified US Coast Guard lighthouse and some random freighter. Even then, I wondered why the lighthouse omitted a critical fact, that it was a dry-land lighthouse, and not just another ship, holding this detail till last.

This has been around forever:

. Joe Gwinn

Mebe. But the stricter emissions tests these days are making them increasingly rare.

-- This message may be freely reproduced without limit or charge only via the Usenet protocol. Reproduction in whole or part through other protocols, whether for profit or not, is conditional upon a charge of GBP10.00 per reproduction. Publication in this manner via non-Usenet protocols constitutes acceptance of this condition.

Is there a step-through de-bugger for Linux? I like the speed of gcc and whatnot, but it's no frills and very bare bones.

--
This message may be freely reproduced without limit or charge only via  
the Usenet protocol. Reproduction in whole or part through other  
protocols, whether for profit or not, is conditional upon a charge of  
GBP10.00 per reproduction. Publication in this manner via non-Usenet  
protocols constitutes acceptance of this condition.

It is possible if there are bugs in the code that allow it. Many programming languages have better control of access to buffers than C does - in those languages, buffer overflows are typically impossible.

Why "native" types? You can handle them perfectly well in user-created or library types in C++.

If you use a language that supports this sort of thing natively, it is much easier to write correct code, and much harder to write incorrect code (at least, for this kind of error). Often that is the prime concern - a lot of software that is written in C would have been better written in other languages.

On the other hand, C gives you more flexibility and can be more efficient.

Again, you are wrong. But is there any point in my explaining it /again/, when you have failed to learn anything from my previous attempts?

You don't know much about programming. I don't know so much about analogue electronics. Let's agree that I will stop making repeated incorrect and ignorant remarks about everything that is wrong in the analogue electronics world, and you stop making such incorrect and ignorant remarks about programming. Oh, wait, like most people I /don't/ keep making the same ignorant and incorrect remarks about topics I don't understand. Perhaps there is some hidden lesson here that you could learn from.

gdb is the most common debugger for Linux. It has a text-based interface, which is efficient if you are used to it and know the commands, and easy for automation, but a pain for other uses. There are lots of front-ends, either stand-alone (like ddd, for a blast from the past) or using an IDE such as emacs or eclipse.