timmerk / nfc-tools

Automatically exported from code.google.com/p/nfc-tools
0 stars 0 forks source link

mifare_application_alloc should take size in block not in sector #31

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Actually, mifare_application_alloc takes "size" argument in "sector" unit, but 
this function should provide more easier way to allocate memory in MAD: using 
block unit, it will be simplier : blocks are ALWAYS 16 bytes long, but sectors 
can be 4 blocks long (Mifare Classic 1K) or 15 blocks long (Mifare Classic 4K, 
on sectors > 32).

Before documentation fix in r393, manpages talk about blocks and I think that's 
a better way.

Original issue reported on code.google.com by romu...@libnfc.org on 30 Jun 2010 at 8:07

GoogleCodeExporter commented 9 years ago
Totally agree, requireing number of sectors is a bug in the API.

Maybe instead of blocks we can just ask for a number of bytes and then allocate 
the correct space to align on sectors (yep! Basically just like malloc(3) does).

This may make the API even easier to use, e.g.

=============8<-----------------------

// build NDEF
char *ndef = ...

mifare_application_alloc (mad, aid, ndef_length (ndef));
mad_write (tag, mad, ...);
mifare_application_write (tag, aid, ndef, ndef_length (ndef));

=============8<-----------------------

Original comment by romain.t...@gmail.com on 30 Jun 2010 at 8:55

GoogleCodeExporter commented 9 years ago
I think its a good idea you purpose. Allocate using size in bytes is more 
coherent and mifare_application_write() is a great enhancement.

Original comment by romu...@libnfc.org on 30 Jun 2010 at 9:14

GoogleCodeExporter commented 9 years ago
I'll take it.

Original comment by romain.t...@gmail.com on 1 Jul 2010 at 2:36

GoogleCodeExporter commented 9 years ago
Skizophrenia problem…

*I* will take it!

Original comment by rtarti...@il4p.fr on 1 Jul 2010 at 2:38

GoogleCodeExporter commented 9 years ago
This issue was closed by revision r403.

Original comment by rtarti...@il4p.fr on 1 Jul 2010 at 5:05