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

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

Array sizes and const

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

Contents

  Array sizes and const Les Cargill <lcargill99@comcast.com> - 2012-06-02 15:43 -0500
    Re: Array sizes and const Ian Collins <ian-news@hotmail.com> - 2012-06-03 08:56 +1200
    Re: Array sizes and const Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-02 16:59 -0400
      Re: Array sizes and const Les Cargill <lcargill99@comcast.com> - 2012-06-02 16:35 -0500
        Re: Array sizes and const jgk@panix.com (Joe keane) - 2012-06-08 20:05 +0000
        Re: Array sizes and const jgk@panix.com (Joe keane) - 2012-06-09 21:36 +0000
      Re: Array sizes and const Les Cargill <lcargill99@comcast.com> - 2012-06-02 16:43 -0500
    Re: Array sizes and const Keith Thompson <kst-u@mib.org> - 2012-06-02 14:59 -0700
      Re: Array sizes and const Les Cargill <lcargill99@comcast.com> - 2012-06-02 17:12 -0500
        Re: Array sizes and const Keith Thompson <kst-u@mib.org> - 2012-06-02 18:27 -0700
          Re: Array sizes and const Les Cargill <lcargill99@comcast.com> - 2012-06-02 22:27 -0500
        Re: Array sizes and const "BartC" <bc@freeuk.com> - 2012-06-03 11:24 +0100
          Re: Array sizes and const Keith Thompson <kst-u@mib.org> - 2012-06-03 13:51 -0700
            Re: Array sizes and const "BartC" <bc@freeuk.com> - 2012-06-04 12:20 +0100
              Re: Array sizes and const Jens Gustedt <jens.gustedt@loria.fr> - 2012-06-04 13:54 +0200
              Re: Array sizes and const Keith Thompson <kst-u@mib.org> - 2012-06-04 14:32 -0700
    Re: Array sizes and const Nobody <nobody@nowhere.com> - 2012-06-02 23:50 +0100
      Re: Array sizes and const Ian Collins <ian-news@hotmail.com> - 2012-06-03 10:53 +1200
        Re: Array sizes and const Nobody <nobody@nowhere.com> - 2012-06-03 14:35 +0100
      Re: Array sizes and const James Kuyper <jameskuyper@verizon.net> - 2012-06-02 21:11 -0400
        Re: Array sizes and const Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-06-03 07:39 -0700
          Re: Array sizes and const James Kuyper <jameskuyper@verizon.net> - 2012-06-03 16:03 -0400
          Re: Array sizes and const Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-03 21:49 +0100
            Re: Array sizes and const Keith Thompson <kst-u@mib.org> - 2012-06-03 14:49 -0700
            Re: Array sizes and const Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-06-03 15:02 -0700
              Re: Array sizes and const Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-04 01:21 +0100
          Re: Array sizes and const Ian Collins <ian-news@hotmail.com> - 2012-06-04 09:08 +1200
            Re: Array sizes and const Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-06-03 15:08 -0700
              Re: Array sizes and const Ian Collins <ian-news@hotmail.com> - 2012-06-04 10:37 +1200
                Re: Array sizes and const "BartC" <bc@freeuk.com> - 2012-06-03 23:47 +0100
                  Re: Array sizes and const Ian Collins <ian-news@hotmail.com> - 2012-06-04 10:55 +1200
                    Re: Array sizes and const Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-06-03 16:04 -0700
                      Re: Array sizes and const Ian Collins <ian-news@hotmail.com> - 2012-06-04 11:14 +1200
                        Re: Array sizes and const "BartC" <bc@freeuk.com> - 2012-06-04 00:23 +0100
                          Re: Array sizes and const Ian Collins <ian-news@hotmail.com> - 2012-06-04 11:30 +1200
                            Re: Array sizes and const "BartC" <bc@freeuk.com> - 2012-06-04 00:52 +0100
                              Re: Array sizes and const Ian Collins <ian-news@hotmail.com> - 2012-06-04 12:04 +1200
                          Re: Array sizes and const Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-04 01:39 +0100
                        Re: Array sizes and const Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-06-04 02:35 -0700
                    Re: Array sizes and const Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-04 01:33 +0100
                      Re: Array sizes and const Ian Collins <ian-news@hotmail.com> - 2012-06-04 12:35 +1200
                  Re: Array sizes and const pacman@kosh.dhis.org (Alan Curry) - 2012-06-04 21:28 +0000
          Re: Array sizes and const James Kuyper <jameskuyper@verizon.net> - 2012-06-04 12:08 -0400
          Re: Array sizes and const jgk@panix.com (Joe keane) - 2012-06-04 22:49 +0000
      Re: Array sizes and const David Brown <david.brown@hesbynett.no> - 2012-06-03 15:46 -0500
    Re: Array sizes and const Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-08 02:08 -0700
      Re: Array sizes and const Les Cargill <lcargill99@comcast.com> - 2012-06-08 06:45 -0500
        Re: Array sizes and const Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-08 10:49 -0700
          Re: Array sizes and const Les Cargill <lcargill99@comcast.com> - 2012-06-08 18:05 -0500
      Re: Array sizes and const Keith Thompson <kst-u@mib.org> - 2012-06-08 13:31 -0700
        Re: Array sizes and const Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-08 20:30 -0700

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

