Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

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

a doubt about c

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

Contents

  a doubt about c Ya Shou <zxyzxy12321@gmail.com> - 2011-06-11 06:11 -0700
    Re: a doubt about c James Kuyper <jameskuyper@verizon.net> - 2011-06-11 09:36 -0400
    Re: a doubt about c Angel <angel+news@spamcop.net> - 2011-06-11 14:37 +0000
      Re: a doubt about c Keith Thompson <kst-u@mib.org> - 2011-06-11 11:55 -0700
        Re: a doubt about c Angel <angel+news@spamcop.net> - 2011-06-11 20:41 +0000
          Re: a doubt about c Ian Collins <ian-news@hotmail.com> - 2011-06-12 08:58 +1200
            Re: a doubt about c Shao Miller <sha0.miller@gmail.com> - 2011-06-11 17:09 -0500
            Re: a doubt about c Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-11 18:25 -0400
              Re: a doubt about c Ian Collins <ian-news@hotmail.com> - 2011-06-12 11:43 +1200
              Re: a doubt about c Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-06-12 05:38 -0700
                Re: a doubt about c Roberto Waltman <usenet@rwaltman.com> - 2011-06-12 10:12 -0400
                  Re: a doubt about c Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-12 10:59 -0400
                    Re: a doubt about c Nobody <nobody@nowhere.com> - 2011-06-15 17:07 +0100
                  Re: a doubt about c Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-06-12 11:33 -0700
                  Re: a doubt about c James Kuyper <jameskuyper@verizon.net> - 2011-06-15 09:53 -0400
                  Re: a doubt about c Dr Nick <3-nospam@temporary-address.org.uk> - 2011-06-16 18:46 +0100
            Re: a doubt about c DSF <notavalid@address.here> - 2011-06-11 18:53 -0500
              Re: a doubt about c Keith Thompson <kst-u@mib.org> - 2011-06-11 16:18 -0700
                Re: a doubt about c Stephen Sprunk <stephen@sprunk.org> - 2011-06-11 21:13 -0500
                  Re: a doubt about c Ian Collins <ian-news@hotmail.com> - 2011-06-12 14:56 +1200
                  Re: a doubt about c Keith Thompson <kst-u@mib.org> - 2011-06-11 20:24 -0700
                  Re: a doubt about c Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-12 08:10 -0400
              Re: a doubt about c Ian Collins <ian-news@hotmail.com> - 2011-06-12 11:49 +1200
          Re: a doubt about c Keith Thompson <kst-u@mib.org> - 2011-06-11 15:36 -0700
        Re: a doubt about c Nobody <nobody@nowhere.com> - 2011-06-12 00:23 +0100
          Re: a doubt about c Seebs <usenet-nospam@seebs.net> - 2011-06-13 14:39 +0000
            Re: a doubt about c Squeamizh <squeamz@hotmail.com> - 2011-06-15 15:44 -0700
              Re: a doubt about c Geoff <geoff@invalid.invalid> - 2011-06-15 19:57 -0700
                Re: a doubt about c "J. J. Farrell" <jjf@bcs.org.uk> - 2011-06-16 18:39 +0100
                  Re: a doubt about c Nobody <nobody@nowhere.com> - 2011-06-17 15:39 +0100
                    Re: a doubt about c Willem <willem@toad.stack.nl> - 2011-06-17 14:49 +0000
                      Re: a doubt about c Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-17 09:14 -0600
                      Re: a doubt about c Shao Miller <sha0.miller@gmail.com> - 2011-06-17 12:00 -0500
                    Re: a doubt about c Shao Miller <sha0.miller@gmail.com> - 2011-06-17 11:08 -0500
                      Re: [OT] Doubt vs. question. (Re: a doubt about c) Shao Miller <sha0.miller@gmail.com> - 2011-06-17 13:00 -0500
                        Re: [OT] Doubt vs. question. (Re: a doubt about c) Shao Miller <sha0.miller@gmail.com> - 2011-06-22 19:01 -0500
                    Re: a doubt about c Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-17 09:14 -0600
                    Re: a doubt about c Seebs <usenet-nospam@seebs.net> - 2011-06-17 22:16 +0000
                    Re: a doubt about c "J. J. Farrell" <jjf@bcs.org.uk> - 2011-06-18 02:24 +0100
        Re: a doubt about c Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-11 23:09 -0600
        [OT] Doubt vs. question.  (Re: a doubt about c) Roberto Waltman <usenet@rwaltman.com> - 2011-06-12 10:05 -0400
          Re: [OT] Doubt vs. question.  (Re: a doubt about c) Keith Thompson <kst-u@mib.org> - 2011-06-12 11:22 -0700
            Re: [OT] Doubt vs. question.  (Re: a doubt about c) Ben Pfaff <blp@cs.stanford.edu> - 2011-06-12 11:44 -0700
          Re: [OT] Doubt vs. question.  (Re: a doubt about c) Ralph Spitzner <rasp@spitzner.org> - 2011-06-13 11:31 +0200
            Re: [OT] Doubt vs. question.  (Re: a doubt about c) James Kuyper <jameskuyper@verizon.net> - 2011-06-15 10:03 -0400
              Re: [OT] Doubt vs. question. (Re: a doubt about c) Dr Nick <3-nospam@temporary-address.org.uk> - 2011-06-17 07:52 +0100
              Re: [OT] Doubt vs. question.  (Re: a doubt about c) Michael Press <rubrum@pacbell.net> - 2011-06-19 00:41 -0700
                Re: [OT] Doubt vs. question.  (Re: a doubt about c) James Kuyper <jameskuyper@verizon.net> - 2011-06-19 07:04 -0400
                  Re: [OT] Doubt vs. question.  (Re: a doubt about c) Bill Waddington <william.waddington@beezmo.com> - 2011-06-23 11:03 -0700
    Re: a doubt about c Shao Miller <sha0.miller@gmail.com> - 2011-06-11 11:23 -0500
      Re: a doubt about c pete <pfiland@mindspring.com> - 2011-06-11 13:56 -0400
        Re: a doubt about c "dr.oktopus" <blindwilly@freeonline.zzn.com> - 2011-06-11 12:53 -0700
          Re: a doubt about c Lew Pitcher <lpitcher@teksavvy.com> - 2011-06-11 16:01 -0400
          Re: a doubt about c Keith Thompson <kst-u@mib.org> - 2011-06-11 13:07 -0700
          Re: a doubt about c Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-11 14:13 -0600
            Re: a doubt about c Nobody <nobody@nowhere.com> - 2011-06-11 23:31 +0100
              Re: a doubt about c pete <pfiland@mindspring.com> - 2011-06-11 20:07 -0400
              Re: a doubt about c Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-11 23:05 -0600
        Re: a doubt about c Shao Miller <sha0.miller@gmail.com> - 2011-06-11 16:42 -0500
          Re: a doubt about c "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2011-06-11 14:23 -0700
            Re: a doubt about c Shao Miller <sha0.miller@gmail.com> - 2011-06-11 17:27 -0500
              Re: a doubt about c Keith Thompson <kst-u@mib.org> - 2011-06-11 15:42 -0700
    Re: a doubt about c Seebs <usenet-nospam@seebs.net> - 2011-06-13 14:39 +0000

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

