It's a popular misconception that Dijkstra damned goto. But no one who parrots that line has actually read his paper...
Harmful on the whole, perhaps, but there are some very good places to use it. And those are the cases where real programmers use them.
I'd be very curious actually, how you propose to avoid gotos in assembler. That sounds almost as horrible as MOV-only!
Tim
-- Seven Transistor Labs, LLC Electrical Engineering Consultation and Design Website: https://www.seventransistorlabs.com/
The Chinese script is not syllable writing,
The Mandarin lanuage has every word a single syllable, but there are
300 to 1500 odd different syllables (depending on how you count), but 10 times more words, plenty of scope for word play.-- When I tried casting out nines I made a hash of it.
Some computers allow a MOV into the PC, but most still have branch, conditional branch, jump, and jump subroutine.
PDP11 had the "land mine" instruction
MOV -(PC), -(PC)
PC was also R7, just another register.
-- John Larkin Highland Technology, Inc lunatic fringe electronics
rdware what the Chinese syllable-writing system is to a proper phoneme-base d alphabet, but the Chinese are still using their hard-to-remember syllable symbols. "C" seems to be more nearly adequate as a computer language. "Lin ux" is more a social movement than anything else, but some social movements do last, particularly when they perform a service that people need.
Perhaps not, but it certainly isn't alphabetic.
times
Tone languages do offer extra routes to disambiguation, but English isn't h omophone free either. We cope.
-- Bill Sloman, Sydney
You just need a good macro assembler and a suitable macro set. From the DECUS 1977 tape
Abstract: MACRO-11/SP is a set of MACRO-11 macros which provides a concise, comprehensive set of control structures for assembler programs. The facilities provided are IF...ELSE..FI, LOOP..REPEAT, CASE...CASEND, PROC...END and CALL.
I assume this refers to the same macro set that at the times was known as Macro-11 Plus.
I wrote several programs with this macro-set and very rarely needed some explicit branch instructions (GOTOs). The only problem was that the macros were so complex that it took a long time to compile.
Later on, I also wrote a similar macro set for the VAX.
Macros, sure, but what does it expand to?
Some assemblers don't even let you indent arbitrarily, they expect one or two tabs at a newline.
Well, such is software, some things are more horrible than others.
Tim
-- Seven Transistor Labs, LLC Electrical Engineering Consultation and Design Website: https://www.seventransistorlabs.com/
It is interesting to note that someone freaks out like this. even if It has been decades since the worst coding wars.
After all, the structured language constructs are just syntactic sugar
Some languages have better syntactic sugar than others. Some languages have the ability to name loops and then it is possible to exit from a deeply nested loop to some outer level.
Some languages from the 1970's had a mechanism to put named error handlers at the end of the function and then 'escape' to the error handler, without using that "horrible" GOTO keyword. This construct allowed to keep the main program logic clean, without spreading error handling within the main program logic.
From those days, I do not know of any languages that would have had a true exception handler. However, the VAX/VMS had from the beginning (1975) a system level exception handler mechanism. For instance after a divide by zero, the exception handler could set a desired result (say MAXINT/(MININT) and continue execution from the next instruction or unwind the stack to some outer level procedure exception handler or if no outer level exception handler had been defined terminate the program by unwinding the stack to the OS.
Regarding "spaghetti code" it is easily created, if there are no suitable loop constructs to replace backward GOTOs. Even Fortran IV had the DO-loop, so this was a handy way of handling backward jumps. IMHO using GOTOs for only forward jumps helps readability a lot.
Dijstra was all about making the solution follow the problem statement. Problems do not have goto's, in general.
If you decompose problem structure, you get iteration, selection, condition, etc; easily represented by structured code blocks.
Or later, by functional derivations of output from input, without a procedural approach at all.
Clifford Heath.
Such a macro set is just defining a new, usually less well defined/tested, high-level language.
Not totally. Someone could clandestinely install a communication device, or clone modify & swap the SSD/HDD etc. In espionage situations there can be motivation to do that. Or on a more common level, a disgruntled employee or bored kid.
NT
That would, perhaps, be a "process". But it is not a sensible process.
You start with a design with no /known/ vulnerabilities that you can practically and economically avoid. You include an understanding of the ones that you know still exist, but cannot reasonably block. You include appropriate ways to handle the situation when new vulnerabilities occur (such as having a way to update the software, or warn users, or help users inform you about problems).
And your process from there involves identifying and reacting to security problems (and any other problems) as they are discovered.
I expect we will be using them for a good while yet. Why?
OK, explain how a buffer overflow exploit works.
-- John Larkin Highland Technology, Inc lunatic fringe electronics
You trick the software into writing beyond the end of a buffer, thus overwriting data in a way the program is not expecting, and using this to influence the running of the code.
If the buffer is on the stack, this can include writing over the function return address pushed on the stack - thus letting you jump to code at the address you specify.
It does not need the code segments to be writeable - indeed, that would typically be irrelevant since the buffer you are overflowing is not in the code segment to start with.
It does not need the data segments to be executable, but sometimes that could be helpful to the attacker (by putting executable code into the buffer before then changing the function return address to point to the new code).
Most often it is just a denial of service attack - you mess up the running of the program. That is particularly the case when you have, as most modern OS'es do, address space randomisation. You can rarely get the program to jump to somewhere useful to the attacker, but you can usually provoke a crash or fault.
Buffer overflows occur through simple bugs in the code, and are usually simple to avoid by being a little careful in your coding.
Of course.
And with enough imagination and a wide enough definition of "security" and "remote attack", pretty much everything is vulnerable. Your kettle might have just one switch and no electronics (never mind any software), but if people can cut the electricity supply to your house then it is still vulnerable to remote denial of service attacks.
The problem with "goto" is that it is very easy to abuse and produce spaghetti code - it is too flexible. More nuanced programmers accept that sometimes "goto" can be the best choice of code flow control, but those occasions are rare. They are particularly rare in languages with rich alternatives for code flow.
Nonsense. Event-driven and state machine code are not uncommon in high reliability code - they occur in many types of coding. And high reliability code can have many types of structures and code flow. One thing it does not have, however, is more than very, very occasional gotos.
When writing provable code, "goto" is something you would usually avoid. It makes it extremely difficult to prove the effects of the code, compared to loops, recursion, or other structures.
I never thought of a kettle as being vulnerable to a DoS attack before. Motivation might be lacking though. Someone tried to secure to this one against such attacks:
NT
David Brown wrote
Seems a bit of a religious statement to me.
1) I think the discussion makes no sense, goto is just fine. 2) as soon as you move towards higher level languages like C and upwards there are many very serious problems.Let's have an example Single chip RS232 remote controlled storage oscilloscope implemented in a PIC 18F14K22
grep goto scope.asm goto test_for_1 goto test_for_2 goto test_for_3 goto lcd_cs_end goto reset_entry goto int_8 ; goto int_18 goto end_bor_reset goto end_watchdog_reset goto end_test_watchdog_reset goto end_test_brownout_reset goto end_test_x_y_sensitivity_change goto main_update_display ; mode changed goto main_no_mode_change goto end_test_new_baudrate goto baudrate_change_cancelled ; goto 0 goto main_end goto main_end goto end_test_x_y_mode goto main_end ; clear x_y mode goto end_test_scope_mode goto main_end ; clear scope mode goto main_loop ; IF NOT FOUND, ONLY CLEAR mode if something found. ; goto main_end goto main_end goto main_loop goto scope_timebase_set_range_1 ; 1000 ms goto scope_timebase_set_range_2 ; 500 ms goto scope_timebase_set_range_3 ; 200 ms goto scope_timebase_set_range_4 ; 100 ms goto scope_timebase_set_range_5 ; 50 ms goto scope_timebase_set_range_6 ; 20 ms goto scope_timebase_set_range_7 ; 10 ms goto scope_timebase_set_range_8 ; 5 ms goto scope_timebase_set_range_9 ; 2 ms goto scope_timebase_set_range_10 ; 1 ms goto scope_timebase_set_range_11 ; 500 us goto scope_x_delay_loop ; 2 cycles goto scope_x_delay_out_loop goto inner_loop_done goto lcd_delay_loop goto outher_loop goto lcd_busy_check goto lcd_y_addess_c2 goto lcd_y_address_set goto test_y_range goto y_range_ok goto decrement_lcd_x goto have_lcd_x goto mod_count_loop goto row_done goto row_one_up goto lcd_set_clear_bit goto lcd_clear_bit goto lcd_set_bit goto lcd_reset_y_address goto lcd_cls_y_loop_c1 goto lcd_cls_x_loop goto do_a_zero goto do_a_plot goto column_loop goto lcd_row_loop1 goto lcd_text_pri_loop goto lcd_count10 ; substraction failed goto lcd_loop_hundreds goto lcd_suppress_first_zero goto lcd_count1 goto lcd_loop_tenth goto lcd_print_tenth ; tenth not zero goto lcd_print_units ; if first digit was not zero, print this zero goto select_adc_low_speed goto select_adc_end goto test_tx_empty goto count10 ; substraction failed goto loop_hundreds goto suppress_first_zero goto count1 goto loop_tenth goto print_tenth ; tenth not zero goto print_units ; if first digit was not zero, print this zero goto print_ones goto pri_nibble_out goto eeprom_poll_write_complete_loop goto eeprom_write_error goto eeprom_is_programmed goto pri_test_vref_2048 goto pri_vref_divide goto pri_vref_must_be_1024 goto pri_vref_divide goto wait_number goto NOCHK goto NOGO goto neg_B ; negate REGA ( -REGA -> REGA ) goto chek_A goto neg_A goto mloop goto muloop goto dtstgt goto dtstgt goto dtstgt goto dremlt goto dvloop goto rtstgt goto dtstgt goto rtstgt goto rremlt goto rremlt goto rremlt goto rremlt goto ststgt goto ststgt goto sremlt goto sqloop goto nega1 goto nega1 goto nega1 goto negb1 goto negb1 goto negb1 goto test_rx_interrupt goto in_5 ; goto int_end goto test_overrun goto reset_rx_circuit goto get_rx_char ; goto int_end ; discard character goto int_end goto int_end ;; goto process_digits_cr goto process_character goto process_digits_cr goto remote_plot_command goto end_remote_plot_command goto end_print_text_lcd_command goto cr_command goto lcd_cls_command goto cr_command goto read_adc_command goto read_adc_command goto select_baudrate_command goto plot_black_dot_command ; goto set_lcd_chip_select_command goto dump_display_command ; goto set_lcd_data_command goto external_trigger_on_command goto external_trigger_off_command goto fft_mode_on_command goto fft_mode_off_command goto calibrate_clock_command goto print_clock_calibration_command goto print_help goto cu_up_command goto cu_left_command goto cu_right_command goto cu_down_command goto lcd_on_command goto lcd_off_command goto lcd_print_test_command goto x_y_storage_on_command goto x_y_storage_off_command goto print_lcd_data_command goto scope_mode_auto_command goto scope_mode_single_trace_command goto print_text_lcd_command goto lcd_xy_plot_command goto on_screen_display_on_command goto on_screen_display_off_command goto lcd_print_char_set_command goto plot_white_dot_command goto set_lcd_x_address_command goto set_lcd_y_address_command goto scope_x_y_mode_on_command goto scope_x_y_mode_off_command goto input_sensitivity_up_command goto input_sensitivity_down_command goto change_y_channel_command goto change_y_channel_command goto scope_select_positive_trigger_command goto scope_select_negative_trigger_command goto scope_x_delay_out_up_command goto scope_x_delay_out_down_command goto scope_x_delay_in_up_command goto scope_x_delay_in_down_command goto scope_trigger_level_up_command goto scope_trigger_level_down_command goto scope_timebase_up_command goto scope_timebase_down_command goto cr_command goto process_digits_command goto process_digits_command goto process_digits_command goto process_digits_command goto process_digits_command goto process_digits_command goto process_digits_command goto process_digits_command goto process_digits_command goto process_digits_command goto int_end goto int_end goto end_read_adc_command goto end_calibrate_clock_command goto end_get_number_command ; goto end_set_lcd_chip_select_command ; goto end_set_lcd_data_command goto end_set_lcd_x_address_command goto end_set_lcd_y_address_command goto int_end goto int_end_clr goto int_end_clr goto int_end_clr goto int_end_clr goto int_end_clr goto plot_test_loop goto plot_test_loop2 goto int_end_clr goto int_end_clr goto int_end ; do not clear command goto int_end_clr goto int_end ; stay in this command mode goto int_end_clr goto int_end_clr goto int_end_clr goto int_end_clr goto int_end_clr goto int_end_clr goto int_end_clr goto int_end_clr goto int_end_clr goto int_end_clr goto int_end_clr goto int_end_clr ; goto command_end goto command_end goto print_text_test_loop goto command_end goto command_end goto command_end goto int_end_clr goto int_end_clr goto int_end_clr goto int_end_clr goto int_end_clr goto int_end_clr goto int_end_clr goto int_end_clr goto int_end_clr goto int_end_clr goto int_end_clr goto int_end_clr goto int_end_clr goto int_end_clr goto int_end_clr goto int_end_clr goto int_end_clr goto int_end_clr goto int_end_clr goto int_end_clr goto command_end goto command_end goto command_end goto command_end goto command_end ; goto command_end ; goto command_end goto command_end goto command_end goto command_end_status goto command_end_status goto command_end_status ; goto command_end_status ; goto command_end_status goto command_end_status goto command_end_status goto int_end goto int_end goto text_pri goto text_pri goto text_pri goto text_pri goto text_pri_loop goto sin_pri_loop goto sin_lookup goto cos_pos goto hamming_loop goto test_loop_h goto add_32_positive goto add_32_positive_imag goto fft_inner_loop goto bar_finished goto fft_bar_plot_loop goto fft_frequency_loop goto lcd_print_lpd goto lcd_loop_lpd goto lcd_print_lpd1 goto lcd_print_none goto lcd_clear_space_loop goto test_vref_2048 goto vref_divide goto vref_must_be_1024 goto vref_divide goto dump_display_print_zero goto dump_display_print_pixel goto dump_pixel_loop goto dump_line_loop goto scope_display_clear_mem_loop goto scope_x_y_y goto scope_x_y_x goto scope_x_y_loop goto set_115200bd goto set_19200bd goto set_9600bd goto set_1200bd ; goto select_baudrate_end goto set_115200bd goto select_baudrate_end goto select_baudrate_end goto select_baudrate_end goto erase_fft goto display_data goto scope_get_plot_data goto scope_test_for_display_top goto scope_plot_dot ; plot a white dot, lcd_plot_d = 0 goto scope_display_loop goto scope_wait_internal_trigger goto scope_external_positive_trigger_mode goto scope_have_trigger goto scope_external_trigger_test_auto goto scope_have_trigger goto scope_wait_external_trigger goto scope_wait_external_trigger goto scope_have_trigger goto scope_internal_posive_trigger goto scope_store_old goto scope_store_old goto scope_have_trigger goto scope_store_old ; new value not higher, get new value goto scope_have_trigger goto scope_wait_internal_trigger goto scope_wait_internal_trigger goto scope_aquisition_loop goto scope_max_speed_aquisition_loop goto scope_acquistion_complete goto scope_aquisition_loop goto scope goto trigger_level_changed goto end_test_trigger_level_change goto cursor_moved goto cursor_moved goto end_test_cursor goto test_x_y_sens_1 goto say_volts_fsd goto x_y_sens_2 goto say_volts_fsd
scope.asm is 9486 lines of asm, well divide by 2 at least for comments and empty lines for clearity.
The fun thing is when I wrote that, the 18F14K22 was sorta new to me and I had not _really_ bothered to read the instruction set, later I found it also had a 'bra' instruction, relative jump, so I could have saved some space and maybe increased speed and added more features in the 8 k words / 16 kB code space.
Now you all in you f*cking high level languages may or may not be able to write that in that code space.. with or without goto. Personally I would not even try in C and forget about any other languages.
An other fun thing is the 'skip if ' in PIC asm. skips the next instruction (that could be a jump or call) if is met,
All that d*mn filosphy here about the work of dickstar who obviously was no coder and about security by non-hackers, what a waste of time. Write some code, publish it, see that it works so others can use it prove the idiot wrong with gotoes ;-) or follow his religion.
In this newsreader,
LOL
And all your 'high' level languages and compilers in the end create gotos.
The reason things are bloated these days is coders using those high level languages who have no clue about hardware, and use library on top of library on top of library needing 10 MB code to say 'hello world'. And many of those, for example creating websites with those tools, have not the slightest inkling about logic, are not capable of logic thinking, and create a world of rubbish.
Huge projects like for example the tax system here, millions put into it, failed. It becomes a money sucking operation and the managers are either idiots and / or do not know the basics of computing, or see it as their job to makes the things as expensive as possible and suck the most money from the taxpayer that is. Same for US military projects like for example F35, useless joke of no value in a real war. US warships dead in the water because windows cashed... Was it caused by gotos
Let's move on.
Shit
On Dec 31, 2018, snipped-for-privacy@nospam.org wrote (in article ):
Actually, gotos were not the root cause. Which you knew.
It was stupider than that, someone down in the Engine Room accidentally entered a zero (by a fat-finger error) in a database field on pump flow or capacity or something, crashing the badly-written statistics database, which in turn took the local operating system down, which in turn brought the shipboard LAN down, which in turn caused all attached computers to hang. They had to reboot the entire ship and bring it back up one system at a time; this is what took about three hours.
There was a lot about this in The Risks Digest in 1998 as well: .
========================== ============ From a presentation I made in 2004:
o For almost three hours in September 1997, the Yorktown, a billion-dollar Aegis guided-missile cruiser, drifted helplessly off Cape Charles, VA, without propulsion, steering, weapons, or sensors, all due to a crash in a Windows-NT client, which took the entire shipboard LAN and connected computers down with it (Ref: "Was it Windows or Human Error", WSJ 27 Aug
1998, page B6)- If this had happened in a storm or during a battle, or far from home, ship and crew could have been lost. Many naval battles have been lost and/or ships sunk simply because a ship's rudder jammed. A dead propulsion system is far worse.
o The Yorktown was the prototype IT-21 "SmartShip"
- In January 2001, the Smart Ship program died of injuries received in the Yorktown Incident (Ref: "Navy postmortem tries to pinpoint what went wrong with the 'Smart Ship' ", Edward J. Walsh, Military& Aerospace Electronics
- OACE has apparently taken over the realtime mission, and the IT-21 name survives for shipboard office automation applications only (OACE = Open Architecture Computing Environment) o The fundamental problem was the inappropriate use of a desktop operating system for an application that is both mission-critical and safety-critical
- Civilian Air Traffic Control systems have since the 1970s or 1980s had full fault tolerance, with tenth-second recovery times. Warships should be able to do at least this well.
- A traditional two-box solution, with a standard RTOS controlling propulsion et al in one set of boxes and NT in a different set of boxes, communicating via standard Internet protocols on the shipboard LANs, would have allowed the Yorktown to sail on unaffected while Windows was being brought back up.
o For safety-critical applications, Windows NT/2000/XP or its successors may never suffice, and/or be accepted by the relevant safety review boards
End of 2004 presentation.
========================== =========
During the rise of the IT-21 program, pointing out the folly of useng a desktop operating system for things like sensors, weapons, combat systems, et al would cause significant career damage, so most people bided their time. After the Yotktown Incident, the direction of career damage abruptly reversed.
What replaced Windows for embedded realtime was the traditional two-box solution, but using Red Hat Enterprise Linux plus a real RTOS kernel like VxWorks. Many FPGAs have a mini Linux inside. And so on.
And there are now two physically isolated LANs, one (usually redundant) for the combat system et al, and the other for admin tasks (where Windows boxes are used).
Joe Gwinn
Or use the HDD or SMC or PMIC or various other peripherals to store information or run code. Basically everything contains Flash and a microcontroller, nowadays, and can be updated via drivers.
Remember, your "computer" is actually dozens of CPUs (equivalent to maybe
60s-70s era supercomputers/mainframes), supporting typically two supercomputers (as such were in the mid-90s or so).It is not at all unreasonable for, say, the NSA to obtain a manufacturer's keys, craft a custom driver to be distributed to a target (say by MITM'ing Windows Update servers), and having that implant persistent monitoring and reporting code inside some "hardware" device, independent of OS, hard drive or a lot of other things.
I think they tend not to do that, exactly. AFAIK, they have the authority to obtain keys, but it's rather a nuclear option as far as burdening manufacturers with the knowledge that their whole distribution chain is now not quite theirs. Hence the preference for physical implant devices and existing vulnerabilities.
It has happened before -- there have been two virus attacks where a Microsoft key was stolen or cracked, and malicious software distributed via Windows Update, IIRC.
Tim
-- Seven Transistor Labs, LLC Electrical Engineering Consultation and Design Website: https://www.seventransistorlabs.com/
Ah, but the rise of the European empires only really got going once tea and coffee were introduced to Europe--kettle DoS is obviously a nefarious plot to overturn Western civilization. ;)
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 http://hobbs-eo.com
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.