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

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

sizeof(arr[0])

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

Contents

  sizeof(arr[0]) kuznecov.alexey@gmail.com - 2015-06-10 12:38 -0700
    Re: sizeof(arr[0]) James Kuyper <jameskuyper@verizon.net> - 2015-06-10 16:00 -0400
      Re: sizeof(arr[0]) kuznecov.alexey@gmail.com - 2015-06-10 14:53 -0700
    Re: sizeof(arr[0]) kuznecov.alexey@gmail.com - 2015-06-10 13:11 -0700
    Re: sizeof(arr[0]) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-10 21:21 +0100
      Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-10 22:08 +0100
        Re: sizeof(arr[0]) Andrew Cooper <amc96@cam.ac.uk> - 2015-06-11 00:27 +0100
          Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-11 00:34 +0100
            Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-11 00:38 +0100
            Re: writing code for people who don't know the language (was: sizeof(arr[0])) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-06-10 21:16 -0400
            Re: writing code for people who don't know the language Richard Heathfield <rjh@cpax.org.uk> - 2015-06-11 02:35 +0100
              Re: writing code for people who don't know the language Bartc <bc@freeuk.com> - 2015-06-11 11:16 +0100
            Re: writing code for people who don't know the language Bartc <bc@freeuk.com> - 2015-06-11 11:29 +0100
              Re: writing code for people who don't know the language gazelle@shell.xmission.com (Kenny McCormack) - 2015-06-11 11:43 +0000
            Re: sizeof(arr[0]) Paul N <gw7rib@aol.com> - 2015-06-14 13:13 -0700
              Re: sizeof(arr[0]) Philip Lantz <prl@canterey.us> - 2015-06-14 17:52 -0700
            Re: sizeof(arr[0]) "Bill Cunningham" <nospam@nspam.invalid> - 2015-06-15 14:26 -0400
              Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-15 19:34 +0100
                Re: sizeof(arr[0]) "Bill Cunningham" <nospam@nspam.invalid> - 2015-06-15 14:55 -0400
                  Re: sizeof(arr[0]) Melzzzzz <melz@zzzzz.com> - 2015-06-15 20:59 +0200
                  Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-15 20:11 +0100
                    Re: sizeof(arr[0]) "Bill Cunningham" <nospam@nspam.invalid> - 2015-06-15 15:22 -0400
                      Re: sizeof(arr[0]) David Kleinecke <dkleinecke@gmail.com> - 2015-06-16 09:51 -0700
                        Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 10:51 -0700
                          Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-16 19:14 +0100
                            Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 11:43 -0700
                              Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-16 20:03 +0100
                          Re: sizeof(arr[0]) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-16 19:15 +0100
                            Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 11:34 -0700
                              Re: sizeof(arr[0]) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-16 20:28 +0100
                                Re: sizeof(arr[0]) James Kuyper <jameskuyper@verizon.net> - 2015-06-16 15:42 -0400
                                  Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-16 13:35 -0700
                                    Re: sizeof(arr[0]) James Kuyper <jameskuyper@verizon.net> - 2015-06-16 16:59 -0400
                                    Re: sizeof(arr[0]) Dr Nick <nospam-4@temporary-address.org.uk> - 2015-06-16 22:05 +0100
                                      Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-16 14:27 -0700
                                        Re: sizeof(arr[0]) Dr Nick <nospam-4@temporary-address.org.uk> - 2015-06-17 07:07 +0100
                                  Re: sizeof(arr[0]) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 01:22 +0100
                                Re: sizeof(arr[0]) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-16 19:45 +0000
                                Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 13:03 -0700
                                  Re: sizeof(arr[0]) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 10:58 +0100
                                    Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-17 05:58 -0700
                                      Re: sizeof(arr[0]) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 15:46 +0100
                                        Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-17 08:14 -0700
                                          Re: sizeof(arr[0]) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 17:58 +0100
                                            Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-17 10:07 -0700
                                              Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-17 10:09 -0700
                                                Re: sizeof(arr[0]) David Kleinecke <dkleinecke@gmail.com> - 2015-06-17 10:46 -0700
                                              Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-17 11:13 -0700
                                                Re: sizeof(arr[0]) Nathan Wagner <nw@hydaspes.if.org> - 2015-06-18 07:14 +0000
                                                  Re: sizeof(arr[0]) David Brown <david.brown@hesbynett.no> - 2015-06-18 09:54 +0200
                                                  Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-18 05:19 -0700
                                          Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-17 10:53 -0700
                                            Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-17 11:17 -0700
                                              Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-17 13:59 -0700
                                                Re: sizeof(arr[0]) Ian Collins <ian-news@hotmail.com> - 2015-06-18 13:41 +1200
                                            Re: sizeof(arr[0]) David Brown <david.brown@hesbynett.no> - 2015-06-18 10:04 +0200
                              Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-16 13:18 -0700
                                Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-16 21:30 +0100
                                  Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 13:53 -0700
                                Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 13:43 -0700
                                  Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-16 21:52 +0100
                                    Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 14:01 -0700
                                    Re: sizeof(arr[0]) David Brown <david.brown@hesbynett.no> - 2015-06-16 23:49 +0200
                                      Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 14:58 -0700
                                        Re: sizeof(arr[0]) David Brown <david.brown@hesbynett.no> - 2015-06-17 14:10 +0200
                                          Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-17 13:20 +0100
                                  Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-16 14:16 -0700
                                    Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 14:39 -0700
                          Re: sizeof(arr[0]) gazelle@shell.xmission.com (Kenny McCormack) - 2015-06-16 18:38 +0000
                            Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 11:45 -0700
                              Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-16 13:22 -0700
                                Re: sizeof(arr[0]) gazelle@shell.xmission.com (Kenny McCormack) - 2015-06-16 21:25 +0000
                        Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-16 11:05 -0700
                          Re: sizeof(arr[0]) James Kuyper <jameskuyper@verizon.net> - 2015-06-16 14:15 -0400
                          Re: sizeof(arr[0]) David Kleinecke <dkleinecke@gmail.com> - 2015-06-17 10:07 -0700
                            Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-17 11:16 -0700
                              Re: sizeof(arr[0]) David Kleinecke <dkleinecke@gmail.com> - 2015-06-18 10:22 -0700
                                Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-18 10:42 -0700
                                  Re: sizeof(arr[0]) David Kleinecke <dkleinecke@gmail.com> - 2015-06-18 11:41 -0700
                    Re: sizeof(arr[0]) Philip Lantz <prl@canterey.us> - 2015-06-16 00:12 -0700
                      Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-16 10:12 +0100
                        Re: sizeof(arr[0]) Philip Lantz <prl@canterey.us> - 2015-06-16 09:12 -0700
                          Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-16 17:32 +0100
      Re: sizeof(arr[0]) kuznecov.alexey@gmail.com - 2015-06-10 14:56 -0700
        Re: sizeof(arr[0]) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-10 23:53 +0100
        Re: sizeof(arr[0]) Bartc <bc@freeuk.com> - 2015-06-11 00:33 +0100
          Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-11 00:37 +0100
    Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-17 06:05 -0700
      [OT] The number 42 (was Re: sizeof(arr[0])) David Brown <david.brown@hesbynett.no> - 2015-06-17 16:07 +0200
        Re: [OT] The number 42 (was Re: sizeof(arr[0])) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-17 08:23 -0700
          Re: [OT] The number 42 (was Re: sizeof(arr[0])) David Brown <david.brown@hesbynett.no> - 2015-06-18 10:21 +0200
        Re: [OT] The number 42 (was Re: sizeof(arr[0])) David Kleinecke <dkleinecke@gmail.com> - 2015-06-17 10:35 -0700
          Re: [OT] The number 42 (was Re: sizeof(arr[0])) David Brown <david.brown@hesbynett.no> - 2015-06-18 10:18 +0200
            Re: [OT] The number 42 (was Re: sizeof(arr[0])) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-18 10:08 +0100
      Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-17 15:13 +0100
        Re: sizeof(arr[0]) raltbos@xs4all.nl (Richard Bos) - 2015-06-18 20:38 +0000

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

