dosbox-staging (DOSBox Git repo)

Developer's Forum, for discussion of bugs, code, and other developmental aspects of DOSBox.

Re: dosbox-staging (DOSBox Git repo)

Postby dreamer_ » 2019-11-12 @ 10:03

The latest round of krcroft's CD-DA changes just got merged to the master branch - thanks to everyone helping :)

The code went through several rounds of review and more-than-average testing, so I figured out it will be easier to work with this merged in. We're still waiting for second patch series to be addressed by maintainers (and, hopefully, committed to SVN), after that'll be done, new CD-DA will be send upstream in the third patch series. (If it'll make its way to trunk earlier via other means, that would be OK, too).

[edit]
I think it's time to implement nightly builds to make it easier for people to test this stuff ;)
Code: Select all
| ← Ceci n'est pas une pipe
User avatar
dreamer_
Newbie
 
Posts: 67
Joined: 2019-5-17 @ 20:19

Re: dosbox-staging (DOSBox Git repo)

Postby dreamer_ » 2019-11-25 @ 00:14

Third patch series of changes from dosbox-staging was just submitted for inclusion in SVN. You can follow discussion in here: https://sourceforge.net/p/dosbox/patches/284/ (yes, this is the same thread as series 2, as none of those patches were included yet).

These are the exact commits from this series: https://github.com/dreamer/dosbox-stagi ... 54da6ee765

Quick summary of changes:

- ALL of krcroft's work regarding sound handling, including the latest improvements merged in today (this is the good stuff, it improves compatibility with some games, e.g. Destruction Derby - it also lowers memory consumption and CPU usage when audio from .cue files is played).
- Lots of warning fixes (or silencing, if it can be trivially accomplished) - this is our quest to reach 0 warnings, which in turn would speed up code reviews
- Some static analysis fixes - it seems like one change in here prevents potential buffer overflow

Some of changes we made would be very hard or impossible to implement without C++11, therefore this patch tries to enable it again. We need this.

If the goal is to eventually switch to SDL2, then there's no point in slowing down development by gripping to an old standard. Some modern compilers do not even give an option to select pre-C++11 standard any more while others started to show warnings about usage of anything that was removed from the language in C++17.

@users who want to test it I am working on setting up automatic release builds, but they're not ready yet. In the meantime, I recommend building from the master branch instead of applying these patches to your SVN working copies. At the moment master includes all changes from svn trunk until r4294.

@Qbix can we do something to facilitate faster inclusion of patches in SVN?
Since patch series 2 was posted, we saw few changes from patch series 1 included in trunk… but that's really slow. Preparing series 2 for inclusing in SVN was easy, patch series 3 was a bit troublesome already…
Code: Select all
| ← Ceci n'est pas une pipe
User avatar
dreamer_
Newbie
 
Posts: 67
Joined: 2019-5-17 @ 20:19

Re: dosbox-staging (DOSBox Git repo)

Postby DosFreak » 2019-11-25 @ 00:59

If DOSbox does switch to using C++11 it would be nice to mention in the changelog when this was introduced "C++11 Minimum of VS2012\VS2013 Required less than Windows XP support dropped)" so that those using <VS2012 know what last commit they can use since VS2008+ dropped <XP compatibility (okay 2000 still works on VS2008) due to changes in the CRT. This can be worked around easily with VS2008 by using LegacyExtender but for anything newer requires a bit more work see (copied and pasted from elsewhere) viewtopic.php?f=31&t=55706&p=792269&hilit=compilation#p792237 . Mingw/GCC should be unaffected except for using a newer minimum version (GCC 4.7/4.8.1? but could be earlier) but Windows OS compatibility there is unaffected.

IIRC, latest ver of original mingw uses GCC v6.3.0 and last I tested with Mingw-W64 w/ gcc 8.1.0 Windows compatibility with DOSBox from Original 95\NT3.50+ still worked as long as a newer msvcrt.dll was used. Mingw-W64 w/Clang required XP+ due to posix when last tested with v5.0.1.

Only issue I'm aware of concerning Windows OS compatibility with the original mingw w/gcc is the below and as long as mingwrt <5.0.1 or >=5.0.2 is used then no issue.
Mingwrt v5.0.1 introduced SSE intructions that crashes DOSBox in 9x on pre-sse processors but that was fixed in Mingwrt 5.0.2
https://sourceforge.net/p/mingw/bugs/2357/

Need to check with Dominus to see if this would affect his OSX builds, most likely not.

OS/2 can use newer GCC versions and I think I saw work on an SDL2 fork so shouldn't be an issue there.

Support For C++11
https://docs.microsoft.com/en-us/previo ... 8(v=vs.140)?redirectedfrom=MSDN
https://docs.microsoft.com/en-us/cpp/ov ... ew=vs-2019
https://en.cppreference.com/w/cpp/compiler_support
User avatar
DosFreak
l33t++
 
Posts: 10521
Joined: 2002-6-30 @ 16:35
Location: Your Head

Re: dosbox-staging (DOSBox Git repo)

Postby jmarsh » 2019-11-25 @ 01:14

Do you actually test the automatically compiled builds that are being used to confirm these fixes as valid?

I had a quick to look to investigate some of the proposed changes because they looked incorrect (using a "%lu" format specifier for Bitu is wrong since a long is always 4 bytes on windows) and from the logs your 32-bit builds are broken; they're including risc_x64.h instead of risc_x86.h, which wouldn't work at all. Example: https://github.com/dreamer/dosbox-stagi ... step:8:668

Quite frankly the insistence to adopt c++11 (and drop support for the various platforms/device SDKs that don't support it) just to eliminate a few harmless warnings is ridiculous.
jmarsh
Member
 
Posts: 332
Joined: 2014-1-04 @ 09:17

Re: dosbox-staging (DOSBox Git repo)

Postby spiroyster » 2019-11-25 @ 13:03

jmarsh wrote:Quite frankly the insistence to adopt c++11 (and drop support for the various platforms/device SDKs that don't support it) just to eliminate a few harmless warnings is ridiculous.

Yes I agree, I would very much like to keep legacy C++ standards going for as along as can be. dosbox shouldn't just be for the latest n' greatest software/hardware imo.

What exactly is it that requires the upgrade to C++11? static_assert and is_standard_layout?

Also, while on the subject... exactly what requirements warrant upgrading to Vuikan?

The development overhead would be quite substantial in setting up the Vulkan pipelines, not only does it bump up end user requirements, considering what GL is actually used for in dosbox, I would put a lot of money on the fact that you wouldn't see any performance gains anyway o.0

While I like the CI stuff and appreciate what you have done so far, one of the main benefits of CI is testing, namely regression testing! Having a build is one thing, having it work is another...

At some point you have to stop and ask why are these changes being made, as it doesn't appear to be for the benefit of the end user, and that should be the priority imho.
User avatar
spiroyster
Oldbie
 
Posts: 541
Joined: 2015-10-12 @ 12:26

Re: dosbox-staging (DOSBox Git repo)

Postby dreamer_ » 2019-11-25 @ 13:54

jmarsh, spiroyster - do I understand you correctly? You are AGAINST moving DOSBox to SDL2? Because my call for C++11 was precluded with "if the goal is to eventually switch to SDL2". SDL2 does not support all those legacy and "extremely popular" platforms you so care about. How many users did download DOSBox 0.74-3 for, let's say, OS/2? 0 - the package wasn't even built and nobody noticed, because no one cares. How many people used DOSBox 0.74-3 to actually play games on Windows 95 in 2019? What's the point of doing so - if someone is interested in retro-computing, then it's more effective to just install DOS on an old machine or VM. And even if DOSBox 0.75.x won't support those platforms any more - you will still be able to download (or even continue developing) 0.74.x branch in the future.

spiroyster wrote:What exactly is it that requires the upgrade to C++11? static_assert and is_standard_layout?

Yes. Amongst many, many, many other language features. The new standard (well, C++11 is old already) is there to speed up development and prevent the programmer errors. (And yes, that asserts you feel are pointless - they already helped find one new bug in DOSBox, so it won't affect the users).

Is this forum called VogoNs? Shouldn't you rename it to VogoVOs?
Code: Select all
| ← Ceci n'est pas une pipe
User avatar
dreamer_
Newbie
 
Posts: 67
Joined: 2019-5-17 @ 20:19

Re: dosbox-staging (DOSBox Git repo)

Postby Dominus » 2019-11-25 @ 13:57

Even still switching to SDL2 doesn't make c++11 necessary. What exactly does NEED it? And what about the other points raised?
User avatar
Dominus
DOSBox Moderator
 
Posts: 8020
Joined: 2002-10-03 @ 09:54
Location: Ludwigsburg

Re: dosbox-staging (DOSBox Git repo)

Postby jmarsh » 2019-11-25 @ 14:08

SDL2 supports anything that anyone bothers to port it to. Don't use it to push your own personal agenda.
jmarsh
Member
 
Posts: 332
Joined: 2014-1-04 @ 09:17

Re: dosbox-staging (DOSBox Git repo)

Postby dreamer_ » 2019-11-25 @ 14:56

jmarsh do you plan to fork SDL2 to support Windows 95 to keep using it as an argument against using C++11? Which platforms do you plan to support in your fork, that don't have C++11 capable compiler?

And… my "personal agenda"? What?

Dominus wrote:Even still switching to SDL2 doesn't make c++11 necessary. What exactly does NEED it? And what about the other points raised?

But supporting SDL2 makes *not-using* C++11 pointless. Therefore, doesn't it make sense to start using C++11 to speed up development to mainline SDL2 support faster? And please be specific about which other points were raised, because I haven't seen a single one worth responding to specifically.
Code: Select all
| ← Ceci n'est pas une pipe
User avatar
dreamer_
Newbie
 
Posts: 67
Joined: 2019-5-17 @ 20:19

Re: dosbox-staging (DOSBox Git repo)

Postby Dominus » 2019-11-25 @ 15:08

But supporting SDL2 makes *not-using* C++11 pointless

you could have dual targets in the code that makes it easy to switch from SDL 1.2x to SDL2, in the fashion of Ny00123's patch. So still no pointlessness. SDL2 is just not the selling point you are looking for.

Again, is there any need for c++11 besides warnings?

And please be specific about which other points were raised, because I haven't seen a single one worth responding to specifically.

Is this forum called VogoNs? Shouldn't you rename it to VogoVOs?

Toning down the hostility here and in the staging repo comments might be the best way to get further. I *think* what makes people be so antagonistic to the proposed changes is the way you are pushing for it and lashing out in frustration for not getting your way.
User avatar
Dominus
DOSBox Moderator
 
Posts: 8020
Joined: 2002-10-03 @ 09:54
Location: Ludwigsburg

Re: dosbox-staging (DOSBox Git repo)

Postby jmarsh » 2019-11-25 @ 15:27

dreamer_ wrote: And please be specific about which other points were raised, because I haven't seen a single one worth responding to specifically.

Your warning "fixes" introduce warnings and your builds are misconfigured and will crash the moment they switch to the dynamic core.

If you want to contribute to an open source project it is common sense to match your contributions to the existing style/format of the project, not demand that they be changed to match your expectations.
jmarsh
Member
 
Posts: 332
Joined: 2014-1-04 @ 09:17

Re: dosbox-staging (DOSBox Git repo)

Postby spiroyster » 2019-11-25 @ 15:55

dreamer_ wrote:Yes. Amongst many, many, many other language features. The new standard (well, C++11 is old already) is there to speed up development and prevent the programmer errors.
By this logic, why go to Vulkan then? While yes AZDO gives it performance advantages, this is at the expense of development (the code will be probably about 10x the size of the GL code, requires Vulkan expertise, and given the features that dosbox uses GL for... is pretty pointless... this is not a development or user win in any context). Vulkan benefits applications that really push the pixels and need to squeeze as much performance out as possible, which dosbox is not ... it simply renders a quad and blits the frameimage as a texture to it. Are you yourself going to write the new Vulkan code for this? Or just proposing?

I don't think asserts are pointless, far from it, but...
(1) You can do a static (compile time) assert without using the C++11 static assert.
(2) is_std_layout is only required if the object you are checking violates StandardLayoutType. Is there any risk that object you are checking will violate this?

dreamer_ wrote:they already helped find one new bug in DOSBox
Was it a bug? Are there re-creatable steps to manifest this behaviour at runtime? ...or is it that a static analyser picked it up?

I'm not saying ignore what the static analyser says, but a lot of time without re-creatable behaviour... without regression testing... if you cannot identify the advantage of what the change does, it could be questioned if it adds anything, and could even be considered dangerous!

Granted the user base requiring < C++11 is probably very small, but why change unless you need to? (I myself found out about dosbox as I had an SGI 320 and Win2K and that hardware wouldn't even run DOS). There are copious amounts of threads on this forum discussing old hardware and software. As time moves on what is considered new now, will be old. I can certainly see people wanting to run DOS applications on non-DOS OS's without the need to dual boot or get older DOS compliant hardware/computers.

dreamer_ wrote:Is this forum called VogoNs? Shouldn't you rename it to VogoVOs?
lol I agree with that, however thats feature creep for you! More importantly though, it does not prevent me from using it!

As I said, I do appreciate what you have done with the CI, but worry that some changes are a bit 'bull in a china shop'. Fundamental changes like the ones you propose, need to be thought about and ultimately should not be at the expense of current functionality or alienating user base as much as possible. Personally in my job, I've had to clean up the mess too many times because of indiscriminate hipster use of XXX lib just because YYY uses it and they wanted to use 0.001% of the features and didn't really have a true understanding of the scope of their requirements/needs and thus broke things they did not know about until after it was too late. On an open source project it means divergence! and that is exactly what I thought dosbox-staging wasn't?
User avatar
spiroyster
Oldbie
 
Posts: 541
Joined: 2015-10-12 @ 12:26

Re: dosbox-staging (DOSBox Git repo)

Postby dreamer_ » 2019-11-25 @ 16:24

jmarsh wrote:Your warning "fixes" introduce warnings

No, they do not. We have scripts on CI, that verify maximum limit of warnings - when the number is raised, the build fails. I am progressively lowering the limit as more and more warnings are fixed - the goal is to have 0 warnings and set -Werror on CI, eventually. Twice now I needed to RAISE the allowed limit after merging-in changes from SVN.

You are referring exactly to this commit: https://github.com/dreamer/dosbox-stagi ... 24645cbb4e

Which was fixing a bunch of warnings like this:
Code: Select all
cpu.cpp:506:33: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘Bitu’ {aka ‘long unsigned int’} [-Wformat=]
  506 |    E_Exit("Task switch CS Type %d",cs_desc.Type());
      |                                ~^  ~~~~~~~~~~~~~~
      |                                 |              |
      |                                 int            Bitu {aka long unsigned int}
      |                                %ld

So, before my changes, the code was using `%d` to format Bitu (aka "unsigned long") values and I replaced it with `%lu`. This solved a lot of warnings on Linux and macOS, works correctly in MSVC 32-bit builds (64-bit MSVC builds are not supported currently), and it kept the warnings limit the same on non-MSVC Windows builds (surprise, surprise, who could've guessed that on those builds Bitu is actually "unsigned long long"). After my change SVN received fixes only in places I touched (which caused conflicts - I'm not sure if it was deliberate or not), while disregarding a hundred or so other places in code, where these warnings still exist.

jmarsh wrote:… and your builds are misconfigured and will crash the moment they switch to the dynamic core.


Well, isn't it a problem for DOSBox SVN when built with MSYS2 or MinGW on Windows as well? Thank you for pointing this out.

jmarsh wrote:If you want to contribute to an open source project it is common sense to match your contributions to the existing style/format of the project, not demand that they be changed to match your expectations.


Believe it or not, I did contribute to a number of Open Source projects. Usually, those project maintainers respond to patches, offer review to clean up patches to make them ok for inclusion, have coding guidelines or conventions estabilished, often have CI and tests to prevent regression, and their technical decisions are explained, e.g. "we allow only C89, because this and this usecase". DOSBox uses arguments like "we want to compile DOSBox on Windows 95 in 2019" while disregarding serious usability and technical issues the users have. Can you name a single popular project (Open Source or not), that keeps supporting Windows 95 in 2019? What is the value of doing it?

Right now, most of the world moved on to C++11 or newer. When merging in changes from outside of DOSBox (like code from mame project). DOSBox maintainer needed to actively work on backporting C++11 code to old standard. At this point in time, clinging to old standard is a liability.
Code: Select all
| ← Ceci n'est pas une pipe
User avatar
dreamer_
Newbie
 
Posts: 67
Joined: 2019-5-17 @ 20:19

Re: dosbox-staging (DOSBox Git repo)

Postby BloodyCactus » 2019-11-25 @ 16:31

you should not be using %lu or %d anywhere. you should be using proper defined types, like PRId64, PRIu32, PRIx16, etc.

in c, its <inttypes.h> in c++ its <cinttypes>

so
Code: Select all
"foo %d %lu\n"
becomes
Code: Select all
"foo %"PRId32" "PRIu32"\n"


this is the proper way to do it and you will not have the useless compiler warnings about type sizes spat out across architectures.
--/\-[ Stu : Bloody Cactus :: http://kråketær.com :: http://mega-tokyo.com ]-/\--
User avatar
BloodyCactus
Oldbie
 
Posts: 945
Joined: 2016-2-03 @ 13:34
Location: Lexington VA

Re: dosbox-staging (DOSBox Git repo)

Postby krcroft » 2019-11-25 @ 16:48

jmarsh,

Regarding the ./configure error you mentioned: Do you have a github account? With an account, you can click on a line of source-code and drop feedback in on-the-fly; might as well give yourself a voice if you're already sifting through the scripts and code; I have appreciated your feedback.

Talking about typedef's and sizes in a general sense:

DOSBox requires exact type sizes for hardware and interface emulation, and obviously the existing language specification has done us wrong by allowing those underlying types to vary among platforms and architectures. So without being able to trust the the language spec, DOSBox was forced to define its own: Bit8u, Bit16s, Bit32u, and so on.

SDL has its own too: Uint8, Sint16, and Uint32, ...
Ogg has its own too: ogg_int16_t, ogg_int32_t, ogg_uint64_t, ...

These worlds collide in code that straddle two more area, such as this: https://github.com/dreamer/dosbox-stagi ... ers/opus.c
It's pretty gross mixing and matching all these types (and casting between types), but that's life when your language specification isn't robust enough to guarantee type byte sizes.

So I ask this question - has the C++ standards committee finally been smart enough to fix their types, in such as a way that (almost) every project out there doesn't have to redefine their own types?

Here are the types defined in C++11: https://en.cppreference.com/w/cpp/types/integer
Could DOSBox use those straight-away?
User avatar
krcroft
Member
 
Posts: 421
Joined: 2017-4-29 @ 15:07
Location: Ogden's Retreat

Re: dosbox-staging (DOSBox Git repo)

Postby BloodyCactus » 2019-11-25 @ 17:08

stdint types were a thing from C99.. which predates sdl + dosbox. that people were defining their own types was just ignorance, but things perpetuate and here we are 20 years later. Now having worked with ancient compilers that didnt always support stdint+inttypes its easy to know why these things get created in the first place. (hello old sun + sgi + amiga compilers!)

there comes a point of diminishing returns, does that 1988 amiga c compiler still need to be supported with its lack of standards? every codebase has a legacy.

dosbox team is small and are seemingly happy with where things are, refactoring a type rename is probably not even on their radar, and its no small job.
--/\-[ Stu : Bloody Cactus :: http://kråketær.com :: http://mega-tokyo.com ]-/\--
User avatar
BloodyCactus
Oldbie
 
Posts: 945
Joined: 2016-2-03 @ 13:34
Location: Lexington VA

Re: dosbox-staging (DOSBox Git repo)

Postby dreamer_ » 2019-11-25 @ 17:20

spiroyster wrote:By this logic, why go to Vulkan then?

At this point, Vulkan support is nothing more than a vague possibility after SDL2 support will land in. There are important reasons to support it though: macOS is dropping OpenGL, so with Vulkan in place it would be possible to have one API covering all OSes (with macOS going via MoltenVK - again, just a possibility, because having macOS-only Metal backend would be quite a problem to implement).

spiroyster wrote:Are you yourself going to write the new Vulkan code for this? Or just proposing?

I hope to, but if anyone else would like to do it faster, then I'll be happy to help. SDL2 support is a prerequisite for that, though. And krcroft's replacement for SDL_sound is a prerequisite for SDL2.

(1) You can do a static (compile time) assert without using the C++11 static assert.


Really? How? Anyway, C++11 includes some STL constructs, that make it easier to use static asserts: type_traits

(2) is_std_layout is only required if the object you are checking violates StandardLayoutType. Is there any risk that object you are checking will violate this?


Yes, of course. Right now, that piece of code depends on structure offsets being 0 for specific fields. As soon as standard layout rule will be broken (and it might be broken by mistake, e.g. by someone adding a private field to the end of that structure), that assumption is broken. Without static assert, a programmer can make a mistake and it would easily pass any review, because that interaction is really, really not obvious. With static assert, a programming mistake will result in a failed compilation, so programmers time won't be wasted, reviewer time won't be wasted, user time won't be wasted.

Was it a bug? Are there re-creatable steps to manifest this behaviour at runtime? ...or is it that a static analyser picked it up?

I can go into details, but it would take some time - short version: after a change (moving fields around), that was supposed to keep runtime behaviour exactly the same while preventing triggering C++ Undefined Behaviour, runtime behaviour of code *changed*. I was writing static asserts to verify if the code is ok (it's easier to write a static assert than read the code, keep C++ standard open on the second monitor and verify several pages of specification manually). By writing those asserts and trying to understand what the code actually does (as opposed to just avoiding a warning), I discovered that runtime asserts would need to be written as well - I added those, and they blew the moment I started DOSBox. This way a bug was *prevented* before it even reached any user. No time was wasted on posting threads or investigations or reverting patches, etc.

I've had to clean up the mess too many times because of indiscriminate hipster use of XXX lib just because YYY uses it (…)

I understand… But at this point in time, C++11 replaced older standards, most C++ programmers embraced it (and for good reasons - it is a SERIOUS improvement to the language). It's not new, it is ~9 years old at this point. New MSVC does not even support limiting your project to using pre-C++11 code any more! Using the old standard is a hipster move.

(I myself found out about dosbox as I had an SGI 320 and Win2K and that hardware wouldn't even run DOS).

And me, and users of my projects can't use upstream DOSBox RIGHT NOW on Linux, because of pervasive input issues. It's not a theoretical problem affecting the old system only.

On an open source project it means divergence! and that is exactly what I thought dosbox-staging wasn't?

I really, really try to keep divergence as low as possible - that's why I keep sending patches upstream… But there are no contributing rules for DOSBox, everything happens at maintainers discretion, and… out of ~60 patches or so, only ~4 were acknowledged and merged in (or re-implemented). DOSBox SVN is so far behind, that it's starting to be harder for me to keep verifying and sending patches.
Code: Select all
| ← Ceci n'est pas une pipe
User avatar
dreamer_
Newbie
 
Posts: 67
Joined: 2019-5-17 @ 20:19

Re: dosbox-staging (DOSBox Git repo)

Postby dreamer_ » 2019-11-25 @ 17:32

BloodyCactus wrote:you should not be using %lu or %d anywhere. you should be using proper defined types, like PRId64, PRIu32, PRIx16, etc.

I wholeheartedly agree! We can't do it right now, because Bit* types are redefined via autoconf.

But Bitu is not a fixed-size type (or it would be named Bit64u or something) - I think hardcoding it as an alias for "unsigned long" or "unsigned long long" would be fine (which would require dosbox-wide update to either %lu or %llu - but almost all of those places in code use %d now, so it needs to happen anyway).

One of my longer term plans is to replace Bitu, Bit32u, … definitions with simple int, uint32_t, etc… to avoid this whole mess of unnecessary casting throughout the DOSBox codebase. This is yet another reason to switch to C++11 (standard C++ fixed-size integer types are available only since C++11: https://en.cppreference.com/w/cpp/types/integer).

[edit]

BloodyCactus wrote:dosbox team is small and are seemingly happy with where things are, refactoring a type rename is probably not even on their radar, and its no small job.

DOSBox team is small, because new contributors are shunned or ignored and centralized SVN is contributing to this problem. And let's not get distracted here - depending on OS/compiler configuration, DOSBox has between 200-400 warnings right now, there are far more serious things to fix (like lots of misaligned pointer accesses).

Anyone having technical issues with how things are being done in dosbox-staging: don't hold it in to unleash on forum, leave comments in code review, create issues in bugtracker, or just send a PR. We will gladly accept more contributors.
Code: Select all
| ← Ceci n'est pas une pipe
User avatar
dreamer_
Newbie
 
Posts: 67
Joined: 2019-5-17 @ 20:19

Re: dosbox-staging (DOSBox Git repo)

Postby krcroft » 2019-11-25 @ 18:02

C++11 lets us use safer types, algorithms, and constructs that 1) automatically handle memory and cleanup for us or 2) limit or eliminate the ability to misuse memory.

Our CI workflow executes six types of Linux builds with instrumentation to detect runtime errors. I've attached those reports as well as the following Coverty scans of dosbox-staging:

2019-11-25_09-05_1.png

2019-11-25_09-05.png

2019-11-25_09-11.png

(Note: Results are from the linux pathway through DOSBox.. the #def exclusions for macOS and Windows weren't scanned.)

The need for low-level memory control won't go away in DOSBox's core emulations areas; but we can certainly benefit from C++11's safer constructs where our needs are pedestrian, like parsing config files, performing logging, parsing the shell input, interfacing with SDL an so on.

And yes - you see two issues relating to dr_flac in there. I reported those last night and the developer is already on them.
Attachments
GCC-logs.zip
(59.91 KiB) Downloaded 1 time
Clang-logs.zip
(172.53 KiB) Downloaded 2 times
Last edited by krcroft on 2019-11-25 @ 19:16, edited 2 times in total.
User avatar
krcroft
Member
 
Posts: 421
Joined: 2017-4-29 @ 15:07
Location: Ogden's Retreat

Re: dosbox-staging (DOSBox Git repo)

Postby krcroft » 2019-11-25 @ 18:08

Here's the last log attachment, because this forum has a limit of 5 attachments.
Attachments
report.zip
(2 MiB) Downloaded 3 times
User avatar
krcroft
Member
 
Posts: 421
Joined: 2017-4-29 @ 15:07
Location: Ogden's Retreat

PreviousNext

Return to DOSBox Development

Who is online

Users browsing this forum: No registered users and 3 guests