Le 26/04/2011 08:56, Martin Paljak a écrit :
> Hello,
>
> On Fri, Apr 22, 2011 at 11:13, Viktor TARASOV
> wrote:
>>> ... the other 'warnings' should not happen with 'READ BINARY' when data
>>> are returned,
>>> with exception of 6281 'Part of the returned data may be corrupted'.
>>> I guess that
Hello,
On Fri, Apr 22, 2011 at 11:13, Viktor TARASOV
wrote:
>> ... the other 'warnings' should not happen with 'READ BINARY' when data
>> are returned,
>> with exception of 6281 'Part of the returned data may be corrupted'.
>> I guess that this 'warning' is an error and cannot be ignored.
>> An a
Le 21/04/2011 11:19, Viktor TARASOV a écrit :
Le 21/04/2011 10:55, Frank Morgner a écrit :
Hi!
I think that a flag could be invented for switching between these
two modes of operation (the otherwise unused "flags" parameter to
sc_read_binary). The default could be the mode that honors passed
El jue, 21-04-2011 a las 10:03 +0200, NdK escribió:
> > The problem I have is to read a file with an unknown length.
> How is that possible? Aren't file sizes fixed at file creation time?
> Have I missed something?
> IIUC, when you issue a SELECT_FILE, you can see its size, too. I'm confused.
Sure
Le 21/04/2011 10:55, Frank Morgner a écrit :
> Hi!
>
> I think that a flag could be invented for switching between these
> two modes of operation (the otherwise unused "flags" parameter to
> sc_read_binary). The default could be the mode that honors passed
> in parameters.
Act
Hi!
I think that a flag could be invented for switching between these
two modes of operation (the otherwise unused "flags" parameter to
sc_read_binary). The default could be the mode that honors passed
in parameters.
>>> Actually the 0x6282 is mapped to the general SC_ERROR_CA
Hi!
> > But all other functions of libopensc require the caller to allocate
> > enough space.
> Vital for maintainable software: who needs memory, allocates (*and
> frees*) it. As a sage said a long time ago: "or you rewrite your project
> this way, or your project will rewrite you" :)
As long as
Il 20/04/2011 22:24, Frank Morgner ha scritto:
> But all other functions of libopensc require the caller to allocate
> enough space.
Vital for maintainable software: who needs memory, allocates (*and
frees*) it. As a sage said a long time ago: "or you rewrite your project
this way, or your project
Hi!
In the svn tree there is a change that breaks my code: The ISO
driver automatically sends read binary APDUs until the number of
requested bytes is reached (iso7816.c:136).
You mean r5237 [1] ?
Yes!
Previously only one APDU was sent. The change surely intendeds to
read as much as possible
Hi!
> >> In the svn tree there is a change that breaks my code: The ISO
> >> driver automatically sends read binary APDUs until the number of
> >> requested bytes is reached (iso7816.c:136).
> > You mean r5237 [1] ?
Yes!
> >> Previously only one APDU was sent. The change surely intendeds to
> >>
Le 20/04/2011 15:03, Martin Paljak a écrit :
> Hello,
> On Apr 20, 2011, at 13:22 , Frank Morgner wrote:
>
>> In the svn tree there is a change that breaks my code: The ISO driver
>> automatically sends read binary APDUs until the number of requested
>> bytes is reached (iso7816.c:136).
> You mean
Hello,
On Apr 20, 2011, at 13:22 , Frank Morgner wrote:
> In the svn tree there is a change that breaks my code: The ISO driver
> automatically sends read binary APDUs until the number of requested
> bytes is reached (iso7816.c:136).
You mean r5237 [1] ?
> Previously only one APDU was sent. The
12 matches
Mail list logo