#63378

On 16/06/15 21:43, Rick C. Hodgin wrote:
> On Tuesday, June 16, 2015 at 4:18:59 PM UTC-4, Keith Thompson wrote:

<snip>

>> You can construct a mental model that treats "sizeof" as if it
>> were a function.  If you do so carefully enough, and keep in mind
>> the special cases that result from the inconsistencies between
>> that model and reality, you can write consistent and correct code.
>> But IMHO that's a lot more effort than just learning what "sizeof"
>> really is.  To do it reliably, you have to understand both your
>> mental model and the actual syntax and semantics of the language,
>> so you can avoid the inconsistencies.
>
> I have never found an inconsistency in using that form. I'd be curious
> to hear of one which could exist, after which I will likely explain
> further how I would never code in that way. :-)

If you treat sizeof like a function, you can't pass it a type name as an 
argument, because functions don't accept type names as arguments. So, to 
be consistent in treating sizeof as a function, you would have to 
refrain from "passing" type names to it (in which case, by the by, the 
parentheses are never, ever required).

<snip>

> BTW, 42 was Jackie Robinson's jersey number.  I've often wondered if
> that wasn't Adams' impetus in using that number for the answer to
> why the universe exists ... ie, breaking down barriers, working
> together, and doing our best.

He is on record as saying that he picked 42 merely because it was a 
perfectly ordinary number, a number that you could, without 
embarrassment, take home to meet your parents. I doubt whether he'd ever 
heard of Jackie Robinson, who retired from playing baseball when DNA was 
about 4 years old. In fact, it's probably fair to say that only a tiny 
minority of English people have ever heard of Jackie Robinson, of which 
minority I was not a member until just now.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#63381

On Tuesday, June 16, 2015 at 4:52:43 PM UTC-4, Richard Heathfield wrote:
> On 16/06/15 21:43, Rick C. Hodgin wrote:
> > On Tuesday, June 16, 2015 at 4:18:59 PM UTC-4, Keith Thompson wrote:
> >> You can construct a mental model that treats "sizeof" as if it
> >> were a function.  If you do so carefully enough, and keep in mind
> >> the special cases that result from the inconsistencies between
> >> that model and reality, you can write consistent and correct code.
> >> But IMHO that's a lot more effort than just learning what "sizeof"
> >> really is.  To do it reliably, you have to understand both your
> >> mental model and the actual syntax and semantics of the language,
> >> so you can avoid the inconsistencies.
> >
> > I have never found an inconsistency in using that form. I'd be curious
> > to hear of one which could exist, after which I will likely explain
> > further how I would never code in that way. :-)
> 
> If you treat sizeof like a function, you can't pass it a type name as an 
> argument, because functions don't accept type names as arguments. So, to 
> be consistent in treating sizeof as a function, you would have to 
> refrain from "passing" type names to it (in which case, by the by, the 
> parentheses are never, ever required).

The built-in functions allow for more non-variable input than do user
functions because they are computed at compile-time when everything is
known.

I don't view that as an inconsistency because it's merely a rule, like
"int f(int a)" being unable to receive a char* as input.  In that case,
it would be tested at compile-time and fail.

With sizeof(), passing a type is not against its rule.

> <snip>
> 
> > BTW, 42 was Jackie Robinson's jersey number.  I've often wondered if
> > that wasn't Adams' impetus in using that number for the answer to
> > why the universe exists ... ie, breaking down barriers, working
> > together, and doing our best.
> 
> He is on record as saying that he picked 42 merely because it was a 
> perfectly ordinary number, a number that you could, without 
> embarrassment, take home to meet your parents. I doubt whether he'd ever 
> heard of Jackie Robinson, who retired from playing baseball when DNA was 
> about 4 years old. In fact, it's probably fair to say that only a tiny 
> minority of English people have ever heard of Jackie Robinson, of which 
> minority I was not a member until just now.

Well ... *bang* goes that line of thinking. :-)

Best regards,
Rick C. Hodgin

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

#63387

On 16/06/15 22:52, Richard Heathfield wrote:
> On 16/06/15 21:43, Rick C. Hodgin wrote:

>> BTW, 42 was Jackie Robinson's jersey number.  I've often wondered if
>> that wasn't Adams' impetus in using that number for the answer to
>> why the universe exists ... ie, breaking down barriers, working
>> together, and doing our best.
>
> He is on record as saying that he picked 42 merely because it was a
> perfectly ordinary number, a number that you could, without
> embarrassment, take home to meet your parents. I doubt whether he'd ever
> heard of Jackie Robinson, who retired from playing baseball when DNA was
> about 4 years old. In fact, it's probably fair to say that only a tiny
> minority of English people have ever heard of Jackie Robinson, of which
> minority I was not a member until just now.
>

Although I am not English, I too had to look up Jackie Robinson - Rick's 
post made it look like he was someone important or famous.  It turns out 
he played in American-only sports.  I cannot imagine why anyone would 
think there was a connection here with Douglas Adams, especially as he 
liked the English bat-and-ball game, cricket.  DNA was famous for 
marvelling in the ordinary and everyday - people who did anything 
special or unusual he mostly found boring.

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

#63388

On Tuesday, June 16, 2015 at 5:49:37 PM UTC-4, David Brown wrote:
> On 16/06/15 22:52, Richard Heathfield wrote:
> > On 16/06/15 21:43, Rick C. Hodgin wrote:
> 
> >> BTW, 42 was Jackie Robinson's jersey number.  I've often wondered if
> >> that wasn't Adams' impetus in using that number for the answer to
> >> why the universe exists ... ie, breaking down barriers, working
> >> together, and doing our best.
> >
> > He is on record as saying that he picked 42 merely because it was a
> > perfectly ordinary number, a number that you could, without
> > embarrassment, take home to meet your parents. I doubt whether he'd ever
> > heard of Jackie Robinson, who retired from playing baseball when DNA was
> > about 4 years old. In fact, it's probably fair to say that only a tiny
> > minority of English people have ever heard of Jackie Robinson, of which
> > minority I was not a member until just now.
> >
> 
> Although I am not English, I too had to look up Jackie Robinson - Rick's 
> post made it look like he was someone important or famous.  It turns out 
> he played in American-only sports.  I cannot imagine why anyone would 
> think there was a connection here with Douglas Adams, especially as he 
> liked the English bat-and-ball game, cricket.  DNA was famous for 
> marvelling in the ordinary and everyday - people who did anything 
> special or unusual he mostly found boring.

He was a significant person in common U.S. history. He broke down race
barriers for the mainstream populace at a point in our history where
race was a real issue.

In 2013 they made a movie about him with a budget of $40 million:

    https://en.wikipedia.org/wiki/42_%28film%29

My thinking in Adams' using his number as that answer was because of
what he had done -- brought people together in spite of adversity.
It seems to be a good answer to why the universe exists.

Best regards,
Rick C. Hodgin

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

#63398

