Groups > comp.lang.c > #61737 > unrolled thread

Could you please discuss whether casting a size_t variable to unsigned int variable is the correct way to handle...

Started by	G G <gdotone@gmail.com>
First post	2015-05-07 17:12 -0700
Last post	2015-05-08 05:12 +0000
Articles	20 on this page of 57 — 16 participants

Back to article view | Back to comp.lang.c

Page 2 of 3 — ← Prev page 1 [2] 3 Next page →

#61925

From	Keith Thompson <kst-u@mib.org>
Date	2015-05-12 12:59 -0700
Message-ID	<87lhgtefe2.fsf@kst-u.example.com>
In reply to	#61918

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
[...]
>>> 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 <stddef.h>.
>
> Presumably you meant to say that the other way around.

Yes.

    typedef unsigned __int24 size_t;

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
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"

[toc] | [prev] | [next] | [standalone]

#62445

From	Tim Rentsch <txr@alumni.caltech.edu>
Date	2015-05-22 08:11 -0700
Message-ID	<kfnzj4w8x6f.fsf@x-alumni2.alumni.caltech.edu>
In reply to	#61925

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>
> [...]
>
>>>> 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 <stddef.h>.
>>
>> Presumably you meant to say that the other way around.
>
> Yes.
>
>     typedef unsigned __int24 size_t;

