[Toybox] blkid fixed for strict-alias

[Rob Landley]

On 10/09/2013 03:25:27 AM, Conroy, Bradley Quentin wrote:
> 
> >Sort of moot at this point, I did a largeish rewrite. (Attached, I
> >should be able to rsync it up to the site tonight.)
> 
> I'll wait on recoding it with the union of structs pointing to toybuf  
> then.
> That would take care of the strict aliasing, reduced the memory foot-
> print and simplified a bunch of code, but I'm interested to see how
> you did it.

It was attached to the previous email.

> >There are currently three obvious problems with it, all to do with  
> vfat:
> >
> >1) it always prints a LABEL even if it's all spaces or the magic "NO
> >LABEL" value.
> 
> I think it is safe to check *offset==' ', but "NO LABEL"? really?  Who
> does that?  I think I would consider that disk to be labeled.

According to http://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html (and  
some testing here) it's "NO NAME    " (yes, space padded at the end)  
and various format tools create that.

A vague todo item I've had is something mtools-like. The fat filesystem  
is a bit unusual due to being 30 years old and very simple, things like  
qemu generate it on the fly.

But for 1.0 I wanted to concentrate on the roadmap. That's why the  
constant stream of commands not in the roadmap is so depressing; I  
don't exactly want to say no to them, but dealing with them prevents me  
from getting any closer to 1.0, and the project keeps getting bigger  
and more complex without getting any closer to the original goals,  
unless I mostly ignore outside contributions.

No clue how to deal with that. (I _have_ decided what I want to do  
about the tcpsrv submission, which is add the relevant functionality to  
netcat and make a "server" alias for that which is _not_ tcpsrv or  
udpsrv because those are part of a larger suite of tools that do not  
belong in toybox, and implementing part of that suite invites an  
endless stream of questions about why I haven't got the rest of it.

So providing the functionality yes, opening that can of worms no.

But I also expect this to disappoint people, which is why I haven't  
done it yet. (Saying no to code nobody ever asked me if I wanted makes  
me the bad guy. Comes with the territory I guess...)

> >2) The funky 32 bit uuid is printed big endian, when the other prints
> >it little endian.
> 
> Yeah, fun stuff.  There isn't a lot of conformity there either.

The thing is, FAT is one exception and NTFS is another (completely  
different) exception. It's not "add a flag for endianness", so far this  
is just a special case for a single filesystem.

Filesystem special cases I want to put in the C code after the table,  
flags to indicate things that apply to more than one filesystem should  
be in the table, so I need more dat about what the full table looks  
like before finalizing the design. :)

> >3) It prints the uuid hex all lower case, where vfat is uppercase and
> >ext2 is lowercase. (Sigh.)
> 
> That is why I had %X in one and %x in the other.  At least with a  
> union
> of structs you can just use sizeof(fs->something.uuid) to get the size
> and data,

No you can't, not unless you define your own type for each filesystem.  
(Sizeof fat12/16 is 5. It would have to be a char array. I made it 64  
bit integer.)

The special case code to deal with each member of the union means the C  
code is large and complex even if the table isn't, plus this is an  
array so it gets padded out to the largest possible size so you're not  
actually saving any space...

> but still have to track these nuances by masking some flags.
>   labelisUCS = 1

There is exactly one instance.

>   backwarduuid = 2

So far, exactly one instance.

>   capsuuid=4

Don't even know what that means.

>   halfbackwarduuid=8 (i think there is some other wierd nuance)

Again: dunno.

>   spaceisblanklabel=16

Can we just say a label of all whitespace is considered blank? Do we  
really need a flag for that? (And again, what filesystems would this  
apply to? If it's just one, then it's a special case not a flag...)

I note that the current FAT uuid is, at least, unique. If all you care  
is recognizing devices you've seen before, we're done. Probably we care  
about more than that, but I honestly dunno what the requirements are  
here.

Rob
 1381562169.0