Recent

Author Topic: Definition C array to Pascal array  (Read 9244 times)

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Definition C array to Pascal array
« Reply #15 on: June 01, 2021, 10:32:43 am »
That said, a program should _not_ depend on range checking to operate correctly.

I don't believe that anybody suggested that. The argument is over whether simply ignoring (the possibility of) range check errors is ever acceptable.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

440bx

  • Hero Member
  • *****
  • Posts: 3946
Re: Definition C array to Pascal array
« Reply #16 on: June 01, 2021, 10:44:15 am »
The point I was trying to make, which apparently I didn't make well, is that range checking should only be used as a debugging aid and only when it may be helpful and not normally be enabled during development. 

That eliminates the need for directives to turn it off (because it's normally off.)
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Definition C array to Pascal array
« Reply #17 on: June 01, 2021, 11:08:22 am »
The point I was trying to make, which apparently I didn't make well, is that range checking should only be used as a debugging aid and only when it may be helpful and not normally be enabled during development. 

That eliminates the need for directives to turn it off (because it's normally off.)

Range checking should only be disabled if a program can be formally proven to never need it.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

440bx

  • Hero Member
  • *****
  • Posts: 3946
Re: Definition C array to Pascal array
« Reply #18 on: June 01, 2021, 11:21:16 am »
Range checking should only be disabled if a program can be formally proven to never need it.
The way I think about it is, if a program is bug-free (which is what it should be) then it doesn't need range checking or any other mechanisms to trap bugs.

Except is some rare cases, it is usually not possible to formally prove a program is bug free but, I don't believe that should be used as a reason to enable bug-trapping mechanisms.

(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Definition C array to Pascal array
« Reply #19 on: June 01, 2021, 01:17:16 pm »
The point I was trying to make, which apparently I didn't make well, is that range checking should only be used as a debugging aid and only when it may be helpful and not normally be enabled during development. 

That eliminates the need for directives to turn it off (because it's normally off.)

But the point is if you enable range checking then you want to deal with the problem you want to tackle and not with potential false positives. Thus explicitly disabling of range checks for selected parts where one knows that a range check would trigger, but where it is a false positive is part of "defensive programming" in my opinion.

Also I don't agree that these checks should be off during development. They should be off for the final release, yes, but during development they can catch errors that would otherwise manifest as bugs (for the compiler itself these checks have already revealed quite a bunch during development before even comitting).

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Definition C array to Pascal array
« Reply #20 on: June 01, 2021, 01:29:07 pm »
Also I don't agree that these checks should be off during development. They should be off for the final release, yes, but during development they can catch errors that would otherwise manifest as bugs (for the compiler itself these checks have already revealed quite a bunch during development before even comitting).

Quite frankly I'm not convinced that they should be off for release code. Now that CPUs no longer provide fine-grained protection (e.g. using segments) the more help that the system gets to detect random errors caused by stray radiation or thermal effects the better.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

jamie

  • Hero Member
  • *****
  • Posts: 6091
Re: Definition C array to Pascal array
« Reply #21 on: June 01, 2021, 05:14:00 pm »
Quote

Quite frankly I'm not convinced that they should be off for release code. Now that CPUs no longer provide fine-grained protection (e.g. using segments) the more help that the system gets to detect random errors caused by stray radiation or thermal effects the better.

MarkMLl
:-[
Why not? You don't believe in "I test my work in production" ?
The only true wisdom is knowing you know nothing

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Definition C array to Pascal array
« Reply #22 on: June 01, 2021, 06:18:27 pm »
:-[
Why not? You don't believe in "I test my work in production" ?

I don't. But now that comparatively few systems have ECC memory, and the best that hardware protection can offer is fairly coarse-grained process-based memory protection, the more checking of instructions and intermediate results the better.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

440bx

  • Hero Member
  • *****
  • Posts: 3946
Re: Definition C array to Pascal array
« Reply #23 on: June 01, 2021, 06:58:56 pm »
Also I don't agree that these checks should be off during development. They should be off for the final release, yes, but during development they can catch errors that would otherwise manifest as bugs (for the compiler itself these checks have already revealed quite a bunch during development before even comitting).
We have a different philosophy about development.  Myself, I want to see the bugs in what is always close to the final product during development.  If there is a bug then, the aids the compiler provides are welcome (just like having a good debugger is always welcome.)  Also, not having the "artificial protections" shows how the program behaves when a particular bug is present.  That experience is often useful when a customer describes some weird situation that makes the program fail because it's likely the developer saw similar behavior during development.

I believe it's important to keep the product as close to the final product during development in order to gain experience with how the program behaves when some bug is triggered.  I want to see every bug imaginable during development, that way I know how the program behaves in the presence of a particular bug.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

ASerge

  • Hero Member
  • *****
  • Posts: 2223
Re: Definition C array to Pascal array
« Reply #24 on: June 01, 2021, 08:07:51 pm »
I’m porting a C library to pascal. In the c- header file I found a array definition. I have problems to translate to pascal. The structures are used to allocate a buffer and returned with  pdesc_list.
My question: Gives a pascal declaration equivalent to C.
In my opinion a couple of years ago it was already discussed and I gave a solution. Example (without range errors):
Code: Pascal  [Select][+][-]
  1. {$MODE OBJFPC}
  2. {$MODESWITCH ADVANCEDRECORDS}
  3. {$RANGECHECKS ON} // Even so!
  4. {$APPTYPE CONSOLE}
  5.  
  6. type
  7.   PDesc = ^TDesc;
  8.   TDesc = record
  9.     Length: Cardinal;
  10.     Count: Cardinal;
  11.   end;
  12.  
  13.   PDescList = ^TDescList;
  14.   TDescList = packed record
  15.     NumDesc: Cardinal;
  16.     function Descs: PDesc; inline;
  17.   strict private
  18.     DescsStart: record end;
  19.   end;
  20.  
  21. function TDescList.Descs: PDesc;
  22. begin
  23.   Result := PDesc(@DescsStart);
  24. end;
  25.  
  26. procedure Test;
  27. const
  28.   CCount = 100;
  29. var
  30.   P: PDescList;
  31.   i: Integer;
  32. begin
  33.   GetMem(P, SizeOf(TDescList) + CCount * SizeOf(TDesc));
  34.   try
  35.     P^.NumDesc := CCount;
  36.     i := CCount - 1;
  37.     P^.Descs[i].Count := 12345;
  38.     Writeln(P^.Descs[i].Count);
  39.   finally
  40.     FreeMem(P);
  41.   end;
  42. end;
  43.  
  44. begin
  45.   Test;
  46.   Readln;
  47. end.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Definition C array to Pascal array
« Reply #25 on: June 02, 2021, 09:14:20 am »
Also I don't agree that these checks should be off during development. They should be off for the final release, yes, but during development they can catch errors that would otherwise manifest as bugs (for the compiler itself these checks have already revealed quite a bunch during development before even comitting).

Quite frankly I'm not convinced that they should be off for release code. Now that CPUs no longer provide fine-grained protection (e.g. using segments) the more help that the system gets to detect random errors caused by stray radiation or thermal effects the better.

Pages which usually are 4 KiB are much more fine grained than what segments offered (64 KiB). Also current CPUs provide the option to mark pages as "no execute" and any number of page can be marked as such while only a single segment could be the code segment. Not to mention that one doesn't have the hassle with far calls to switch from one code segment to the other.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Definition C array to Pascal array
« Reply #26 on: June 02, 2021, 10:08:23 am »
Pages which usually are 4 KiB are much more fine grained than what segments offered (64 KiB). Also current CPUs provide the option to mark pages as "no execute" and any number of page can be marked as such while only a single segment could be the code segment. Not to mention that one doesn't have the hassle with far calls to switch from one code segment to the other.

Disagree. The granularity of x86-style segmentation was 16 bytes, and then you had precise bounds-checking of arrays. However (a) doing this thoroughly rapidly exhausted the descriptor tables and (b) bounds checking is incomplete for things like network messages which might not fill the defined type but should still be protected. BTDT.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018