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 1 of 2  [1] 2  Next page →

#76389 — howmany -- What the F**k ?

I run gcc under cygwin and recently discovered something that made me
furious^H^H^H^H^H^H^H^H^H^H^H annoyed me a little. 

I named a function howmany().  Not __howmany() or HoWmAnY() or
___SYS__howmanY() or whatever the reserving rules prohibit, just
howmany(). 

Of course I got a weird syntax error and immediately guessed what was 
wrong.  I changed the function name to howmany_and_fuk_you_too(), and it 
worked.  But I still took the time to track it down.  Note that one can 
imagine situations where debugging would have been harder.

sys/types.h has
	#define  howmany(x,y)    (((x)+((y)-1))/(y))

The problem was caused by my including stdio.h, a header I barely use.  
I see that it is
  " Copyright (c) 1990 The Regents of the University of California."
stdio.h includes sys/types.h which doesn't deign to identify its
source or copyright owner, though other headers in the same directory 
mention "Red Hat, Inc." and "CYGWIN_LICENSE."

(Trying to play like the pedants, I even include stdlib.h -- a header 
which has absolutely no value to me except suppressing an inane warning 
about exit().  Perhaps I should stop including it before its zillions of 
garbage defines find a way of causing more trouble.)

So my questions are:

(1) Do any of you ever use the RedHat/Whatever howmany() ?
I often need that facility but ... gasp! ... invest several hundred
milliseconds to type out the arithmetic myself.  Or, gasp, write my own 
inane macros in my own inane header file using names and usages, gasp, 
convenient for me.

(2) Should such garbage be given reserved names like
  ___WHATEVER___howmany() ?
(I'm uninterested in details about "reserved names" -- I don't
think "howmany" is reserved and that's what I'm talking about.)

Whatever genius defined howmany for me isn't the only problem.
j0, j1, yn etc. have been shitcanned for decades as soon as you
include math.h -- I guess the fear there was that bessel_j0()
would be less descriptive than j0().


Comments?

James Dow Allen

[toc] | [next] | [standalone]

#76394

On 11/18/2015 7:01 AM, James Dow Allen wrote:
> I run gcc under cygwin and recently discovered something that made me
> furious^H^H^H^H^H^H^H^H^H^H^H annoyed me a little.
>
> I named a function howmany().  Not __howmany() or HoWmAnY() or
> ___SYS__howmanY() or whatever the reserving rules prohibit, just
> howmany().
>
> Of course I got a weird syntax error and immediately guessed what was
> wrong.  I changed the function name to howmany_and_fuk_you_too(), and it
> worked.  But I still took the time to track it down.  Note that one can
> imagine situations where debugging would have been harder.
>
> sys/types.h has
> 	#define  howmany(x,y)    (((x)+((y)-1))/(y))
>
> The problem was caused by my including stdio.h, a header I barely use.
> I see that it is
>    " Copyright (c) 1990 The Regents of the University of California."
> stdio.h includes sys/types.h which doesn't deign to identify its
> source or copyright owner, though other headers in the same directory
> mention "Red Hat, Inc." and "CYGWIN_LICENSE."
>
> (Trying to play like the pedants, I even include stdlib.h -- a header
> which has absolutely no value to me except suppressing an inane warning
> about exit().  Perhaps I should stop including it before its zillions of
> garbage defines find a way of causing more trouble.)
>
> So my questions are:
>
> (1) Do any of you ever use the RedHat/Whatever howmany() ?
> I often need that facility but ... gasp! ... invest several hundred
> milliseconds to type out the arithmetic myself.  Or, gasp, write my own
> inane macros in my own inane header file using names and usages, gasp,
> convenient for me.
>
> (2) Should such garbage be given reserved names like
>    ___WHATEVER___howmany() ?
> (I'm uninterested in details about "reserved names" -- I don't
> think "howmany" is reserved and that's what I'm talking about.)
>
> Whatever genius defined howmany for me isn't the only problem.
> j0, j1, yn etc. have been shitcanned for decades as soon as you
> include math.h -- I guess the fear there was that bessel_j0()
> would be less descriptive than j0().
>
>
> Comments?

     Correctness meets reality, and correctness loses out.

     `howmany' and the other names you mentioned belong to the
programmer, not to the Standard or to the implementation.  An
implementation that declares them is non-conforming (unless
it's specifically been asked to do so, e.g., by inclusion of
a non-Standard header).

     I fooled around with various -std= settings and with -pedantic,
but found no combination that suppressed the bogus declaration.
Sloppy work in the headers, I guess, but ...

     ... correctness loses out.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

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

#76396

James Dow Allen, there are far better ways to be than vulgar.

Best regards,
Rick C. Hodgin

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

#76411

Eric Sosman <esosman@comcast-dot-net.invalid> writes:
[...]
>      `howmany' and the other names you mentioned belong to the
> programmer, not to the Standard or to the implementation.  An
> implementation that declares them is non-conforming (unless
> it's specifically been asked to do so, e.g., by inclusion of
> a non-Standard header).
>
>      I fooled around with various -std= settings and with -pedantic,
> but found no combination that suppressed the bogus declaration.
> Sloppy work in the headers, I guess, but ...
>
>      ... correctness loses out.