#21790

On 06/ 4/12 12:33 PM, Ben Bacarisse wrote:
> Ian Collins<ian-news@hotmail.com>  writes:
>
>> On 06/ 4/12 10:47 AM, BartC wrote:
>>> "Ian Collins"<ian-news@hotmail.com>   wrote in message
> <snip>
>>>> If a function doesn't modify a parameter, declare it const.  What's so
>>>> hard about that?
>>>
>>> Because nineteen times out of twenty, it won't modify it, so it means loads
>>> of const attributes cluttering up code.
>>>
>>> Of course some parameter types can be harmlessly modified (ints for
>>> example), and const isn't necessary, but then you have to start thinking
>>> about about every parameter and whether it will be modified in the caller or
>>> in the callee.
>>
>> Isn't that part of the design process?  Naturally it's pointless
>> declaring a value type parameter const, but pointer types should
>> be.
>
> A minor point...
>
> You keep talking about declaring parameters const when a function does
> not modify them (and now BartC has taken you at your word) but you are
> not, I think, talking about const parameters, nor about pointer
> parameters being const, (as above), but about parameters that are
> pointers to const types.

I am, thank you for the clarification.

-- 
Ian Collins

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

#21833

In article <jqgpig$plu$1@dont-email.me>, BartC <bc@freeuk.com> wrote:
>"Ian Collins" <ian-news@hotmail.com> wrote in message
>news:a327a6F5maU3@mid.individual.net...
>>
>> If a function doesn't modify a parameter, declare it const.  What's so
>> hard about that?
>
>Because nineteen times out of twenty, it won't modify it, so it means loads
>of const attributes cluttering up code.

The omission of const qualifiers clutters the code with spurious requests for
write access.

const-as-default for pointer target types is a good idea. It would be nice to
have it in the language, but the next best thing is to have it in your coding
style.

-- 
Alan Curry

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

#21821

On 06/03/2012 10:39 AM, Malcolm McLean wrote:
...
> ... Part of the reason is that whilst int member(const FOO *obj) is clear enough in intention, in fact the constness of obj does not extend to its members.

A compiler for which that was the case would be non-conforming. It
violates 6.5.2.3p4: "A postfix expression followed by the -> operator
and an identifier designates a member of a structure or union object.
... If the first expression is a pointer to a qualified type, the result
has the so-qualified version of the type of the designated member." Can
you provide an example of a compiler claiming to conform to the C
standard which treats a member of *obj as though it was not const-qualified?

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

#21843

In article <39346056-1528-4667-85d2-a860b6ba018a@googlegroups.com>,
Malcolm McLean  <malcolm.mclean5@btinternet.com> wrote:
>Part of the reason is that whilst int member(const FOO *obj) is clear
>enough in intention, in fact the constness of obj does not extend to
>its members.

know what you meant

The problem is that people often want a 'semantic' const.

For example:

    struct bar
    {
	int bar_color;
	char *bar_name;
	struct whiz *bar_whiz;
    };

    struct const_bar
    {
	const int bar_color;
	const char *bar_name;
	const struct whiz *bar_whiz;
    };

At first it looks like i made all the members 'const', but of course
that's not true.

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

#21764

On Sat, 02 Jun 2012 23:50:03 +0100, Nobody wrote:

> On Sat, 02 Jun 2012 15:43:40 -0500, Les Cargill wrote:
> 
>> And yes, I understand/speak/grok preprocessor vs. compiler. I know
>> *how*, I just wonder *why*. Is this a practical, strategic or tactical
>> thing, or am I just being silly? Was it a conscious decision of the
>> committee, or just one of those things?
> 
> K&R C didn't have "const". Along with "volatile", it was added during
> the standardisation process to facilitate optimisation.
> 
> The main purpose of "const" is to tell the compiler to assume that the
> value won't change. However, a const-qualified variable is still an
> lvalue, not a compile-time constant; changing that was presumably
> considered too radical.
> 
> If you want a compile-time integer constant, you can use enum, e.g.:
> 
> 	enum { size = SIZE };
> 
> This "trick" is still quite common in C++ code due to some compilers
> being a bit late to accept that a "static const" member really is a
> compile-time constant in C++, and the preprocessor not being an
> acceptable substitute when the name has to belong to a class or
> namespace.

In C, although you still can't declare a file-scope array of size "size" 
with "static const size = 100;", it is still better to make your "const" 
values "static" if you can.  Even though the compiler can't break the 
language rules and make "char array[size];" legal, it can at least do 
better optimisation with the static const.

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

#21946

Les Cargill <lcargill99@comcast.com> writes:

> I am using Mingw 3.4.5 on a 'Doze box, but it pretty much
> follows any Gnu compiler I've run into.
>
> Why is this:
>
> ---------------------------
> #define SIZE 20
> const int size = SIZE;
> char array[SIZE];
> ---------------------------
>
> legal, yet
>
> ---------------------------
> #define SIZE 20
> const int size = SIZE;
> char array[size];
> ---------------------------
>
> not?
>
> The int size is invariant, and ... "morally"
> equivalent to using SIZE, yet it won't let me do that.
>
> And yes, I understand/speak/grok preprocessor vs.
> compiler. I know *how*, I just wonder *why*. Is
> this a practical, strategic or tactical thing,
> or am I just being silly? Was it a conscious decision
> of the committee, or just one of those things?

I would like to offer some contrasting opinions to those of
Ian Collins (and no disrepect intended, I just have some
different views to suggest).

At the time C was first standardized, I don't think any C
implementations had this capability.  (I was working
actively in C++ during this time, and I don't remember C++
having it either.)  Whether it was considered or not, the
committee chose to be cautiously conservative and not
include such a rule in the Standard, and IMO that was an
apppropriate policy at that time.

Subsequently, I suspect it wasn't added for some combination
of (a) no one proposing/championing it, (b) little or no
experience with C implementations that offer it, and / or
(c) no perception of any significant demand.

Personally I would tend to side with those in category (c).
As language features go this one doesn't offer very much.
I know a lot of people don't like the C preprocessor, but
except for that I don't see any significant benefit from
providing this capability.  Why complicate the language
definition needlessly?

Incidentally, note that the Standard actually does allow
implementations to accept the example code without
complaint, under paragraph 10 of the section on Constant
Expressions.  (Some other people who post in c.l.c don't
agree with this conclusion;  note however that gcc's
behavior, to give one example, agrees with my assessment.)
Despite having the freedom to accept this construct, I'm not
aware of any implementations (of C) that do.  That probably
means there haven't been a lot of people clamoring for it.

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

#21951

Tim Rentsch wrote:
> Les Cargill <lcargill99@comcast.com> writes:
>
>> I am using Mingw 3.4.5 on a 'Doze box, but it pretty much
>> follows any Gnu compiler I've run into.
>>
>> Why is this:
>>
>> ---------------------------
>> #define SIZE 20
>> const int size = SIZE;
>> char array[SIZE];
>> ---------------------------
>>
>> legal, yet
>>
>> ---------------------------
>> #define SIZE 20
>> const int size = SIZE;
>> char array[size];
>> ---------------------------
>>
>> not?
>>
>> The int size is invariant, and ... "morally"
>> equivalent to using SIZE, yet it won't let me do that.
>>
>> And yes, I understand/speak/grok preprocessor vs.
>> compiler. I know *how*, I just wonder *why*. Is
>> this a practical, strategic or tactical thing,
>> or am I just being silly? Was it a conscious decision
>> of the committee, or just one of those things?
>
> I would like to offer some contrasting opinions to those of
> Ian Collins (and no disrepect intended, I just have some
> different views to suggest).
>
> At the time C was first standardized, I don't think any C
> implementations had this capability.  (I was working
> actively in C++ during this time, and I don't remember C++
> having it either.)  Whether it was considered or not, the
> committee chose to be cautiously conservative and not
> include such a rule in the Standard, and IMO that was an
> apppropriate policy at that time.
>
> Subsequently, I suspect it wasn't added for some combination
> of (a) no one proposing/championing it, (b) little or no
> experience with C implementations that offer it, and / or
> (c) no perception of any significant demand.
>
> Personally I would tend to side with those in category (c).
> As language features go this one doesn't offer very much.

It really doesn't offer much. The only reason I asked is
because there's been a gradual movement away from K&R to
.... something else.

> I know a lot of people don't like the C preprocessor,