On 16/06/15 23:58, Rick C. Hodgin wrote:
> On Tuesday, June 16, 2015 at 5:49:37 PM UTC-4, David Brown wrote:
>> On 16/06/15 22:52, Richard Heathfield wrote:
>>> On 16/06/15 21:43, Rick C. Hodgin wrote:
>>
>>>> BTW, 42 was Jackie Robinson's jersey number.  I've often wondered if
>>>> that wasn't Adams' impetus in using that number for the answer to
>>>> why the universe exists ... ie, breaking down barriers, working
>>>> together, and doing our best.
>>>
>>> He is on record as saying that he picked 42 merely because it was a
>>> perfectly ordinary number, a number that you could, without
>>> embarrassment, take home to meet your parents. I doubt whether he'd ever
>>> heard of Jackie Robinson, who retired from playing baseball when DNA was
>>> about 4 years old. In fact, it's probably fair to say that only a tiny
>>> minority of English people have ever heard of Jackie Robinson, of which
>>> minority I was not a member until just now.
>>>
>>
>> Although I am not English, I too had to look up Jackie Robinson - Rick's 
>> post made it look like he was someone important or famous.  It turns out 
>> he played in American-only sports.  I cannot imagine why anyone would 
>> think there was a connection here with Douglas Adams, especially as he 
>> liked the English bat-and-ball game, cricket.  DNA was famous for 
>> marvelling in the ordinary and everyday - people who did anything 
>> special or unusual he mostly found boring.
> 
> He was a significant person in common U.S. history. He broke down race
> barriers for the mainstream populace at a point in our history where
> race was a real issue.

Race is still a "real issue" in much of the USA.  But while I am sure he
made his mark here, he was just one of many black Americans who refused
to be treated as second-class humans - and he was not one that was
famous enough or important enough to be known outside the USA.  (I don't
mean to belittle the man or his achievements, but he simply is not
internationally known in the way Malcolm X, Martin Luther King, Mohammed
Ali or Rosa Parks are.)

Perhaps this is because his sport, baseball, is hugely popular in the
USA and almost totally irrelevant elsewhere (in the UK, it is something
kids might play in the playground between classes - called "rounders" or
"softball" - it is not something people take seriously).

> 
> In 2013 they made a movie about him with a budget of $40 million:
> 
>     https://en.wikipedia.org/wiki/42_%28film%29
> 
> My thinking in Adams' using his number as that answer was because of
> what he had done -- brought people together in spite of adversity.

That is not something that DNA was especially interested in.  He liked
to tell entertaining stories about ordinary people doing extraordinary
things, and to let his imagination run wild.

(As a side note, the book which Douglas Adams wanted most to be
remembered for is not "The Hitchhikers' Guide to the Galaxy", but "Last
Chance to See" about endangered species.)

> It seems to be a good answer to why the universe exists.
> 

DNA was an atheist - he was never interested in finding out why the
universe exists, and certainly would not have thought it was something
revolving around humans.  A key concept of THGTTG was that the earth was
made by interstellar mice so that /they/ could find the real question to
fit the answer to life, the universe and everything.  He was interested
in the question and what people think of it, and was mocking those that
took the question too seriously - but he did not think that there was
any "answer" or any point in looking for an answer.

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

#63399

On 17/06/15 13:10, David Brown wrote:

[Re: Jackie Robinson]

> Perhaps this is because his sport, baseball, is hugely popular in the
> USA and almost totally irrelevant elsewhere (in the UK, it is something
> kids might play in the playground between classes - called "rounders" or
> "softball" - it is not something people take seriously).

I simply *must* take issue with this. The folks at Bletchley Park took 
their games of rounders *very* seriously. Disputed decisions were 
commonplace, and were discussed with all the gravity normally reserved 
for cracking Nazi ciphers.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#63383

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> On Tuesday, June 16, 2015 at 4:18:59 PM UTC-4, Keith Thompson wrote:
[...]
>> Imagine a language that's identical to C, except that it spells
>> `sizeof` as `$"`  Would you still insist on writing `$(x)`, or
>> would you be willing to write `$ x` or `$x`?
>
> I would write this every time:
>
>     $((*p)->x)
>
> Every time. Without reservation. Unless I was threatened in some
> way, in which case I would probably yield.

I didn't ask about `(*p)->x` as the operand; in that moderately complex
case, parentheses might be justifed for clarity.  I asked about `x` as
the operand.

Again, assuming a C-like language that spells `sizeof` as `$`.  It's one
of several unary operators, all of which have punctuation characters as
their symbols.  For which of the following would you feel the need to
add parentheses, and why?  Assume in each case that x is of an
appropriate type.  Remember, the operand is literally the identifier
`x`; that's not a stand-in for some more complicated expression.

    & x
    * x
    + x
    - x
    ~ x
    ! x

>> You can construct a mental model that treats "sizeof" as if it
>> were a function.  If you do so carefully enough, and keep in mind
>> the special cases that result from the inconsistencies between
>> that model and reality, you can write consistent and correct code.
>> But IMHO that's a lot more effort than just learning what "sizeof"
>> really is.  To do it reliably, you have to understand both your
>> mental model and the actual syntax and semantics of the language,
>> so you can avoid the inconsistencies.
>
> I have never found an inconsistency in using that form. I'd be curious
> to hear of one which could exist, after which I will likely explain
> further how I would never code in that way. :-)

Do you never apply sizeof to a type?  Or do you think of `sizeof(int)`
as a function call, even though `func_name(x)` would be a syntax error?

[...]