Are you also using Cygwin?

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

#76416

On 11/18/2015 11:26 AM, Keith Thompson wrote:
> Eric Sosman <esosman@comcast-dot-net.invalid> writes:
> [...]
>>       `howmany' and the other names you mentioned belong to the
>> programmer, not to the Standard or to the implementation.  An
>> implementation that declares them is non-conforming (unless
>> it's specifically been asked to do so, e.g., by inclusion of
>> a non-Standard header).
>>
>>       I fooled around with various -std= settings and with -pedantic,
>> but found no combination that suppressed the bogus declaration.
>> Sloppy work in the headers, I guess, but ...
>>
>>       ... correctness loses out.
>
> Are you also using Cygwin?

     For the fooling around mentioned, yes.  Armchair diagnosis
suggests that Cygwin's headers are insufficiently armored with
#ifdef and the like, and wind up usurping names that belong to
the programmer.

     "Proper armoring" is no small matter, because the C Standard
is often not the only governing document in play.  When you're
trying to follow the C Standard(s!) *and* a selection of POSIX
standards *and* something from X-Open *and* Lord knows what else,
the interactions and conflicts can be bafflingly baroque.  It's my
vague understanding that there are a few points on which the various
standards are in direct conflict, some requiring what others forbid.
The non-conformance of Cygwin's headers may not be due to sloppiness,
but to the sheer impossibility of satisfying multiple masters.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

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

#76425

Eric Sosman <esosman@comcast-dot-net.invalid> writes:
> On 11/18/2015 11:26 AM, Keith Thompson wrote:
[...]
>> Are you also using Cygwin?
>
>      For the fooling around mentioned, yes.  Armchair diagnosis
> suggests that Cygwin's headers are insufficiently armored with
> #ifdef and the like, and wind up usurping names that belong to
> the programmer.
>
>      "Proper armoring" is no small matter, because the C Standard
> is often not the only governing document in play.  When you're
> trying to follow the C Standard(s!) *and* a selection of POSIX
> standards *and* something from X-Open *and* Lord knows what else,
> the interactions and conflicts can be bafflingly baroque.  It's my
> vague understanding that there are a few points on which the various
> standards are in direct conflict, some requiring what others forbid.
> The non-conformance of Cygwin's headers may not be due to sloppiness,
> but to the sheer impossibility of satisfying multiple masters.

I don't *think* that's the case.  Certainly the maintainers of the POSIX
standard have been very careful to avoid conflicting with the C
standard.

I personally wish that all the POSIX-specific functionality had been
defined in headers other than the ones specified by ISO C, but there was
existing practice to consider.

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

#76397

On 11/18/2015 07:01 AM, James Dow Allen wrote:
> I run gcc under cygwin and recently discovered something that made me
> furious^H^H^H^H^H^H^H^H^H^H^H annoyed me a little. 
> 
> I named a function howmany().  Not __howmany() or HoWmAnY() or
> ___SYS__howmanY() or whatever the reserving rules prohibit, just
> howmany(). 
> 
> Of course I got a weird syntax error and immediately guessed what was 
> wrong.  I changed the function name to howmany_and_fuk_you_too(), and it 
> worked.  But I still took the time to track it down.  Note that one can 
> imagine situations where debugging would have been harder.
> 
> sys/types.h has
> 	#define  howmany(x,y)    (((x)+((y)-1))/(y))
> 
> The problem was caused by my including stdio.h, a header I barely use.  
> I see that it is
>   " Copyright (c) 1990 The Regents of the University of California."
> stdio.h includes sys/types.h which doesn't deign to identify its
> source or copyright owner, though other headers in the same directory 
> mention "Red Hat, Inc." and "CYGWIN_LICENSE."
...
> (2) Should such garbage be given reserved names like
>   ___WHATEVER___howmany() ?

Yes, that would have been one way to conform to the C standard.

Alternatively, howmany() should only have been #defined if an
appropriate option had been selected (or not selected, depending upon
the option). For example, many POSIX functions intrude on the name space
reserved by the C standard for users. However, the relevant headers only
declare those functions if __STRICT_ANSI__ is not #defined. The -ansi
option pre#defines that macro.
-- 
James Kuyper

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

#76410

James Dow Allen <gmail@jamesdowallen.nospam> writes:
> I run gcc under cygwin and recently discovered something that [...]
> annoyed me a little. 
>
> I named a function howmany().  [...]
>
> Of course I got a weird syntax error and immediately guessed what was 
> wrong.  I changed the function name to howmany_and_fuk_you_too(), and it 
> worked.  But I still took the time to track it down.  Note that one can 
> imagine situations where debugging would have been harder.
>
> sys/types.h has
> 	#define  howmany(x,y)    (((x)+((y)-1))/(y))
>
> The problem was caused by my including stdio.h, a header I barely use.  
[...]

gcc is not a conforming C compiler by default.  But even given that,
defining an identifier like `howmany` in a standard header is unwise at
best; I'd call it a bug.

> (Trying to play like the pedants, I even include stdlib.h -- a header 
> which has absolutely no value to me except suppressing an inane warning 
> about exit().  Perhaps I should stop including it before its zillions of 
> garbage defines find a way of causing more trouble.)

<stdlib.h> is the header that declares the exit() funcion.  That's not
an inane warning; it's telling you that you're calling an undeclared
function.  It's *probably* not going to cause problems (if it compiles),
but it's probably assuming that exit returns int rather than void.  My
advice: If you're going to call exit(), add the `#include <stdlib.h>`
(and then deal with any problems it might cause).

> So my questions are:
>
> (1) Do any of you ever use the RedHat/Whatever howmany() ?
> I often need that facility but ... gasp! ... invest several hundred
> milliseconds to type out the arithmetic myself.  Or, gasp, write my own 
> inane macros in my own inane header file using names and usages, gasp, 
> convenient for me.

I had never heard of it.

> (2) Should such garbage be given reserved names like
>   ___WHATEVER___howmany() ?

Yes.

> (I'm uninterested in details about "reserved names" -- I don't
> think "howmany" is reserved and that's what I'm talking about.)

That's a pity, because the details of which names are reserved are at
the heart of the problem you're having.  You're right, "howmany" isn't
reserved, and an implementation shouldn't be making it visible in a way
that interferes with user code.

> Whatever genius defined howmany for me isn't the only problem.
> j0, j1, yn etc. have been shitcanned for decades as soon as you
> include math.h -- I guess the fear there was that bessel_j0()
> would be less descriptive than j0().

Normally if you compile with something like

    gcc -std=cNN -pedantic

where NN is 89, 90, 99, or 11, it should avoid defining any non-reserved
identifiers.  If it doesn't, that's a bug.  (That goes for j0, j1, et al.)

I don't see the issue on my own system (Linux, gcc, glibc), but I seem
to recall running into something similar on Cygwin, which uses a
different library implementation.  I have a Cygwin system at home; I'll
try to look into it in the next few days.

You can report the bug on one of the Cygwin mailing lists.  I suggest
showing a minimal test case that defines `howmany`, along with the
result of compiling with `gcc -std=c99 -pedantic`.

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

#76452

