grub/grub-core/commands/setpci.c

341 lines
8.5 KiB
C
Raw Normal View History

2009-12-22 15:42:45 +00:00
/* lspci.c - List PCI devices. */
/*
* GRUB -- GRand Unified Bootloader
* Copyright (C) 2008, 2009 Free Software Foundation, Inc.
*
* GRUB is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* GRUB is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with GRUB. If not, see <http://www.gnu.org/licenses/>.
*/
#include <grub/pci.h>
#include <grub/dl.h>
#include <grub/misc.h>
#include <grub/extcmd.h>
#include <grub/env.h>
#include <grub/mm.h>
#include <grub/i18n.h>
2009-12-22 15:42:45 +00:00
GRUB_MOD_LICENSE ("GPLv3+");
2009-12-22 15:42:45 +00:00
struct pci_register
{
const char *name;
grub_uint16_t addr;
unsigned size;
};
static struct pci_register pci_registers[] =
2009-12-22 15:42:45 +00:00
{
{"VENDOR_ID", GRUB_PCI_REG_VENDOR , 2},
{"DEVICE_ID", GRUB_PCI_REG_DEVICE , 2},
{"COMMAND", GRUB_PCI_REG_COMMAND , 2},
{"STATUS", GRUB_PCI_REG_STATUS , 2},
{"REVISION", GRUB_PCI_REG_REVISION , 1},
{"CLASS_PROG", GRUB_PCI_REG_CLASS + 1 , 1},
{"CLASS_DEVICE", GRUB_PCI_REG_CLASS + 2 , 2},
{"CACHE_LINE_SIZE", GRUB_PCI_REG_CACHELINE , 1},
{"LATENCY_TIMER", GRUB_PCI_REG_LAT_TIMER , 1},
{"HEADER_TYPE", GRUB_PCI_REG_HEADER_TYPE , 1},
{"BIST", GRUB_PCI_REG_BIST , 1},
{"BASE_ADDRESS_0", GRUB_PCI_REG_ADDRESS_REG0, 4},
{"BASE_ADDRESS_1", GRUB_PCI_REG_ADDRESS_REG1, 4},
{"BASE_ADDRESS_2", GRUB_PCI_REG_ADDRESS_REG2, 4},
{"BASE_ADDRESS_3", GRUB_PCI_REG_ADDRESS_REG3, 4},
{"BASE_ADDRESS_4", GRUB_PCI_REG_ADDRESS_REG4, 4},
{"BASE_ADDRESS_5", GRUB_PCI_REG_ADDRESS_REG5, 4},
{"CARDBUS_CIS", GRUB_PCI_REG_CIS_POINTER , 4},
{"SUBVENDOR_ID", GRUB_PCI_REG_SUBVENDOR , 2},
{"SUBSYSTEM_ID", GRUB_PCI_REG_SUBSYSTEM , 2},
{"ROM_ADDRESS", GRUB_PCI_REG_ROM_ADDRESS , 4},
{"CAP_POINTER", GRUB_PCI_REG_CAP_POINTER , 1},
{"INTERRUPT_LINE", GRUB_PCI_REG_IRQ_LINE , 1},
{"INTERRUPT_PIN", GRUB_PCI_REG_IRQ_PIN , 1},
{"MIN_GNT", GRUB_PCI_REG_MIN_GNT , 1},
{"MAX_LAT", GRUB_PCI_REG_MIN_GNT , 1},
};
static const struct grub_arg_option options[] =
{
{0, 'd', 0, N_("Select device by vendor and device IDs."),
N_("[vendor]:[device]"), ARG_TYPE_STRING},
{0, 's', 0, N_("Select device by its position on the bus."),
N_("[bus]:[slot][.func]"), ARG_TYPE_STRING},
{0, 'v', 0, N_("Save read value into variable VARNAME."),
N_("VARNAME"), ARG_TYPE_STRING},
2009-12-22 15:42:45 +00:00
{0, 0, 0, 0, 0, 0}
};
static grub_uint32_t pciid_check_mask, pciid_check_value;
static int bus, device, function;
static int check_bus, check_device, check_function;
static grub_uint32_t write_mask, regwrite;
static int regsize;
static grub_uint16_t regaddr;
static const char *varname;
static int
grub_setpci_iter (grub_pci_device_t dev, grub_pci_id_t pciid,
void *data __attribute__ ((unused)))
2009-12-22 15:42:45 +00:00
{
grub_uint32_t regval = 0;
grub_pci_address_t addr;
if ((pciid & pciid_check_mask) != pciid_check_value)
return 0;
if (check_bus && grub_pci_get_bus (dev) != bus)
return 0;
if (check_device && grub_pci_get_device (dev) != device)
return 0;
if (check_function && grub_pci_get_function (dev) != function)
2009-12-22 15:42:45 +00:00
return 0;
addr = grub_pci_make_address (dev, regaddr);
switch (regsize)
{
case 1:
regval = grub_pci_read_byte (addr);
break;
case 2:
regval = grub_pci_read_word (addr);
break;
case 4:
regval = grub_pci_read (addr);
break;
}
if (varname)
{
char buf[sizeof ("XXXXXXXX")];
2010-01-20 19:54:58 +00:00
grub_snprintf (buf, sizeof (buf), "%x", regval);
2009-12-22 15:42:45 +00:00
grub_env_set (varname, buf);
return 1;
}
if (!write_mask)
{
grub_printf (_("Register %x of %x:%02x.%x is %x\n"), regaddr,
2009-12-22 15:42:45 +00:00
grub_pci_get_bus (dev),
grub_pci_get_device (dev),
grub_pci_get_function (dev),
regval);
return 0;
}
regval = (regval & ~write_mask) | regwrite;
switch (regsize)
{
case 1:
grub_pci_write_byte (addr, regval);
break;
case 2:
grub_pci_write_word (addr, regval);
break;
case 4:
grub_pci_write (addr, regval);
break;
}
return 0;
}
static grub_err_t
2010-06-10 06:42:03 +00:00
grub_cmd_setpci (grub_extcmd_context_t ctxt, int argc, char **argv)
2009-12-22 15:42:45 +00:00
{
const char *ptr;
unsigned i;
pciid_check_value = 0;
pciid_check_mask = 0;
2010-06-10 06:42:03 +00:00
if (ctxt->state[0].set)
2009-12-22 15:42:45 +00:00
{
2010-06-10 06:42:03 +00:00
ptr = ctxt->state[0].arg;
misc: Make grub_strtol() "end" pointers have safer const qualifiers Currently the string functions grub_strtol(), grub_strtoul(), and grub_strtoull() don't declare the "end" pointer in such a way as to require the pointer itself or the character array to be immutable to the implementation, nor does the C standard do so in its similar functions, though it does require us not to change any of it. The typical declarations of these functions follow this pattern: long strtol(const char * restrict nptr, char ** restrict endptr, int base); Much of the reason for this is historic, and a discussion of that follows below, after the explanation of this change. (GRUB currently does not include the "restrict" qualifiers, and we name the arguments a bit differently.) The implementation is semantically required to treat the character array as immutable, but such accidental modifications aren't stopped by the compiler, and the semantics for both the callers and the implementation of these functions are sometimes also helped by adding that requirement. This patch changes these declarations to follow this pattern instead: long strtol(const char * restrict nptr, const char ** const restrict endptr, int base); This means that if any modification to these functions accidentally introduces either an errant modification to the underlying character array, or an accidental assignment to endptr rather than *endptr, the compiler should generate an error. (The two uses of "restrict" in this case basically mean strtol() isn't allowed to modify the character array by going through *endptr, and endptr isn't allowed to point inside the array.) It also means the typical use case changes to: char *s = ...; const char *end; long l; l = strtol(s, &end, 10); Or even: const char *p = str; while (p && *p) { long l = strtol(p, &p, 10); ... } This fixes 26 places where we discard our attempts at treating the data safely by doing: const char *p = str; long l; l = strtol(p, (char **)&ptr, 10); It also adds 5 places where we do: char *p = str; while (p && *p) { long l = strtol(p, (const char ** const)&p, 10); ... /* more calls that need p not to be pointer-to-const */ } While moderately distasteful, this is a better problem to have. With one minor exception, I have tested that all of this compiles without relevant warnings or errors, and that /much/ of it behaves correctly, with gcc 9 using 'gcc -W -Wall -Wextra'. The one exception is the changes in grub-core/osdep/aros/hostdisk.c , which I have no idea how to build. Because the C standard defined type-qualifiers in a way that can be confusing, in the past there's been a slow but fairly regular stream of churn within our patches, which add and remove the const qualifier in many of the users of these functions. This change should help avoid that in the future, and in order to help ensure this, I've added an explanation in misc.h so that when someone does get a compiler warning about a type error, they have the fix at hand. The reason we don't have "const" in these calls in the standard is purely anachronistic: C78 (de facto) did not have type qualifiers in the syntax, and the "const" type qualifier was added for C89 (I think; it may have been later). strtol() appears to date from 4.3BSD in 1986, which means it could not be added to those functions in the standard without breaking compatibility, which is usually avoided. The syntax chosen for type qualifiers is what has led to the churn regarding usage of const, and is especially confusing on string functions due to the lack of a string type. Quoting from C99, the syntax is: declarator: pointer[opt] direct-declarator direct-declarator: identifier ( declarator ) direct-declarator [ type-qualifier-list[opt] assignment-expression[opt] ] ... direct-declarator [ type-qualifier-list[opt] * ] ... pointer: * type-qualifier-list[opt] * type-qualifier-list[opt] pointer type-qualifier-list: type-qualifier type-qualifier-list type-qualifier ... type-qualifier: const restrict volatile So the examples go like: const char foo; // immutable object const char *foo; // mutable pointer to object char * const foo; // immutable pointer to mutable object const char * const foo; // immutable pointer to immutable object const char const * const foo; // XXX extra const keyword in the middle const char * const * const foo; // immutable pointer to immutable // pointer to immutable object const char ** const foo; // immutable pointer to mutable pointer // to immutable object Making const left-associative for * and right-associative for everything else may not have been the best choice ever, but here we are, and the inevitable result is people using trying to use const (as they should!), putting it at the wrong place, fighting with the compiler for a bit, and then either removing it or typecasting something in a bad way. I won't go into describing restrict, but its syntax has exactly the same issue as with const. Anyway, the last example above actually represents the *behavior* that's required of strtol()-like functions, so that's our choice for the "end" pointer. Signed-off-by: Peter Jones <pjones@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
2020-02-21 21:39:33 +00:00
pciid_check_value |= (grub_strtoul (ptr, &ptr, 16) & 0xffff);
2009-12-22 15:42:45 +00:00
if (grub_errno == GRUB_ERR_BAD_NUMBER)
{
grub_errno = GRUB_ERR_NONE;
2010-06-10 06:42:03 +00:00
ptr = ctxt->state[0].arg;
2009-12-22 15:42:45 +00:00
}
else
pciid_check_mask |= 0xffff;
if (grub_errno)
return grub_errno;
if (*ptr != ':')
return grub_error (GRUB_ERR_BAD_ARGUMENT, N_("missing `%c' symbol"), ':');
2009-12-22 15:42:45 +00:00
ptr++;
misc: Make grub_strtol() "end" pointers have safer const qualifiers Currently the string functions grub_strtol(), grub_strtoul(), and grub_strtoull() don't declare the "end" pointer in such a way as to require the pointer itself or the character array to be immutable to the implementation, nor does the C standard do so in its similar functions, though it does require us not to change any of it. The typical declarations of these functions follow this pattern: long strtol(const char * restrict nptr, char ** restrict endptr, int base); Much of the reason for this is historic, and a discussion of that follows below, after the explanation of this change. (GRUB currently does not include the "restrict" qualifiers, and we name the arguments a bit differently.) The implementation is semantically required to treat the character array as immutable, but such accidental modifications aren't stopped by the compiler, and the semantics for both the callers and the implementation of these functions are sometimes also helped by adding that requirement. This patch changes these declarations to follow this pattern instead: long strtol(const char * restrict nptr, const char ** const restrict endptr, int base); This means that if any modification to these functions accidentally introduces either an errant modification to the underlying character array, or an accidental assignment to endptr rather than *endptr, the compiler should generate an error. (The two uses of "restrict" in this case basically mean strtol() isn't allowed to modify the character array by going through *endptr, and endptr isn't allowed to point inside the array.) It also means the typical use case changes to: char *s = ...; const char *end; long l; l = strtol(s, &end, 10); Or even: const char *p = str; while (p && *p) { long l = strtol(p, &p, 10); ... } This fixes 26 places where we discard our attempts at treating the data safely by doing: const char *p = str; long l; l = strtol(p, (char **)&ptr, 10); It also adds 5 places where we do: char *p = str; while (p && *p) { long l = strtol(p, (const char ** const)&p, 10); ... /* more calls that need p not to be pointer-to-const */ } While moderately distasteful, this is a better problem to have. With one minor exception, I have tested that all of this compiles without relevant warnings or errors, and that /much/ of it behaves correctly, with gcc 9 using 'gcc -W -Wall -Wextra'. The one exception is the changes in grub-core/osdep/aros/hostdisk.c , which I have no idea how to build. Because the C standard defined type-qualifiers in a way that can be confusing, in the past there's been a slow but fairly regular stream of churn within our patches, which add and remove the const qualifier in many of the users of these functions. This change should help avoid that in the future, and in order to help ensure this, I've added an explanation in misc.h so that when someone does get a compiler warning about a type error, they have the fix at hand. The reason we don't have "const" in these calls in the standard is purely anachronistic: C78 (de facto) did not have type qualifiers in the syntax, and the "const" type qualifier was added for C89 (I think; it may have been later). strtol() appears to date from 4.3BSD in 1986, which means it could not be added to those functions in the standard without breaking compatibility, which is usually avoided. The syntax chosen for type qualifiers is what has led to the churn regarding usage of const, and is especially confusing on string functions due to the lack of a string type. Quoting from C99, the syntax is: declarator: pointer[opt] direct-declarator direct-declarator: identifier ( declarator ) direct-declarator [ type-qualifier-list[opt] assignment-expression[opt] ] ... direct-declarator [ type-qualifier-list[opt] * ] ... pointer: * type-qualifier-list[opt] * type-qualifier-list[opt] pointer type-qualifier-list: type-qualifier type-qualifier-list type-qualifier ... type-qualifier: const restrict volatile So the examples go like: const char foo; // immutable object const char *foo; // mutable pointer to object char * const foo; // immutable pointer to mutable object const char * const foo; // immutable pointer to immutable object const char const * const foo; // XXX extra const keyword in the middle const char * const * const foo; // immutable pointer to immutable // pointer to immutable object const char ** const foo; // immutable pointer to mutable pointer // to immutable object Making const left-associative for * and right-associative for everything else may not have been the best choice ever, but here we are, and the inevitable result is people using trying to use const (as they should!), putting it at the wrong place, fighting with the compiler for a bit, and then either removing it or typecasting something in a bad way. I won't go into describing restrict, but its syntax has exactly the same issue as with const. Anyway, the last example above actually represents the *behavior* that's required of strtol()-like functions, so that's our choice for the "end" pointer. Signed-off-by: Peter Jones <pjones@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
2020-02-21 21:39:33 +00:00
pciid_check_value |= (grub_strtoul (ptr, &ptr, 16) & 0xffff) << 16;
2009-12-22 15:42:45 +00:00
if (grub_errno == GRUB_ERR_BAD_NUMBER)
grub_errno = GRUB_ERR_NONE;
else
pciid_check_mask |= 0xffff0000;
}
pciid_check_value &= pciid_check_mask;
check_bus = check_device = check_function = 0;
2010-06-10 06:42:03 +00:00
if (ctxt->state[1].set)
2009-12-22 15:42:45 +00:00
{
const char *optr;
misc: Make grub_strtol() "end" pointers have safer const qualifiers Currently the string functions grub_strtol(), grub_strtoul(), and grub_strtoull() don't declare the "end" pointer in such a way as to require the pointer itself or the character array to be immutable to the implementation, nor does the C standard do so in its similar functions, though it does require us not to change any of it. The typical declarations of these functions follow this pattern: long strtol(const char * restrict nptr, char ** restrict endptr, int base); Much of the reason for this is historic, and a discussion of that follows below, after the explanation of this change. (GRUB currently does not include the "restrict" qualifiers, and we name the arguments a bit differently.) The implementation is semantically required to treat the character array as immutable, but such accidental modifications aren't stopped by the compiler, and the semantics for both the callers and the implementation of these functions are sometimes also helped by adding that requirement. This patch changes these declarations to follow this pattern instead: long strtol(const char * restrict nptr, const char ** const restrict endptr, int base); This means that if any modification to these functions accidentally introduces either an errant modification to the underlying character array, or an accidental assignment to endptr rather than *endptr, the compiler should generate an error. (The two uses of "restrict" in this case basically mean strtol() isn't allowed to modify the character array by going through *endptr, and endptr isn't allowed to point inside the array.) It also means the typical use case changes to: char *s = ...; const char *end; long l; l = strtol(s, &end, 10); Or even: const char *p = str; while (p && *p) { long l = strtol(p, &p, 10); ... } This fixes 26 places where we discard our attempts at treating the data safely by doing: const char *p = str; long l; l = strtol(p, (char **)&ptr, 10); It also adds 5 places where we do: char *p = str; while (p && *p) { long l = strtol(p, (const char ** const)&p, 10); ... /* more calls that need p not to be pointer-to-const */ } While moderately distasteful, this is a better problem to have. With one minor exception, I have tested that all of this compiles without relevant warnings or errors, and that /much/ of it behaves correctly, with gcc 9 using 'gcc -W -Wall -Wextra'. The one exception is the changes in grub-core/osdep/aros/hostdisk.c , which I have no idea how to build. Because the C standard defined type-qualifiers in a way that can be confusing, in the past there's been a slow but fairly regular stream of churn within our patches, which add and remove the const qualifier in many of the users of these functions. This change should help avoid that in the future, and in order to help ensure this, I've added an explanation in misc.h so that when someone does get a compiler warning about a type error, they have the fix at hand. The reason we don't have "const" in these calls in the standard is purely anachronistic: C78 (de facto) did not have type qualifiers in the syntax, and the "const" type qualifier was added for C89 (I think; it may have been later). strtol() appears to date from 4.3BSD in 1986, which means it could not be added to those functions in the standard without breaking compatibility, which is usually avoided. The syntax chosen for type qualifiers is what has led to the churn regarding usage of const, and is especially confusing on string functions due to the lack of a string type. Quoting from C99, the syntax is: declarator: pointer[opt] direct-declarator direct-declarator: identifier ( declarator ) direct-declarator [ type-qualifier-list[opt] assignment-expression[opt] ] ... direct-declarator [ type-qualifier-list[opt] * ] ... pointer: * type-qualifier-list[opt] * type-qualifier-list[opt] pointer type-qualifier-list: type-qualifier type-qualifier-list type-qualifier ... type-qualifier: const restrict volatile So the examples go like: const char foo; // immutable object const char *foo; // mutable pointer to object char * const foo; // immutable pointer to mutable object const char * const foo; // immutable pointer to immutable object const char const * const foo; // XXX extra const keyword in the middle const char * const * const foo; // immutable pointer to immutable // pointer to immutable object const char ** const foo; // immutable pointer to mutable pointer // to immutable object Making const left-associative for * and right-associative for everything else may not have been the best choice ever, but here we are, and the inevitable result is people using trying to use const (as they should!), putting it at the wrong place, fighting with the compiler for a bit, and then either removing it or typecasting something in a bad way. I won't go into describing restrict, but its syntax has exactly the same issue as with const. Anyway, the last example above actually represents the *behavior* that's required of strtol()-like functions, so that's our choice for the "end" pointer. Signed-off-by: Peter Jones <pjones@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
2020-02-21 21:39:33 +00:00
2010-06-10 06:42:03 +00:00
ptr = ctxt->state[1].arg;
2009-12-22 15:42:45 +00:00
optr = ptr;
misc: Make grub_strtol() "end" pointers have safer const qualifiers Currently the string functions grub_strtol(), grub_strtoul(), and grub_strtoull() don't declare the "end" pointer in such a way as to require the pointer itself or the character array to be immutable to the implementation, nor does the C standard do so in its similar functions, though it does require us not to change any of it. The typical declarations of these functions follow this pattern: long strtol(const char * restrict nptr, char ** restrict endptr, int base); Much of the reason for this is historic, and a discussion of that follows below, after the explanation of this change. (GRUB currently does not include the "restrict" qualifiers, and we name the arguments a bit differently.) The implementation is semantically required to treat the character array as immutable, but such accidental modifications aren't stopped by the compiler, and the semantics for both the callers and the implementation of these functions are sometimes also helped by adding that requirement. This patch changes these declarations to follow this pattern instead: long strtol(const char * restrict nptr, const char ** const restrict endptr, int base); This means that if any modification to these functions accidentally introduces either an errant modification to the underlying character array, or an accidental assignment to endptr rather than *endptr, the compiler should generate an error. (The two uses of "restrict" in this case basically mean strtol() isn't allowed to modify the character array by going through *endptr, and endptr isn't allowed to point inside the array.) It also means the typical use case changes to: char *s = ...; const char *end; long l; l = strtol(s, &end, 10); Or even: const char *p = str; while (p && *p) { long l = strtol(p, &p, 10); ... } This fixes 26 places where we discard our attempts at treating the data safely by doing: const char *p = str; long l; l = strtol(p, (char **)&ptr, 10); It also adds 5 places where we do: char *p = str; while (p && *p) { long l = strtol(p, (const char ** const)&p, 10); ... /* more calls that need p not to be pointer-to-const */ } While moderately distasteful, this is a better problem to have. With one minor exception, I have tested that all of this compiles without relevant warnings or errors, and that /much/ of it behaves correctly, with gcc 9 using 'gcc -W -Wall -Wextra'. The one exception is the changes in grub-core/osdep/aros/hostdisk.c , which I have no idea how to build. Because the C standard defined type-qualifiers in a way that can be confusing, in the past there's been a slow but fairly regular stream of churn within our patches, which add and remove the const qualifier in many of the users of these functions. This change should help avoid that in the future, and in order to help ensure this, I've added an explanation in misc.h so that when someone does get a compiler warning about a type error, they have the fix at hand. The reason we don't have "const" in these calls in the standard is purely anachronistic: C78 (de facto) did not have type qualifiers in the syntax, and the "const" type qualifier was added for C89 (I think; it may have been later). strtol() appears to date from 4.3BSD in 1986, which means it could not be added to those functions in the standard without breaking compatibility, which is usually avoided. The syntax chosen for type qualifiers is what has led to the churn regarding usage of const, and is especially confusing on string functions due to the lack of a string type. Quoting from C99, the syntax is: declarator: pointer[opt] direct-declarator direct-declarator: identifier ( declarator ) direct-declarator [ type-qualifier-list[opt] assignment-expression[opt] ] ... direct-declarator [ type-qualifier-list[opt] * ] ... pointer: * type-qualifier-list[opt] * type-qualifier-list[opt] pointer type-qualifier-list: type-qualifier type-qualifier-list type-qualifier ... type-qualifier: const restrict volatile So the examples go like: const char foo; // immutable object const char *foo; // mutable pointer to object char * const foo; // immutable pointer to mutable object const char * const foo; // immutable pointer to immutable object const char const * const foo; // XXX extra const keyword in the middle const char * const * const foo; // immutable pointer to immutable // pointer to immutable object const char ** const foo; // immutable pointer to mutable pointer // to immutable object Making const left-associative for * and right-associative for everything else may not have been the best choice ever, but here we are, and the inevitable result is people using trying to use const (as they should!), putting it at the wrong place, fighting with the compiler for a bit, and then either removing it or typecasting something in a bad way. I won't go into describing restrict, but its syntax has exactly the same issue as with const. Anyway, the last example above actually represents the *behavior* that's required of strtol()-like functions, so that's our choice for the "end" pointer. Signed-off-by: Peter Jones <pjones@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
2020-02-21 21:39:33 +00:00
bus = grub_strtoul (ptr, &ptr, 16);
2009-12-22 15:42:45 +00:00
if (grub_errno == GRUB_ERR_BAD_NUMBER)
{
grub_errno = GRUB_ERR_NONE;
ptr = optr;
}
else
check_bus = 1;
if (grub_errno)
return grub_errno;
if (*ptr != ':')
return grub_error (GRUB_ERR_BAD_ARGUMENT, N_("missing `%c' symbol"), ':');
2009-12-22 15:42:45 +00:00
ptr++;
optr = ptr;
misc: Make grub_strtol() "end" pointers have safer const qualifiers Currently the string functions grub_strtol(), grub_strtoul(), and grub_strtoull() don't declare the "end" pointer in such a way as to require the pointer itself or the character array to be immutable to the implementation, nor does the C standard do so in its similar functions, though it does require us not to change any of it. The typical declarations of these functions follow this pattern: long strtol(const char * restrict nptr, char ** restrict endptr, int base); Much of the reason for this is historic, and a discussion of that follows below, after the explanation of this change. (GRUB currently does not include the "restrict" qualifiers, and we name the arguments a bit differently.) The implementation is semantically required to treat the character array as immutable, but such accidental modifications aren't stopped by the compiler, and the semantics for both the callers and the implementation of these functions are sometimes also helped by adding that requirement. This patch changes these declarations to follow this pattern instead: long strtol(const char * restrict nptr, const char ** const restrict endptr, int base); This means that if any modification to these functions accidentally introduces either an errant modification to the underlying character array, or an accidental assignment to endptr rather than *endptr, the compiler should generate an error. (The two uses of "restrict" in this case basically mean strtol() isn't allowed to modify the character array by going through *endptr, and endptr isn't allowed to point inside the array.) It also means the typical use case changes to: char *s = ...; const char *end; long l; l = strtol(s, &end, 10); Or even: const char *p = str; while (p && *p) { long l = strtol(p, &p, 10); ... } This fixes 26 places where we discard our attempts at treating the data safely by doing: const char *p = str; long l; l = strtol(p, (char **)&ptr, 10); It also adds 5 places where we do: char *p = str; while (p && *p) { long l = strtol(p, (const char ** const)&p, 10); ... /* more calls that need p not to be pointer-to-const */ } While moderately distasteful, this is a better problem to have. With one minor exception, I have tested that all of this compiles without relevant warnings or errors, and that /much/ of it behaves correctly, with gcc 9 using 'gcc -W -Wall -Wextra'. The one exception is the changes in grub-core/osdep/aros/hostdisk.c , which I have no idea how to build. Because the C standard defined type-qualifiers in a way that can be confusing, in the past there's been a slow but fairly regular stream of churn within our patches, which add and remove the const qualifier in many of the users of these functions. This change should help avoid that in the future, and in order to help ensure this, I've added an explanation in misc.h so that when someone does get a compiler warning about a type error, they have the fix at hand. The reason we don't have "const" in these calls in the standard is purely anachronistic: C78 (de facto) did not have type qualifiers in the syntax, and the "const" type qualifier was added for C89 (I think; it may have been later). strtol() appears to date from 4.3BSD in 1986, which means it could not be added to those functions in the standard without breaking compatibility, which is usually avoided. The syntax chosen for type qualifiers is what has led to the churn regarding usage of const, and is especially confusing on string functions due to the lack of a string type. Quoting from C99, the syntax is: declarator: pointer[opt] direct-declarator direct-declarator: identifier ( declarator ) direct-declarator [ type-qualifier-list[opt] assignment-expression[opt] ] ... direct-declarator [ type-qualifier-list[opt] * ] ... pointer: * type-qualifier-list[opt] * type-qualifier-list[opt] pointer type-qualifier-list: type-qualifier type-qualifier-list type-qualifier ... type-qualifier: const restrict volatile So the examples go like: const char foo; // immutable object const char *foo; // mutable pointer to object char * const foo; // immutable pointer to mutable object const char * const foo; // immutable pointer to immutable object const char const * const foo; // XXX extra const keyword in the middle const char * const * const foo; // immutable pointer to immutable // pointer to immutable object const char ** const foo; // immutable pointer to mutable pointer // to immutable object Making const left-associative for * and right-associative for everything else may not have been the best choice ever, but here we are, and the inevitable result is people using trying to use const (as they should!), putting it at the wrong place, fighting with the compiler for a bit, and then either removing it or typecasting something in a bad way. I won't go into describing restrict, but its syntax has exactly the same issue as with const. Anyway, the last example above actually represents the *behavior* that's required of strtol()-like functions, so that's our choice for the "end" pointer. Signed-off-by: Peter Jones <pjones@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
2020-02-21 21:39:33 +00:00
device = grub_strtoul (ptr, &ptr, 16);
2009-12-22 15:42:45 +00:00
if (grub_errno == GRUB_ERR_BAD_NUMBER)
{
grub_errno = GRUB_ERR_NONE;
ptr = optr;
}
else
check_device = 1;
if (*ptr == '.')
{
ptr++;
misc: Make grub_strtol() "end" pointers have safer const qualifiers Currently the string functions grub_strtol(), grub_strtoul(), and grub_strtoull() don't declare the "end" pointer in such a way as to require the pointer itself or the character array to be immutable to the implementation, nor does the C standard do so in its similar functions, though it does require us not to change any of it. The typical declarations of these functions follow this pattern: long strtol(const char * restrict nptr, char ** restrict endptr, int base); Much of the reason for this is historic, and a discussion of that follows below, after the explanation of this change. (GRUB currently does not include the "restrict" qualifiers, and we name the arguments a bit differently.) The implementation is semantically required to treat the character array as immutable, but such accidental modifications aren't stopped by the compiler, and the semantics for both the callers and the implementation of these functions are sometimes also helped by adding that requirement. This patch changes these declarations to follow this pattern instead: long strtol(const char * restrict nptr, const char ** const restrict endptr, int base); This means that if any modification to these functions accidentally introduces either an errant modification to the underlying character array, or an accidental assignment to endptr rather than *endptr, the compiler should generate an error. (The two uses of "restrict" in this case basically mean strtol() isn't allowed to modify the character array by going through *endptr, and endptr isn't allowed to point inside the array.) It also means the typical use case changes to: char *s = ...; const char *end; long l; l = strtol(s, &end, 10); Or even: const char *p = str; while (p && *p) { long l = strtol(p, &p, 10); ... } This fixes 26 places where we discard our attempts at treating the data safely by doing: const char *p = str; long l; l = strtol(p, (char **)&ptr, 10); It also adds 5 places where we do: char *p = str; while (p && *p) { long l = strtol(p, (const char ** const)&p, 10); ... /* more calls that need p not to be pointer-to-const */ } While moderately distasteful, this is a better problem to have. With one minor exception, I have tested that all of this compiles without relevant warnings or errors, and that /much/ of it behaves correctly, with gcc 9 using 'gcc -W -Wall -Wextra'. The one exception is the changes in grub-core/osdep/aros/hostdisk.c , which I have no idea how to build. Because the C standard defined type-qualifiers in a way that can be confusing, in the past there's been a slow but fairly regular stream of churn within our patches, which add and remove the const qualifier in many of the users of these functions. This change should help avoid that in the future, and in order to help ensure this, I've added an explanation in misc.h so that when someone does get a compiler warning about a type error, they have the fix at hand. The reason we don't have "const" in these calls in the standard is purely anachronistic: C78 (de facto) did not have type qualifiers in the syntax, and the "const" type qualifier was added for C89 (I think; it may have been later). strtol() appears to date from 4.3BSD in 1986, which means it could not be added to those functions in the standard without breaking compatibility, which is usually avoided. The syntax chosen for type qualifiers is what has led to the churn regarding usage of const, and is especially confusing on string functions due to the lack of a string type. Quoting from C99, the syntax is: declarator: pointer[opt] direct-declarator direct-declarator: identifier ( declarator ) direct-declarator [ type-qualifier-list[opt] assignment-expression[opt] ] ... direct-declarator [ type-qualifier-list[opt] * ] ... pointer: * type-qualifier-list[opt] * type-qualifier-list[opt] pointer type-qualifier-list: type-qualifier type-qualifier-list type-qualifier ... type-qualifier: const restrict volatile So the examples go like: const char foo; // immutable object const char *foo; // mutable pointer to object char * const foo; // immutable pointer to mutable object const char * const foo; // immutable pointer to immutable object const char const * const foo; // XXX extra const keyword in the middle const char * const * const foo; // immutable pointer to immutable // pointer to immutable object const char ** const foo; // immutable pointer to mutable pointer // to immutable object Making const left-associative for * and right-associative for everything else may not have been the best choice ever, but here we are, and the inevitable result is people using trying to use const (as they should!), putting it at the wrong place, fighting with the compiler for a bit, and then either removing it or typecasting something in a bad way. I won't go into describing restrict, but its syntax has exactly the same issue as with const. Anyway, the last example above actually represents the *behavior* that's required of strtol()-like functions, so that's our choice for the "end" pointer. Signed-off-by: Peter Jones <pjones@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
2020-02-21 21:39:33 +00:00
function = grub_strtoul (ptr, &ptr, 16);
2009-12-22 15:42:45 +00:00
if (grub_errno)
return grub_errno;
check_function = 1;
}
}
2010-06-10 06:42:03 +00:00
if (ctxt->state[2].set)
varname = ctxt->state[2].arg;
2009-12-22 15:42:45 +00:00
else
varname = NULL;
write_mask = 0;
if (argc != 1)
return grub_error (GRUB_ERR_BAD_ARGUMENT, N_("one argument expected"));
2009-12-22 15:42:45 +00:00
ptr = argv[0];
for (i = 0; i < ARRAY_SIZE (pci_registers); i++)
{
if (grub_strncmp (ptr, pci_registers[i].name,
grub_strlen (pci_registers[i].name)) == 0)
break;
}
if (i == ARRAY_SIZE (pci_registers))
{
regsize = 0;
misc: Make grub_strtol() "end" pointers have safer const qualifiers Currently the string functions grub_strtol(), grub_strtoul(), and grub_strtoull() don't declare the "end" pointer in such a way as to require the pointer itself or the character array to be immutable to the implementation, nor does the C standard do so in its similar functions, though it does require us not to change any of it. The typical declarations of these functions follow this pattern: long strtol(const char * restrict nptr, char ** restrict endptr, int base); Much of the reason for this is historic, and a discussion of that follows below, after the explanation of this change. (GRUB currently does not include the "restrict" qualifiers, and we name the arguments a bit differently.) The implementation is semantically required to treat the character array as immutable, but such accidental modifications aren't stopped by the compiler, and the semantics for both the callers and the implementation of these functions are sometimes also helped by adding that requirement. This patch changes these declarations to follow this pattern instead: long strtol(const char * restrict nptr, const char ** const restrict endptr, int base); This means that if any modification to these functions accidentally introduces either an errant modification to the underlying character array, or an accidental assignment to endptr rather than *endptr, the compiler should generate an error. (The two uses of "restrict" in this case basically mean strtol() isn't allowed to modify the character array by going through *endptr, and endptr isn't allowed to point inside the array.) It also means the typical use case changes to: char *s = ...; const char *end; long l; l = strtol(s, &end, 10); Or even: const char *p = str; while (p && *p) { long l = strtol(p, &p, 10); ... } This fixes 26 places where we discard our attempts at treating the data safely by doing: const char *p = str; long l; l = strtol(p, (char **)&ptr, 10); It also adds 5 places where we do: char *p = str; while (p && *p) { long l = strtol(p, (const char ** const)&p, 10); ... /* more calls that need p not to be pointer-to-const */ } While moderately distasteful, this is a better problem to have. With one minor exception, I have tested that all of this compiles without relevant warnings or errors, and that /much/ of it behaves correctly, with gcc 9 using 'gcc -W -Wall -Wextra'. The one exception is the changes in grub-core/osdep/aros/hostdisk.c , which I have no idea how to build. Because the C standard defined type-qualifiers in a way that can be confusing, in the past there's been a slow but fairly regular stream of churn within our patches, which add and remove the const qualifier in many of the users of these functions. This change should help avoid that in the future, and in order to help ensure this, I've added an explanation in misc.h so that when someone does get a compiler warning about a type error, they have the fix at hand. The reason we don't have "const" in these calls in the standard is purely anachronistic: C78 (de facto) did not have type qualifiers in the syntax, and the "const" type qualifier was added for C89 (I think; it may have been later). strtol() appears to date from 4.3BSD in 1986, which means it could not be added to those functions in the standard without breaking compatibility, which is usually avoided. The syntax chosen for type qualifiers is what has led to the churn regarding usage of const, and is especially confusing on string functions due to the lack of a string type. Quoting from C99, the syntax is: declarator: pointer[opt] direct-declarator direct-declarator: identifier ( declarator ) direct-declarator [ type-qualifier-list[opt] assignment-expression[opt] ] ... direct-declarator [ type-qualifier-list[opt] * ] ... pointer: * type-qualifier-list[opt] * type-qualifier-list[opt] pointer type-qualifier-list: type-qualifier type-qualifier-list type-qualifier ... type-qualifier: const restrict volatile So the examples go like: const char foo; // immutable object const char *foo; // mutable pointer to object char * const foo; // immutable pointer to mutable object const char * const foo; // immutable pointer to immutable object const char const * const foo; // XXX extra const keyword in the middle const char * const * const foo; // immutable pointer to immutable // pointer to immutable object const char ** const foo; // immutable pointer to mutable pointer // to immutable object Making const left-associative for * and right-associative for everything else may not have been the best choice ever, but here we are, and the inevitable result is people using trying to use const (as they should!), putting it at the wrong place, fighting with the compiler for a bit, and then either removing it or typecasting something in a bad way. I won't go into describing restrict, but its syntax has exactly the same issue as with const. Anyway, the last example above actually represents the *behavior* that's required of strtol()-like functions, so that's our choice for the "end" pointer. Signed-off-by: Peter Jones <pjones@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
2020-02-21 21:39:33 +00:00
regaddr = grub_strtoul (ptr, &ptr, 16);
2009-12-22 15:42:45 +00:00
if (grub_errno)
return grub_error (GRUB_ERR_BAD_ARGUMENT, "unknown register");
2009-12-22 15:42:45 +00:00
}
else
{
regaddr = pci_registers[i].addr;
regsize = pci_registers[i].size;
ptr += grub_strlen (pci_registers[i].name);
}
if (grub_errno)
return grub_errno;
if (*ptr == '+')
{
ptr++;
misc: Make grub_strtol() "end" pointers have safer const qualifiers Currently the string functions grub_strtol(), grub_strtoul(), and grub_strtoull() don't declare the "end" pointer in such a way as to require the pointer itself or the character array to be immutable to the implementation, nor does the C standard do so in its similar functions, though it does require us not to change any of it. The typical declarations of these functions follow this pattern: long strtol(const char * restrict nptr, char ** restrict endptr, int base); Much of the reason for this is historic, and a discussion of that follows below, after the explanation of this change. (GRUB currently does not include the "restrict" qualifiers, and we name the arguments a bit differently.) The implementation is semantically required to treat the character array as immutable, but such accidental modifications aren't stopped by the compiler, and the semantics for both the callers and the implementation of these functions are sometimes also helped by adding that requirement. This patch changes these declarations to follow this pattern instead: long strtol(const char * restrict nptr, const char ** const restrict endptr, int base); This means that if any modification to these functions accidentally introduces either an errant modification to the underlying character array, or an accidental assignment to endptr rather than *endptr, the compiler should generate an error. (The two uses of "restrict" in this case basically mean strtol() isn't allowed to modify the character array by going through *endptr, and endptr isn't allowed to point inside the array.) It also means the typical use case changes to: char *s = ...; const char *end; long l; l = strtol(s, &end, 10); Or even: const char *p = str; while (p && *p) { long l = strtol(p, &p, 10); ... } This fixes 26 places where we discard our attempts at treating the data safely by doing: const char *p = str; long l; l = strtol(p, (char **)&ptr, 10); It also adds 5 places where we do: char *p = str; while (p && *p) { long l = strtol(p, (const char ** const)&p, 10); ... /* more calls that need p not to be pointer-to-const */ } While moderately distasteful, this is a better problem to have. With one minor exception, I have tested that all of this compiles without relevant warnings or errors, and that /much/ of it behaves correctly, with gcc 9 using 'gcc -W -Wall -Wextra'. The one exception is the changes in grub-core/osdep/aros/hostdisk.c , which I have no idea how to build. Because the C standard defined type-qualifiers in a way that can be confusing, in the past there's been a slow but fairly regular stream of churn within our patches, which add and remove the const qualifier in many of the users of these functions. This change should help avoid that in the future, and in order to help ensure this, I've added an explanation in misc.h so that when someone does get a compiler warning about a type error, they have the fix at hand. The reason we don't have "const" in these calls in the standard is purely anachronistic: C78 (de facto) did not have type qualifiers in the syntax, and the "const" type qualifier was added for C89 (I think; it may have been later). strtol() appears to date from 4.3BSD in 1986, which means it could not be added to those functions in the standard without breaking compatibility, which is usually avoided. The syntax chosen for type qualifiers is what has led to the churn regarding usage of const, and is especially confusing on string functions due to the lack of a string type. Quoting from C99, the syntax is: declarator: pointer[opt] direct-declarator direct-declarator: identifier ( declarator ) direct-declarator [ type-qualifier-list[opt] assignment-expression[opt] ] ... direct-declarator [ type-qualifier-list[opt] * ] ... pointer: * type-qualifier-list[opt] * type-qualifier-list[opt] pointer type-qualifier-list: type-qualifier type-qualifier-list type-qualifier ... type-qualifier: const restrict volatile So the examples go like: const char foo; // immutable object const char *foo; // mutable pointer to object char * const foo; // immutable pointer to mutable object const char * const foo; // immutable pointer to immutable object const char const * const foo; // XXX extra const keyword in the middle const char * const * const foo; // immutable pointer to immutable // pointer to immutable object const char ** const foo; // immutable pointer to mutable pointer // to immutable object Making const left-associative for * and right-associative for everything else may not have been the best choice ever, but here we are, and the inevitable result is people using trying to use const (as they should!), putting it at the wrong place, fighting with the compiler for a bit, and then either removing it or typecasting something in a bad way. I won't go into describing restrict, but its syntax has exactly the same issue as with const. Anyway, the last example above actually represents the *behavior* that's required of strtol()-like functions, so that's our choice for the "end" pointer. Signed-off-by: Peter Jones <pjones@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
2020-02-21 21:39:33 +00:00
regaddr += grub_strtoul (ptr, &ptr, 16);
2009-12-22 15:42:45 +00:00
if (grub_errno)
return grub_errno;
}
if (grub_memcmp (ptr, ".L", sizeof (".L") - 1) == 0
|| grub_memcmp (ptr, ".l", sizeof (".l") - 1) == 0)
{
regsize = 4;
ptr += sizeof (".l") - 1;
}
else if (grub_memcmp (ptr, ".W", sizeof (".W") - 1) == 0
|| grub_memcmp (ptr, ".w", sizeof (".w") - 1) == 0)
{
regsize = 2;
ptr += sizeof (".w") - 1;
}
else if (grub_memcmp (ptr, ".B", sizeof (".B") - 1) == 0
|| grub_memcmp (ptr, ".b", sizeof (".b") - 1) == 0)
{
regsize = 1;
ptr += sizeof (".b") - 1;
}
if (!regsize)
return grub_error (GRUB_ERR_BAD_ARGUMENT,
"unknown register size");
2009-12-22 15:42:45 +00:00
write_mask = 0;
if (*ptr == '=')
{
ptr++;
misc: Make grub_strtol() "end" pointers have safer const qualifiers Currently the string functions grub_strtol(), grub_strtoul(), and grub_strtoull() don't declare the "end" pointer in such a way as to require the pointer itself or the character array to be immutable to the implementation, nor does the C standard do so in its similar functions, though it does require us not to change any of it. The typical declarations of these functions follow this pattern: long strtol(const char * restrict nptr, char ** restrict endptr, int base); Much of the reason for this is historic, and a discussion of that follows below, after the explanation of this change. (GRUB currently does not include the "restrict" qualifiers, and we name the arguments a bit differently.) The implementation is semantically required to treat the character array as immutable, but such accidental modifications aren't stopped by the compiler, and the semantics for both the callers and the implementation of these functions are sometimes also helped by adding that requirement. This patch changes these declarations to follow this pattern instead: long strtol(const char * restrict nptr, const char ** const restrict endptr, int base); This means that if any modification to these functions accidentally introduces either an errant modification to the underlying character array, or an accidental assignment to endptr rather than *endptr, the compiler should generate an error. (The two uses of "restrict" in this case basically mean strtol() isn't allowed to modify the character array by going through *endptr, and endptr isn't allowed to point inside the array.) It also means the typical use case changes to: char *s = ...; const char *end; long l; l = strtol(s, &end, 10); Or even: const char *p = str; while (p && *p) { long l = strtol(p, &p, 10); ... } This fixes 26 places where we discard our attempts at treating the data safely by doing: const char *p = str; long l; l = strtol(p, (char **)&ptr, 10); It also adds 5 places where we do: char *p = str; while (p && *p) { long l = strtol(p, (const char ** const)&p, 10); ... /* more calls that need p not to be pointer-to-const */ } While moderately distasteful, this is a better problem to have. With one minor exception, I have tested that all of this compiles without relevant warnings or errors, and that /much/ of it behaves correctly, with gcc 9 using 'gcc -W -Wall -Wextra'. The one exception is the changes in grub-core/osdep/aros/hostdisk.c , which I have no idea how to build. Because the C standard defined type-qualifiers in a way that can be confusing, in the past there's been a slow but fairly regular stream of churn within our patches, which add and remove the const qualifier in many of the users of these functions. This change should help avoid that in the future, and in order to help ensure this, I've added an explanation in misc.h so that when someone does get a compiler warning about a type error, they have the fix at hand. The reason we don't have "const" in these calls in the standard is purely anachronistic: C78 (de facto) did not have type qualifiers in the syntax, and the "const" type qualifier was added for C89 (I think; it may have been later). strtol() appears to date from 4.3BSD in 1986, which means it could not be added to those functions in the standard without breaking compatibility, which is usually avoided. The syntax chosen for type qualifiers is what has led to the churn regarding usage of const, and is especially confusing on string functions due to the lack of a string type. Quoting from C99, the syntax is: declarator: pointer[opt] direct-declarator direct-declarator: identifier ( declarator ) direct-declarator [ type-qualifier-list[opt] assignment-expression[opt] ] ... direct-declarator [ type-qualifier-list[opt] * ] ... pointer: * type-qualifier-list[opt] * type-qualifier-list[opt] pointer type-qualifier-list: type-qualifier type-qualifier-list type-qualifier ... type-qualifier: const restrict volatile So the examples go like: const char foo; // immutable object const char *foo; // mutable pointer to object char * const foo; // immutable pointer to mutable object const char * const foo; // immutable pointer to immutable object const char const * const foo; // XXX extra const keyword in the middle const char * const * const foo; // immutable pointer to immutable // pointer to immutable object const char ** const foo; // immutable pointer to mutable pointer // to immutable object Making const left-associative for * and right-associative for everything else may not have been the best choice ever, but here we are, and the inevitable result is people using trying to use const (as they should!), putting it at the wrong place, fighting with the compiler for a bit, and then either removing it or typecasting something in a bad way. I won't go into describing restrict, but its syntax has exactly the same issue as with const. Anyway, the last example above actually represents the *behavior* that's required of strtol()-like functions, so that's our choice for the "end" pointer. Signed-off-by: Peter Jones <pjones@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
2020-02-21 21:39:33 +00:00
regwrite = grub_strtoul (ptr, &ptr, 16);
2009-12-22 15:42:45 +00:00
if (grub_errno)
return grub_errno;
write_mask = 0xffffffff;
if (*ptr == ':')
{
ptr++;
misc: Make grub_strtol() "end" pointers have safer const qualifiers Currently the string functions grub_strtol(), grub_strtoul(), and grub_strtoull() don't declare the "end" pointer in such a way as to require the pointer itself or the character array to be immutable to the implementation, nor does the C standard do so in its similar functions, though it does require us not to change any of it. The typical declarations of these functions follow this pattern: long strtol(const char * restrict nptr, char ** restrict endptr, int base); Much of the reason for this is historic, and a discussion of that follows below, after the explanation of this change. (GRUB currently does not include the "restrict" qualifiers, and we name the arguments a bit differently.) The implementation is semantically required to treat the character array as immutable, but such accidental modifications aren't stopped by the compiler, and the semantics for both the callers and the implementation of these functions are sometimes also helped by adding that requirement. This patch changes these declarations to follow this pattern instead: long strtol(const char * restrict nptr, const char ** const restrict endptr, int base); This means that if any modification to these functions accidentally introduces either an errant modification to the underlying character array, or an accidental assignment to endptr rather than *endptr, the compiler should generate an error. (The two uses of "restrict" in this case basically mean strtol() isn't allowed to modify the character array by going through *endptr, and endptr isn't allowed to point inside the array.) It also means the typical use case changes to: char *s = ...; const char *end; long l; l = strtol(s, &end, 10); Or even: const char *p = str; while (p && *p) { long l = strtol(p, &p, 10); ... } This fixes 26 places where we discard our attempts at treating the data safely by doing: const char *p = str; long l; l = strtol(p, (char **)&ptr, 10); It also adds 5 places where we do: char *p = str; while (p && *p) { long l = strtol(p, (const char ** const)&p, 10); ... /* more calls that need p not to be pointer-to-const */ } While moderately distasteful, this is a better problem to have. With one minor exception, I have tested that all of this compiles without relevant warnings or errors, and that /much/ of it behaves correctly, with gcc 9 using 'gcc -W -Wall -Wextra'. The one exception is the changes in grub-core/osdep/aros/hostdisk.c , which I have no idea how to build. Because the C standard defined type-qualifiers in a way that can be confusing, in the past there's been a slow but fairly regular stream of churn within our patches, which add and remove the const qualifier in many of the users of these functions. This change should help avoid that in the future, and in order to help ensure this, I've added an explanation in misc.h so that when someone does get a compiler warning about a type error, they have the fix at hand. The reason we don't have "const" in these calls in the standard is purely anachronistic: C78 (de facto) did not have type qualifiers in the syntax, and the "const" type qualifier was added for C89 (I think; it may have been later). strtol() appears to date from 4.3BSD in 1986, which means it could not be added to those functions in the standard without breaking compatibility, which is usually avoided. The syntax chosen for type qualifiers is what has led to the churn regarding usage of const, and is especially confusing on string functions due to the lack of a string type. Quoting from C99, the syntax is: declarator: pointer[opt] direct-declarator direct-declarator: identifier ( declarator ) direct-declarator [ type-qualifier-list[opt] assignment-expression[opt] ] ... direct-declarator [ type-qualifier-list[opt] * ] ... pointer: * type-qualifier-list[opt] * type-qualifier-list[opt] pointer type-qualifier-list: type-qualifier type-qualifier-list type-qualifier ... type-qualifier: const restrict volatile So the examples go like: const char foo; // immutable object const char *foo; // mutable pointer to object char * const foo; // immutable pointer to mutable object const char * const foo; // immutable pointer to immutable object const char const * const foo; // XXX extra const keyword in the middle const char * const * const foo; // immutable pointer to immutable // pointer to immutable object const char ** const foo; // immutable pointer to mutable pointer // to immutable object Making const left-associative for * and right-associative for everything else may not have been the best choice ever, but here we are, and the inevitable result is people using trying to use const (as they should!), putting it at the wrong place, fighting with the compiler for a bit, and then either removing it or typecasting something in a bad way. I won't go into describing restrict, but its syntax has exactly the same issue as with const. Anyway, the last example above actually represents the *behavior* that's required of strtol()-like functions, so that's our choice for the "end" pointer. Signed-off-by: Peter Jones <pjones@redhat.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
2020-02-21 21:39:33 +00:00
write_mask = grub_strtoul (ptr, &ptr, 16);
2009-12-22 15:42:45 +00:00
if (grub_errno)
return grub_errno;
write_mask = 0xffffffff;
}
regwrite &= write_mask;
}
if (write_mask && varname)
return grub_error (GRUB_ERR_BAD_ARGUMENT,
"option -v isn't valid for writes");
2009-12-22 15:42:45 +00:00
grub_pci_iterate (grub_setpci_iter, NULL);
2009-12-22 15:42:45 +00:00
return GRUB_ERR_NONE;
}
static grub_extcmd_t cmd;
GRUB_MOD_INIT(setpci)
{
cmd = grub_register_extcmd ("setpci", grub_cmd_setpci, 0,
N_("[-s POSITION] [-d DEVICE] [-v VAR] "
2013-01-16 19:44:11 +00:00
"REGISTER[=VALUE[:MASK]]"),
N_("Manipulate PCI devices."), options);
2009-12-22 15:42:45 +00:00
}
GRUB_MOD_FINI(setpci)
{
grub_unregister_extcmd (cmd);
}