dummzeuch

You passed the test. 😉

Isn't there something like {$SomeOption default} to reset an option to the value given in the project options? I seem to remember reading about that at some time in the what's new with Delphi Xxxx.

I know now. I'm thinking about adding Assertions but only in debug mode. But that would make the code even less readable ... 😞 I could also use a sub range type.

... unless you know exactly which values you are dealing with.

It turns out that the range for _Digits is indeed 0 .. 4095 because that value comes from the following code: // 3. Project the value on 12 Bit (11 = 2 * $5800 / 4096) // (The value of the laser laser is -$5800 to +$5800.) Value := Round(DigitInt / 11); // 4. signed -> unsigned 12 Bit Inc(Value, 2048); if Value < 0 then Value := 0; if Value > 4095 then Value := 4095; Digits := Value; // <== This is where the digits value come from So the changed function from above should do the trick as I tested it for _Digits = 0 .. 4095

The point is that I want to find range check errors and fix them. That's why I have enabled them in the debug build (in Delphi 2007 where it was off by default).

I hoped for a better way. This does the trick: function BuildDigits(_Digits: UInt16; _Invalids: UInt8): UInt16; var TempInt: Smallint; // 16 bit signed integer begin TempInt := _Digits; Dec(TempInt, 2048); TempInt := TempInt * 11; Move(TempInt, Result, SizeOf(Result)); Result := (Result and $FFFC) or (_Invalids and $03); Result := Swap16(Result); It returns the same values for _Digits = 0 .. 5000 and _Invalids = 0 .. $FF. Does anybody see anything wrong with this changed code? Now I need to check what the actual range of _Digits is. I hope it is documented somewhere. I guess it's 0 .. 4095 because the value is read from an analogue digital converter. But I'm not sure whether any preprocessing has already happened. (As said above: My excuse is that it's hot and that I haven't slept long enough.)

Why? -2048 is a perfectly fine value for an Int16.

Hm, yes, that's odd: -32678 <= -22528 <= 32767 Why didn't I see that? That was the line the debugger stopped on and I didn't question it. I'll need to have a closer look. Edit: The line the crash occurred was not the one multiplying with 11 but the one below: TempInt := (TempInt and $FFFC) or (_Invalids and $03); And that's probably because $FFFC is not an Int16. (I just changed the original post to reflect that.)

Yes, that's how I "solved" it for now, but it feels like a hack. Edit: No, I put the whole function body into these, still feels like a hack.

Yeah, I kind of knew that, I guess. It came up in a different discussion on a similar topic. That's why I use (U)Int(Len) types everywhere which are declared as being the correct length and also checked by an assertion. Apart from that, with names like these, it's clear what they are. (UInt32 = Cardinal which AFAIK is always 32 bit unsigned). Until somebody comes up with the great idea to change Int64 to be 128 bit for "compatibility reasons".... I guess I'll no longer be around by then and hope that there will be a mob to lynch that person.

If the number of bits of an integer type matters, don't use Integer, use SmallInt, ShortInt, LongInt and Int64 (and Byte, Word, LongWord and UInt64). But yes, I see the problem. I am as culpable as anybody else of assuming Integer to be 32 bits and it has bitten me several times when I had to make some changes to an old Borland Pascal DOS program, where Integer is 16 bit. Since then I have been changing data types to (U)Int8, (U)Int16, (U)Int32 and (U)Int64 in records, where the size matters, whenever I come across them. I also add some assertion code as to the size of these records to the initialization section of the unit that declares them. (Yes, we use a lot of these records, the original software was written for DOS and used file of record for everything. We have switched to a self describing file format now that has a header describing the record structure (based on a mechanism described in "Tomes Of Delphi"). And before anybody asks: No, databases are not an option, even DBase is too slow.) But I digress ...

I told ChatGPT to write a blog post for me thinking I might save some effort and finally get something useful out of it. Write a blog post about the Uses Clause Manager Expert in GExperts (Yes, I'm a lazy basterd™) It wrote a very convincing blog post on the topic which unfortunately was utter bullshit. None, I repeat: None, of the claims were true. So what did I do? I blogged about it.

As soon as ChatGPT files a feature request for them ... 😉

You realize that this doesn't answer the question, do you? As for "nobody": That's me then. I don't subscribe to any streaming services - I tried a few but they sucked - but I have got a sh*tload of music files on my computer and smartphone, most of them ripped from a CD years ago. Yes, I know that nobody buys CDs any more either. Back to the question: Sorry, I have no idea how to do that. I put my files on the phone using SyncThing (actually that is a convenient side effect of syncing my photos and notes to the desktop computer), but that's nothing the average user will even think about.

This wasn't a mistake. This reflects the underlying platform. It might not have been a mistake, but it did make it harder to port code that assumed that Integer and Pointer have the same size from 32 bit to 64 bit. That's all I said.

AI Researchers Warn of 'Model Collapse' As AI Trains On AI-Generated Content Who would have guessed?

Unfortunately they (Borland? Or was it already Embarcadero?) decided, to keep Integer a 32 bit data type rather changing it to the same bitness as Pointer. So even with large address awareness this leaves a lot of room for compile and runtime errors. They even managed to make a mistake in the declaration of NativeInt in Delphi 7 to 2007 where it was 64 bit rather than 32 bit, even though the compilers were all 32 bit back then. OK, that's ancient history, but the fact that Integer is still 32 bit remains.

That's not restricted to the Delphi IDE and packages though. Basically any DLL loaded into a process can do the same to that process. (I'm not sure about dotNET in that respect though.)

Using the debugger works for most cases. But that (memory overwrite) is exactly the kind of bug where changing some compiler options might make the problem disappear because the memory layout changes. Of course the bug would still be there and simply waiting to bite you in the back.

David was talking about the platform, not the language. That would be the dotNet framework and the Delphi VCL/RTL. I can't really say whether that's true or not, I've never used dotNet and I'm unlikely to ever do that. (Unless after retirement I find that dotNet is a good solution for writing Linux programs for personal use and for fun, because I plan to ditch Windows when that time comes.)

After trying to get anything useful out of chatGPT and wasting a lot of time to fix all the errors in the answer(s) I got, I am all for banning it from SO. I'm not sure it will work though. The dilution of web search results with plausible but wrong content generated by AI has already started and we will see a lot more of it. Of course there was already a lot of garbage on the web to start with, but now it has become much easier (-> cheaper) to produce it.

Alternatively there are quite a few other scripting engines, like the one included in Fastreport (Pascal, Basic, C, if I remember correctly) or DWScript (formerly known as Delphi Web Script, but definitely not restricted to Web usage). Extending a program by such an engine mostly means to provide an interface for these scripts to access the programs data and optionally the UI. It can be quite challenging to determine what to expose and in which way.

You should specify the complete path to exclude: C:\Windows Not just Windows

This command also searches all subdirectories and only later applies a filter removing all entries that start with c:\Windows\. The function @programmerdelphi2k gave you is actually more efficient because it doesn't descend into the windows directory at all.