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

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

About -lm switch used for linking math.h

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

Contents

  About -lm switch used for linking math.h Avinash Sonawane <avinash.sonawane1990@gmail.com> - 2012-01-26 13:59 -0800
    Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-26 14:15 -0800
    Re: About -lm switch used for linking math.h James Kuyper <jameskuyper@verizon.net> - 2012-01-26 17:17 -0500
      Re: About -lm switch used for linking math.h Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-26 20:54 -0500
      Re: About -lm switch used for linking math.h Kaz Kylheku <kaz@kylheku.com> - 2012-01-27 02:12 +0000
    Re: About -lm switch used for linking math.h jacob navia <jacob@spamsink.net> - 2012-01-26 23:29 +0100
    Re: About -lm switch used for linking math.h Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-01-26 23:09 -0700
      Re: About -lm switch used for linking math.h jacob navia <jacob@spamsink.net> - 2012-01-27 08:37 +0100
      Re: About -lm switch used for linking math.h gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-27 09:48 +0000
        OT:Re: About -lm switch used for linking math.h Kleuske <kleuske@nowhere.net> - 2012-01-27 10:15 +0000
          Re: OT:Re: About -lm switch used for linking math.h gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-27 14:43 +0000
            Re: OT:Re: About -lm switch used for linking math.h tom st denis <tom@iahu.ca> - 2012-01-27 07:49 -0800
              Re: OT:Re: About -lm switch used for linking math.h gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-27 15:55 +0000
                Re: OT:Re: About -lm switch used for linking math.h tom st denis <tom@iahu.ca> - 2012-01-27 10:14 -0800
              Re: OT:Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-27 11:23 -0800
            Re: OT:Re: About -lm switch used for linking math.h Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-01-27 09:42 -0700
              Re: OT:Re: About -lm switch used for linking math.h 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-28 14:08 -0800
          Re: OT:Re: About -lm switch used for linking math.h Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-14 13:14 +0200
        Re: About -lm switch used for linking math.h Rui Maciel <rui.maciel@gmail.com> - 2012-01-27 16:56 +0000
          Re: About -lm switch used for linking math.h gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-27 17:34 +0000
            Re: About -lm switch used for linking math.h Rui Maciel <rui.maciel@gmail.com> - 2012-01-27 17:50 +0000
            Re: About -lm switch used for linking math.h Kaz Kylheku <kaz@kylheku.com> - 2012-01-27 17:58 +0000
              Re: About -lm switch used for linking math.h tom st denis <tom@iahu.ca> - 2012-01-27 10:15 -0800
              Re: About -lm switch used for linking math.h gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-27 19:25 +0000
                Re: About -lm switch used for linking math.h Kleuske <kleuske@nowhere.net> - 2012-01-28 18:09 +0000
              Re: About -lm switch used for linking math.h jt@toerring.de (Jens Thoms Toerring) - 2012-01-27 21:32 +0000
      Re: About -lm switch used for linking math.h "Wolfgang.Draxinger" <Wolfgang.Draxinger@physik.uni-muenchen.de> - 2012-01-27 12:40 +0100
        Re: About -lm switch used for linking math.h "BartC" <bc@freeuk.com> - 2012-01-27 12:48 +0000
          Re: About -lm switch used for linking math.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-27 14:28 +0000
        Re: About -lm switch used for linking math.h Kaz Kylheku <kaz@kylheku.com> - 2012-01-27 17:14 +0000
          Re: About -lm switch used for linking math.h gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-27 17:34 +0000
        Re: About -lm switch used for linking math.h Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-01-27 10:43 -0700
      Re: About -lm switch used for linking math.h Stephen Sprunk <stephen@sprunk.org> - 2012-01-27 12:25 -0600
        Re: About -lm switch used for linking math.h "BartC" <bc@freeuk.com> - 2012-01-27 18:41 +0000
          Re: About -lm switch used for linking math.h James Kuyper <jameskuyper@verizon.net> - 2012-01-27 13:45 -0500
            Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-27 11:29 -0800
          Re: About -lm switch used for linking math.h Jens Gustedt <jens.gustedt@loria.fr> - 2012-01-27 22:35 +0100
          Re: About -lm switch used for linking math.h Stephen Sprunk <stephen@sprunk.org> - 2012-01-27 17:19 -0600
            Re: About -lm switch used for linking math.h James Kuyper <jameskuyper@verizon.net> - 2012-01-27 19:22 -0500
              Re: About -lm switch used for linking math.h Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 23:32 -0800
            Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-27 16:26 -0800
              Re: About -lm switch used for linking math.h Ian Collins <ian-news@hotmail.com> - 2012-01-28 13:30 +1300
                Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-27 17:04 -0800
                  Re: About -lm switch used for linking math.h Ian Collins <ian-news@hotmail.com> - 2012-01-28 14:10 +1300
                  Re: About -lm switch used for linking math.h Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-27 21:06 -0500
                    Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-27 20:09 -0800
                    Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-27 20:15 -0800
                Re: About -lm switch used for linking math.h Stephen Sprunk <stephen@sprunk.org> - 2012-01-27 23:03 -0600
                  Re: About -lm switch used for linking math.h Ian Collins <ian-news@hotmail.com> - 2012-01-28 19:10 +1300
                  Re: About -lm switch used for linking math.h Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-28 04:28 -0800
                    Re: About -lm switch used for linking math.h Stephen Sprunk <stephen@sprunk.org> - 2012-01-28 15:25 -0600
                      Re: About -lm switch used for linking math.h Ian Collins <ian-news@hotmail.com> - 2012-01-29 11:39 +1300
                        Re: About -lm switch used for linking math.h Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-29 09:53 -0800
                          Re: About -lm switch used for linking math.h Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-03 10:39 +0000
                        Re: About -lm switch used for linking math.h Joshua Maurice <joshuamaurice@gmail.com> - 2012-02-01 16:42 -0800
                        Re: About -lm switch used for linking math.h jgk@panix.com (Joe keane) - 2012-02-02 01:29 +0000
                      Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-28 15:22 -0800
                        Re: About -lm switch used for linking math.h Stephen Sprunk <stephen@sprunk.org> - 2012-01-29 16:52 -0600
                          Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-30 02:04 -0800
                            Re: About -lm switch used for linking math.h Ike Naar <ike@iceland.freeshell.org> - 2012-01-30 10:22 +0000
                              Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-30 02:36 -0800
                              Re: About -lm switch used for linking math.h Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-14 13:33 +0200
                                Re: About -lm switch used for linking math.h Ike Naar <ike@iceland.freeshell.org> - 2012-02-14 23:48 +0000
                                  Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-02-14 16:35 -0800
                                  Re: About -lm switch used for linking math.h Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-22 02:44 +0200
                          Re: About -lm switch used for linking math.h Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-30 04:30 -0800
                            Re: About -lm switch used for linking math.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-30 14:36 +0000
                            Re: About -lm switch used for linking math.h Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 23:50 -0800
                    Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-28 15:29 -0800
                      Re: About -lm switch used for linking math.h Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-29 09:11 -0800
                      Re: About -lm switch used for linking math.h "BartC" <bc@freeuk.com> - 2012-01-29 17:49 +0000
                        Re: About -lm switch used for linking math.h Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-29 10:07 -0800
                        Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-29 14:24 -0800
                    Re: About -lm switch used for linking math.h Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-29 09:43 -0800
              Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-27 16:54 -0800
                Re: About -lm switch used for linking math.h Kaz Kylheku <kaz@kylheku.com> - 2012-01-28 01:09 +0000
                  Re: About -lm switch used for linking math.h Ian Collins <ian-news@hotmail.com> - 2012-01-28 14:20 +1300
                    Re: About -lm switch used for linking math.h Azazel <azazel@remove.azazel.net> - 2012-01-30 17:40 -0600
                      Re: About -lm switch used for linking math.h Kaz Kylheku <kaz@kylheku.com> - 2012-01-31 00:05 +0000
      Re: About -lm switch used for linking math.h jgk@panix.com (Joe keane) - 2012-01-27 20:03 +0000
        Re: About -lm switch used for linking math.h Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-27 12:26 -0800
          Re: About -lm switch used for linking math.h Ian Collins <ian-news@hotmail.com> - 2012-01-28 10:24 +1300
            Re: About -lm switch used for linking math.h "BartC" <bc@freeuk.com> - 2012-01-27 21:32 +0000
              Re: About -lm switch used for linking math.h James Kuyper <jameskuyper@verizon.net> - 2012-01-27 16:39 -0500
              Re: About -lm switch used for linking math.h Robert Wessel <robertwessel2@yahoo.com> - 2012-01-27 23:24 -0600
                Re: About -lm switch used for linking math.h Ian Collins <ian-news@hotmail.com> - 2012-01-28 20:38 +1300
                  Re: About -lm switch used for linking math.h Robert Wessel <robertwessel2@yahoo.com> - 2012-01-28 02:17 -0600
                Re: About -lm switch used for linking math.h Richard Damon <news.x.richarddamon@xoxy.net> - 2012-01-28 14:07 -0500
                  Re: About -lm switch used for linking math.h Robert Wessel <robertwessel2@yahoo.com> - 2012-01-28 15:07 -0600
          Re: About -lm switch used for linking math.h jgk@panix.com (Joe keane) - 2012-01-28 21:09 +0000
        Re: About -lm switch used for linking math.h Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-01-27 21:39 -0700
          Re: About -lm switch used for linking math.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-28 11:21 +0000
            Re: About -lm switch used for linking math.h Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-01-28 17:51 -0700
              Re: About -lm switch used for linking math.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-29 02:03 +0000
        Re: About -lm switch used for linking math.h Kaz Kylheku <kaz@kylheku.com> - 2012-01-28 18:58 +0000
          Re: About -lm switch used for linking math.h jacob navia <jacob@spamsink.net> - 2012-01-28 20:48 +0100
            Re: About -lm switch used for linking math.h Robert Wessel <robertwessel2@yahoo.com> - 2012-01-28 22:54 -0600
        Re: About -lm switch used for linking math.h jgk@panix.com (Joe keane) - 2012-01-29 21:42 +0000
          Re: About -lm switch used for linking math.h Robert Wessel <robertwessel2@yahoo.com> - 2012-01-30 00:14 -0600
    Re: About -lm switch used for linking math.h Stephen Sprunk <stephen@sprunk.org> - 2012-01-27 11:12 -0600

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

