| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gcc -fsanitize=undefined gives following warning.
include/pt-mbr.h:27:51: runtime error: left shift of 248 by 24 places cannot
be represented in type 'int'
It looks like char is converted internally to int before bit-shift, and that
type overflows when char value is greater than 127. Following code snippet
will show the effect what is stored when undefined behaviour happens.
#include <stdio.h>
#include <inttypes.h>
int main(int argc, unsigned char **argv)
{
char p[] = { 170, 170, 170, 170 };
unsigned int uint = p[3];
uint64_t res = 0;
/* overflow */
res = p[0] | (p[1] << 8) | (p[2] << 16) | (p[3] << 24);
printf("%" PRIu64 "\n", res);
/* this is fine */
res = 0;
res = p[0] | (p[1] << 8) | (p[2] << 16) | (uint << 24);
printf("%" PRIu64 "\n", res);
return 0;
}
I tested gcc 8.1.0, clang 6.0.0, and tcc 0.9.27 and they all printed the
same values.
$ ./a.out
18446744073709551530
4294967210
Because output is result of undefined behavior what is stored may change in
future, and other compilers / version might do something different. In the
case of what pt-mbr.h the destination data type size was commonly 32 bits in
size, that truncated excess rubbish from bitshift. Needless to say that was
not very robust code.
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
|
| |
|
|
|
|
|
|
| |
We assume that users will have a kernel >= 2.6.0 and removel
references to earlier kernels. There are still a few ones
left.
Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
./include/optutils.h:12:18: warning: null pointer dereference [-Wnull-dereference]
for (o = opts; o->name; o++)
~^~~~~~
In file included from libfdisk/src/dos.c:12:0:
./include/pt-mbr.h:25:47: warning: potential null pointer dereference [-Wnull-dereference]
return p[0] | (p[1] << 8) | (p[2] << 16) | (p[3] << 24);
~^~~
Well these should be impossible, so add assert() to catch possible bugs.
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I use Intel Rapid Start Technology on my PC. According to their User Guide
"Rapid_Start_Technology_User_Guide_v1.4.pdf" I create a partition with id=84
for hibernation by this Technology.
Unfortunately the software fdisk (util-linux-2.27) classifies that partition as
"OS/2 hidden C:". That is not wrong, but on website
https://en.wikipedia.org/wiki/Partition_type is written, that id 0x84 beside
using for hiding drive C: this type is a also used as hibernation partition for
Microsoft APM and also for Intel Rapid Start
So I patched 2 header files so that fdisk recognize this partition type variation.
Signed-off-by: Karel Zak <kzak@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
i used a partitioning+formatting tool product rufus 2.2. of
https://rufus.akeo.ie/ This software has an extra format option for older BIOS.
With this fix the main partition is created with some alignments and for the
remaining unallocated space a small extra and empty partition with
identification 0xEA is created.
On the List of partition identifiers for PCs at
http://www.win.tue.nl/~aeb/partitions/partition_types-1.html is is said that
there is a freedesktop proposal to use also type ea as boot partition
Unfortunately the software fdisk (util-linux-2.27) can not classify that
partition. I send for the fdisk program my 2 patches so that fdisk recognize
this partition type.
Signed-off-by: Karel Zak <kzak@redhat.com>
|
| |
|
|
| |
Signed-off-by: Karel Zak <kzak@redhat.com>
|
| |
|
|
|
|
| |
References: http://www.acronis.de/products/trueimage
Signed-off-by: Karel Zak <kzak@redhat.com>
Signed-off-by: Jörg Jenderek <joerg.jen.der.ek@gmx.net>
|
| |
|
|
| |
Signed-off-by: Karel Zak <kzak@redhat.com>
|
| |
|
|
| |
Signed-off-by: Karel Zak <kzak@redhat.com>
|
| |
|
|
|
|
|
| |
This makes struct dos_partition more compatible with the current fdisk
code.
Signed-off-by: Karel Zak <kzak@redhat.com>
|
| |
|
|
| |
Signed-off-by: Karel Zak <kzak@redhat.com>
|
| | |
|
|
|
Signed-off-by: Karel Zak <kzak@redhat.com>
|