I am not one of them. In lots of cases, I *prefer* it.
Attempts to eliminate the preprocessor are generally
somewhat/somehow worse than what they replace.

> but
> except for that I don't see any significant benefit from
> providing this capability.  Why complicate the language
> definition needlessly?
>

The only "why" is that you now have two thingies - one's
a macro, one's a const object, and they have slightly
different semantics, despite me wanting them to be the same
thing :)

It's by no means a huge problem.

> Incidentally, note that the Standard actually does allow
> implementations to accept the example code without
> complaint, under paragraph 10 of the section on Constant
> Expressions.  (Some other people who post in c.l.c don't
> agree with this conclusion;  note however that gcc's
> behavior, to give one example, agrees with my assessment.)
> Despite having the freedom to accept this construct, I'm not
> aware of any implementations (of C) that do.  That probably
> means there haven't been a lot of people clamoring for it.
>

--
Les Cargill

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

#21977

Les Cargill <lcargill99@comcast.com> writes:

> Tim Rentsch wrote:
>> Les Cargill <lcargill99@comcast.com> writes:
>>
>>> I am using Mingw 3.4.5 on a 'Doze box, but it pretty much
>>> follows any Gnu compiler I've run into.
>>>
>>> Why is this:
>>>
>>> ---------------------------
>>> #define SIZE 20
>>> const int size = SIZE;
>>> char array[SIZE];
>>> ---------------------------
>>>
>>> legal, yet
>>>
>>> ---------------------------
>>> #define SIZE 20
>>> const int size = SIZE;
>>> char array[size];
>>> ---------------------------
>>>
>>> not?
>>>
>>> [snip]
>> ... I don't see any significant benefit from
>> providing this capability.  Why complicate the language
>> definition needlessly?
>>
>
> The only "why" is that you now have two thingies - one's
> a macro, one's a const object, and they have slightly
> different semantics, despite me wanting them to be the same
> thing :)  [snip]

I suggest that there are at least a couple of other
reasons.  First is that the new method would need
to be documented in the Standard.  Readers of the
Standard know that many aspects that are seemingly
simple take an inordinate amount of description
(and discussion about what the description should
be) to specify.  In other words there is work
involved to do it, and the committee has plenty of
other, more important, things to keep them busy.

Second is that if such a capability were put in,
it's only a matter of time before someone wants
a "natural" extension to handle other possible
cases.  For example, what about this:

   const int size;
   char array[size];

   ...

   const int size = 20;

This should be easy to implement;  why not have it
(or so the argument would go)?

For another example, what about this:

   extern const int size;
   char array[size];

   ... and in another translation unit

   const int size = 20;

This also shouldn't be too hard to implement.  It
needs more elaborate linker technology, but given
what all else relocating linker/loaders do, that
isn't too much of a stretch.

I'm not trying to say that such arguments would be
convincing;  only that suggestions like these would
be made (and arguments to go with them).  Once the
door is opened, it's almost for sure that some
people will want to open it farther.  Better not
to open the door in the first place.

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

#22025

Tim Rentsch wrote:
> Les Cargill <lcargill99@comcast.com> writes:
>
>> Tim Rentsch wrote:
>>> Les Cargill <lcargill99@comcast.com> writes:
>>>
>>>> I am using Mingw 3.4.5 on a 'Doze box, but it pretty much
>>>> follows any Gnu compiler I've run into.
>>>>
>>>> Why is this:
>>>>
>>>> ---------------------------
>>>> #define SIZE 20
>>>> const int size = SIZE;
>>>> char array[SIZE];
>>>> ---------------------------
>>>>
>>>> legal, yet
>>>>
>>>> ---------------------------
>>>> #define SIZE 20
>>>> const int size = SIZE;
>>>> char array[size];
>>>> ---------------------------
>>>>
>>>> not?
>>>>
>>>> [snip]
>>> ... I don't see any significant benefit from
>>> providing this capability.  Why complicate the language
>>> definition needlessly?
>>>
>>
>> The only "why" is that you now have two thingies - one's
>> a macro, one's a const object, and they have slightly
>> different semantics, despite me wanting them to be the same
>> thing :)  [snip]
>
> I suggest that there are at least a couple of other
> reasons.  First is that the new method would need
> to be documented in the Standard.  Readers of the
> Standard know that many aspects that are seemingly
> simple take an inordinate amount of description
> (and discussion about what the description should
> be) to specify.  In other words there is work
> involved to do it, and the committee has plenty of
> other, more important, things to keep them busy.
>
> Second is that if such a capability were put in,
> it's only a matter of time before someone wants
> a "natural" extension to handle other possible
> cases.  For example, what about this:
>
>     const int size;
>     char array[size];
>
>     ...
>
>     const int size = 20;
>
> This should be easy to implement;  why not have it
> (or so the argument would go)?
>
> For another example, what about this:
>
>     extern const int size;
>     char array[size];
>
>     ... and in another translation unit
>
>     const int size = 20;
>
> This also shouldn't be too hard to implement.  It
> needs more elaborate linker technology, but given
> what all else relocating linker/loaders do, that
> isn't too much of a stretch.
>
> I'm not trying to say that such arguments would be
> convincing;  only that suggestions like these would
> be made (and arguments to go with them).  Once the
> door is opened, it's almost for sure that some
> people will want to open it farther.  Better not
> to open the door in the first place.
>