#5904 — [OT] Doubt vs. question. (Re: a doubt about c)

Keith Thompson wrote:
>(Incidentally, the word "doubt" is not synonymous with "question",
>at least not in most dialects of English.  A "doubt" generally
>implies that you disbelieve something.)

I asked once about this, (don't recall if it was in c.l.c,) and was
told that in today's English as spoken in India, "doubt" an "question"
are indeed synonyms.
--
Roberto Waltman

[ Please reply to the group,
  return address is invalid ]

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

#5913 — Re: [OT] Doubt vs. question. (Re: a doubt about c)

Roberto Waltman <usenet@rwaltman.com> writes:
> Keith Thompson wrote:
>>(Incidentally, the word "doubt" is not synonymous with "question",
>>at least not in most dialects of English.  A "doubt" generally
>>implies that you disbelieve something.)
>
> I asked once about this, (don't recall if it was in c.l.c,) and was
> told that in today's English as spoken in India, "doubt" an "question"
> are indeed synonyms.

Yes, that's my understanding as well.

The point, I suppose, is that speakers of the Indian dialect of
English should be aware of this when posting to an international
forum like this one.  One solution would be for them to use the word
"question" instead.  And of course the rest of us also need to be
aware of the issue.

(Although I work with a number of people from India, and I don't
recall any of them ever using the word "doubt" in that way.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#5915 — Re: [OT] Doubt vs. question. (Re: a doubt about c)

Keith Thompson <kst-u@mib.org> writes:
["doubt" as "question" in Indian dialect of English]
> (Although I work with a number of people from India, and I don't
> recall any of them ever using the word "doubt" in that way.)

I have known some who do.  In particular, back when I was an
undergrad I remember an Indian teaching assistant who would ask
the class "any doubts?" during a lecture in place of "any
questions?".
-- 
Ben Pfaff 
http://benpfaff.org

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

#5961 — Re: [OT] Doubt vs. question. (Re: a doubt about c)

Roberto Waltman wrote:
> Keith Thompson wrote:
>> (Incidentally, the word "doubt" is not synonymous with "question",
>> at least not in most dialects of English.  A "doubt" generally
>> implies that you disbelieve something.)
>
> I asked once about this, (don't recall if it was in c.l.c,) and was
> told that in today's English as spoken in India, "doubt" an "question"
> are indeed synonyms.

Could be because to 'doubt' something is putting something in
question.

[Say "is this right the way it is ?"]

	-rasp

Just my 0.02EUR to the term itself :-P

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

#6107 — Re: [OT] Doubt vs. question. (Re: a doubt about c)

On 06/13/2011 05:31 AM, Ralph Spitzner wrote:
> Roberto Waltman wrote:
>> Keith Thompson wrote:
>>> (Incidentally, the word "doubt" is not synonymous with "question",
>>> at least not in most dialects of English.  A "doubt" generally
>>> implies that you disbelieve something.)
>>
>> I asked once about this, (don't recall if it was in c.l.c,) and was
>> told that in today's English as spoken in India, "doubt" an "question"
>> are indeed synonyms.
> 
> Could be because to 'doubt' something is putting something in
> question.
> 
> [Say "is this right the way it is ?"]

That's quite probably how that usage came into existence, but the point
is, it's still incorrect usage anywhere except Indian English, as far as
I know. The number of Indians who speak Indian English as a second
language is immense, but it's the native language of only a tiny
fraction of them. They need to be aware that this is a dialect-specific
usage, and one that is likely to confuse people who don't speak that
dialect. It should be avoided in contexts, such as this one, where most
of the participants don't speak that dialect.
-- 
James Kuyper

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

#6222 — Re: [OT] Doubt vs. question. (Re: a doubt about c)

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Kenneth Brody <kenbrody@spamcop.net> writes:
>>And, being an implementation-specific extension to "Standard English", is OT 
>>for clc.  :-)
>
>   According to the following page, one also might 
>   have written »An ask about C«.
>
> http://english.stackexchange.com/questions/4246/can-or-should-ask-ever-be-used-as-a-noun

Going ever further off topic (come and join us on alt.english.usage if
you want to talk properly about this stuff), the phrase "a big ask" has
become sports commentator jargon for "trying to do what he's paid a huge
sum of money for".
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

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

#6424 — Re: [OT] Doubt vs. question. (Re: a doubt about c)

In article <PIidncY06OIir2TQnZ2dnUVZ_vqdnZ2d@bestweb.net>,
 Kenneth Brody <kenbrody@spamcop.net> wrote:

> On 6/15/2011 10:03 AM, James Kuyper wrote:
> [... "Doubt" vs "Question" -- Indian-English ...]
> > That's quite probably how that usage came into existence, but the point
> > is, it's still incorrect usage anywhere except Indian English, as far as
> > I know. The number of Indians who speak Indian English as a second
> > language is immense, but it's the native language of only a tiny
> > fraction of them. They need to be aware that this is a dialect-specific
> > usage,
> 
> And, being an implementation-specific extension to "Standard English", is OT 
> for clc.  :-)
> 
> > and one that is likely to confuse people who don't speak that
> > dialect. It should be avoided in contexts, such as this one, where most
> > of the participants don't speak that dialect.
> 
> However, I believe that it's been seen enough in this group that us 
> "regulars" understand the usage, at least in the context of clc.
> 
> That said, "it couldn't hurt" to point out the possible confusion of such 
> usage, and encourage the posters to use "question" instead.

Not to mention (well actually I do mention it) that 
among native English speakers `doubt' and `question'
carry distinct overtones, so that confusing them 
decreases the resolution of sentences using those words.

-- 
Michael Press

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

#6434 — Re: [OT] Doubt vs. question. (Re: a doubt about c)

On 06/19/2011 03:41 AM, Michael Press wrote:
...
> Not to mention (well actually I do mention it) that 
> among native English speakers `doubt' and `question'
> carry distinct overtones, so that confusing them 
> decreases the resolution of sentences using those words.

That's not true of the native speakers of the Indian dialect of English.
Sources differ as to their number, but it seems to be somewhat less than
250,000, a rather small fraction of the number of speakers of that language.
-- 
James Kuyper

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

#6748 — Re: [OT] Doubt vs. question. (Re: a doubt about c)

On Sun, 19 Jun 2011 07:04:45 -0400, James Kuyper
<jameskuyper@verizon.net> wrote:

>On 06/19/2011 03:41 AM, Michael Press wrote:
>...
>> Not to mention (well actually I do mention it) that 
>> among native English speakers `doubt' and `question'
>> carry distinct overtones, so that confusing them 
>> decreases the resolution of sentences using those words.
>
>That's not true of the native speakers of the Indian dialect of English.
>Sources differ as to their number, but it seems to be somewhat less than
>250,000, a rather small fraction of the number of speakers of that language.

[a little more OT speculation]

Is it perhaps an influence of the speaker's first language?  Maybe
there's a Hindi word (if that's the correct language) that can mean
either "doubt" or "question".

For example, in Japanese "oshiemasu" can mean "teach" or "tell".  A
native speaker using English might say "teach me the answer".
Likewise, "shimasu" can mean "do" or "play."  A Tokyo PE instructor
once said to my son: "Sukotto, let's play swimming!"

I'm no expert on Hindi or Japanese, just curious.

Bill
-- 
William D Waddington
william.waddington@beezmo.com
"Even bugs...are unexpected signposts on
the long road of creativity..." - Ken Burtch

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

#5843

On 6/11/2011 8:11 AM, Ya Shou wrote:
>...
> I read some open source c program code, found a problem that let me doubt.
> All those programs are using macros to define constants, and did not use an enum to achieve, but I think in the enumeration constants is very convenient.
> Enumeration defines constants used in c++, but not seen any in c, why?
> ...

If you mean "integer constant expressions," I prefer to use 'enum's in C 
wherever possible.

If an integer constant expression needs to be used as part of an '#if' 
pre-processing directive, then I will '#define' and use a macro whose 
definition will not contain any identifiers (except other macros) or 
keywords.

   #define ALL_ONES_CHAR ((1 << CHAR_BIT) - 1)

   enum cv {
       cv_minute = 60,
       cv_timeout = 2 * cv_minute,
       cv_sector_size = 1 << 9,
       cv_max_buf_size = 4 * cv_sector_size,
       /* ... */
       cv_zero = 0
     };

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

#5846

Shao Miller wrote:
> 
> On 6/11/2011 8:11 AM, Ya Shou wrote:
> >...
> > I read some open source c program code, found a problem that let me doubt.
> > All those programs are using macros to define constants, and did not use an enum to achieve, but I think in the enumeration constants is very convenient.
> > Enumeration defines constants used in c++, but not seen any in c, why?
> > ...
> 
> If you mean "integer constant expressions," I prefer to use 'enum's in C
> wherever possible.
> 
> If an integer constant expression needs to be used as part of an '#if'
> pre-processing directive, then I will '#define' and use a macro whose
> definition will not contain any identifiers (except other macros) or
> keywords.
> 
>    #define ALL_ONES_CHAR ((1 << CHAR_BIT) - 1)

That's undefined if sizeof (int) equals one.

-- 
pete

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

#5849

On 11 Giu, 18:56, pete <pfil...@mindspring.com> wrote:
> Shao Miller wrote:
>
> >    #define ALL_ONES_CHAR ((1 << CHAR_BIT) - 1)
>
> That's undefined if sizeof (int) equals one.
>
> --

I think that ints are required to be at least 16 bits wide, so
sizeof (int) is always at least 2 (in all ANSI conforming
implementation)

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

#5851

On June 11, 2011 15:53, in comp.lang.c, blindwilly@freeonline.zzn.com wrote:

> On 11 Giu, 18:56, pete <pfil...@mindspring.com> wrote:
>> Shao Miller wrote:
>>
>> > #define ALL_ONES_CHAR ((1 << CHAR_BIT) - 1)
>>
>> That's undefined if sizeof (int) equals one.
>>
>> --
> 
> I think that ints are required to be at least 16 bits wide, so
> sizeof (int) is always at least 2
> (in all ANSI conforming implementation)

No

  sizeof(int) may be 1 in an ISO (and ANSI) conforming implementation
Granted, CHAR_BIT would have to be greater than 8 in such a configuration.

-- 
Lew Pitcher
Master Codewright & JOAT-in-training   | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
----------      Slackware - Because I know what I'm doing.         ------

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

#5852

"dr.oktopus" <blindwilly@freeonline.zzn.com> writes:
> On 11 Giu, 18:56, pete <pfil...@mindspring.com> wrote:
>> Shao Miller wrote:
>>
>> >    #define ALL_ONES_CHAR ((1 << CHAR_BIT) - 1)
>>
>> That's undefined if sizeof (int) equals one.
>
> I think that ints are required to be at least 16 bits wide,

Yes.  Specifically INT_MIN <= -32767, and INT_MAX >= 32767,
which implies that you need at least 16 bits.

>                                                             so
> sizeof (int) is always at least 2 (in all ANSI conforming
> implementation)

No.  sizeof (int) is at least 2 on systems with CHAR_BIT == 8,
but if CHAR_BIT >= 16, sizeof (int) can be 1.

Almost all modern implementations, and probably all actual hosted
implemenations, have CHAR_BIT==8, but I understand that there are
implemntations for DSPs (digital signal processors) with larger
CHAR_BIT values.

Note that a "byte" is defined in C by the value of CHAR_BIT; if
CHAR_BIT is 16, then a byte is 16 bits, not the more common 8 bits.

Incidentally, it makes more sense to talk about ISO conforming
implementations.  ISO issued the C99 standard; ANSI, the US standards
body, adopted it after puplication, as did other national standards
bodies.  (The previous standard was originally published by ANSI
in 1989 and adopted by ISO in 1990, and ANSI members have a strong
presence on the ISO committee, but ANSI itself has no real standing
outside the US.)  Referring to ISO C can also avoid confusion since,
for historical reasons, the phrase "ANSI C" commonly refers to the
1989/1990 standard, not the current 1999 standard.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#5853

"dr.oktopus" <blindwilly@freeonline.zzn.com> writes:

> On 11 Giu, 18:56, pete <pfil...@mindspring.com> wrote:
>> Shao Miller wrote:
>>
>> >    #define ALL_ONES_CHAR ((1 << CHAR_BIT) - 1)
>>
>> That's undefined if sizeof (int) equals one.
>>
>> --
>
> I think that ints are required to be at least 16 bits wide, so
> sizeof (int) is always at least 2 (in all ANSI conforming
> implementation)

A brief search of the C99 standard failed to turn this up.  I was able
to find (in 6.2.5):

    A ``plain'' int object has the natural size suggested by the
    architecture of the execution environment (large enough to contain
    any value in the range INT_MIN to INT_MAX as defined in the header
    <limits.h>).

(which doesn't say you can't have a 1-byte int).  That said, I don't
think I've ever encountered a compiler (even for an 8 bit processor)
that didn't use at least a 16 bit int.

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

#5863

On Sat, 11 Jun 2011 14:13:58 -0600, Joe Pfeiffer wrote:

> A brief search of the C99 standard failed to turn this up.  I was able
> to find (in 6.2.5):
> 
>     A ``plain'' int object has the natural size suggested by the
>     architecture of the execution environment (large enough to contain
>     any value in the range INT_MIN to INT_MAX as defined in the header
>     <limits.h>).
> 
> (which doesn't say you can't have a 1-byte int).  That said, I don't
> think I've ever encountered a compiler (even for an 8 bit processor)
> that didn't use at least a 16 bit int.

From 5.2.4.2.1, the smallest permitted values for for INT_MIN and INT_MAX
are:

         -- minimum value for an object of type int
            INT_MIN                     -32767 // -(215-1)

         -- maximum value for an object of type int
            INT_MAX                     +32767 // 215-1

So you can only have a 1-byte int if you have 16-bit bytes.

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

#5873

Nobody wrote:
> 
> On Sat, 11 Jun 2011 14:13:58 -0600, Joe Pfeiffer wrote:
> 
> > A brief search of the C99 standard failed to turn this up.  I was able
> > to find (in 6.2.5):
> >
> >     A ``plain'' int object has the natural size suggested by the
> >     architecture of the execution environment (large enough to contain
> >     any value in the range INT_MIN to INT_MAX as defined in the header
> >     <limits.h>).
> >
> > (which doesn't say you can't have a 1-byte int).  That said, I don't
> > think I've ever encountered a compiler (even for an 8 bit processor)
> > that didn't use at least a 16 bit int.
> 
> From 5.2.4.2.1, the smallest permitted values for for INT_MIN and INT_MAX
> are:
> 
>          -- minimum value for an object of type int
>             INT_MIN                     -32767 // -(215-1)
> 
>          -- maximum value for an object of type int
>             INT_MAX                     +32767 // 215-1
> 
> So you can only have a 1-byte int if you have 16-bit bytes.

... or bytes with more than 16 bits.

-- 
pete

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

#5879

Nobody <nobody@nowhere.com> writes:

> On Sat, 11 Jun 2011 14:13:58 -0600, Joe Pfeiffer wrote:
>
>> A brief search of the C99 standard failed to turn this up.  I was able
>> to find (in 6.2.5):
>> 
>>     A ``plain'' int object has the natural size suggested by the
>>     architecture of the execution environment (large enough to contain
>>     any value in the range INT_MIN to INT_MAX as defined in the header
>>     <limits.h>).
>> 
>> (which doesn't say you can't have a 1-byte int).  That said, I don't
>> think I've ever encountered a compiler (even for an 8 bit processor)
>> that didn't use at least a 16 bit int.
>
> From 5.2.4.2.1, the smallest permitted values for for INT_MIN and INT_MAX
> are:
>
>          -- minimum value for an object of type int
>             INT_MIN                     -32767 // -(215-1)
>
>          -- maximum value for an object of type int
>             INT_MAX                     +32767 // 215-1
>
> So you can only have a 1-byte int if you have 16-bit bytes.

Thanks.  Of course, the macro still doesn't work in that case!

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

#5855

On 6/11/2011 12:56 PM, pete wrote:
> Shao Miller wrote:
>>
>> On 6/11/2011 8:11 AM, Ya Shou wrote:
>>> ...
>>> I read some open source c program code, found a problem that let me doubt.
>>> All those programs are using macros to define constants, and did not use an enum to achieve, but I think in the enumeration constants is very convenient.
>>> Enumeration defines constants used in c++, but not seen any in c, why?
>>> ...
>>
>> If you mean "integer constant expressions," I prefer to use 'enum's in C
>> wherever possible.
>>
>> If an integer constant expression needs to be used as part of an '#if'
>> pre-processing directive, then I will '#define' and use a macro whose
>> definition will not contain any identifiers (except other macros) or
>> keywords.
>>
>>     #define ALL_ONES_CHAR ((1<<  CHAR_BIT) - 1)
>
> That's undefined if sizeof (int) equals one.
>

Do you mean if 'sizeof (intmax_t) == 1'[6.10.1p4] (assuming C99)?

So it's undefined if 'CHAR_BIT' is greater than or equal to the width of 
'intmax_t'[6.5.7p3], right?

I think that 6.2.6.2p1 implies that there are no padding bits for 
'unsigned char'.  Would you agree?

'char', 'signed char', 'unsigned char' have the same 
'sizeof'[6.5.3.4p3], would you agree?

The width of 'signed char' must be less than or equal to 
'CHAR_BIT'[6.2.6.2p2, 6.2.6.2p6], right?

If 'sizeof (int) == 1', then the width of 'int' must be less than or 
equal to 'CHAR_BIT', do you suppose?  If that holds, then all of the 
values of 'unsigned char' cannot be represented by 'int', is that so?

If 'sizeof (int) == sizeof (unsigned int)'[6.2.5p6], and if 'sizeof 
(int) == 1', then the width of 'unsigned int' must be less than or equal 
to 'CHAR_BIT', is that so?  If so:

The width of 'int' cannot be less than the width of 'signed 
char'[6.2.5p8] and the width of 'unsigned int' cannot be less than the 
width of 'unsigned char' due to their ranks[6.3.1.1p1], if I'm not mistaken.

If 'intmax_t' is a type whose values can represent the values of all 
signed types[7.18.1.5p1], then I would conclude from all of this that 
the behaviour is only undefined if the width of 'intmax_t' is the same 
as the width of 'int' and is also the same as the width of 'signed 
char'.  Does that make sense?

If that conclusion holds as true and your statement that the behaviour 
is undefined holds as true, then I think that there could be no signed 
integer values that are not representable as 'signed char'.  What do you 
think?

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

#5859

On Jun 11, 10:42 pm, Shao Miller <sha0.mil...@gmail.com> wrote:

> If that conclusion holds as true and your statement that the behaviour
> is undefined holds as true, then I think that there could be no signed
> integer values that are not representable as 'signed char'.  What do you
> think?

It's the shift operation by itself that would be undefined. For
example, if int has 32 bits then any shift of a signed or unsigned int
by 32 or more bits is undefined. If an int has CHAR_BIT bits, then any
shift of a signed or unsigned int by CHAR_BIT or more bits is
undefined.

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

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

Back to top | Article view | comp.lang.c

csiph-web