#16423

Ike Naar <ike@iceland.freeshell.org> writes:
> On 2012-01-30, Keith Thompson <kst-u@mib.org> wrote:
>> Stephen Sprunk <stephen@sprunk.org> writes:
>>> I'll note, though, that "if (ok!=false)" works just fine, even for
>>> uncommon values of truth.
>>
>> Yes, but "if (!ok)" is clearer and, IMHO, better.
>
> (ok) is still clearer and still better.

D!oh

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

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

#17301

Ike Naar <ike@iceland.freeshell.org> writes:
> On 2012-01-30, Keith Thompson <kst-u@mib.org> wrote:
> > Stephen Sprunk <stephen@sprunk.org> writes:
> >> I'll note, though, that "if (ok!=false)" works just fine, even for
> >> uncommon values of truth.
> >
> > Yes, but "if (!ok)" is clearer and, IMHO, better.
> 
> (ok) is still clearer and still better.

Except when it isn't. For example the commonly adopted coding style
for the linux kernel is to have desirable operation flow uninterupted
down a function, and for failures to jump away from that flow (be that
goto, break, return, whatever).

Phil
-- 
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator

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

#17342

On 2012-02-14, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
> Ike Naar <ike@iceland.freeshell.org> writes:
>> On 2012-01-30, Keith Thompson <kst-u@mib.org> wrote:
>> > Stephen Sprunk <stephen@sprunk.org> writes:
>> >> I'll note, though, that "if (ok!=false)" works just fine, even for
>> >> uncommon values of truth.
>> >
>> > Yes, but "if (!ok)" is clearer and, IMHO, better.
>> 
>> (ok) is still clearer and still better.
>
> Except when it isn't. For example the commonly adopted coding style
> for the linux kernel is to have desirable operation flow uninterupted
> down a function, and for failures to jump away from that flow (be that
> goto, break, return, whatever).

