Re: [riot-devel] Coding conventions amendment
Hi Ludwig! On Fri, Oct 14, 2016 at 12:26:19PM +0200, Ludwig Knüpfer wrote: > Am 14. Oktober 2016 10:04:07 MESZ, schrieb Oleg Hahm: > >On Fri, Oct 14, 2016 at 09:13:50AM +0200, Ludwig Knüpfer wrote: > >> In general it is safer to explicate the integer width. As RIOT is > >> targeted at 32 bit architectures, > > > >I object! > > With what exactly? With your last (half a) sentence I quoted. RIOT is IMO explicitly not targeted only for 32-bit architectures. That's one thing that distinguishes RIOT from many other OSs in this area. Cheers, Oleg -- printk(KERN_WARNING MYNAM ": (time to go bang on somebodies door)\n"); linux-2.6.6/drivers/message/fusion/mptctl.c signature.asc Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Coding conventions amendment
Hi, Am 14. Oktober 2016 10:04:07 MESZ, schrieb Oleg Hahm: >Hi Ludwig! > >On Fri, Oct 14, 2016 at 09:13:50AM +0200, Ludwig Knüpfer wrote: >> In general it is safer to explicate the integer width. As RIOT is >targeted >> at 32 bit architectures, > >I object! With what exactly? Cheers, Ludwig ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Coding conventions amendment
On 14-10-16 10:05, Oleg Hahm wrote: Hi Kees! On Fri, Oct 14, 2016 at 08:05:51AM +0200, Kees Bakker wrote: On 13-10-16 22:42, Kaspar Schleiser wrote: On 10/13/2016 09:43 PM, Kees Bakker wrote: Does anybody object to adding this to the coding conventions explicitly? What about `size_t`? +1 for size_t Well, any convention would need careful wording. ``` for (uint32_t timeout = 1; timeout < (10LU*1000*1000); timeout *= 2) { if(try()) break; } ``` ... cannot blindly by convention converted to size_t as loop variable. Of course not. But I believe the question was more, in case of an unsigned type, should we use "unsigned int" or size_t. In that case I would go for size_t. No, the initial question was whether we should recommend (unsigned) int (or (s)size_t) as loop iterator variable types. OK. In that case I wouldn't recommend anything. -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Coding conventions amendment
Hi Kees! On Fri, Oct 14, 2016 at 08:05:51AM +0200, Kees Bakker wrote: > On 13-10-16 22:42, Kaspar Schleiser wrote: > > On 10/13/2016 09:43 PM, Kees Bakker wrote: > > > > > Does anybody object to adding this to the coding > > > > > > > conventions explicitly? > > > > > What about `size_t`? > > > +1 for size_t > > Well, any convention would need careful wording. > > > > ``` > > for (uint32_t timeout = 1; timeout < (10LU*1000*1000); timeout *= 2) { > > if(try()) break; > > } > > ``` > > > > ... cannot blindly by convention converted to size_t as loop variable. > > Of course not. > But I believe the question was more, in case of an unsigned type, > should we use "unsigned int" or size_t. In that case I would go for size_t. No, the initial question was whether we should recommend (unsigned) int (or (s)size_t) as loop iterator variable types. Cheers, Oleg -- printk(KERN_WARNING "%s: Thanks, I feel much better now!\n", dev->name); linux-2.6.6/drivers/net/de620.c signature.asc Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Coding conventions amendment
Hi Ludwig! On Fri, Oct 14, 2016 at 09:13:50AM +0200, Ludwig Knüpfer wrote: > In general it is safer to explicate the integer width. As RIOT is targeted > at 32 bit architectures, I object! Cheers, Oleg -- rio_dprintk (RIO_DEBUG_ROUTE, "LIES! DAMN LIES! %d LIES!\n",Lies); linux-2.6.6/drivers/char/rio/rioroute.c signature.asc Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Coding conventions amendment
Hi, Am 14. Oktober 2016 08:05:51 MESZ, schrieb Kees Bakker: >But I believe the question was more, in case of an unsigned type, >should we use "unsigned int" or size_t. In that case I would go for >size_t. BTW: there is also the signed type `ssize_t`. Cheers, Ludwig ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Coding conventions amendment
Hi, Am 13. Oktober 2016 22:42:11 MESZ, schrieb Kaspar Schleiser: >Hi, > >On 10/13/2016 09:43 PM, Kees Bakker wrote: Does anybody object to adding this to the coding >> conventions explicitly? >>> > What about `size_t`? >> +1 for size_t > >Well, any convention would need careful wording. > >``` >for (uint32_t timeout = 1; timeout < (10LU*1000*1000); timeout *= 2) { > if(try()) break; >} >``` > >... cannot blindly by convention converted to size_t as loop variable. > >IMHO this example also answers Oleg's initial concern: sometimes int or >unsigned int or size_t just don't work. Of course there are cases where this default can or should not be applied for various (e.g. type safety, numeric, or optimization) reasons. In general it is safer to explicate the integer width. As RIOT is targeted at 32 bit architectures, I can also see a rationale for `*int32_t` as the default per convention. Cheers, Ludwig ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Coding conventions amendment
On 13-10-16 22:42, Kaspar Schleiser wrote: Hi, On 10/13/2016 09:43 PM, Kees Bakker wrote: Does anybody object to adding this to the coding conventions explicitly? What about `size_t`? +1 for size_t Well, any convention would need careful wording. ``` for (uint32_t timeout = 1; timeout < (10LU*1000*1000); timeout *= 2) { if(try()) break; } ``` ... cannot blindly by convention converted to size_t as loop variable. Of course not. But I believe the question was more, in case of an unsigned type, should we use "unsigned int" or size_t. In that case I would go for size_t. IMHO this example also answers Oleg's initial concern: sometimes int or unsigned int or size_t just don't work. Sure. -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Coding conventions amendment
Am 10/12/2016 um 05:00 PM schrieb Oleg Hahm: Hi Martin! On Wed, Oct 12, 2016 at 04:52:37PM +0200, Landsmann, Martin wrote: On Wed, Oct 12, 2016 at 12:57:50PM +0200, Ludwig Knüpfer wrote: Am 12. Oktober 2016 09:48:28 MESZ, schrieb Oleg Hahm: as far I'm concerned it has been an undocumented coding convention so far to use `int` or `unsigned int` for iterator variables in a loop instead of fixed width integer types. Does anybody object to adding this to the coding conventions explicitly? What about `size_t`? I don't see a reason against `size_t` - but also no good reason that speaks for it. What's the rationale? size_t is suited best to be used for iterating array indices and never overflow holding them [1]. [1] http://stackoverflow.com/a/2550799 Sorry, I don't get this. Can you elaborate? size_t is the type returned from sizeof() call that you may use to determine any object size (including length of static arrays), so for my understanding the returned size_t value can not exceed the highest possible index for any array that can be allocated on the underlying platform. But as Kaspar suggested we should probably state against using fixed width and only recommend size_t. Cheers, Oleg ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Coding conventions amendment
Hi, On 10/12/2016 04:44 PM, René Kijewski wrote: `size_t` is optimal for every architecture that does not use segmented memory. ... when iterating over array indices. Otherwise the width of it is as uncertain (in respect to the underlying platform) as "unsigned int". IMHO there's no need for a convention "use size_t as iterator in for loops", on the contrary, it might confuse newbies (and thus lead to bugs). Not using uint8_t is another matter. Kaspar ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Coding conventions amendment
Hi Martin! On Wed, Oct 12, 2016 at 04:52:37PM +0200, Landsmann, Martin wrote: > > On Wed, Oct 12, 2016 at 12:57:50PM +0200, Ludwig Knüpfer wrote: > > > Am 12. Oktober 2016 09:48:28 MESZ, schrieb Oleg Hahm > > >: > > > > as far I'm concerned it has been an undocumented coding convention so > > > > far > > > > to use `int` or `unsigned int` for iterator variables in a loop instead > > > > of > > > > fixed width integer types. Does anybody object to adding this to the > > > > coding > > > > conventions explicitly? > > > What about `size_t`? > > I don't see a reason against `size_t` - but also no good reason that speaks > > for it. What's the rationale? > size_t is suited best to be used for iterating array indices and never > overflow holding them [1]. > > [1] http://stackoverflow.com/a/2550799 Sorry, I don't get this. Can you elaborate? Cheers, Oleg -- printk(KERN_WARNING MYNAM ": (time to go bang on somebodies door)\n"); linux-2.6.6/drivers/message/fusion/mptctl.c signature.asc Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Coding conventions amendment
Hi, Am 10/12/2016 um 04:37 PM schrieb Oleg Hahm: Hi! On Wed, Oct 12, 2016 at 12:57:50PM +0200, Ludwig Knüpfer wrote: Am 12. Oktober 2016 09:48:28 MESZ, schrieb Oleg Hahm: as far I'm concerned it has been an undocumented coding convention so far to use `int` or `unsigned int` for iterator variables in a loop instead of fixed width integer types. Does anybody object to adding this to the coding conventions explicitly? What about `size_t`? I don't see a reason against `size_t` - but also no good reason that speaks for it. What's the rationale? size_t is suited best to be used for iterating array indices and never overflow holding them [1]. [1] http://stackoverflow.com/a/2550799 Cheers, Oleg ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel Best regards, Martin ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Coding conventions amendment
Hi! On Wed, Oct 12, 2016 at 12:57:50PM +0200, Ludwig Knüpfer wrote: > Am 12. Oktober 2016 09:48:28 MESZ, schrieb Oleg Hahm: > >as far I'm concerned it has been an undocumented coding convention so far > >to use `int` or `unsigned int` for iterator variables in a loop instead of > >fixed width integer types. Does anybody object to adding this to the coding > >conventions explicitly? > > What about `size_t`? I don't see a reason against `size_t` - but also no good reason that speaks for it. What's the rationale? Cheers, Oleg -- printk(KERN_WARNING "Warning: defective CD-ROM (volume sequence number). Enabling \"cruft\" mount option.\n"); linux-2.2.16/fs/isofs/inode.c signature.asc Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Coding conventions amendment
Am Wed, 12 Oct 2016 16:33:11 +0200 schrieb Martin: > Am 10/12/2016 um 12:57 PM schrieb Ludwig Knüpfer: > > Am 12. Oktober 2016 09:48:28 MESZ, schrieb Oleg Hahm > > : > >> as far I'm concerned it has been an undocumented coding convention so > >> far to use `int` or `unsigned int` for iterator variables in a loop > >> instead of > >> fixed width integer types. Does anybody object to adding this to the coding > >> conventions explicitly? > > What about `size_t`? > +1 for size_t Hi, `size_t` is optimal for every architecture that does not use segmented memory. The only platform that I know which used segmented memory was 80286, which was not produced since the mid 90th. According to Wikipedia the last architecture that used segmented memory died out in 1997. So, +1 for size_t from me, too. Cheer René -- Freie Universität Berlin Veterinärmedizinische Bibliothek Oertzenweg 19b, 14163 Berlin Tel.: 030 838 59270 ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel