Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: size_t

Reply
Thread Tools

Re: size_t

 
 
Dan Pop
Guest
Posts: n/a
 
      06-24-2003
In <(E-Mail Removed)> CBFalconer <(E-Mail Removed)> writes:

>"Arthur J. O'Dwyer" wrote:
>>
>> [cross-post to comp.std.c removed - this never was a standards issue]
>>
>> On Mon, 23 Jun 2003, Keith Thompson wrote:
>> > Tony Finch <(E-Mail Removed)> writes:
>> > > http://www.velocityreviews.com/forums/(E-Mail Removed) (Dan Pop) wrote:
>> > > >
>> > > > The two most common situations requiring unsigned are:
>> > > > accessing anobject as an array of bytes (unsigned char)
>> > > > and bitwise manipulation.
>> > >
>> > > ctype.h
>> >
>> > How does that apply?

>>
>> Certain functions in <ctype.h> expect 'int' arguments whose
>> values fit in the range of 'unsigned char' (or, equivalently,
>> 'unsigned char' arguments that have been cast to 'int').
>> However, this isn't necessarily a reason to use 'unsigned'
>> anything, except as a type cast.
>>
>> int c;
>> while ((c=getchar()) != EOF) {
>> if (isalpha((unsigned char)c)) ...
>> }
>>
>> doesn't invoke undefined behavior for any user input, even the
>> ones where c is, say, a (non-EOF) negative number. OTOH, it
>> still might do the *wrong thing* for those user inputs, so I
>> for one don't consider the "correct" code much of an
>> improvement over the "incorrect" code.

>
>Except in that fragment the cast should be unnecessary, as I
>believe getchar always returns an unsigned char (or EOF).


getchar() always returns an *int* value in the range of unsigned char or
EOF.

>Unfortunately I can't find the standard section that spells that
>out.


That's because you foolishly limited your search to the description of
getchar().

- The byte input/output functions - those functions described
in this subclause that perform input/output: fgetc, fgets,
fprintf, fputc, fputs, fread, fscanf, fwrite, getc, getchar,
gets, printf, putc, putchar, puts, scanf, ungetc, vfprintf,
vfscanf, vprintf, and vscanf.
....
The byte input functions read characters from the stream
as if by successive calls to the fgetc function.
....
2 If the end-of-file indicator for the input stream pointed to by
stream is not set and a next character is present, the fgetc
function obtains that character as an unsigned char converted
to an int and advances the associated file position indicator
for the stream (if defined).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: (E-Mail Removed)
 
Reply With Quote
 
 
 
 
Alex
Guest
Posts: n/a
 
      06-24-2003
Dan Pop <(E-Mail Removed)> wrote:
> In <(E-Mail Removed)> CBFalconer <(E-Mail Removed)> writes:


>>"Arthur J. O'Dwyer" wrote:
>>>
>>> [cross-post to comp.std.c removed - this never was a standards issue]
>>>
>>> On Mon, 23 Jun 2003, Keith Thompson wrote:
>>> > Tony Finch <(E-Mail Removed)> writes:
>>> > > (E-Mail Removed) (Dan Pop) wrote:
>>> > > >
>>> > > > The two most common situations requiring unsigned are:
>>> > > > accessing anobject as an array of bytes (unsigned char)
>>> > > > and bitwise manipulation.
>>> > >
>>> > > ctype.h
>>> >
>>> > How does that apply?
>>>
>>> Certain functions in <ctype.h> expect 'int' arguments whose
>>> values fit in the range of 'unsigned char' (or, equivalently,
>>> 'unsigned char' arguments that have been cast to 'int').
>>> However, this isn't necessarily a reason to use 'unsigned'
>>> anything, except as a type cast.
>>>
>>> int c;
>>> while ((c=getchar()) != EOF) {
>>> if (isalpha((unsigned char)c)) ...
>>> }
>>>
>>> doesn't invoke undefined behavior for any user input, even the
>>> ones where c is, say, a (non-EOF) negative number. OTOH, it
>>> still might do the *wrong thing* for those user inputs, so I
>>> for one don't consider the "correct" code much of an
>>> improvement over the "incorrect" code.

>>
>>Except in that fragment the cast should be unnecessary, as I
>>believe getchar always returns an unsigned char (or EOF).


> getchar() always returns an *int* value in the range of unsigned char or
> EOF.


His assertion is still correct. The cast is superfluous since there is
an explicit check for EOF.

Alex
 
Reply With Quote
 
 
 
 
Arthur J. O'Dwyer
Guest
Posts: n/a
 
      06-24-2003

On Tue, 24 Jun 2003, Alex wrote:
>
> Dan Pop <(E-Mail Removed)> wrote:
> > In <(E-Mail Removed)> CBFalconer <(E-Mail Removed)> writes:
> >>"Arthur J. O'Dwyer" wrote:

[...]
> >>> ones where c is, say, a (non-EOF) negative number. OTOH, it
> >>> still might do the *wrong thing* for those user inputs, so I
> >>> for one don't consider the "correct" code much of an
> >>> improvement over the "incorrect" code.
> >>
> >>Except in that fragment the cast should be unnecessary, as I
> >>believe getchar always returns an unsigned char (or EOF).

> >
> > getchar() always returns an *int* value in the range of unsigned char or
> > EOF.

>
> His assertion is still correct. The cast is superfluous since there is
> an explicit check for EOF.


Dan was pointing out that CBFalconer wrote "returns an unsigned char"
when what he should have written was "returns an int [not a char!] in the
range of unsigned char, or EOF" -- which is technically not the same thing
at all, even if we all know what he meant anyway.

-Arthur
 
Reply With Quote
 
Alex
Guest
Posts: n/a
 
      06-24-2003
Arthur J. O'Dwyer <(E-Mail Removed)> wrote:

> On Tue, 24 Jun 2003, Alex wrote:
>>
>> Dan Pop <(E-Mail Removed)> wrote:
>> > In <(E-Mail Removed)> CBFalconer <(E-Mail Removed)> writes:
>> >>"Arthur J. O'Dwyer" wrote:

> [...]
>> >>> ones where c is, say, a (non-EOF) negative number. OTOH, it
>> >>> still might do the *wrong thing* for those user inputs, so I
>> >>> for one don't consider the "correct" code much of an
>> >>> improvement over the "incorrect" code.
>> >>
>> >>Except in that fragment the cast should be unnecessary, as I
>> >>believe getchar always returns an unsigned char (or EOF).
>> >
>> > getchar() always returns an *int* value in the range of unsigned char or
>> > EOF.

>>
>> His assertion is still correct. The cast is superfluous since there is
>> an explicit check for EOF.


> Dan was pointing out that CBFalconer wrote "returns an unsigned char"
> when what he should have written was "returns an int [not a char!] in the
> range of unsigned char, or EOF" -- which is technically not the same thing
> at all, even if we all know what he meant anyway.


Yes. I was just pointing out that the assertion is still valid in light
of this correction.

Alex
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
reinterpret_cast<std::size_t>(p) and reinterpret_cast<std::size_t&>() Alex Vinokur C++ 1 02-06-2011 07:48 AM
Casting from const pair<const unsigned char*, size_t>* to constpair<unsigned char*, size_t>* Alex Vinokur C++ 9 10-13-2008 05:05 PM
Re: for(size_t a=begin();a!=end();++a){} Chris \( Val \) C++ 2 07-14-2003 06:31 AM
Re: size_t ... standards Howard Hinnant C++ 5 06-30-2003 07:22 PM
Re: size_t ... standards Howard Hinnant C++ 0 06-29-2003 05:45 PM



Advertisments