Even under such a coding style, "!ok" means the opposite of "ok!=false".

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

#17346

Ike Naar <ike@iceland.freeshell.org> writes:
> On 2012-02-14, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
>> Ike Naar <ike@iceland.freeshell.org> writes:
>>> On 2012-01-30, Keith Thompson <kst-u@mib.org> wrote:
>>> > Stephen Sprunk <stephen@sprunk.org> writes:
>>> >> I'll note, though, that "if (ok!=false)" works just fine, even for
>>> >> uncommon values of truth.
>>> >
>>> > Yes, but "if (!ok)" is clearer and, IMHO, better.
>>> 
>>> (ok) is still clearer and still better.
>>
>> Except when it isn't. For example the commonly adopted coding style
>> for the linux kernel is to have desirable operation flow uninterupted
>> down a function, and for failures to jump away from that flow (be that
>> goto, break, return, whatever).
>
> Even under such a coding style, "!ok" means the opposite of "ok!=false".

Yes, that was my mistake, which I acknowleged when it was first pointed out.

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

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

#17759

Ike Naar <ike@iceland.freeshell.org> writes:

> On 2012-02-14, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
> > Ike Naar <ike@iceland.freeshell.org> writes:
> >> On 2012-01-30, Keith Thompson <kst-u@mib.org> wrote:
> >> > Stephen Sprunk <stephen@sprunk.org> writes:
> >> >> I'll note, though, that "if (ok!=false)" works just fine, even for
> >> >> uncommon values of truth.
> >> >
> >> > Yes, but "if (!ok)" is clearer and, IMHO, better.
> >> 
> >> (ok) is still clearer and still better.
> >
> > Except when it isn't. For example the commonly adopted coding style
> > for the linux kernel is to have desirable operation flow uninterupted
> > down a function, and for failures to jump away from that flow (be that
> > goto, break, return, whatever).
> 
> Even under such a coding style, "!ok" means the opposite of "ok!=false".

Ack. I only read context if the new material doesn't make sense - 
my key-hole approach gave me an inappropriate context. Apologies.

Phil
-- 
> I'd argue that there is much evidence for the existence of a God.
Pics or it didn't happen.
-- Tom (/. uid 822)

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

#16424

On Jan 29, 10:52 pm, Stephen Sprunk <step...@sprunk.org> wrote:
>
> Do you eschew unsigned types because signed ones are good enough and
> _you_ know that a particular variable will never be negative, even if
> the compiler doesn't?  No, because you're used to them and know that, in
> certain cases, unsigned types work better.  I assert the same would be
> true if you were used to having a true boolean type.
>
I would write

void payroll(EMPLOYEE *employees, int N)

if the code has to run on a 16 bit int machine, it's most unlikely
that there would be enough memory to store more than 32767 employees

N is of course naturally unsigned. But unsigned adds visual clutter.
size_t is now the official preferred way, but it's confusing, because
N is a count, not a size.
Then say for some reason we want to step backwards through the array.

for(i=N-1;i>=0;i--)

is the obvious way to do it. It only works if i and N are signed. If
we want to revert to stepping forwards through the array, we just
rewrite the for control.
If N is unsigned we have to make i unsigned which means that we can't
reuse i in a signed context. It also means that we have to write
something like
i = N;
while(i--)

now if we want to change to stepping forwards, the programmer has to
follow through the logic. Of course it's still a standard programming
task, but it's a bit harder, and more likely to introduce a bug.


--
MiniBasic - how to write a script interpreter
http://www.malcolmmclean.site11.com/www

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

#16426

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Jan 29, 10:52 pm, Stephen Sprunk <step...@sprunk.org> wrote:
>>
>> Do you eschew unsigned types because signed ones are good enough and
>> _you_ know that a particular variable will never be negative, even if
>> the compiler doesn't?  No, because you're used to them and know that, in
>> certain cases, unsigned types work better.  I assert the same would be
>> true if you were used to having a true boolean type.
>>
> I would write
>
> void payroll(EMPLOYEE *employees, int N)
>
> if the code has to run on a 16 bit int machine, it's most unlikely
> that there would be enough memory to store more than 32767 employees
>
> N is of course naturally unsigned. But unsigned adds visual clutter.
> size_t is now the official preferred way, but it's confusing, because
> N is a count, not a size.
> Then say for some reason we want to step backwards through the array.
>
> for(i=N-1;i>=0;i--)
>
> is the obvious way to do it. It only works if i and N are signed. If
> we want to revert to stepping forwards through the array, we just
> rewrite the for control.

