v.in.dwg: Avoid using same variable as parameter and destination in sprintf

[ymdatta]

Currently, one instance of sprintf has same variable as parameter and destination in sprintf. This scneario leads to undefined behavior in C.

sprintf(buf, _("%s Cannot open %s"), buf, path);

Modify the code to:

1. Write initial error string using snprintf() onto the buffer. Using snprintf() makes sure that we stay within the buffer size and avoid overflow errors.
2. Use snprintf() again to write another error string at the end of previous error string in the same buffer. We again use snprintf() to make sure we are not overflowing the buffer with data.

This was found using cppcheck tool.

Prior to fix:

After fix:

Additional information:

1. Machine used: Virtual Machine running Ubuntu 22.04.4 LTS.
2. Reproduction rate: 100%, reproducible every time.
3. Architecture: Not specific to any underlying architecture.

[ymdatta]

Note: I couldn't compile the files in this package as I was not able to download the OpenDWG toolkit headers and libraries from http://www.opendwg.org from instructions in README. I believe the link is dead. So, I'm a bit uneasy about these changes. But, it's still a problem at hand as current code can cause undefined behavior.

I want to get inputs from you all on this.

[neteler]

I was not able to download the OpenDWG toolkit headers and libraries from http://www.opendwg.org from instructions in README. I believe the link is dead. So, I'm a bit uneasy about these changes

I have search around and the OpenDWG page went offline around 2011. Perhaps we should rather retire this code?

[nilason]

I was not able to download the OpenDWG toolkit headers and libraries from http://www.opendwg.org from instructions in README. I believe the link is dead. So, I'm a bit uneasy about these changes

I have search around and the OpenDWG page went offline around 2011. Perhaps we should rather retire this code?

I think we should. We have v.in.redwg as replacement.

[ymdatta]

That makes sense.

By retiring the code, do we stop pushing new commits to this module? If so, I can close this PR.

[wenzeslaus]

@nilason if your comment was resolved, I suggest merging and then removing the disabled code in another PR. If it is not resolved, I suggest closing and, again, removing.

[nilason]

@nilason if your comment was resolved, I suggest merging and then removing the disabled code in another PR. If it is not resolved, I suggest closing and, again, removing.

@ymdatta did resolve the changes of the code and came up a nice string catenation solution using snprinft() (strlen() was the key).
However, if we are going to remove the module, why push any updates to it?

[neteler]

The update is appreciated and then we may move it to add-ons, in a good shape.

[nilason]

The update is appreciated and then we may move it to add-ons, in a good shape.

Move is something else than remove :-) In not sure about the good shape, this has probably not been tested (or even used) in quite a while (depending on proprietary SDK), although it will certainly be better!

[wenzeslaus]

However, if we are going to remove the module, why push any updates to it?

Just because @ymdatta already created the changes. I would not be suggesting that otherwise.

I'm saying, let's merge this (rather than close), and then remove the code (directory and Makefile entry).

[wenzeslaus]

@ymdatta, can you please create a PR to remove v.in.dwg?