>> Similarly, "return" is a keyword, not a function, and it's used
>> as part of a "return statement", which has its own unique syntax
>> that's not related to function call syntax.
>> 
>> A return statement, unlike a function call, doesn't yield a result;
>> you can't write `x = return 42;`.  It causes the function in which
>> it occurs to return a result, which then becomes the value yielded
>> by the function call expression.  *Very* different.
>
> I see it as not different, because ... the "x = return 42;" operation
> you state here really does exist, but it comes in the form "x = f();"
> where the last thing done in f() for source code is "return 42;" which
> then does assign to the value x and initiates whatever machine
> mechanics are required to return from the function call, so as to
> return control to the remainder of the mechanics first initiated in
> the mechanics of executing f(), to then use that value for the
> assignment.

If you stretch things enough, you can think of just about anything as a
"function".  A switch statement is a "function" that takes two
arguments, an expression and a statement.  A struct definition is a
function that takes a list of member declarations as arguments, with a
funny syntax.  I'm sure a Lisp programmer could come up with more
examples.

I prefer to think of things that the C standard actually calls
"functions" as functions.  It's a lot less effort.

[...]

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

#63386

On Tuesday, June 16, 2015 at 5:16:49 PM UTC-4, Keith Thompson wrote:
> > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> Again, assuming a C-like language that spells `sizeof` as `$`.  It's one
> of several unary operators, all of which have punctuation characters as
> their symbols.  For which of the following would you feel the need to
> add parentheses, and why?  Assume in each case that x is of an
> appropriate type.  Remember, the operand is literally the identifier
> `x`; that's not a stand-in for some more complicated expression.
> 
>     & x
>     * x
>     + x
>     - x
>     ~ x
>     ! x

I sometimes put a parenthesis around bitwise operations. Probably not
ever on the other ones.

> > I have never found an inconsistency in using that form. I'd be curious
> > to hear of one which could exist, after which I will likely explain
> > further how I would never code in that way. :-)
> 
> Do you never apply sizeof to a type?  Or do you think of `sizeof(int)`
> as a function call, even though `func_name(x)` would be a syntax error?

I hadn't considered that to be an inconsistency with other functions, but
rather a nuance of its base ability being properly applied and exposed
through its syntax.

> If you stretch things enough, you can think of just about anything as a
> "function".  A switch statement is a "function" that takes two
> arguments, an expression and a statement.  A struct definition is a
> function that takes a list of member declarations as arguments, with a
> funny syntax.  I'm sure a Lisp programmer could come up with more
> examples.

That's actually an interesting way to think of that process. Same
with switch. I've never thought of it that way before. Interesting.

> I prefer to think of things that the C standard actually calls
> "functions" as functions.  It's a lot less effort.

I understand where you're coming from. I often look at things differently.
I recognize that sizeof() can take as input types and not generate a
syntax error. I view that as its allowance of input, just as int f(int a)
can receive a wide range of input values which are all legal, but it
won't receive a char*, for example, just as it won't receive "int".

I prefer to think of things as they are rather than how they've been
conveyed by (often legacy) convention over time.  It is a more effort,
but it results in a much more philosophical understanding of the thing,
and a less mechanical view of the thing.

It also comes with some detraction because such a person is often
isolated within their philosophy, which may seem fundamentally
divergent from mainstream ideas, and therefore kept at or beyond
arm's length. In short: it's lonely.

Best regards,
Rick C. Hodgin

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

#63364

In article <d880c856-c620-47d3-b70f-c2fbe753c5a3@googlegroups.com>,
Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
>On Tuesday, June 16, 2015 at 12:51:42 PM UTC-4, David Kleinecke wrote:
>> One way to think of it is that "sizeof (int)" is the sizeof operator 
>> acting on a type cast and "sizeof x" is the operator acting on a 
>> variable (like "& x") - and to forget that "sizeof (x)" is possible.
>
>It's why sizeof should always be sizeof(), and never sizeof.  I feel
>the same way about return (it should always be return() rather than
>return, and the same for other similar keywords).
>
>Enclosing in parentheses removes ambiguity and helps document exactly
>what's happening without needing to have a comprehensive understanding
>of the peculiarities of syntax on certain compiler keywords.
>
>Best regards,
>Rick C. Hodgin

Leader Kiki is not going to like this.

-- 
One of the best lines I've heard lately:

    Obama could cure cancer tomorrow, and the Republicans would be
    complaining that he had ruined the pharmaceutical business.

(Heard on Stephanie Miller = but the sad thing is that there is an awful lot
of direct truth in it.  We've constructed an economy in which eliminating
cancer would be a horrible disaster.  There are many other such examples.)

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

#63366

On Tuesday, June 16, 2015 at 2:38:28 PM UTC-4, Kenny McCormack wrote:
> Leader Kiki is not going to like this.

Who's Kiki?  Is Kiki the "K" in this "K&R" I've been reading about? :-)

Best regards,
Rick C. Hodgin

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

#63374

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> On Tuesday, June 16, 2015 at 2:38:28 PM UTC-4, Kenny McCormack wrote:
>> Leader Kiki is not going to like this.
>
> Who's Kiki?  Is Kiki the "K" in this "K&R" I've been reading about? :-)

"Kiki" seems to be this troll's childish nickname for me.  He's been
trying to bully me for years.  I suggest ignoring him.

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

#63384