In my opinion, a better way to do this is to always run the loop forward
and to transform the index in the loop body.  This localises the changes
needed in one place and makes the loop robust against index type
changes:

  for (i = 0; i < N; i++) {
      size_t element = N - 1 - i;
      /* ... */
  }

You can even do this retrospectively without altering the loop body at
the expense of some yuckery:

  for (i = 0; i < N; i++) {
      size_t oi = i, i = N - 1 - oi; /* run the loop backwards */
      /* ... */
  }

Finally, rather than map the index, it's sometimes worthwhile mapping to
an element pointer:

  for (i = 0; i < N; i++) {
      EMPLOYEE *employee = &employees[N - 1 - i];
      /* ... */
  }

If this is the case, flipping the order by adjusting the index
expression is perfectly natural.

<snip>
-- 
Ben.

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

#16576

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Jan 29, 10:52 pm, Stephen Sprunk <step...@sprunk.org> wrote:
>>
>> Do you eschew unsigned types because signed ones are good enough and
>> _you_ know that a particular variable will never be negative, even if
>> the compiler doesn't?  No, because you're used to them and know that, in
>> certain cases, unsigned types work better.  I assert the same would be
>> true if you were used to having a true boolean type.
>>
> I would write
>
> void payroll(EMPLOYEE *employees, int N)
>
> if the code has to run on a 16 bit int machine, it's most unlikely
> that there would be enough memory to store more than 32767 employees
>
> N is of course naturally unsigned. But unsigned adds visual clutter.
> [snip unrelated]

Forgive me for being blunt, but that's a moronic statement.
There isn't any clutter in using 'unsigned' any more than
there would be for 'long' or 'float' or 'double'.  All of
these express a basic type in a single English word.  Are they
all longer than 'int'?  Sure.  Do they have any extraneous or
redundant parts (ie, clutter)?  They do not.

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

#16374

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> Then we'd expect that _Bool myflags[100000000]; would be a space
> efficient way of declaring a big array of flags. If instead you've got
> to do unsigned char myflags[10000000/8], then you've got two boolean
> types kicking about your program, and _Bool is a hinderance rather
> than a help to anyone who's got to read your code.

Packing _Bool arrays would violate the general rule that objects other
than bit fields are at least one byte.  Indexing such an array could not
be defined in terms of pointer arithmetic, as all other array indexing
is, because single bits are not addressable.

I've worked in other languages where you can declare packed arrays of
booleans (which works only because those languages don't define array
indexing in terms of lower-level constructs, and either don't let you
take the address of an element of a packed array or use fat pointers).

Adding such a feature to C is tempting, but I don't see how it could be
done without either breaking existing code, or adding an entirely new
feature to the language.

> It is obviously good to have booleans documented as such. But in most
> functions, you don't normally have many booleans, and they normally do
> something quite simple, like adding or suppressing a newline on the
> last line of output. For a small gain, _Bool causes too many
> headaches, and that's neglecting the problem of double definition.

The pre-C99 treatment of booleans caused a great many headaches.  IMHO,
the best way to avoid those headaches would have been to have "bool"
built into the language from the beginning.  Since that didn't happen, I
think adding _Bool later on was the best compromise.  But I acknowledge
that it was a compromise, and there are some drawbacks to it.

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

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

#16397

On Jan 28, 11:29 pm, Keith Thompson <ks...@mib.org> wrote:
> Malcolm McLean <malcolm.mcle...@btinternet.com> writes:
>
> > Then we'd expect that _Bool myflags[100000000]; would be a space
> > efficient way of declaring a big array of flags. If instead you've got
> > to do unsigned char myflags[10000000/8], then you've got two boolean
> > types kicking about your program, and _Bool is a hinderance rather
> > than a help to anyone who's got to read your code.
>
> Packing _Bool arrays would violate the general rule that objects other
> than bit fields are at least one byte.  Indexing such an array could not
> be defined in terms of pointer arithmetic, as all other array indexing
> is, because single bits are not addressable.
>
Exactly. If you need a space-efficient array of booleans, which might
not happen that often, but isn't such an uncommon thing to need, you
can't use _Bool, and there's no way of changing the semantics of _Bool
so that you can use it, without all sorts of knock-on effects
elsewhere in the language. (I once suggested that size_t be a double,
to accomodate bools and bitfields). But that limits the usefulness of
_Bool. It can't replace all booleans in every program.

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

