comp.lang.c - 6 new messages in 4 topics - digest

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

* Esoteric definitions of TRUE and FALSE - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/30ef3f092afa5a2e?hl=en
* Reading from files and range of char and friends - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/9ea72d3469ce4fc3?hl=en
* Is "int main() { }" strictly conforming? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/ccd6b9c5c69f2740?hl=en
* What scope are struct members in? - 3 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/fa070eeedafcafec?hl=en

==============================================================================
TOPIC: Esoteric definitions of TRUE and FALSE
http://groups.google.com/group/comp.lang.c/t/30ef3f092afa5a2e?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 11 2011 9:02 pm
From: pete

John Gordon wrote:
>
> In <kfnei6dz97v.fsf@x-alumni2.alumni.caltech.edu> Tim Rentsch <txr@alumni.caltech.edu> writes:
>
> > ram@zedat.fu-berlin.de (Stefan Ram) writes:
>
> > > Keith Thompson <kst-u@mib.org> writes:
> > >>are equally correct, but the shorter form is definitely *better*.
> > >
> > > This I use a my general style guideline:
> > >
> > > When two wordings are equivalent, use the shorter one.
> > >
> > > More precise:
> > >
> > > When two wordings are equivalent, and there is no other
> > > strong reason to prefer one of them, use the shorter one.
>
> > This is a vacuous statement unless some effort is made to
> > identify which reasons might be sufficiently compelling
> > to justify a longer wording and which others are not.
>
> I disagree.
> There can be any number of reasons to prefer one equivalent
> wording over another, and those reasons can vary wildly depending on
> the problem domain.
>
> Just to pick one random example,
> if you're writing user documentation you
> might prefer a passage with a friendly tone versus a shorter one that
> contains the same technical content but is terse and unwelcoming.

This fragment
if ((c) != '\0')
and this fragment
if (c)
are exactly equivalent,
in any context,
regardless of the type of (c).

If c was assigned the value of a byte in a string,
I would write
if (c != '\0')
instead of
if (c)

--
pete

==============================================================================
TOPIC: Reading from files and range of char and friends
http://groups.google.com/group/comp.lang.c/t/9ea72d3469ce4fc3?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 11 2011 9:14 pm
From: pete

Keith Thompson wrote:
>
> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
> > On 3/11/2011 4:57 PM, lawrence.jones@siemens.com wrote:
> >> Tim Rentsch<txr@alumni.caltech.edu> wrote:
> >>>
> >>> A call to getc() cannot return negative zero. The reason is,
> >>> getc() is defined in terms of fgetc(), which returns an
> >>> 'unsigned char' converted to an 'int', and such conversions
> >>> cannot produce negative zeros.
> >>
> >> They can if char and int are the same size.
> >
> > Despite 6.2.6.2p3? In ISO/IEC 9899:TC3 (perhaps the wording
> > has changed in more recent versions), "conversion" is not listed
> > among the operations that can generate a negative zero. Even if
> > a negative zero arises, this paragraph says it's unspecified whether
> > storing it in an object stores a negative or a "normal" zero.
>
> 6.3p2:
>
> Conversion of an operand value to a compatible type causes no
> change to the value or the representation.
>
> Looks like a mild inconsistency.

I don't see the relevance of that quote,
because it is about compatible type conversion,
and I don't see anything about compatible types
in the above quoted post.

--
pete

==============================================================================
TOPIC: Is "int main() { }" strictly conforming?
http://groups.google.com/group/comp.lang.c/t/ccd6b9c5c69f2740?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 11 2011 11:54 pm
From: Tim Rentsch

"Johannes Schaub (litb)" <schaub.johannes@googlemail.com> writes:

> The spec says it can be defined as
>
> int main(void) { /* ... */ }
>
> or
>
> int main(int argc, char *argv[]) { /* ... */ }
>
> or equivalent. Or in some implementation-defined manner (not strictly
> conforming anymore).
>
> Because "int main() { }" is not equivalent to "int main(void) { }", I take
> it that "int main() { }" is not supported for strictly conforming programs?

will respond in comp.std.c.

==============================================================================
TOPIC: What scope are struct members in?
http://groups.google.com/group/comp.lang.c/t/fa070eeedafcafec?hl=en
==============================================================================

== 1 of 3 ==
Date: Sat, Mar 12 2011 12:01 am
From: "Johannes Schaub (litb)"

Eric Sosman wrote:

> On 3/11/2011 9:45 PM, Stefan Ram wrote:
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>> »the identifier is visible (i.e., can be used) only
>>> within a region of program text called its scope.«,
>>
>> For example,
>>
>> struct a { int b; }; int main( void ){ b; }
>>
>> test.c:1: error: 'b' undeclared (first use in this function)
>>
>> , doesn't sound as if »b« would be visible in main.
>>
>> But, of course, gcc is just a compiler.
>>
>> But ISO/IEC 9899:1999 (E) even explains »visible«:
>> »can be used« (see quotation above).
>>
>> »b« cannot be used in main above.
>>
>> We could add »a.« in front of »b« - but then it would
>> be another program, so assertions about the scope in
>> this other program would not be valid for the program
>> above.
>
> You're using "scope" for two notions that the Standard calls
> "scope" and "name space." The identifier `b' is in scope everywhere
> after its declaration -- including inside main() -- but has meaning
> only in the name space of `struct a'. See 6.2.3.
>

The Standard introduces the concept of "namespaces" as merely a syntactic
construct to disambiguate uses, and not as a semantic entity that somehow
"contains" identifiers.

What does "in the namespace" mean?

== 2 of 3 ==
Date: Sat, Mar 12 2011 12:07 am
From: "Johannes Schaub (litb)"

Stefan Ram wrote:

> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>»the identifier is visible (i.e., can be used) only
>>within a region of program text called its scope.«,
>
> For example,
>
> struct a { int b; }; int main( void ){ b; }
>
> test.c:1: error: 'b' undeclared (first use in this function)
>
> , doesn't sound as if »b« would be visible in main.
>
> But, of course, gcc is just a compiler.
>
> But ISO/IEC 9899:1999 (E) even explains »visible«:
> »can be used« (see quotation above).
>
> »b« cannot be used in main above.
>
> We could add »a.« in front of »b« - but then it would
> be another program, so assertions about the scope in
> this other program would not be valid for the program
> above.

No, "b" can be used in "main". But if you just do "b;", it will look into
the ordinary namespace for identifiers. You have to use an "a." or "a->" to
make it look into the struct-A members namespace of the global scope to use
"b" in main.

Just like you have to use "struct a" to use the identifier "a" in main,
which is in the tags namespace of the global scope.

== 3 of 3 ==
Date: Sat, Mar 12 2011 12:05 am
From: "Johannes Schaub (litb)"

Johannes Schaub (litb) wrote:

> Eric Sosman wrote:
>
>> On 3/11/2011 9:45 PM, Stefan Ram wrote:
>>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>>> »the identifier is visible (i.e., can be used) only
>>>> within a region of program text called its scope.«,
>>>
>>> For example,
>>>
>>> struct a { int b; }; int main( void ){ b; }
>>>
>>> test.c:1: error: 'b' undeclared (first use in this function)
>>>
>>> , doesn't sound as if »b« would be visible in main.
>>>
>>> But, of course, gcc is just a compiler.
>>>
>>> But ISO/IEC 9899:1999 (E) even explains »visible«:
>>> »can be used« (see quotation above).
>>>
>>> »b« cannot be used in main above.
>>>
>>> We could add »a.« in front of »b« - but then it would
>>> be another program, so assertions about the scope in
>>> this other program would not be valid for the program
>>> above.
>>
>> You're using "scope" for two notions that the Standard calls
>> "scope" and "name space." The identifier `b' is in scope everywhere
>> after its declaration -- including inside main() -- but has meaning
>> only in the name space of `struct a'. See 6.2.3.
>>
>
> The Standard introduces the concept of "namespaces" as merely a syntactic
> construct to disambiguate uses, and not as a semantic entity that somehow
> "contains" identifiers.
>
> What does "in the namespace" mean?

Ah I think I get this now. The name spaces divide a scope into multiple
sections.

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en

To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en