dummzeuch

You could simply use Notepad++ to change the line break to Unix and back to Windows. That fixes any of these problems. Also Delphi 11 comes with a setting to do that automatically: Tools -> Options -> User Interface -> Editor -> Line Endings: "Convert files with known extensions to CRLF" (No idea when that was introduced. I had not noticed before. Also no idea whether it actually works.)

They will just introduce a new API and deprecate the old one. Happened before, will happen again.

There are usually some tasks that do not need to run on the performance cores, so setting the affinity mask for the whole program may not be the best strategy, even though it's the easiest way. But I'm sure that sooner or later Windows will start ignoring those masks because everybody sets them. Of course this is currently the only way to do that for threads generated using parallel for.

I have inherited this code from a program originally written in Borland Pascal for DOS, which I have adapted to Delphi 32 Bit: function BuildDigits(_Digits: UInt16; _Invalids: UInt8): UInt16; var TempInt: Int16; begin TempInt := _Digits; Dec(TempInt, 2048); TempInt := TempInt * 11; TempInt := (TempInt and $FFFC) or (_Invalids and $03); // <-- crashes here TempInt := Swap16(TempInt); Move(TempInt, Result, SizeOf(Result)); end; The adaptations were to change variable declarations: Word -> UInt16, Byte -> UInt8, Integer -> Int16 (Integer was 16 bits in Borland Pascal). Only Integer -> Int16 was really necessary, the others were just to confuse^d^d^d^d^d^d^d^d^d^dclarify the code. (The function Swap16 swaps the bytes of a 16 bit value, so $1234 becomes $3412.) The code works fine if range checking is turned off {$R-}. But with range checking turned on {$R+}, it fails for e.g. _Digits = 0, because a range check error occurs in the line marked above. Edit: The line the crash occurred was not the one multiplying with 11 but the one below. I would like to be able to keep range checking enabled in debug mode, so how can I modify the code to return the same results as if range checking was disabled? My idea was to change TempInt to an Int32 but I am unsure how to proceed. (I'm getting old. I'm sure this wouldn't have posed a problem for me 10 years ago. Or maybe it's the heat and not enough sleep.)

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.)