On Wednesday, November 18, 2015 at 11:44:26 PM UTC+7, Eric Sosman wrote:
> The non-conformance of Cygwin's headers may not be due to sloppiness,
> but to the sheer impossibility of satisfying multiple masters.

Or ignorance about the existence of
   #undef
My guess is that somebody was so proud of their little howmany()
macro that they thought everybody should have it.  :-)


On Wednesday, November 18, 2015 at 11:26:02 PM UTC+7, Keith Thompson wrote:
> <stdlib.h> is the header that declares the exit() funcion.

Obviously.

> but it's probably assuming that exit returns int rather than void.

In my experience exit() doesn't return at all!  :-)

> My
> advice: If you're going to call exit(), add the `#include <stdlib.h>`
> (and then deal with any problems it might cause).

::whack::  That's what I *was* doing.  Now I have to weigh the virtue
of the inane exit()-warning suppression versus the aggravation of
the next misbegotten idiocy of the howmany ilk.
> 
> > (I'm uninterested in details about "reserved names" -- I don't
> > think "howmany" is reserved and that's what I'm talking about.)

> That's a pity, because the details of which names are reserved are at
> the heart of the problem you're having.

?? Is this response as silly as it seems?  Everybody knows howmany
is NOT reserved.  ???

Once upon a time, there was *documentation*.  One could even type
'man howmany' if one were curious.  And GET OFF MY LAWN!!  :-)

> You can report the bug on one of the Cygwin mailing lists.

?? Why would I do that? If someone cares about cygwin more than
I do, they're welcome to report the bug. Were I to wade back into
the Cygwin mailing list morass I've far more important
matters to ask about.

-- James

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

#76455

On 11/18/2015 2:58 PM, James Dow Allen wrote:
> On Wednesday, November 18, 2015 at 11:44:26 PM UTC+7, Eric Sosman wrote:
>> The non-conformance of Cygwin's headers may not be due to sloppiness,
>> but to the sheer impossibility of satisfying multiple masters.
>
> Or ignorance about the existence of
>     #undef

     If you read a few of the Cygwin headers, I think you will
quickly abandon the notion that they were written in ignorance.

>> You can report the bug on one of the Cygwin mailing lists.
>
> ?? Why would I do that? If someone cares about cygwin more than
> I do, they're welcome to report the bug. [...]

     If you don't care, why are you complaining?  Vehemently?

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

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

#76477

On Thursday, November 19, 2015 at 3:14:23 AM UTC+7, Eric Sosman wrote:
> > Or ignorance about the existence of
> >     #undef
> 
>      If you read a few of the Cygwin headers, I think you will
> quickly abandon the notion that they were written in ignorance.

I've no idea what this is supposed to mean.  Nobody thinks
Cygwin developers are morons(*) in a clinical sense.
Are you disagreeing that #undef would have been appropriate
(assuming they "needed" the macro at all)?

> 
> >> You can report the bug on one of the Cygwin mailing lists.
> >
> > ?? Why would I do that? If someone cares about cygwin more than
> > I do, they're welcome to report the bug. [...]
> 
>      If you don't care, why are you complaining?  Vehemently?

I do prefer systems that are unbroken, but it would be far easier
to add the undef's myself than go through the mailing-list
rigmarole, which would have no purpose than charity.  Any
c.l.c'er is welcome to commit the charity themselves.  I'm reminded
of the time I phoned a government official, explained a flaw
in their procedure and was invited to submit a suggestion.
::whack::  If I did go through the rigmarole I'll bet I'd have
to listen to noise like I got here -- Keith thinks I should
keep including the stdlib.h I don't need and troubleshoot any
further howmany-like bugs that turn up.  ::whack::
If pressed I suppose he'd justify that with "Your program is
non-conformant.  The compiler has the right to format your hard
disk if you call exit() without a correct prototype."

* -- Speaking of moronic programming, did you ever figure out
how uniform floating-point random numbers work, Eric?

-- James

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

#76478

On 11/18/2015 08:48 PM, James Dow Allen wrote:
> * -- Speaking of moronic programming, did you ever figure out
> how uniform floating-point random numbers work, Eric?

Could you identify the context of your inquiry? I did a Google Groups
search for "random uniform floating Sosman", and got only one hit. I
don't see how your comment could be related to his contribution to that
discussion.

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

#76511

On 11/18/2015 8:48 PM, James Dow Allen wrote:
> On Thursday, November 19, 2015 at 3:14:23 AM UTC+7, Eric Sosman wrote:
>>> Or ignorance about the existence of
>>>      #undef
>>
>>       If you read a few of the Cygwin headers, I think you will
>> quickly abandon the notion that they were written in ignorance.
>
> I've no idea what this is supposed to mean.  Nobody thinks
> Cygwin developers are morons(*) in a clinical sense.
> Are you disagreeing that #undef would have been appropriate
> (assuming they "needed" the macro at all)?

     I am disputing your claim that the writers of the Cygwin
headers were "ignoran[t] about the existence of #undef."

     It's a dumb-ass claim.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

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

#76604

James Dow Allen <jdallen2000@yahoo.com> writes:
> On Thursday, November 19, 2015 at 3:14:23 AM UTC+7, Eric Sosman wrote:
[...]
>>      If you don't care, why are you complaining?  Vehemently?
>
> I do prefer systems that are unbroken, but it would be far easier
> to add the undef's myself than go through the mailing-list
> rigmarole, which would have no purpose than charity.  Any
> c.l.c'er is welcome to commit the charity themselves.  I'm reminded
> of the time I phoned a government official, explained a flaw
> in their procedure and was invited to submit a suggestion.
> ::whack::  If I did go through the rigmarole I'll bet I'd have
> to listen to noise like I got here -- Keith thinks I should
> keep including the stdlib.h I don't need and troubleshoot any
> further howmany-like bugs that turn up.  ::whack::
> If pressed I suppose he'd justify that with "Your program is
> non-conformant.  The compiler has the right to format your hard
> disk if you call exit() without a correct prototype."

I'll just mention that calling exit() without a visible declaration
has undefined behavior in C90, and is a constraint violation in C99
and later.  If your compiler happens to accept it, it will probably
work as expected.  What you do with that information is up to you.
My advice was offered in good faith.  You are under no obligation
to follow it, but if your response is "::whack::" I will not be
inclined to try to help you in the future.

And if you don't care enough about getting this problem corrected
to take the time to report it on the Cygwin mailing list, that
also makes me less inclined to help you in the future.  Again,
what you do with that information is up to you.

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

#76670

James Dow Allen <jdallen2000@yahoo.com> writes:

> [...]
>
> * -- Speaking of moronic programming, did you ever figure out
> how uniform floating-point random numbers work, Eric?

Well, someone got up on the wrong side of the bed this
morning.

On the other hand, it is refreshing to find JDA voice a
disparaging view of someone and have it not be me. :)

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

#76620

James Dow Allen <gmail@jamesdowallen.nospam> writes:
> I run gcc under cygwin and recently discovered something that made me
> furious^H^H^H^H^H^H^H^H^H^H^H annoyed me a little. 
>
> I named a function howmany().  Not __howmany() or HoWmAnY() or
> ___SYS__howmanY() or whatever the reserving rules prohibit, just
> howmany(). 
>
> Of course I got a weird syntax error and immediately guessed what was 
> wrong.  I changed the function name to howmany_and_fuk_you_too(), and it 
> worked.  But I still took the time to track it down.  Note that one can 
> imagine situations where debugging would have been harder.
>
> sys/types.h has
> 	#define  howmany(x,y)    (((x)+((y)-1))/(y))

Reported: https://cygwin.com/ml/cygwin/2015-11/msg00293.html

[...]

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

#76832

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

However, they also propose to move the definition into sys/param.h
and sys/select.h, so if those files are not included by any
standard-defined headers, it may be sufficient. I don't use Cygwin,
so I can't check.

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

#76867

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).

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

#76895

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.)

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

#76899

In article <MPG.30bba6c41628ff09e@news.eternal-september.org>,
Philip Lantz  <prl@canterey.us> 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.

    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.

-- 
"I heard somebody say, 'Where's Nelson Mandela?' Well, 
Mandela's dead. Because Saddam killed all the Mandelas." 

George W. Bush, on the former South African president who 
is still very much alive, Sept. 20, 2007

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web