#16399

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:ln1uqj1k5b.fsf@nuthaus.mib.org...
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> [...]
>> Then we'd expect that _Bool myflags[100000000]; would be a space
>> efficient way of declaring a big array of flags. If instead you've got
>> to do unsigned char myflags[10000000/8], then you've got two boolean
>> types kicking about your program, and _Bool is a hinderance rather
>> than a help to anyone who's got to read your code.

> I've worked in other languages where you can declare packed arrays of
> booleans (which works only because those languages don't define array
> indexing in terms of lower-level constructs, and either don't let you
> take the address of an element of a packed array or use fat pointers).
>
> Adding such a feature to C is tempting, but I don't see how it could be
> done without either breaking existing code, or adding an entirely new
> feature to the language.

Addressing a single bit means adding 3 extra bits or so to a pointer (when 
there are no spare bits). I thought C could accommodate pointers of 
different widths? The only problem then is that void pointers would need to 
be bit-pointer compatible, making them inefficient wherever bit-addressing 
is not needed.

Alternatively, bit-pointers can be a special case which cannot be converted 
fully to and from conventional pointers. Either it's not allowed at all, or 
some information might be lost.

-- 
Bartc 

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

#16401

On Jan 29, 5:49 pm, "BartC" <b...@freeuk.com> wrote:
>
> Addressing a single bit means adding 3 extra bits or so to a pointer (when
> there are no spare bits). I thought C could accommodate pointers of
> different widths? The only problem then is that void pointers would need to
> be bit-pointer compatible, making them inefficient wherever bit-addressing
> is not needed.
>
It's not really a problem on 64 bit systems. Computers which use all
64 bits of address space won't be commonly available for quite some
time (about 48 years, assuming Moore's law is correct, and that a
present day computer uses all of 32 bits). So we can put the extra bit
index bits in a normal width pointer.

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

#16411

"BartC" <bc@freeuk.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:ln1uqj1k5b.fsf@nuthaus.mib.org...
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> [...]
>>> Then we'd expect that _Bool myflags[100000000]; would be a space
>>> efficient way of declaring a big array of flags. If instead you've got
>>> to do unsigned char myflags[10000000/8], then you've got two boolean
>>> types kicking about your program, and _Bool is a hinderance rather
>>> than a help to anyone who's got to read your code.
>
>> I've worked in other languages where you can declare packed arrays of
>> booleans (which works only because those languages don't define array
>> indexing in terms of lower-level constructs, and either don't let you
>> take the address of an element of a packed array or use fat pointers).
>>
>> Adding such a feature to C is tempting, but I don't see how it could be
>> done without either breaking existing code, or adding an entirely new
>> feature to the language.
>
> Addressing a single bit means adding 3 extra bits or so to a pointer
> (when there are no spare bits). I thought C could accommodate pointers
> of different widths? The only problem then is that void pointers would
> need to be bit-pointer compatible, making them inefficient wherever
> bit-addressing is not needed.

C can accommodate pointers of different widths, but it can't accomodate
pointers to units smaller than CHAR_BIT bits (i.e., at least 8 bits).

> Alternatively, bit-pointers can be a special case which cannot be
> converted fully to and from conventional pointers. Either it's not
> allowed at all, or some information might be lost.

Yes, as I said, if you don't want to break existing code (by
violating existing guarantees about pointers), you'd need a new
language feature.

