nfc-mfclassic's output should be more clear

[GoogleCodeExporter]

At r138, nfc-mftool have a nice feature: it could try to read a MIFARE card
using "defaults" keys.
But the output is not clear:

nfc-mftool r a dump.mfd

Checking arguments and settings
Succesful opened MIFARE the required files
Connected to NFC reader: ACR122U102 - PN532 v1.4 (0x07)
Found MIFARE Classic 1K card with uid: ec81d51a
Reading out 64 blocks |............xxxx|
Writing data to file: dump.mfd
Done, all bytes dumped to file!

What does mean dots '...' and crosses 'xxx" ? If crosses are failures, we
shouldn't have a "Done, all bytes dumped to file!" message.

Original issue reported on code.google.com by romu...@libnfc.org on 5 Oct 2009 at 3:29

[GoogleCodeExporter]

Mistake: that was since r136 that nfc-mftool try to read MIFARE Classic using
defaults key.

Original comment by romu...@libnfc.org on 20 Oct 2009 at 4:01

[GoogleCodeExporter]

. => OK
x => wrong
(writing (OK) data to file : ...)

Do you have any suggestions to make this more readable ?:)

Original comment by r...@libnfc.org on 31 Oct 2009 at 1:43

[GoogleCodeExporter]

Yes Roel: like previously said: "If crosses are failures, we shouldn't have a 
"Done,
all bytes dumped to file!" message." isn't it ?

Original comment by romu...@libnfc.org on 2 Nov 2009 at 8:21

[GoogleCodeExporter]

Agreed, let's get rid of the stupid message ;)

Original comment by r...@libnfc.org on 3 Nov 2009 at 1:40

[GoogleCodeExporter]

NOTE: This patch is not tested!

Original comment by emanuele.bertoldi on 19 Nov 2009 at 10:33

Attachments:

• nfc-mfclassic.c.patch

[GoogleCodeExporter]

how it works this patch?

Original comment by foro.d...@gmail.com on 20 Nov 2009 at 3:44

[GoogleCodeExporter]

At first sight, this patch contains one error: switching from signed to unsigned
integer deny to be below under 0...so please don't use this patch if you don't 
know
how to fix it.

Original comment by romu...@libnfc.org on 20 Nov 2009 at 4:05

[GoogleCodeExporter]

Well, there is another typo error: "print_success_of_failure" instead of
"print_success_or_failure".

For the un/signed problem, simply don't change the "iBlock" variable. But why 
we need
a signed counter?

Original comment by emanuele.bertoldi on 20 Nov 2009 at 4:22

[GoogleCodeExporter]

This is a better version.

Original comment by emanuele.bertoldi on 20 Nov 2009 at 5:09

Attachments:

• nfc-mfclassic.c.patch

[GoogleCodeExporter]

Zuck> For the un/signed problem, simply don't change the "iBlock" variable. But 
why
we need a signed counter?

If you check the for-loop:
> for (iBlock=uiBlocks; iBlock>=0; iBlock--)
You can see that for-loop will loop until iBlock < 0. And iBlock can't be 
negative if
it's unsigned.

BTW, thanks for patch. I will try to commit them in trunk on Monday 23th.

Original comment by romu...@libnfc.org on 20 Nov 2009 at 6:21

[GoogleCodeExporter]

Romuald, this is clear, but that is the only signed counter in "classic" and
"ultralight" tools. Why we can't simply switch to an unsigned one and change the
guard condition?

Please, correct the typo error when you merge it to the trunk ;)

Original comment by emanuele.bertoldi on 23 Nov 2009 at 10:27

[GoogleCodeExporter]

Patch have been applied in r212. Thanks you Zuck.

Original comment by romu...@libnfc.org on 27 Nov 2009 at 4:53

• Changed title: nfc-mfclassic's output should be more clear

[GoogleCodeExporter]

Original comment by romu...@libnfc.org on 27 Nov 2009 at 4:53

• Changed state: Fixed