resolve warning: assignment discards 'const' qualifier from pointer target type

[viktorTarasov]

This warning became quite frequent after the data member of sc_apdu lost it's const qualifier.
It was done to allow the background treatment of SM wrap/unwrap of the APDU data. Probably solution was not the best and there exists a better one.

[frankmorgner]

On Sunday, June 01 at 02:53AM, viktorTarasov wrote:

This warning became quite frequent after the data member of sc_apdu lost it's const qualifier.
It was done to allow the background treatment of SM wrap/unwrap of the APDU data. Probably solution was not the best and there exists a better one.

First of all: Some years ago I proposed a generalized form of SM, which
would not modify the incoming APDU to add SM but instead create a new
APDU with SM and leave the original APDU untouched. This kind of
implementation would not have had this issue. This would be one route to
go...

Second, earlier this year I proposed a patch fixing all warnings by
(among others) re-enabled the const modifier for the data member. You
can cast the few occurrences in the SM case to non-const if required. In
the end, const means that apdu->data shall not be changed. But if you
know what you are doing, it's valid to do so. Also, there are AFAIK, no
parts of the code that rely on an unchanged value of apdu->data.

[viktorTarasov]

First:
as far as I remember, some years ago I do not got the answer on question how your generalized form of SM could be applied to the other cards. It had distinguished flavor of nPA card.

Second:
I processed your fix-all-warning patch: major part applied, some changed (compilation problems), few postponed for future . Your patch do not concerns warnings on Windows 32/64 -- it also waits for the enthusiasts .

Do you consider this issue as non-minor and preventing the publication of the next release ?

[frankmorgner]

Let's don't grieve about the past. I think the most pragmatic solution would be to change the type of sc_apdu_t.data back to const and cast the few occurences where non-const is needed.

Windows warnings need to be fixed from peoples using OpenSC Windows. I personally don't even know where to find VS projects for OpenSC. (I would be curious about it, though.)

[viktorTarasov]

frankmorgner commented Friday at 10:05 PM

I personally don't even know where to find VS projects for OpenSC. (I would be curious about it, though.)

There is no supported VS project,
but the MSIs (x32, x64) are built for releases and nightly built for commits and placed on sourceforge.

[frankmorgner]

There is no supported VS project,
but the MSIs (x32, x64) are built for releases and nightly built for commits and placed on sourceforge.

In my eyes, the MSIs are untrusted since I can't build and verify them
myself. Would you mind sharing the build scripts? Publishing a working
Visual Studio project would also lower the barrier for contributions to
OpenSC.

[viktorTarasov]

https://www.opensc-project.org/opensc/wiki/WindowsInstaller#

CI builds it like this:

cd "C:\Program Files\Microsoft Visual Studio 10.0\VC"
call vcvarsall.bat x86
cd "%WORKSPACE%\opensc-*"
nmake /f Makefile.mak
cd win32
nmake /f Makefile.mak OpenSC.msi

[frankmorgner]

The last 'const' warnings are from here:
https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-iasecc.c#L2222
https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-iasecc.c#L2227
As author of the files you may have look into them...

If there are no objections, I'd like to merge #311