Recent

Author Topic: [Solved]Buffer overflows  (Read 4057 times)

Thaddy

  • Hero Member
  • *****
  • Posts: 17176
  • Ceterum censeo Trump esse delendam
Re: Buffer overflows
« Reply #15 on: September 26, 2024, 12:27:30 pm »
Cars don't cause accidents.
Yes, they do, independent of drivers. (E.g. Tesla's but there are many more examples from different brands)
The same is true for compilers: the compilers themselves can - and do - cause accidents, irrespective of the programmer.
« Last Edit: September 26, 2024, 12:29:27 pm by Thaddy »
Due to censorship, I changed this to "Nelly the Elephant". Keeps the message clear.

TRon

  • Hero Member
  • *****
  • Posts: 4377
Re: Buffer overflows
« Reply #16 on: September 26, 2024, 12:29:27 pm »
Nevermind "defensive programming techniques", which get lost on the wayside.....
Well, in case of driving you might as well do it safely. If someone decides to use a wrecking-ball instead then why bother at all ? (and as you and Mark correctly pointed out that is a choice).

Perhaps I am missing the point ?
Today is tomorrow's yesterday.

Zvoni

  • Hero Member
  • *****
  • Posts: 2982
Re: Buffer overflows
« Reply #17 on: September 26, 2024, 12:30:16 pm »
Cars don't cause accidents.
Yes, they do, independent of drivers. (E.g. Tesla's but there are many more examples from different brands)
The same is true for compilers: the compilers themselves can cause accidents, irrespective of the programmer.
Have to disagree.
A compiler itself doesn't cause errors.
It's the human being that programmed the compiler

.... and now let's move off topic with AI-generated compilers  :P
One System to rule them all, One Code to find them,
One IDE to bring them all, and to the Framework bind them,
in the Land of Redmond, where the Windows lie
---------------------------------------------------------------------
Code is like a joke: If you have to explain it, it's bad

Thaddy

  • Hero Member
  • *****
  • Posts: 17176
  • Ceterum censeo Trump esse delendam
Re: Buffer overflows
« Reply #18 on: September 26, 2024, 12:31:55 pm »
Nevermind "defensive programming techniques", which get lost on the wayside.....
Yes, if you are referring to the wiki. One of those things I still have to finish. It is on my list. But what is there is already valuable.
Due to censorship, I changed this to "Nelly the Elephant". Keeps the message clear.

TRon

  • Hero Member
  • *****
  • Posts: 4377
Re: Buffer overflows
« Reply #19 on: September 26, 2024, 12:34:43 pm »
.... and now let's move off topic with AI-generated compilers  :P
Great ! compilers that now have thoughts, can think about their decisions which as a result takes longer to compile and because of that are a bit more expensive to use... ow and the output becomes more rotten with each compilation \o/  :D :gets-back-to-his-cage:
Today is tomorrow's yesterday.

Thaddy

  • Hero Member
  • *****
  • Posts: 17176
  • Ceterum censeo Trump esse delendam
Re: Buffer overflows
« Reply #20 on: September 26, 2024, 12:37:00 pm »
.... and now let's move off topic with AI-generated compilers  :P
That is on topic, since AI is a human concept.
Couldn't help it:
Code: Pascal  [Select][+][-]
  1. program PCodeCompiler;
  2.  
  3. type
  4.   TInstruction = (ADD, SUB, MUL, DIV, PUSH, HALT);
  5.   TCode = record
  6.     instr: TInstruction;
  7.     operand: Integer;
  8.   end;
  9.  
  10. var
  11.   code: array[1..100] of TCode;
  12.   stack: array[1..100] of Integer;
  13.   sp, pc: Integer;
  14.  
  15. procedure Emit(instr: TInstruction; operand: Integer);
  16. begin
  17.   Inc(pc);
  18.   code[pc].instr := instr;
  19.   code[pc].operand := operand;
  20. end;
  21.  
  22. procedure Execute;
  23. var
  24.   instr: TInstruction;
  25.   operand: Integer;
  26. begin
  27.   pc := 1;
  28.   sp := 0;
  29.   repeat
  30.     instr := code[pc].instr;
  31.     operand := code[pc].operand;
  32.     case instr of
  33.       PUSH: begin
  34.         Inc(sp);
  35.         stack[sp] := operand;
  36.       end;
  37.       ADD: begin
  38.         stack[sp-1] := stack[sp-1] + stack[sp];
  39.         Dec(sp);
  40.       end;
  41.       SUB: begin
  42.         stack[sp-1] := stack[sp-1] - stack[sp];
  43.         Dec(sp);
  44.       end;
  45.       MUL: begin
  46.         stack[sp-1] := stack[sp-1] * stack[sp];
  47.         Dec(sp);
  48.       end;
  49.       DIV: begin
  50.         stack[sp-1] := stack[sp-1] div stack[sp];
  51.         Dec(sp);
  52.       end;
  53.       HALT: break;
  54.     end;
  55.     Inc(pc);
  56.   until instr = HALT;
  57. end;
  58.  
  59. begin
  60.   pc := 0;
  61.   Emit(PUSH, 10);  // Example: 10 + 20
  62.   Emit(PUSH, 20);
  63.   Emit(ADD, 0);
  64.   Emit(HALT, 0);
  65.   Execute;
  66.   WriteLn('Result: ', stack[sp]);
  67. end.
« Last Edit: September 26, 2024, 12:40:23 pm by Thaddy »
Due to censorship, I changed this to "Nelly the Elephant". Keeps the message clear.

Zvoni

  • Hero Member
  • *****
  • Posts: 2982
Re: Buffer overflows
« Reply #21 on: September 26, 2024, 12:39:44 pm »
Nevermind "defensive programming techniques", which get lost on the wayside.....
Well, in case of driving you might as well do it safely. If someone decides to use a wrecking-ball instead then why bother at all ? (and as you and Mark correctly pointed out that is a choice).

Perhaps I am missing the point ?
Probably that People (Programmers) don't use "enough" defensive programming (whichever technique).

It's like driving to a gas-station to refuel your car:
You put the gas pump nozzle into the tank neck (gas-tank being your Buffer)

You don't have Range-check? The Buffer overflows (making a mess on the ground around your car, in the worst case going KABOOM)
You do have Range-Check? The gas pump nozzle switches itself off, because it recognizes the Buffer is full
One System to rule them all, One Code to find them,
One IDE to bring them all, and to the Framework bind them,
in the Land of Redmond, where the Windows lie
---------------------------------------------------------------------
Code is like a joke: If you have to explain it, it's bad

Zvoni

  • Hero Member
  • *****
  • Posts: 2982
Re: Buffer overflows
« Reply #22 on: September 26, 2024, 12:41:54 pm »
Nevermind "defensive programming techniques", which get lost on the wayside.....
Yes, if you are referring to the wiki. One of those things I still have to finish. It is on my list. But what is there is already valuable.
Not really, more as a general concept.

e.g. a Form with TEdit's
One such TEdit is for "Quantity" --> NumbersOnly! (How many forget that?)
One System to rule them all, One Code to find them,
One IDE to bring them all, and to the Framework bind them,
in the Land of Redmond, where the Windows lie
---------------------------------------------------------------------
Code is like a joke: If you have to explain it, it's bad

TRon

  • Hero Member
  • *****
  • Posts: 4377
Re: Buffer overflows
« Reply #23 on: September 26, 2024, 12:48:09 pm »
Probably that People (Programmers) don't use "enough" defensive programming (whichever technique).
ah ok, got it. I approached it from the other angle. Thank you for the elaboration (the last few days I seem more out of sync as is normal for me, apologies).

Today is tomorrow's yesterday.

MarkMLl

  • Hero Member
  • *****
  • Posts: 8431
Re: Buffer overflows
« Reply #24 on: September 26, 2024, 01:08:14 pm »
.... and now let's move off topic with AI-generated compilers  :P
That is on topic, since AI is a human concept.

Let's pull this back firmly onto topic.

If a so-called AI ("Spicy pattern matching" as somebody called it) contributes code to a project, who takes responsibility for it?

Specifically, if somebody signs off that code as reliable (or even trusted, i.e. embeds unreliable concepts but behaves reliably), can he justify his actions?

There's a lot of crap written these days about "corporations being people" and so on. But it's important to appreciate that that's normally done in the context of things like political donations: the bottom line is that if something bad happens in an engineering project (or a financial institution etc.) there's almost always a detailed investigation to find out who- i.e. what man or woman- was responsible, even if ultimately it's decided that they weren't malicious.

No such investigation can be performed for current AIs, since they cannot explain their reasoning and since by the time the damage has been detected their reasoning might no longer be reproducible.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Logitech, TopSpeed & FTL Modula-2 on bare metal (Z80, '286 protected mode).
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Zvoni

  • Hero Member
  • *****
  • Posts: 2982
Re: Buffer overflows
« Reply #25 on: September 26, 2024, 01:30:27 pm »
If a so-called AI ("Spicy pattern matching" as somebody called it) contributes code to a project, who takes responsibility for it?
The one who actually requested it from the AI

Quote
Specifically, if somebody signs off that code as reliable (or even trusted, i.e. embeds unreliable concepts but behaves reliably), can he justify his actions?
If he signed it off, then he is responsible (too, if he's not the one requesting it from an AI).
He only has to "justify" his decision if being asked
And NO: "I was only following orders" doesn't count.....
One System to rule them all, One Code to find them,
One IDE to bring them all, and to the Framework bind them,
in the Land of Redmond, where the Windows lie
---------------------------------------------------------------------
Code is like a joke: If you have to explain it, it's bad

TRon

  • Hero Member
  • *****
  • Posts: 4377
Re: Buffer overflows
« Reply #26 on: September 26, 2024, 01:35:34 pm »
If a so-called AI ("Spicy pattern matching" as somebody called it) contributes code to a project, who takes responsibility for it?
That is quite a recognizable description, thank you for that.

Quote
Specifically, if somebody signs off that code as reliable (or even trusted, i.e. embeds unreliable concepts but behaves reliably), can he justify his actions?
The commercial spin-doctors are way ahead of that. The latest most shiny model now has a 'chain of though' (tree of thought) that the ai can explain to the user (if user knows how to correctly engineer such a prompt). Thus, problem solved, at least for the politicians and hot shot ceo's that like buzz-rides... responsibility... ? reminds me of a wrecking-ball  :D
Today is tomorrow's yesterday.

Zvoni

  • Hero Member
  • *****
  • Posts: 2982
Re: Buffer overflows
« Reply #27 on: September 26, 2024, 01:41:07 pm »
If a so-called AI ("Spicy pattern matching" as somebody called it) contributes code to a project, who takes responsibility for it?
That is quite a recognizable description, thank you for that.

Quote
Specifically, if somebody signs off that code as reliable (or even trusted, i.e. embeds unreliable concepts but behaves reliably), can he justify his actions?
The commercial spin-doctors are way ahead of that. The latest most shiny model now has a 'chain of though' (tree of thought) that the ai can explain to the user (if user knows how to correctly engineer such a prompt). Thus, problem solved, at least for the politicians and hot shot ceo's that like buzz-rides... responsibility... ? reminds me of a wrecking-ball  :D

I still remember the dawn of navigation-systems in cars.
"honestly, officer: My navigation-system told me to take that turn! How should i have known, that i'm entering a one-way-street from the wrong end?"
Now, how many times did that statement save anyone from a fine?
One System to rule them all, One Code to find them,
One IDE to bring them all, and to the Framework bind them,
in the Land of Redmond, where the Windows lie
---------------------------------------------------------------------
Code is like a joke: If you have to explain it, it's bad

TRon

  • Hero Member
  • *****
  • Posts: 4377
Re: Buffer overflows
« Reply #28 on: September 26, 2024, 02:06:18 pm »
Now, how many times did that statement save anyone from a fine?
True.

If something goes wrong eventually someone ends up with the blame.

I just read that the big AI companies made a pact with the EU (AI pact) that they promise to honour.... :) (haven't had the time to read through that though, that is if the nitty gritty details are even publicly available).

PS: with apologies to topic starter as this is going waaay off-topic now.
« Last Edit: September 26, 2024, 02:10:15 pm by TRon »
Today is tomorrow's yesterday.

MarkMLl

  • Hero Member
  • *****
  • Posts: 8431
Re: Buffer overflows
« Reply #29 on: September 26, 2024, 02:11:40 pm »
If a so-called AI ("Spicy pattern matching" as somebody called it) contributes code to a project, who takes responsibility for it?
That is quite a recognizable description, thank you for that.

I think I've mis-quoted, but the sentiment is the same:

https://thecleverest.com/gpt3-is-just-spicy-autocomplete/

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Logitech, TopSpeed & FTL Modula-2 on bare metal (Z80, '286 protected mode).
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018