In article <ln8ubjmmic.fsf@nuthaus.mib.org>,
Keith Thompson  <kst-u@mib.org> wrote:
>"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> On Tuesday, June 16, 2015 at 2:38:28 PM UTC-4, Kenny McCormack wrote:
>>> Leader Kiki is not going to like this.
>>
>> Who's Kiki?  Is Kiki the "K" in this "K&R" I've been reading about? :-)
>
>"Kiki" seems to be this troll's childish nickname for me.  He's been
>trying to bully me for years.  I suggest ignoring him.

I didn't invent it.  It was in common usage for quite a while before I
adopted it.

-- 
Mike Huckabee has yet to consciously uncouple from Josh Duggar.

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

#63355

David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> One way to think of it is that "sizeof (int)" is the sizeof operator 
> acting on a type cast and "sizeof x" is the operator acting on a 
> variable (like "& x") - and to forget that "sizeof (x)" is possible. 

That is, in my humble opinion, a misleading way to think about it.

A cast operator and the sizeof operator applied to a type name
both happen to use a similar syntax, a type name in parentheses,
but in very different contexts.  (Compound literals also use a
type name in parentheses, but it's neither preceded by a `sizeof`
operator nor followed by an expression.)

In `sizeof (int)`, the `(int)` is not a cast operator, any more than
the comma in `func(x, y)` is a comma operator or the `*` in `*ptr`
is a multiplication operator.  C re-uses punctuation characters in
diferent contexts, and their meaning is highly context-specific.

As for `sizeof x`, that's a `sizeof` operator applied to an
*expression* (specifically, the grammar requires a *unary-expression*
in that context).  In this case, the expression happens to be the
name of an object, but for example `sizeof 42` is equally valid.
A parenthesized expression is a unary-expression, so `sizeof (x)`
is also valid, but personally I prefer to add parentheses only
when they're necessary for grouping or when they improve clarity.
I probably wouldn't write `sizeof x ++`, but if I felt the need to
do so I might write it as `sizeof (x++)` just to make it obvious
what the `sizeof` applies to.

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

#63358

On 06/16/2015 02:05 PM, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> [...]
>> One way to think of it is that "sizeof (int)" is the sizeof operator 
>> acting on a type cast and "sizeof x" is the operator acting on a 
>> variable (like "& x") - and to forget that "sizeof (x)" is possible. 
> 
> That is, in my humble opinion, a misleading way to think about it.

The key thing about it that is misleading is that a cast operator can
only occur as part of a cast expression, and must therefore always be
followed by either a unary-expression or another cast-expression
(6.5.4p1). When occurring in a sizeof-expression, the parenthesized type
name must NOT be followed by a unary- or cast-expression. If it were, it
would be a syntax error (6.5.3p1).

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

#63432

On Tuesday, June 16, 2015 at 11:05:49 AM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> [...]
> > One way to think of it is that "sizeof (int)" is the sizeof operator 
> > acting on a type cast and "sizeof x" is the operator acting on a 
> > variable (like "& x") - and to forget that "sizeof (x)" is possible. 
> 
> That is, in my humble opinion, a misleading way to think about it.
> 
> A cast operator and the sizeof operator applied to a type name
> both happen to use a similar syntax, a type name in parentheses,
> but in very different contexts.  (Compound literals also use a
> type name in parentheses, but it's neither preceded by a `sizeof`
> operator nor followed by an expression.)
> 
> In `sizeof (int)`, the `(int)` is not a cast operator, any more than
> the comma in `func(x, y)` is a comma operator or the `*` in `*ptr`
> is a multiplication operator.  C re-uses punctuation characters in
> diferent contexts, and their meaning is highly context-specific.
> 
> As for `sizeof x`, that's a `sizeof` operator applied to an
> *expression* (specifically, the grammar requires a *unary-expression*
> in that context).  In this case, the expression happens to be the
> name of an object, but for example `sizeof 42` is equally valid.
> A parenthesized expression is a unary-expression, so `sizeof (x)`
> is also valid, but personally I prefer to add parentheses only
> when they're necessary for grouping or when they improve clarity.
> I probably wouldn't write `sizeof x ++`, but if I felt the need to
> do so I might write it as `sizeof (x++)` just to make it obvious
> what the `sizeof` applies to.
 
Come on - I didn't say sizeof(int) involved a cast. I said think of 
it as a cast - a gimmick to help one remember the syntax.

And it is useful, if I am writing a compliler, to think of the comma
in f(a,b) as the comma operator and give the comma operator different 
semantics in free-standing expressions versus function arguments. That
the standard chose not to do that is irrelevant.

There are numerous places in C where details can be handled in the 
syntax or the semantics and which way one goes is more a matter of 
taste than anything else.

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

#63447

