Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

readexe version 0.1 (Announce)

posted by segin Homepage E-mail, Springfield, MO, USA, 11.08.2023, 13:50

> Hello segin,
>
> I do not know — if you do not actually care about honoring C language
> standards, maybe do not bring them up on the first place?
Because otherwise you get people submitting PRs with state-of-the-1980s things like #define SOME_NYBBLE 0x00F0 and val = (((field & SOME_NYBBLE) >> 4) & 0xF). I'd rather have zero instances of this sort of thing.

Bitfields may be "nonportable" but that actually doesn't matter - they work where they need to work for this particular project. Again, the compilers in use for development handle them in the "correct" manner, and I'm not concerning myself with other devsuites out of KISS reasons (if it comes up, I'll worry then.) They're also a bit more readable than the classic way of doing things.

While nothing per se ties this code to x86 (more so, it's tied to little-endianness than anything else), I also don't concern myself with other CPU architectures at this time. Make the code work first, make the code work elsewhere later (and only if needed.) Walk before you run. It's a tool for retrocomputing on IBM-compatible PCs, and reverse-engineering thereof, and everything is designed to that end. Keep that in mind.

Your points aren't invalid, just less valid than you're thinking. There's no networking here, and the compilers I've found capable of making the builds I want (mingw64-gcc, host clang and gcc on Linux, gcc-ia16, and OpenWatcom) all work in the same, predictable manner on this matter.

It's also important to avoid overengineering. It eats up time and bloats code size with ever-diminishing returns. This is why if there's a problem, there's an issue tracker that anyone with a (easily acquired) GitHub account can submit a bug report with - if it's actually necessary to worry about, someone will definitely tell me in an embarrassing fashion. (I guess I could build and run readexe on my PowerMac G5 and just watch what happens :-D)

>
> OK, I grant that you have very strong opinions on how to write code. But
> then again, a lot of people also have very strong (and different) opinions
> (myself included). It will help if you provide us a good reason to pay
> particular attention to your opinions. :-D

If you felt so badly about bitfields, why didn't you pester ISO to drop them from C17 or C23?

>
> Last but not least: bit-fields already existed in C89.
C99 bitfields aren't quite the same beast as C89 bitfields. For one, you can make assumptions about the in-memory ordering of individual elements with respect to the bitfield's definition in the source, as ISO 9899:1999 has certain requirements around this. Most portability issues you encounter with C89 bitfields are eliminated as the standard leaves far less things up to the implementation to do as it pleases with. The remaining portability issues can be addressed if they come up, when they come up.

>
> Thank you!
No, thank you, one, for the ia16 GNU toolchain, and two, for making me think about all of this. Also, if my commentary seems oddly jarring, it's because I keep editing it in random order before posting.

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22632 Postings in 2109 Threads, 402 registered users, 392 users online (1 registered, 391 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum