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

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

howmany -- What the F**k ?

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

Contents

  howmany -- What the F**k ? James Dow Allen <gmail@jamesdowallen.nospam> - 2015-11-18 12:01 +0000
    Re: howmany -- What the F**k ? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-18 07:52 -0500
      Re: howmany -- What the F**k ? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-18 05:14 -0800
      Re: howmany -- What the F**k ? Keith Thompson <kst-u@mib.org> - 2015-11-18 08:26 -0800
        Re: howmany -- What the F**k ? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-18 11:44 -0500
          Re: howmany -- What the F**k ? Keith Thompson <kst-u@mib.org> - 2015-11-18 09:08 -0800
    Re: howmany -- What the F**k ? James Kuyper <jameskuyper@verizon.net> - 2015-11-18 08:31 -0500
    Re: howmany -- What the F**k ? Keith Thompson <kst-u@mib.org> - 2015-11-18 08:25 -0800
      Re: howmany -- What the F**k ? James Dow Allen <jdallen2000@yahoo.com> - 2015-11-18 11:58 -0800
        Re: howmany -- What the F**k ? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-18 15:14 -0500
          Re: howmany -- What the F**k ? James Dow Allen <jdallen2000@yahoo.com> - 2015-11-18 17:48 -0800
            Re: howmany -- What the F**k ? James Kuyper <jameskuyper@verizon.net> - 2015-11-18 21:06 -0500
            Re: howmany -- What the F**k ? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-19 08:23 -0500
            Re: howmany -- What the F**k ? Keith Thompson <kst-u@mib.org> - 2015-11-19 21:45 -0800
            Re: howmany -- What the F**k ? Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-20 12:55 -0800
    Re: howmany -- What the F**k ? Keith Thompson <kst-u@mib.org> - 2015-11-20 03:27 -0800
      Re: howmany -- What the F**k ? Philip Lantz <prl@canterey.us> - 2015-11-21 20:40 -0800
        Re: howmany -- What the F**k ? James Kuyper <jameskuyper@verizon.net> - 2015-11-22 10:09 -0500
          Re: howmany -- What the F**k ? Philip Lantz <prl@canterey.us> - 2015-11-22 10:18 -0800
            Re: howmany -- What the F**k ? gazelle@shell.xmission.com (Kenny McCormack) - 2015-11-22 18:35 +0000
              Re: howmany -- What the F**k ? Philip Lantz <prl@canterey.us> - 2015-11-22 13:10 -0800
            Re: howmany -- What the F**k ? James Kuyper <jameskuyper@verizon.net> - 2015-11-22 13:57 -0500
              Re: howmany -- What the F**k ? Philip Lantz <prl@canterey.us> - 2015-11-22 13:02 -0800
                Re: howmany -- What the F**k ? James Kuyper <jameskuyper@verizon.net> - 2015-11-22 16:15 -0500
            Re: howmany -- What the F**k ? James Kuyper <jameskuyper@verizon.net> - 2015-11-23 06:33 -0500
              Re: howmany -- What the F**k ? gazelle@shell.xmission.com (Kenny McCormack) - 2015-11-23 12:17 +0000
              Re: howmany -- What the F**k ? Philip Lantz <prl@canterey.us> - 2015-11-23 21:09 -0800
          Re: howmany -- What the F**k ? Keith Thompson <kst-u@mib.org> - 2015-11-22 12:34 -0800
            Re: howmany -- What the F**k ? James Kuyper <jameskuyper@verizon.net> - 2015-11-22 16:18 -0500

Page 2 of 2 — ← Prev page 1 [2]

#76916

Kenny McCormack wrote:
> Philip Lantz wrote:
> ...
> >Am I not allowed to do this:
> >
> >struct s { int _howmany; };
> >
> >?
> >
> >(And by "allowed", I mean, of course, that it is syntactically
> >correct and doesn't result in undefined behavior.)
> 
> Two comments:
> 
>     1) It sure seems to me like that *should* be OK (since there really
> 	isn't any possibility of a legitimate conflict with the the system),
> 	but I'm pretty sure the pedants will tell you that it is not.

Actually, I'm quite sure that the pedants will tell me that it is. (It was
a rhetorical question.)

>     2) This seems to me like an area where compiler can and should trap
> 	this sort of thing (declaring, outside of a struct, int _foo;) as a
> 	syntax error.  Yes, I know all the arguments why it isn't done, but
> 	I maintain that it could (and should) be done.

This is an interesting point. I've never seen a compiler that distinguishes
between definitions of reserved identifiers in standard headers, which is
allowed, of course--since that is what they are reserved for, and definitions
in user code, which result in undefined behavior. In most implementations,
the distinction between these sources is blurred by the preprocessor, but
still, it would not be difficult for the compiler to make the distinction
and give warnings.

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

#76901

On 11/22/2015 01:18 PM, Philip Lantz wrote:
> James Kuyper wrote:
...
>> Why not? I thought the original complaint was about the conflict with a
>> user-defined identifier with the same name. Users have no right to
>> expect a lack of conflict if they use identifiers with file scope that
>> start with an underscore. (7.1.3p1).
> 
> Am I not allowed to do this:
> 
> struct s { int _howmany; };
> 
> ?

Sorry - the rule is short enough that I should have simply quoted it,
rather than summarizing it. My summary left out an important detail
relevant to that example:

"All identifiers that begin with an underscore are always reserved for
use as identifiers with file scope in both the ordinary and tag name
spaces."

Each structure or union has a separate name space for it's members.
(6.2.3p1), so in this case _howmany is in neither the ordinary nor the
tag name space.

Many people keep things simple by never defining identifiers starting
with underscore in any context, even the ones where they're permitted. I
recommend following that approach unless and until you have memorized
7.1.3p1, and possibly even then.

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

#76912

James Kuyper wrote:
> Philip Lantz wrote:
> > James Kuyper wrote:
> ...
> >> Why not? I thought the original complaint was about the conflict with a
> >> user-defined identifier with the same name. Users have no right to
> >> expect a lack of conflict if they use identifiers with file scope that
> >> start with an underscore. (7.1.3p1).
> > 
> > Am I not allowed to do this:
> > 
> > struct s { int _howmany; };
> > 
> > ?
> 
> Sorry - the rule is short enough that I should have simply quoted it,
> rather than summarizing it. My summary left out an important detail
> relevant to that example:
> 
> "All identifiers that begin with an underscore are always reserved for
> use as identifiers with file scope in both the ordinary and tag name
> spaces."
> 
> Each structure or union has a separate name space for it's members.
> (6.2.3p1), so in this case _howmany is in neither the ordinary nor the
> tag name space.
> 
> Many people keep things simple by never defining identifiers starting
> with underscore in any context, even the ones where they're permitted. I
> recommend following that approach unless and until you have memorized
> 7.1.3p1, and possibly even then.

Just to be completely clear, you now agree that my example above is
allowed, right? We use a coding standard (not developed by me), in
which the names of "private"* members of structures start with _.
I would be chagrined to discover that that results in undefined
behavior.

But this is not allowed at file scope:
struct _s { int x; };

Nor this, at file scope:
int _s;


* By "private", I mean members that are intended to be manipulated
only by functions whose purpose is to manage instances of the
struct. You may recognize a similarity to another language that is
off-topic here.

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

#76918

On 11/22/2015 04:02 PM, Philip Lantz wrote:
> James Kuyper wrote:
>> Philip Lantz wrote:
>>> James Kuyper wrote:
>> ...
>>>> Why not? I thought the original complaint was about the conflict with a
>>>> user-defined identifier with the same name. Users have no right to
>>>> expect a lack of conflict if they use identifiers with file scope that
>>>> start with an underscore. (7.1.3p1).
>>>
>>> Am I not allowed to do this:
>>>
>>> struct s { int _howmany; };
>>>
>>> ?
>>
>> Sorry - the rule is short enough that I should have simply quoted it,
>> rather than summarizing it. My summary left out an important detail
>> relevant to that example:
>>
>> "All identifiers that begin with an underscore are always reserved for
>> use as identifiers with file scope in both the ordinary and tag name
>> spaces."
>>
>> Each structure or union has a separate name space for it's members.
>> (6.2.3p1), so in this case _howmany is in neither the ordinary nor the
>> tag name space.
>>
>> Many people keep things simple by never defining identifiers starting
>> with underscore in any context, even the ones where they're permitted. I
>> recommend following that approach unless and until you have memorized
>> 7.1.3p1, and possibly even then.
> 
> Just to be completely clear, you now agree that my example above is
> allowed, right? ...

Yes, it is allowed. I never disagreed with your example.

> ... We use a coding standard (not developed by me), in
> which the names of "private"* members of structures start with _.
> I would be chagrined to discover that that results in undefined
> behavior.
> 
> But this is not allowed at file scope:
> struct _s { int x; };
> 
> Nor this, at file scope:
> int _s;

Correct.

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

#76979

On 11/22/2015 01:18 PM, Philip Lantz wrote:
> James Kuyper wrote:
>> Philip Lantz wrote:
>>> Keith Thompson wrote:
>>>> James Dow Allen writes:
>>>>> sys/types.h has
>>>>> 	#define  howmany(x,y)    (((x)+((y)-1))/(y))
>>>>
>>>> Reported: https://cygwin.com/ml/cygwin/2015-11/msg00293.html
>>>
>>> The proposed fix in that thread appears to be to use _howmany instead
>>> of howmany. That's not an improvement...
>>
>> Why not? I thought the original complaint was about the conflict with a
>> user-defined identifier with the same name. Users have no right to
>> expect a lack of conflict if they use identifiers with file scope that
>> start with an underscore. (7.1.3p1).
> 
> Am I not allowed to do this:
> 
> struct s { int _howmany; };
> 
> ?
> 
> (And by "allowed", I mean, of course, that it is syntactically
> correct and doesn't result in undefined behavior.)

It took me a couple of hours after I read Keith's post yesterday, before
I finally realized what was going on here. When I suggested that
_howmany was fine, I was thinking only of the original context, where
the macro howmany() conflicted with a user-defined function named
howmany(), necessarily at file scope.
By bringing up struct s, you were pointing out that this macro, if named
_homwany(), would still disrupt the definition of struct s, even though
it didn't violate 7.3.1. However, by the time I read your message, I was
thinking only about confirming your belief that your use of _howmany()
doesn't violate 7.3.1. I wasn't thinking about the fact that an
implementation-defined macro named _howmany() therefore does break those
rules.

Sorry for any confusing comments I made.
-- 
James Kuyper

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

#76983

In article <n2utda$2ep$1@dont-email.me>,
James Kuyper  <jameskuyper@verizon.net> wrote:
...
>When I suggested that _howmany was fine, I was thinking only of the
>original context, where the macro howmany() conflicted with a user-defined
>function named howmany(), necessarily at file scope.
>
>By bringing up struct s, you were pointing out that this macro, if named
>_homwany(), would still disrupt the definition of struct s, even though
>it didn't violate 7.3.1. However, by the time I read your message, I was
>thinking only about confirming your belief that your use of _howmany()
>doesn't violate 7.3.1. I wasn't thinking about the fact that an
>implementation-defined macro named _howmany() therefore does break those
>rules.

Aha!  So, this actually shows that both of the following are true:

    1) Keith was right in saying that you should just avoid it entirely,
	even if, technically, the standard allows it.  (The "it" in
	question being defining a struct element named "_howmany")

    2) The standard should be changed to make it illegal (in all cases).

-- 
The last time a Republican cared about you, you were a fetus.

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

#77053

James Kuyper wrote:
> 
> On 11/22/2015 01:18 PM, Philip Lantz wrote:
> > James Kuyper wrote:
> >> Philip Lantz wrote:
> >>> Keith Thompson wrote:
> >>>> James Dow Allen writes:
> >>>>> sys/types.h has
> >>>>> 	#define  howmany(x,y)    (((x)+((y)-1))/(y))
> >>>>
> >>>> Reported: https://cygwin.com/ml/cygwin/2015-11/msg00293.html
> >>>
> >>> The proposed fix in that thread appears to be to use _howmany instead
> >>> of howmany. That's not an improvement...
> >>
> >> Why not? I thought the original complaint was about the conflict with a
> >> user-defined identifier with the same name. Users have no right to
> >> expect a lack of conflict if they use identifiers with file scope that
> >> start with an underscore. (7.1.3p1).
> > 
> > Am I not allowed to do this:
> > 
> > struct s { int _howmany; };
> > 
> > ?
> > 
> > (And by "allowed", I mean, of course, that it is syntactically
> > correct and doesn't result in undefined behavior.)
> 
> It took me a couple of hours after I read Keith's post yesterday, before
> I finally realized what was going on here. When I suggested that
> _howmany was fine, I was thinking only of the original context, where
> the macro howmany() conflicted with a user-defined function named
> howmany(), necessarily at file scope.
> By bringing up struct s, you were pointing out that this macro, if named
> _homwany(), would still disrupt the definition of struct s, even though
> it didn't violate 7.3.1. However, by the time I read your message, I was
> thinking only about confirming your belief that your use of _howmany()
> doesn't violate 7.3.1. I wasn't thinking about the fact that an
> implementation-defined macro named _howmany() therefore does break those
> rules.
> 
> Sorry for any confusing comments I made.

Yep, I figured all that out while I was trying to write a response to
your last message yesterday, which was why I didn't send that response.

On my part, it took me a while to realize that my example didn't actually
demonstrate a conflict with a function-type macro (as Keith's did), and
that the change from howmany to _howmany does solve some cases, even
though it doesn't solve everything.

So it's all good. Thanks.

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

#76907

James Kuyper <jameskuyper@verizon.net> writes:
> On 11/21/2015 11:40 PM, Philip Lantz wrote:
>> Keith Thompson wrote:
>>> James Dow Allen writes:
>>>> sys/types.h has
>>>> 	#define  howmany(x,y)    (((x)+((y)-1))/(y))
>>>
>>> Reported: https://cygwin.com/ml/cygwin/2015-11/msg00293.html
>> 
>> The proposed fix in that thread appears to be to use _howmany instead
>> of howmany. That's not an improvement...
>
> Why not? I thought the original complaint was about the conflict with a
> user-defined identifier with the same name. Users have no right to
> expect a lack of conflict if they use identifiers with file scope that
> start with an underscore. (7.1.3p1).

I believe this program is strictly conforming.  It defines the
identifier _howmany at block scope.

    #include <stdio.h>
    void func(void) { }
    int main(void) {
        void (*_howmany)(void) = func;
        _howmany();
    }

If including <stdio.h> results in the definition of a function-like
macro named "_howmany" that requires one or more arguments, then the
program will fail to compile, which implies that the implementation
is non-conforming.

-- 
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]

#76919

On 11/22/2015 03:34 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
>> On 11/21/2015 11:40 PM, Philip Lantz wrote:
>>> Keith Thompson wrote:
>>>> James Dow Allen writes:
>>>>> sys/types.h has
>>>>> 	#define  howmany(x,y)    (((x)+((y)-1))/(y))
>>>>
>>>> Reported: https://cygwin.com/ml/cygwin/2015-11/msg00293.html
>>>
>>> The proposed fix in that thread appears to be to use _howmany instead
>>> of howmany. That's not an improvement...
>>
>> Why not? I thought the original complaint was about the conflict with a
>> user-defined identifier with the same name. Users have no right to
>> expect a lack of conflict if they use identifiers with file scope that
>> start with an underscore. (7.1.3p1).
> 
> I believe this program is strictly conforming.  It defines the
> identifier _howmany at block scope.
> 
>     #include <stdio.h>
>     void func(void) { }
>     int main(void) {
>         void (*_howmany)(void) = func;
>         _howmany();
>     }
> 
> If including <stdio.h> results in the definition of a function-like
> macro named "_howmany" that requires one or more arguments, then the
> program will fail to compile, which implies that the implementation
> is non-conforming.

You're right - for a macro they need an identifier that is reserved "for
all uses", not just at file scope. I should have thought of that.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web