Yeah, Android's code is really not pretty when you dive in deep. I think the functional question is: if people are going to use adb one way or another, are they better off with our marginally better Debian version, or just downloading from Google?
.hc Ximin Luo: > HOLY SHIT I did not want to open that can of worms. > > I have attached a minimal patch that ought to fix this particular bug, to be > applied against 5.1.1.r29 which I will upload shortly. However, the code is > generally awful. It freely mixes int, unsigned int, size_t (which is *not* > unsigned int on some platforms, as indicated by this bug report) and int64_t, > in contexts where one wants some idea of "length" or "size", and there is no > documentation on the reasoning for this. I hope this is not used in any > security-critical situation. It looks like the code is used in simg_dump.py, > I would not run that on any untrusted inputs. > > As a DD, I only wanted to upgrade adb to the latest version, and I have no > idea what this is used for in general, someone please enlighten me. I would > go far as to suggest removing this from the Debian package, the code is *so > bad*. So I have not yet applied this patch. It's also questionable whether we > want 'unsigned int' - perhaps 'size_t' is better. I'm not sure, I haven't > tried to properly understand the code. But if nobody needs this patch any > more, I'd recommend ditching the code completely. > > Also, someone should file this bug upstream to the Android developers. I > don't have a Google account these days to do that with. > > X > > On Sun, 27 Apr 2014 18:31:06 +0100 Michael Tautschnig <[email protected]> wrote: >> Package: android-tools >> Version: 4.2.2+git20130529-3 >> Usertags: goto-cc >> >> While compiling the package using our research compiler infrastructure the >> build >> failed with the following error: >> >> [...] >> x86_64-linux-gnu-gcc -o fastboot -Wl,-z,relro bootimg.o engine.o fastboot.o >> protocol.o usb_linux.o util_linux.o centraldir.o zipfile.o backed_block.o >> sparse_crc32.o sparse.o sparse_read.o sparse_err.o output_file.o >> make_ext4fs.o crc16.o ext4_utils.o indirect.o allocate.o contents.o uuid.o >> extent.o wipe.o sha1.o -lz -lselinux >> file >> /srv/jenkins-slave/workspace/sid-goto-cc-android-tools/android-tools-4.2.2+git20130529/core/libsparse/sparse_crc32.h >> line 19: error: conflicting function declarations "sparse_crc32" >> old definition in module sparse_crc32 file >> /srv/jenkins-slave/workspace/sid-goto-cc-android-tools/android-tools-4.2.2+git20130529/core/libsparse/sparse_crc32.c >> line 101 >> unsigned int (unsigned int crc_in, const void *buf, signed int size) >> new definition in module sparse_read file >> /srv/jenkins-slave/workspace/sid-goto-cc-android-tools/android-tools-4.2.2+git20130529/core/libsparse/sparse_crc32.h >> line 19 >> unsigned int (unsigned int, const void *, unsigned long int) >> make[2]: *** [fastboot] Error 64 >> >> >> While the build does FTFBS with the standard compiler, as no type checking at >> link time would be performed, any call to sparse_crc32 will currently yield >> undefined results on big-endian systems. For all other systems it will start >> to >> fail as soon as any call actually passes in a long/size_t argument (at >> present, >> all arguments appear to be int or sufficiently small to fit into an int.) >> >> Best, >> Michael >> > > > > _______________________________________________ > Android-tools-devel mailing list > [email protected] > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel >
