On Thursday 07 March 2013 18:47:53 Alexander Stadler wrote: > Am 07.03.2013 17:25, schrieb Tijs Van Buggenhout: > > On Thursday 07 March 2013 16:39:33 Alexander Stadler wrote: > >> Am 07.03.2013 16:24, schrieb Matthijs Kooijman: > >>> Hi Alexander, > > Hi Tijs, > just read after I've sent my last Message.. . > > >>>> The next thought was that ARRAY_SIZE macro must get an array and not > >>> > >>>> an pointer, so I tried it with: > >>> That's exactly right. An array's size is not stored in memory, so you > >>> can only get at it at compile time. However, then you must actually pass > >>> the array, not a pointer to the array (which could potentially point to > >>> different arrays). > >>> > >>>> static void __init board_generic_setup(struct gpio_led *leds_gpio, > >>>> size_t > >>>> leds_gpio_size, struct gpio_keys_button *gpio_keys, size_t > >>>> gpio_keys_size, struct mdio_board_info *mdio0_info, size_t > >>>> mdio0_info_size) > >>>> > >>>> board_generic_setup(board_leds_gpio,ARRAY_SIZE(board_leds_gpio),board_g > >>>> pi > >>>> o_keys,ARRAY_SIZE(board_gpio_keys),board_mdio0_info,ARRAY_SIZE(board_md > >>>> io > >>>> 0_info)); > >> > >> And no const(s)? I'm a bit confused because mdio_board_info seems to use > >> const struct but ath79_register_leds_gpio does not. > > > > In general it's good to inform/promise the compiler when the program is > > not > > going to change data (using const). However, you'll have to adjust to the > > function definition types of the other functions that you are going to use > > in your new function. When compiled with the appropriate flags, when > > passing a const pointer > > As I understand the "struct gpio_led *leds_gpio" syntax was a pointer to a > const struct, and not to a const pointer. So that should give warnings > after used with functions where its defined non-const, because they would > be able to modify the content of the struct. > > But as written in the other mail I now use "struct gpio_led *const > leds_gpio". This should not throw errors (I think because in the next > function its a new pointer, so which then could again be used to point to > an other address?), as long as (in this function) the pointer is not used > to point to another struct (which is exactly what I want to prevent.)
Correct. Every function has its own scope (decendant of global scope), so the leds_gpio pointer is not visible by the next function, unless a pointer to a pointer would be supplied as an argument to the next function. This is not entirely true ofcourse, as pointers are globally "visible", and one could guess the address of the leds_gpio pointer in the next function, and change the address of the pointer there. As long as the intension is not data protection, const can be useful ;-) > > to a function as argument, which is by definition typed non- > > const, it should produce a warning/error. The latter can be avoided by > > casting the const away, but what's the point in that... > > > > This might be interesting reading > > http://publications.gbdirect.co.uk/c_book/chapter8/const_and_volatile.html > > . > > > >>> This would indeed be a sane way to handle this. > >>> > >>>> No problems to expect from the functions like ath79_register_leds_gpio > >>>> when getting the pointer instead the array? > >>> > >>> This should work, since that function also has a size parameter (for the > >>> same reason). > >> > >> The functions use unsigned for the size parameter, not size_t. But I > >> think > >> "my" ARRAY_SIZE will return size_t and so this will be the better > >> approach? > > > > size_t is intended to represent memory related quantities, and is > > preferred in that regard. > > > >>> Gr. > >>> > >>> Matthijs > >> > >> Thanks > >> > >> Alex > > > > Regards, > > Tijs > > Alex > Tijs _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