Thinking about this later something occurred to me.  As written,
this declaration violates a constraint, namely 6.7.2 p2 (because it
isn't one of the listed multisets).  Does this mean a diagnostic is
required?  If not then why not?  Surely the Standard doesn't mean to
allow any use of an extended keyword like __int24 to give carte
blanche to violate constraints or syntax rules.  Or does it?

[toc] | [prev] | [next] | [standalone]

#62459

From	Keith Thompson <kst-u@mib.org>
Date	2015-05-22 11:20 -0700
Message-ID	<87lhggsccs.fsf@kst-u.example.com>
In reply to	#62445

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> Keith Thompson <kst-u@mib.org> writes:
>>>> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>
>> [...]
>>
>>>>> 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 <stddef.h>.
>>>
>>> Presumably you meant to say that the other way around.
>>
>> Yes.
>>
>>     typedef unsigned __int24 size_t;
>
> Thinking about this later something occurred to me.  As written,
> this declaration violates a constraint, namely 6.7.2 p2 (because it
> isn't one of the listed multisets).  Does this mean a diagnostic is
> required?  If not then why not?  Surely the Standard doesn't mean to
> allow any use of an extended keyword like __int24 to give carte
> blanche to violate constraints or syntax rules.  Or does it?

Yes, I believe it's a constraint violation.

One data point: On platforms where it supports __int128, "gcc -pedantic"
issues a warning for any use of "__int128".  (As discussed previously,
gcc treats __int128 as an extension, not as an extended integer type.)

A compiler that wants to support, say, 24-bit integers as extended
integer types could reasonably use __int24 and __uint24; no diagnostic
would be required.

It would make sense for the standard to permit the types to be written
as __int24 and unsigned __int24, but as far as I can tell it doesn't.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
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"

[toc] | [prev] | [next] | [standalone]

#62528

From	Tim Rentsch <txr@alumni.caltech.edu>
Date	2015-05-24 07:59 -0700
Message-ID	<kfnmw0u6mxx.fsf@x-alumni2.alumni.caltech.edu>
In reply to	#62459

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>> Keith Thompson <kst-u@mib.org> writes:
>>>>> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>>
>>> [...]
>>>
>>>>>> 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 <stddef.h>.
>>>>
>>>> Presumably you meant to say that the other way around.
>>>
>>> Yes.
>>>
>>>     typedef unsigned __int24 size_t;
>>
>> Thinking about this later something occurred to me.  As written,
>> this declaration violates a constraint, namely 6.7.2 p2 (because it
>> isn't one of the listed multisets).  Does this mean a diagnostic is
>> required?  If not then why not?  Surely the Standard doesn't mean to
>> allow any use of an extended keyword like __int24 to give carte
>> blanche to violate constraints or syntax rules.  Or does it?
>
> Yes, I believe it's a constraint violation.
>
> One data point:  On platforms where it supports __int128,
> "gcc -pedantic" issues a warning for any use of "__int128".
> (As discussed previously, gcc treats __int128 as an
> extension, not as an extended integer type.)

Right, but that's understandable because using this type in
almost any way would imply some constraint is violated, so
we might as well get the diagnostic out of the way early.
I don't think the same is true of extended integer types,
as opposed to extensions like __int128.

> A compiler that wants to support, say, 24-bit integers as
> extended integer types could reasonably use __int24 and
> __uint24;  no diagnostic would be required.

Strictly speaking I don't think a diagnostic is required
for a declaration using __int128 either.  Uses would, but
AFAICS declarations do not (presuming __int128 is a typedef
name, which it could be).  Do you agree?

> It would make sense for the standard to permit the types to
> be written as __int24 and unsigned __int24, but as far as I
> can tell it doesn't.

10-4, and I concur.  (And I assume you put 'signed __int24'
on that list as well;  certainly I would.)

[toc] | [prev] | [next] | [standalone]

#62546

From	Keith Thompson <kst-u@mib.org>
Date	2015-05-24 13:44 -0700
Message-ID	<87617hpuwn.fsf@kst-u.example.com>
In reply to	#62528

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> A compiler that wants to support, say, 24-bit integers as
>> extended integer types could reasonably use __int24 and
>> __uint24;  no diagnostic would be required.
>
> Strictly speaking I don't think a diagnostic is required
> for a declaration using __int128 either.  Uses would, but
> AFAICS declarations do not (presuming __int128 is a typedef
> name, which it could be).  Do you agree?

If __int128 were a typedef, then no diagnostic would be required for
code that uses it.  But in fact it's a gcc implementation-defined
keyword.  I *think* a diagnostic is required for any use of it.
(Of course that requirement doesn't apply to non-conforming
compilers, such as gcc in its default mode.)

>> It would make sense for the standard to permit the types to
>> be written as __int24 and unsigned __int24, but as far as I
>> can tell it doesn't.
>
> 10-4, and I concur.  (And I assume you put 'signed __int24'
> on that list as well;  certainly I would.)

Yes.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
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"

[toc] | [prev] | [next] | [standalone]

#61917

From	Tim Rentsch <txr@alumni.caltech.edu>
Date	2015-05-12 11:09 -0700
Message-ID	<kfnzj59brcf.fsf@x-alumni2.alumni.caltech.edu>
In reply to	#61883

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>> Keith Thompson <kst-u@mib.org> 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, but that is orthogonal to the question I'm trying to
answer.

[toc] | [prev] | [next] | [standalone]

#61915

From	Keith Thompson <kst-u@mib.org>
Date	2015-05-12 11:02 -0700
Message-ID	<87y4ktekrz.fsf@kst-u.example.com>
In reply to	#61877

Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]
> 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.
[...]

It's a somewhat weak inference from a footnote in 6.2.5.

Paragraph 4 says:

    There may also be implementation-defined extended signed
    integer types.

A footnote on that sentence (footnote 38 in N1570) says:

    Implementation-defined keywords shall have the form of an
    identifier reserved for any use as described in 7.1.3.

I don't see how to make sense of the association between that
sentence and that footnote without an implicit assumption that the
names of extended integer types are implementation-defined keywords.
You could argue that *some* extended integer types might have
different forms, but the standard doesn't mention that possibility.

Furthermore, if size_t is an extended unsigned integer type, then
there must be a corresponding signed integer type.  The two types
*could* be called __ssize_t and size_t (where size_t would be an
identifier for something that can't be defined in the standard
language), but I'd find that a bit perverse.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
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"

[toc] | [prev] | [next] | [standalone]

#62444

From	Tim Rentsch <txr@alumni.caltech.edu>
Date	2015-05-22 08:01 -0700
Message-ID	<kfn4mn4ac6j.fsf@x-alumni2.alumni.caltech.edu>
In reply to	#61915

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
> [...]
>> 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.
>
> [...]
>
> It's a somewhat weak inference from a footnote in 6.2.5.
>
> Paragraph 4 says:
>
>     There may also be implementation-defined extended signed
>     integer types.
>
> A footnote on that sentence (footnote 38 in N1570) says:
>
>     Implementation-defined keywords shall have the form of an
>     identifier reserved for any use as described in 7.1.3.
>
> I don't see how to make sense of the association between that
> sentence and that footnote without an implicit assumption that the
> names of extended integer types are implementation-defined
> keywords.  You could argue that *some* extended integer types
> might have different forms, but the standard doesn't mention that
> possibility.

To me it makes sense for the footnote to suggest that extended
integer types _may_ be introduced by means of such keywords, and
even that this approach might be the most common, but not that
they _must_ be introduced in this way.  As I see it the footnote
is simply pointing out one way of adding names for extended
integer types to the language.

> Furthermore, if size_t is an extended unsigned integer type, then
> there must be a corresponding signed integer type.  The two types
> *could* be called __ssize_t and size_t (where size_t would be an
> identifier for something that can't be defined in the standard
> language), but I'd find that a bit perverse.

A natural choice for the name of size_t's corresponding signed
integer type is (pretty obviously) ptrdiff_t.  That doesn't work
for implementations where size_t is only 16 bits (ie, including
padding bits), but such implementations are likely to use
'unsigned int' for size_t anyway.  Both size_t and ptrdiff_t
are supplied by <stddef.h>.

[toc] | [prev] | [next] | [standalone]

#63053

From	Waldek Hebisch <hebisch@antispam.uni.wroc.pl>
Date	2015-06-08 01:06 +0000
Message-ID	<ml2pqu$r3j$1@z-news2.pwr.wroc.pl>
In reply to	#61834

Keith Thompson <kst-u@mib.org> wrote:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
> > Keith Thompson <kst-u@mib.org> writes:
> >> G G <gdotone@gmail.com> writes:
> >> [...]
> >>> I didn't of think of it.  I was just puzzled because I thought
> >>> size_t was really and unsigned int.
> >>
> >> size_t is an implementation-defined unsigned integer type.  It's
> >> defined via a typedef, which creates an alias for an existing
> >> type, not a new type.  [snip]
> >
> > What makes you say size_t must be defined using 'typedef'?  I
> > agree that this will very likely be true, but I haven't found
> > anything in the Standard that implies that it _must_ be true.  Is
> > there some reason an implementation could not, for example, have
> > something like
> >
> >     _Declare size_t;
> >
> > in those header files required to provide size_t?  AFAICT the
> > type size_t may be distinct from any integer type that is
> > nameable without using 'size_t'.
> 
> You're right, size_t doesn't *necessarily* have to be a typedef.
> 
> The standard (7.19) says that <stddef.h>
> 
>     declares the following types.
>     ...
>     The types are
>     ...
>         size_t
>     which is the unsigned integer type of the result of the sizeof
>     operator;
> 
> 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.

<snip>

> If an implementation used an extension to define size_t without using
> "typedef", I'd have difficulty arguing that it's non-conforming -- but
> it still quacks like a typedef.
> 
> I suspect the authors of the standard assumed size_t is a typedef and
> didn't bother saying so explicitly.

I think you underestimate authors of the standard.  AFAICS standard
was carefully written to allow wide variety of implementations.
In particular, "standard headers" may be completely abstract.
That is compiler seeing for example

#include <stddef.h>

simply may activate apropriate set of declarations.  IIRC the
Tendra compiler worked in such a way: there was a language
to define content of standard header, but this language
had significant differences compared to C.  During compiler
build headers were converted to a binary form which could
be quickly loaded into the compiler.  When using Tendra
compiler including standard headers loaded (if needed)
declarations and activated them.  Beside standard C
headers Tendra handled a lot of other headers (POSIX, X
and more) in the same way.

I suspect that C compiler for diskless 8-bitters used
similar method (why should they waste precious RAM for
storing "stdio.h").

-- 
                              Waldek Hebisch
hebisch@antispam.uni.wroc.pl

[toc] | [prev] | [next] | [standalone]

#63054

From	Keith Thompson <kst-u@mib.org>
Date	2015-06-07 19:12 -0700
Message-ID	<87616zrlrv.fsf@kst-u.example.com>
In reply to	#63053

Waldek Hebisch <hebisch@antispam.uni.wroc.pl> writes:
> Keith Thompson <kst-u@mib.org> wrote:
[...]
>> I suspect the authors of the standard assumed size_t is a typedef and
>> didn't bother saying so explicitly.
>
> I think you underestimate authors of the standard.  AFAICS standard
> was carefully written to allow wide variety of implementations.
> In particular, "standard headers" may be completely abstract.

Perhaps.  But even if the standard headers are something other than C
source files (a possibility the standard acknowledges by saying that
<...> includes a "header" while "..." includes a "source file), that
doesn't necessarily imply that the authors thought that size_t could be
something other than a typedef.

For most of the things declared/defined in the standard headers, the
standard says what kind of entity they are.  Just one example: `assert`
is defined as a macro, even if the definition is in something that's not
a C source file.

size_t certainly *can* be a typedef.  I can't think of a good reason for
an implementation to make it something other than a typedef (possibly
something that acts exactly like a typedef, so we might as well call it
one).

N1570 7.20, the introduction to the section describing <stdint.h>, says
in paragraph 1 that that header "declares sets of integer types".
Paragraph 4 then refers to "typedef names".  The way I read it (and this
is admittedly vague), it seems to assume that typedefs are the way to
define types.

The description of <stddef.h> refers to types not typedefs.  Perhaps
it's just a difference in writing style, since <stddef.h> was added by
C89/C90 and <stdint.h> by C99.

[...]

> I suspect that C compiler for diskless 8-bitters used
> similar method (why should they waste precious RAM for
> storing "stdio.h").

Unless the compiler itself runs on a diskless 8-bitter, storage for
<stdio.h> is not relevant.  Typically it's a C source file on the host
system.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
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"

[toc] | [prev] | [next] | [standalone]

#63078

From	James Kuyper <jameskuyper@verizon.net>
Date	2015-06-08 11:28 -0400
Message-ID	<5575B491.2070407@verizon.net>
In reply to	#63054

On 06/07/2015 10:12 PM, Keith Thompson wrote:
...
> size_t certainly *can* be a typedef.  I can't think of a good reason for
> an implementation to make it something other than a typedef (possibly
> something that acts exactly like a typedef, so we might as well call it
> one).
> 
> N1570 7.20, the introduction to the section describing <stdint.h>, says
> in paragraph 1 that that header "declares sets of integer types".
> Paragraph 4 then refers to "typedef names".  The way I read it (and this
> is admittedly vague), it seems to assume that typedefs are the way to
> define types.
> 
> The description of <stddef.h> refers to types not typedefs.  Perhaps
> it's just a difference in writing style, since <stddef.h> was added by
> C89/C90 and <stdint.h> by C99.

It seems to me that, because the standard doesn't specify that they are
typedefs, the requirements could be met by having the relevant header
contain the equivalent of the following:

    #pragma activate_typename size_t

which activates recognition of size_t as the name of a type. This
differs from a typedef because there is no other name that can be used
for this type. That would be pretty pointless unless size_t has some
properties that differ from any of the basic standard types, which would
odd, but not impossible.
Of course, as far as strictly conforming code is concerned, having
another name that is a reserved identifier is indistinguishable from
having no other name, so I don't see any particular advantage to
implementing it this way - I'm just arguing that it's permitted.

[toc] | [prev] | [next] | [standalone]

#63104

From	Waldek Hebisch <hebisch@antispam.uni.wroc.pl>
Date	2015-06-09 12:23 +0000
Message-ID	<ml6lsu$o2r$1@z-news2.pwr.wroc.pl>
In reply to	#63054

Keith Thompson <kst-u@mib.org> wrote:
> Waldek Hebisch <hebisch@antispam.uni.wroc.pl> writes:
> > Keith Thompson <kst-u@mib.org> wrote:
> [...]
> >> I suspect the authors of the standard assumed size_t is a typedef and
> >> didn't bother saying so explicitly.
> >
> > I think you underestimate authors of the standard.  AFAICS standard
> > was carefully written to allow wide variety of implementations.
> > In particular, "standard headers" may be completely abstract.
> 
> Perhaps.  But even if the standard headers are something other than C
> source files (a possibility the standard acknowledges by saying that
> <...> includes a "header" while "..." includes a "source file), that
> doesn't necessarily imply that the authors thought that size_t could be
> something other than a typedef.
> 
> For most of the things declared/defined in the standard headers, the
> standard says what kind of entity they are.  Just one example: `assert`
> is defined as a macro, even if the definition is in something that's not
> a C source file.
> 
> size_t certainly *can* be a typedef.  I can't think of a good reason for
> an implementation to make it something other than a typedef (possibly
> something that acts exactly like a typedef, so we might as well call it
> one).

IMO the main point is if type is available under different name.
Normally extended integer types to be useful need a name, but
'size_t' is already a perfectly good name.  Implementation may
provide different name for the same type, but AFAICS has no
obligation to do so.  If there are no other name for the
type then it defintely is not a typedef.

Of course usually alternative name is provided.  But there
are reason to avoid it:

 - to limit bloat in the compiler
 - to get stricter type checking.  In usual implementations
   program may be type correct when using one implementation
   because logically distint types happen to be the same actual type
   and fail when using different implementation.  Keeping types
   like 'size_t' separate from other types allows catching
   some of such porblems.
 
> > I suspect that C compiler for diskless 8-bitters used
> > similar method (why should they waste precious RAM for
> > storing "stdio.h").
> 
> Unless the compiler itself runs on a diskless 8-bitter, storage for
> <stdio.h> is not relevant.  Typically it's a C source file on the host
> system.

Of course I meant diskless 8-bitter used as developement host.
In 1985 such sytems were much cheaper than alternatives and
there were C compiers for them.  You loaded C compiler from
tape and everything (compiler, source code, compiled code) had
to fit into limited RAM for smooth work.

-- 
                              Waldek Hebisch
hebisch@math.uni.wroc.pl

[toc] | [prev] | [next] | [standalone]

#63089

From	David Kleinecke <dkleinecke@gmail.com>
Date	2015-06-08 10:56 -0700
Message-ID	<5922caf7-6301-40f8-8f28-64c1346774e2@googlegroups.com>
In reply to	#61834

On Sunday, May 10, 2015 at 11:27:02 AM UTC-7, Keith Thompson wrote:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
> > Keith Thompson <kst-u@mib.org> writes:
> >> G G <gdotone@gmail.com> writes:
> >> [...]
> >>> I didn't of think of it.  I was just puzzled because I thought
> >>> size_t was really and unsigned int.
> >>
> >> size_t is an implementation-defined unsigned integer type.  It's
> >> defined via a typedef, which creates an alias for an existing
> >> type, not a new type.  [snip]
> >
> > What makes you say size_t must be defined using 'typedef'?  I
> > agree that this will very likely be true, but I haven't found
> > anything in the Standard that implies that it _must_ be true.  Is
> > there some reason an implementation could not, for example, have
> > something like
> >
> >     _Declare size_t;
> >
> > in those header files required to provide size_t?  AFAICT the
> > type size_t may be distinct from any integer type that is
> > nameable without using 'size_t'.
> 
> You're right, size_t doesn't *necessarily* have to be a typedef.
> 
> The standard (7.19) says that <stddef.h>
> 
>     declares the following types.
>     ...
>     The types are
>     ...
>         size_t
>     which is the unsigned integer type of the result of the sizeof
>     operator;
> 
> 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.
> size_t is an "unsigned integer type", which means (6.2.5) that it's
> either one of the six "standard unsigned integer types" (it can't
> be _Bool), or an "extended unsigned integer types".  A footnote
> suggests, but doesn't quite say, that extended integer types have
> names that are implementation-defined keywords, which "shall have the
> form of an identifier reserved for any use as described in 7.1.3".
> The name "size_t" doesn't qualify.  (Certainly "size_t" can't be
> treated as a keyword.)
> 
> If an implementation used an extension to define size_t without using
> "typedef", I'd have difficulty arguing that it's non-conforming -- but
> it still quacks like a typedef.
> 
> I suspect the authors of the standard assumed size_t is a typedef and
> didn't bother saying so explicitly.
 
Why not a macro?

[toc] | [prev] | [next] | [standalone]

#63090

From	Keith Thompson <kst-u@mib.org>
Date	2015-06-08 11:32 -0700
Message-ID	<87mw0aqce9.fsf@kst-u.example.com>
In reply to	#63089

David Kleinecke <dkleinecke@gmail.com> writes:
> On Sunday, May 10, 2015 at 11:27:02 AM UTC-7, Keith Thompson wrote:
[...]
>> I suspect the authors of the standard assumed size_t is a typedef and
>> didn't bother saying so explicitly.
>  
> Why not a macro?

Because this strictly conforming program:

#include <stdio.h>
#include <stddef.h>
int main(void) {
#ifdef size_t
    puts("size_t is a macro");
#else
    puts("size_t is not a macro");
#endif
    {
        char *size_t = "Because, among other things, if size_t were "
                       "a macro, this would be a syntax error";
    }
    return 0;
}

must print "size_t is not a macro".

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
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"

[toc] | [prev] | [next] | [standalone]

#63091

From	Bartc <bc@freeuk.com>
Date	2015-06-08 19:40 +0100
Message-ID	<ml4nhg$s6a$1@dont-email.me>
In reply to	#63090

On 08/06/2015 19:32, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
>> On Sunday, May 10, 2015 at 11:27:02 AM UTC-7, Keith Thompson wrote:
> [...]
>>> I suspect the authors of the standard assumed size_t is a typedef and
>>> didn't bother saying so explicitly.
>>
>> Why not a macro?
>
> Because this strictly conforming program:
>
> #include <stdio.h>
> #include <stddef.h>
> int main(void) {
> #ifdef size_t
>      puts("size_t is a macro");
> #else
>      puts("size_t is not a macro");
> #endif
>      {
>          char *size_t = "Because, among other things, if size_t were "
>                         "a macro, this would be a syntax error";

You mean, it's important to be able to do:

size_t size_t;

and that can only be achieved if size_t was a typedef?


-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#63092

From	Richard Heathfield <rjh@cpax.org.uk>
Date	2015-06-08 20:03 +0100
Message-ID	<ml4oqr$jr$1@dont-email.me>
In reply to	#63091

On 08/06/15 19:40, Bartc wrote:
> On 08/06/2015 19:32, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>>> On Sunday, May 10, 2015 at 11:27:02 AM UTC-7, Keith Thompson wrote:
>> [...]
>>>> I suspect the authors of the standard assumed size_t is a typedef and
>>>> didn't bother saying so explicitly.
>>>
>>> Why not a macro?
>>
>> Because this strictly conforming program:
>>
>> #include <stdio.h>
>> #include <stddef.h>
>> int main(void) {
>> #ifdef size_t
>>      puts("size_t is a macro");
>> #else
>>      puts("size_t is not a macro");
>> #endif
>>      {
>>          char *size_t = "Because, among other things, if size_t were "
>>                         "a macro, this would be a syntax error";
>
> You mean, it's important to be able to do:
>
> size_t size_t;
>
> and that can only be achieved if size_t was a typedef?

I don't follow your logic. You asked why size_t can't be a macro. Keith 
has explained why it can't be. He has not said that it is /desirable/ 
for size_t not to be definable using a macro. Nor is he advocating it. 
(Nor is he advocating the opposite.) He's just demonstrating a 
consequence of the way that the C rules work.

Not only that, but he hasn't said that size_t must be a typedef. He has 
only said that it can't be a macro.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#63094

From	Keith Thompson <kst-u@mib.org>
Date	2015-06-08 13:43 -0700
Message-ID	<87ioayq6by.fsf@kst-u.example.com>
In reply to	#63091

Bartc <bc@freeuk.com> writes:
> On 08/06/2015 19:32, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>>> On Sunday, May 10, 2015 at 11:27:02 AM UTC-7, Keith Thompson wrote:
>> [...]
>>>> I suspect the authors of the standard assumed size_t is a typedef and
>>>> didn't bother saying so explicitly.
>>>
>>> Why not a macro?
>>
>> Because this strictly conforming program:
>>
>> #include <stdio.h>
>> #include <stddef.h>
>> int main(void) {
>> #ifdef size_t
>>      puts("size_t is a macro");
>> #else
>>      puts("size_t is not a macro");
>> #endif
>>      {
>>          char *size_t = "Because, among other things, if size_t were "
>>                         "a macro, this would be a syntax error";
>
> You mean, it's important to be able to do:
>
> size_t size_t;
>
> and that can only be achieved if size_t was a typedef?

Right, that's exactly what I *didn't* say.

I'm saying it's *required* to be able to redefine the identifier
"size_t" in an inner scope, and having <stddef.h> define size_t as
a macro that expands to a type name would make that impossible.

I wasn't saying here that size_t must be a typedef, merely that it
cannot be a macro.

"size_t size_t;" is your example, not mine.

The standard *could* have permitted, or even required, size_t to be
defined as a macro.  I, for one, would not have been particularly
inconvenienced if it had.  But it didn't, and that affects what
conforming implementations are permitted to do.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
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"

[toc] | [prev] | [next] | [standalone]

#63095

From	glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date	2015-06-08 21:03 +0000
Message-ID	<ml4vul$gmm$1@speranza.aioe.org>
In reply to	#63090

Keith Thompson <kst-u@mib.org> wrote:
(snip) 
> Because this strictly conforming program:

> #include <stdio.h>
> #include <stddef.h>
> int main(void) {
> #ifdef size_t
>    puts("size_t is a macro");
> #else
>    puts("size_t is not a macro");
> #endif
>    {
>        char *size_t = "Because, among other things, if size_t were "
>                       "a macro, this would be a syntax error";
>    }
>    return 0;
> }

> must print "size_t is not a macro".

Maybe I am missing something (likely), but why can't size_t be
a macro that expands to a typedef name?  That is, with the appropriate
macro expansion it wouldn't be a syntax error, but still would print
"size_t is a macro".

-- glen

[toc] | [prev] | [next] | [standalone]

#63096

From	Keith Thompson <kst-u@mib.org>
Date	2015-06-08 14:52 -0700
Message-ID	<87egllrhoy.fsf@kst-u.example.com>
In reply to	#63095

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> wrote:
> (snip) 
>> Because this strictly conforming program:
>  
>> #include <stdio.h>
>> #include <stddef.h>
>> int main(void) {
>> #ifdef size_t
>>    puts("size_t is a macro");
>> #else
>>    puts("size_t is not a macro");
>> #endif
>>    {
>>        char *size_t = "Because, among other things, if size_t were "
>>                       "a macro, this would be a syntax error";
>>    }
>>    return 0;
>> }
>  
>> must print "size_t is not a macro".
>
> Maybe I am missing something (likely), but why can't size_t be
> a macro that expands to a typedef name?  That is, with the appropriate
> macro expansion it wouldn't be a syntax error, but still would print
> "size_t is a macro".

Interesting question.  If an implementation is permitted to, for
example, have the following in <stddef.h>

    typedef unsigned long size_t;
    #define size_t size_t

then the above program is *not* strictly conforming, but I don't think
the macro definition would affect anything that doesn't explicitly test
whether size_t is defined as a macro.

I have some fairly weak arguments that it's not permitted.

N1570 7.1.2p1 says:

    The header declares a set of related functions, plus any
    necessary types and additional macros needed to facilitate
    their use.

The macro is not *needed* to facilitate the use of the type.

7.1.2p5 says:

    Any definition of an object-like macro described in this clause
    shall expand to code that is fully protected by parentheses
    where necessary, so that it groups in an arbitrary expression
    as if it were a single identifier.

This cannot apply to a macro that expands to a typedef name.

7.1.4p1 gives explicit permission to define functions as macros.  No
such permission is given for type names.

In general, I'd like to say that implementations aren't permitted to
define identifiers in ways not explicitly permitted by the standard,
but I'm not sure I can justify it rigorously.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
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"

[toc] | [prev] | [next] | [standalone]

#63105

From	David Kleinecke <dkleinecke@gmail.com>
Date	2015-06-09 08:30 -0700
Message-ID	<56301485-e5e9-45c7-8357-9a9b21327747@googlegroups.com>
In reply to	#63096

On Monday, June 8, 2015 at 2:52:55 PM UTC-7, Keith Thompson wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> > Keith Thompson <kst-u@mib.org> wrote:
> > (snip) 
> >> Because this strictly conforming program:
> >  
> >> #include <stdio.h>
> >> #include <stddef.h>
> >> int main(void) {
> >> #ifdef size_t
> >>    puts("size_t is a macro");
> >> #else
> >>    puts("size_t is not a macro");
> >> #endif
> >>    {
> >>        char *size_t = "Because, among other things, if size_t were "
> >>                       "a macro, this would be a syntax error";
> >>    }
> >>    return 0;
> >> }
> >  
> >> must print "size_t is not a macro".
> >
> > Maybe I am missing something (likely), but why can't size_t be
> > a macro that expands to a typedef name?  That is, with the appropriate
> > macro expansion it wouldn't be a syntax error, but still would print
> > "size_t is a macro".
> 
> Interesting question.  If an implementation is permitted to, for
> example, have the following in <stddef.h>
> 
>     typedef unsigned long size_t;
>     #define size_t size_t
> 
> then the above program is *not* strictly conforming, but I don't think
> the macro definition would affect anything that doesn't explicitly test
> whether size_t is defined as a macro.
> 
> I have some fairly weak arguments that it's not permitted.
> 
> N1570 7.1.2p1 says:
> 
>     The header declares a set of related functions, plus any
>     necessary types and additional macros needed to facilitate
>     their use.
> 
> The macro is not *needed* to facilitate the use of the type.
> 
> 7.1.2p5 says:
> 
>     Any definition of an object-like macro described in this clause
>     shall expand to code that is fully protected by parentheses
>     where necessary, so that it groups in an arbitrary expression
>     as if it were a single identifier.
> 
> This cannot apply to a macro that expands to a typedef name.
> 
> 7.1.4p1 gives explicit permission to define functions as macros.  No
> such permission is given for type names.
> 
> In general, I'd like to say that implementations aren't permitted to
> define identifiers in ways not explicitly permitted by the standard,
> but I'm not sure I can justify it rigorously.

The preprocessor should not be aware of niceties like functions. It
should preprocess any code or chaos according to its rules. But, of
course, how  do I know I can say "should"?

I think the preprocessor should operate on its own rules without
reference to the program structure. That is my opinion.

I don't think the standard (any standard) is clear on this point.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3 Next page →

csiph-web

Could you please discuss whether casting a size_t variable to unsigned int variable is the correct way to handle...

Contents

#61925

#62445

#62459

#62528

#62546

#61917

#61915

#62444

#63053

#63054

#63078

#63104

#63089

#63090

#63091

#63092

#63094

#63095

#63096

#63105