David Kleinecke <dkleinecke@gmail.com> writes:
> On Tuesday, June 16, 2015 at 11:05:49 AM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> [...]
>> > One way to think of it is that "sizeof (int)" is the sizeof operator 
>> > acting on a type cast and "sizeof x" is the operator acting on a 
>> > variable (like "& x") - and to forget that "sizeof (x)" is possible. 
>> 
>> That is, in my humble opinion, a misleading way to think about it.
>> 
>> A cast operator and the sizeof operator applied to a type name
>> both happen to use a similar syntax, a type name in parentheses,
>> but in very different contexts.  (Compound literals also use a
>> type name in parentheses, but it's neither preceded by a `sizeof`
>> operator nor followed by an expression.)
>> 
>> In `sizeof (int)`, the `(int)` is not a cast operator, any more than
>> the comma in `func(x, y)` is a comma operator or the `*` in `*ptr`
>> is a multiplication operator.  C re-uses punctuation characters in
>> diferent contexts, and their meaning is highly context-specific.
>> 
>> As for `sizeof x`, that's a `sizeof` operator applied to an
>> *expression* (specifically, the grammar requires a *unary-expression*
>> in that context).  In this case, the expression happens to be the
>> name of an object, but for example `sizeof 42` is equally valid.
>> A parenthesized expression is a unary-expression, so `sizeof (x)`
>> is also valid, but personally I prefer to add parentheses only
>> when they're necessary for grouping or when they improve clarity.
>> I probably wouldn't write `sizeof x ++`, but if I felt the need to
>> do so I might write it as `sizeof (x++)` just to make it obvious
>> what the `sizeof` applies to.
>  
> Come on - I didn't say sizeof(int) involved a cast. I said think of 
> it as a cast - a gimmick to help one remember the syntax.

I didn't say you said it was a cast.  I said that thinking of it as a
cast is misleading.

> And it is useful, if I am writing a compliler, to think of the comma
> in f(a,b) as the comma operator and give the comma operator different 
> semantics in free-standing expressions versus function arguments. That
> the standard chose not to do that is irrelevant.

Really?  I don't see how that would be useful.  Most compilers use some
explicit representation of the C grammar.  The use of the comma as an
operator and as a separator between function arguments are in different
clauses of that grammar.  Or they use recursive descent, in which case
the handling of the different uses of the comma will be handled in
different parts of the parser.  How could it be useful to conflate them?

> There are numerous places in C where details can be handled in the 
> syntax or the semantics and which way one goes is more a matter of 
> taste than anything else.

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

#63535

On Wednesday, June 17, 2015 at 11:16:51 AM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> > On Tuesday, June 16, 2015 at 11:05:49 AM UTC-7, Keith Thompson wrote:
> >> David Kleinecke <dkleinecke@gmail.com> writes:
> >> [...]
> >> > One way to think of it is that "sizeof (int)" is the sizeof operator 
> >> > acting on a type cast and "sizeof x" is the operator acting on a 
> >> > variable (like "& x") - and to forget that "sizeof (x)" is possible. 
> >> 
> >> That is, in my humble opinion, a misleading way to think about it.
> >> 
> >> A cast operator and the sizeof operator applied to a type name
> >> both happen to use a similar syntax, a type name in parentheses,
> >> but in very different contexts.  (Compound literals also use a
> >> type name in parentheses, but it's neither preceded by a `sizeof`
> >> operator nor followed by an expression.)
> >> 
> >> In `sizeof (int)`, the `(int)` is not a cast operator, any more than
> >> the comma in `func(x, y)` is a comma operator or the `*` in `*ptr`
> >> is a multiplication operator.  C re-uses punctuation characters in
> >> diferent contexts, and their meaning is highly context-specific.
> >> 
> >> As for `sizeof x`, that's a `sizeof` operator applied to an
> >> *expression* (specifically, the grammar requires a *unary-expression*
> >> in that context).  In this case, the expression happens to be the
> >> name of an object, but for example `sizeof 42` is equally valid.
> >> A parenthesized expression is a unary-expression, so `sizeof (x)`
> >> is also valid, but personally I prefer to add parentheses only
> >> when they're necessary for grouping or when they improve clarity.
> >> I probably wouldn't write `sizeof x ++`, but if I felt the need to
> >> do so I might write it as `sizeof (x++)` just to make it obvious
> >> what the `sizeof` applies to.
> >  
> > Come on - I didn't say sizeof(int) involved a cast. I said think of 
> > it as a cast - a gimmick to help one remember the syntax.
> 
> I didn't say you said it was a cast.  I said that thinking of it as a
> cast is misleading.
> 
> > And it is useful, if I am writing a compliler, to think of the comma
> > in f(a,b) as the comma operator and give the comma operator different 
> > semantics in free-standing expressions versus function arguments. That
> > the standard chose not to do that is irrelevant.
> 
> Really?  I don't see how that would be useful.  Most compilers use some
> explicit representation of the C grammar.  The use of the comma as an
> operator and as a separator between function arguments are in different
> clauses of that grammar.  Or they use recursive descent, in which case
> the handling of the different uses of the comma will be handled in
> different parts of the parser.  How could it be useful to conflate them?
> 
> > There are numerous places in C where details can be handled in the 
> > syntax or the semantics and which way one goes is more a matter of 
> > taste than anything else.
 
In the C compilers I have written expressions are handled in a separate
block (think sub-routine - but not really a subroutine) and a function
call is essentially 
    function-name OPEN (expression) CLOSE
The semantics of COMMA change during this instance of expression from
the default semantics in
    variable EQUAL expression
and all the other places exprssions are used.

To not flip the semantics would be silly. Any other approach is
perverse. 

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

#63539