I can imagine ways to do it.  A *bit-pointer* could be a new kind
of scalar, incompatible with pointers but convertible to and from
them in some restricted cases.  (The name is not intended to imply
that a bit-pointer is a kind of pointer; perhaps a different name
would be clearer, but I can't think of a good one.)  Indexing of
bit arrays could be defined in terms of arithmetic on bit-pointers,
not on pointers.  Conversion of a bit-pointer to void* either would
not be permitted or would lose information, yielding a pointer to
the containing byte.

You could either invent a new syntax for bit-pointer operations,
including indexing, or you could overload the existing syntax,
with the semantics depending on whether the operands are pointers
or bit-pointers.  I'm not sure which would be more confusing.

But given the lack of existing practice and the sparse demand for
this kind of thing, I don't believe it will happen.  The most likely
way to get it into C would be to implement it in a popular compiler
and push for the committee to add it to C202X.

(Interestingly, this article is the only reference I can find to
"C202X" referring to the next C standard, though apparently there's
a mutation by that name.)

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

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

#16398

On Jan 28, 12:28 pm, Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
> On Jan 28, 5:03 am, Stephen Sprunk <step...@sprunk.org> wrote:
>
> > If _Bool were simply an unsigned integer type with one value bit,
> > wouldn't the normal conversion rules mean (_Bool)2 == 0?  That's not how
> > _Bool works.
>
> This is exactly the problem.
>
> Denis Ritchie knew all about boolean types. They were excluded from C
> for some reason, but trying to tack them on now causes all sorts of
> problems and inconsistencies.
>
> In C true is non-zero. But if we hash define true and false, if(2 ==
> true) evaluates to false, if(2) evaluates to true. Most undesireable.
> Adding true as a keyword causes even more problems.
>
> Then if a _Bool is a one bit type, _Bool bit = 2; should set bit to
> zero.
>
> Then we'd expect that _Bool myflags[100000000]; would be a space
> efficient way of declaring a big array of flags. If instead you've got
> to do unsigned char myflags[10000000/8], then you've got two boolean
> types kicking about your program, and _Bool is a hinderance rather
> than a help to anyone who's got to read your code.
>
> It is obviously good to have booleans documented as such. But in most
> functions, you don't normally have many booleans, and they normally do
> something quite simple, like adding or suppressing a newline on the
> last line of output. For a small gain, _Bool causes too many
> headaches, and that's neglecting the problem of double definition.

I like them for predicates, functions that return a bool result.

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

#16329

Keith Thompson <kst-u@mib.org> writes:
> Stephen Sprunk <stephen@sprunk.org> writes:
> [...]
>> "_Bool" is a hack around the fact there is no way to introduce a new
>> basic type in a header file.  "bool" is what the standard was really
>> trying to introduce, but that is a typedef to "_Bool" that one gets by
>> including <stdbool.h>.
>
> "bool" is a macro, not a typedef (I'm not sure why).

Now that I think about it, it's probably so you can do something like
this for legacy code that defines "bool", "true", and/or "false":

    #ifdef __bool_true_false_are_defined
        #undef bool
        #undef true
        #undef false
        #undef __bool_true_false_are_defined
    #endif

You can't undefine a typedef.

Note that just not having "#include <stdbool.h>" is not a complete
solution; it might be included indirectly.

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

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

#16332

On 2012-01-28, Keith Thompson <kst-u@mib.org> wrote:
> Keith Thompson <kst-u@mib.org> writes:
>> Stephen Sprunk <stephen@sprunk.org> writes:
>> [...]
>>> "_Bool" is a hack around the fact there is no way to introduce a new
>>> basic type in a header file.  "bool" is what the standard was really
>>> trying to introduce, but that is a typedef to "_Bool" that one gets by
>>> including <stdbool.h>.
>>
>> "bool" is a macro, not a typedef (I'm not sure why).
>
> Now that I think about it

bool is not a macro that just expands to any old type name, but one that
expands to a new C language keyword (that names a type).

Because it expands to a C language keyword, the following is a syntax 
error:

  {
    typedef int bool;   /* error */
    typedef int while;  /* exactly like this one */

  }

I.e. bool really behaves like a reserved keyword, except that you can #undef it
to make it go away.

Making it a typedef would be a small consolation prize, given that true and
false cannot be similarly made into first-class language features.  The whole
pack of three might as well be macros.

>, it's probably so you can do something like
> this for legacy code that defines "bool", "true", and/or "false":

Legacy code that defines bool, true and false will not #include <stdboo.h>.
Some legacy code also defines uint32_t, etc. So what?

Either fix the legacy code, or don't compile it as C99 and don't include new
headers.

> You can't undefine a typedef.

If this is a disadvantage of typedef, why not replace all standard typedefs
with macros?

They could just have added "untypedef" to the language, by the way.
Compared to some of the arcane inventions, that's trivial.

> Note that just not having "#include <stdbool.h>" is not a complete
> solution; it might be included indirectly.

<inttypes.h> could be included indirectly too. So let's make all types like
uint32_t into macros.

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

#16334

On 01/28/12 02:09 PM, Kaz Kylheku wrote:
> On 2012-01-28, Keith Thompson<kst-u@mib.org>  wrote:
>
>> Note that just not having "#include<stdbool.h>" is not a complete
>> solution; it might be included indirectly.
>
> <inttypes.h>  could be included indirectly too. So let's make all types like
> uint32_t into macros.

On a Unix system, it undoubtedly will as the fixed with types are part 
of the standard interface.

I don't think <stdbool.h> is required anywhere. I guess one reason is 
the "_t" suffix is considered (but not explicitly stated?) as part of 
the operating environment's namespace.

-- 
Ian Collins

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

#16467

On 2012-01-28, Ian Collins <ian-news@hotmail.com> wrote:
> On 01/28/12 02:09 PM, Kaz Kylheku wrote:
> > On 2012-01-28, Keith Thompson<kst-u@mib.org>  wrote:
> >> Note that just not having "#include<stdbool.h>" is not a complete
> >> solution; it might be included indirectly.
> >
> > <inttypes.h>  could be included indirectly too. So let's make all
> > types like uint32_t into macros.
>
> On a Unix system, it undoubtedly will as the fixed with types are part
> of the standard interface.
>
> I don't think <stdbool.h> is required anywhere. I guess one reason is
> the "_t" suffix is considered (but not explicitly stated?) as part of
> the operating environment's namespace.

IIRC, it's POSIX that reserves some "_t" identifiers:

  http://pubs.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_02.html

-- 
Az.

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

#16469

On 2012-01-30, Azazel <azazel@remove.azazel.net> wrote:
> On 2012-01-28, Ian Collins <ian-news@hotmail.com> wrote:
>> On 01/28/12 02:09 PM, Kaz Kylheku wrote:
>> > On 2012-01-28, Keith Thompson<kst-u@mib.org>  wrote:
>> >> Note that just not having "#include<stdbool.h>" is not a complete
>> >> solution; it might be included indirectly.
>> >
>> > <inttypes.h>  could be included indirectly too. So let's make all
>> > types like uint32_t into macros.
>>
>> On a Unix system, it undoubtedly will as the fixed with types are part
>> of the standard interface.
>>
>> I don't think <stdbool.h> is required anywhere. I guess one reason is
>> the "_t" suffix is considered (but not explicitly stated?) as part of
>> the operating environment's namespace.
>
> IIRC, it's POSIX that reserves some "_t" identifiers:
>
>   http://pubs.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_02.html

I'm well aware of this and have always believe that it is completely moronic.

Firstly, POSIX already has feature test macros so that old code does not see
new identifiers. If some foo_t did not exist in 1995 POSIX, and I want to use
1995 POSIX, there is  feature test macro for that so that even if 2012 there is
a foo_t, it will not be seen in my program.

Secondly, POSIX could add new identifiers at any time into headers, in ANY name
space. What's the point of saying _t is reserved, when tomorrow you could
introduce an identifier blorch, without previously having declared that
bl*ch is a reserved space? See point one: a properly versioned feature test
macro will eliminate blorch.

Thirdly, why reserve a commmon fucking space like _t that's part of a
widespread C programming convention?

Feature test macros eliminate the need for reserved spaces like this. All you
need are the generic ones like _[A-Z]* for the internal bits.
You don't need _t for header file internals.

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

#16309

In article <1bipjxvfqk.fsf@pfeifferfamily.net>,
Joe Pfeiffer  <pfeiffer@cs.nmsu.edu> wrote:
>The better question would be why the C standard library function
>prototypes aren't all automatically available, without a bunch of
>#include's.  To me it seems like they ought to be, but the people
>writing the standards and the people writing the compilers don't agree
>with me, so they aren't.

Because the C standard mainly codified existing practice.

One day, C was just a language.  People wrote some utility functions.
If you want a function and it isn't in your program, you copy it from
one that does have it.  If you for some unknown reason want a
declaration, of course that should go in a header file.

Eventually, people settled on a more-or-less standard C library, that
contains stuff like stdio that 'everyone' needs.  And then, there's a
math library; many programs don't need that stuff.  And then, there's
the X library; suprisingly many programs don't do graphics.

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

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

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

csiph-web