That is actually not a bad argument at all, and probably
close to the truth.

--
Les Cargill

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

#22010

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Les Cargill <lcargill99@comcast.com> writes:
>> I am using Mingw 3.4.5 on a 'Doze box, but it pretty much
>> follows any Gnu compiler I've run into.
>>
>> Why is this:
>>
>> ---------------------------
>> #define SIZE 20
>> const int size = SIZE;
>> char array[SIZE];
>> ---------------------------
>>
>> legal, yet
>>
>> ---------------------------
>> #define SIZE 20
>> const int size = SIZE;
>> char array[size];
>> ---------------------------
>>
>> not?

[snip]

> Incidentally, note that the Standard actually does allow
> implementations to accept the example code without
> complaint, under paragraph 10 of the section on Constant
> Expressions.  (Some other people who post in c.l.c don't
> agree with this conclusion;  note however that gcc's
> behavior, to give one example, agrees with my assessment.)
> Despite having the freedom to accept this construct, I'm not
> aware of any implementations (of C) that do.  That probably
> means there haven't been a lot of people clamoring for it.

How does gcc's behavior agree with your assessment?

$ cat c.c
const int max = 42;
int arr[max];
$ gcc -c c.c
c.c:2:5: error: variably modified ‘arr’ at file scope
$ gcc -std=c99 -pedantic -c c.c
c.c:2:5: error: variably modified ‘arr’ at file scope
$ 

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

#22035

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Les Cargill <lcargill99@comcast.com> writes:
>>> I am using Mingw 3.4.5 on a 'Doze box, but it pretty much
>>> follows any Gnu compiler I've run into.
>>>
>>> Why is this:
>>>
>>> ---------------------------
>>> #define SIZE 20
>>> const int size = SIZE;
>>> char array[SIZE];
>>> ---------------------------
>>>
>>> legal, yet
>>>
>>> ---------------------------
>>> #define SIZE 20
>>> const int size = SIZE;
>>> char array[size];
>>> ---------------------------
>>>
>>> not?
>
> [snip]
>
>> Incidentally, note that the Standard actually does allow
>> implementations to accept the example code without
>> complaint, under paragraph 10 of the section on Constant
>> Expressions.  (Some other people who post in c.l.c don't
>> agree with this conclusion;  note however that gcc's
>> behavior, to give one example, agrees with my assessment.)
>> Despite having the freedom to accept this construct, I'm not
>> aware of any implementations (of C) that do.  That probably
>> means there haven't been a lot of people clamoring for it.
>
> How does gcc's behavior agree with your assessment?
>
> $ cat c.c
> const int max = 42;
> int arr[max];
> $ gcc -c c.c
> c.c:2:5: error: variably modified 'arr' at file scope
> $ gcc -std=c99 -pedantic -c c.c
> c.c:2:5: error: variably modified 'arr' at file scope
> $ 

Gcc accepts some expressions as integer constant expressions that
don't satisfy the criteria in 6.6 p6.  It doesn't accept this
particular example, but it does for some others.  For example,
after including <stdlib.h>, a macro call

    offsetof( struct { int x; int y; }, y )

expands (in my local gcc) to

    ((size_t) &((struct { int x; int y; } *)0)->y)

which clearly doesn't satisfy the conditions of 6.6 p6, and yet
the declaration

    int x[ offsetof( struct { int x; int y; }, y ) ];

is accepted (as a top-level declaration) without complaint.
(The use of offsetof() here doesn't affect the behavior - a
similar declaration using the expansion shown above works
just as well in an array declaration.)

Corollory to the above observations, gcc accepts the premise
that 6.6p10 gives permission to accept other expressions
as integer constant expressions, even though they do not
satisfy 6.6 p6.  The example using a declared variable
as the dimension of an array declarator could, if an
implementation so chose, fall into that category.

[toc] | [prev] | [standalone]

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

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

csiph-web