David Kleinecke <dkleinecke@gmail.com> writes:
> On Wednesday, June 17, 2015 at 11:16:51 AM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
[...]
>> > And it is useful, if I am writing a compliler, to think of the comma
>> > in f(a,b) as the comma operator and give the comma operator different 
>> > semantics in free-standing expressions versus function arguments. That
>> > the standard chose not to do that is irrelevant.
>> 
>> Really?  I don't see how that would be useful.  Most compilers use some
>> explicit representation of the C grammar.  The use of the comma as an
>> operator and as a separator between function arguments are in different
>> clauses of that grammar.  Or they use recursive descent, in which case
>> the handling of the different uses of the comma will be handled in
>> different parts of the parser.  How could it be useful to conflate them?
>> 
>> > There are numerous places in C where details can be handled in the 
>> > syntax or the semantics and which way one goes is more a matter of 
>> > taste than anything else.
>  
> In the C compilers I have written expressions are handled in a separate
> block (think sub-routine - but not really a subroutine) and a function
> call is essentially 
>     function-name OPEN (expression) CLOSE
> The semantics of COMMA change during this instance of expression from
> the default semantics in
>     variable EQUAL expression
> and all the other places exprssions are used.
>
> To not flip the semantics would be silly. Any other approach is
> perverse. 

That seems like an odd way to go about it.  Does it handle comma
operators within arguments correctly, like func((x, y))?

Normally the parser analyzes the program structure, driven by the
language grammar.  The portion of the compiler that generates code
for a function call would see a sequence of argument expressions;
it wouldn't even be aware that they were separated in the source
code by a token that happens to look exactly like a comma operator.

If, hypothetically, you wanted to compile a language that's just like
C except that function arguments are separated by semicolons rather
than commas, you'd just have to change the grammar specification,
and everything else would just work.  It would probably be a one-line
change.  I don't suggest that that particular flexibility is a real
advantage; it's merely a consequence of the way most parsers happen
to work.

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

#63546

On Thursday, June 18, 2015 at 10:42:42 AM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> > On Wednesday, June 17, 2015 at 11:16:51 AM UTC-7, Keith Thompson wrote:
> >> David Kleinecke <dkleinecke@gmail.com> writes:
> [...]
> >> > And it is useful, if I am writing a compliler, to think of the comma
> >> > in f(a,b) as the comma operator and give the comma operator different 
> >> > semantics in free-standing expressions versus function arguments. That
> >> > the standard chose not to do that is irrelevant.
> >> 
> >> Really?  I don't see how that would be useful.  Most compilers use some
> >> explicit representation of the C grammar.  The use of the comma as an
> >> operator and as a separator between function arguments are in different
> >> clauses of that grammar.  Or they use recursive descent, in which case
> >> the handling of the different uses of the comma will be handled in
> >> different parts of the parser.  How could it be useful to conflate them?
> >> 
> >> > There are numerous places in C where details can be handled in the 
> >> > syntax or the semantics and which way one goes is more a matter of 
> >> > taste than anything else.
> >  
> > In the C compilers I have written expressions are handled in a separate
> > block (think sub-routine - but not really a subroutine) and a function
> > call is essentially 
> >     function-name OPEN (expression) CLOSE
> > The semantics of COMMA change during this instance of expression from
> > the default semantics in
> >     variable EQUAL expression
> > and all the other places exprssions are used.
> >
> > To not flip the semantics would be silly. Any other approach is
> > perverse. 
> 
> That seems like an odd way to go about it.  Does it handle comma
> operators within arguments correctly, like func((x, y))?
 
Sure. The second ( flips the semantics back again to normal. The
( stack (in my recent stuff - recursion actually handles the flip
automatically) remembers which semantics.

> Normally the parser analyzes the program structure, driven by the
> language grammar.  The portion of the compiler that generates code
> for a function call would see a sequence of argument expressions;
> it wouldn't even be aware that they were separated in the source
> code by a token that happens to look exactly like a comma operator.
 
> If, hypothetically, you wanted to compile a language that's just like
> C except that function arguments are separated by semicolons rather
> than commas, you'd just have to change the grammar specification,
> and everything else would just work.  It would probably be a one-line
> change.  I don't suggest that that particular flexibility is a real
> advantage; it's merely a consequence of the way most parsers happen
> to work.
 
But not my parsers. I'll explain how I parse if you want to know.

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

#63333

Richard Heathfield wrote:
> Bill Cunningham wrote:
> >      That bring up to me something else. What about sizeof (int *) is that
> > valid? I know I should know, but I have so many other things to do too.
> 
> Yes, sizeof (int *) is valid too, although I would not recommend it. It 
> yields the number of bytes required to store a pointer-to-int. The 
> problem with it is as follows:
> 
> int *p;
> p = malloc(n * sizeof(int *));
> if(p != NULL)
> {
>    start filling p[0] to p[n - 1] with ints
> 
> All well and good, until the programmer decides that he actually meant 
> for p to be a double* instead. If he or she forgets to change the malloc 
> line to sizeof(double *), there may well not be enough storage to hold n 
> lots of double (and in fact there almost certainly won't be).
> 
> By writing:
> 
> p = malloc(n * sizeof *p);
> 
> instead, the programmer guards against this possibility because, if the 
> programmer changes the type of p in the declaration, the amount of 
> storage allocated will automatically change in line with the type change.

Not to mention the fact that you allocated space for n pointers to int 
but filled it with n ints.

[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