Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!us.feeder.erje.net!news2.arglkargh.de!news.swapon.de!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Could you please discuss whether casting a size_t variable to unsigned int variable is the correct way to handle... Date: Tue, 12 May 2015 10:05:30 -0700 Organization: None to speak of Lines: 47 Message-ID: <877fsdg205.fsf@kst-u.example.com> References: <87ioc3j29h.fsf@kst-u.example.com> <3cd2ac79-aeaa-4b7a-91d7-6fc63f592f72@googlegroups.com> <87a8xfi01c.fsf@kst-u.example.com> <876180gufr.fsf@kst-u.example.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="9be37d943435275679235b07c7947eef"; logging-data="24166"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+JHvSzEgCTVPWJFhrss2pv" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:+lurN6QMOarfqbQn7Yo6lSRJ+5I= sha1:t14eDlgliUmvb4tLLi6P57IRbl0= Xref: csiph.com comp.lang.c:61912 glen herrmannsfeldt writes: > Tim Rentsch wrote: >> Keith Thompson writes: > (snip) >>> You're right, size_t doesn't *necessarily* have to be a typedef. > > (snip) >>> The only way to define size_t in standard C is to use a typedef -- >>> but standard headers aren't restricted to using standard C. Using >>> an extension would be permissible. > >>> I think it still has to be equivalent to some named predefined >>> type. > >> I agree that size_t must refer to a particular (ie, predefined) >> type - if not a standard integer type then an extended integer >> type. I just don't find anything in the Standard that implies >> that type has to have a name other than (in this case) size_t. >> Why couldn't the name just be size_t? There would need to be a >> way to declare the name, but that could be done using a reserved >> keyword or #pragma. > > OK, say, for example, a system where short is 16 bits, int > and long are 32 bits. Also, consider that size_t > might work just fine at 24 bits. > > If 24 bits could be done faster than 32, it seems reasonable > to use it. Sure -- and one reasonable way to do that would be to define an extended integer type, say `__int24`, and then have typedef size_t unsigned __int24; in . But if 24-bit integers are faster than 32-bit integers, and are useful for representing object sizes, it could also make sense to make one of the standard integer types 24 bits (say, 16-bit short, 24-bit int, 32-bit long). On the other hand, the limited number of standard integer types might make that awkward. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"