Constant strings

[Martin Shobe]

You gave descriptions that contained different words in different
orders, but I couldn't figure out how they had actual meaningfully
different meanings. That could have been a failure on my part to
understand what you were saying, but for now I still don't understand
the distinction you were making.

I don't know how to put it any more clearly. In the one case, the array
as a whole is what's const, and in the other, it's the elements of the
array that are const.

Is there something you can do with a const array of int that you can't
do with a array of const int? How about the other way around? It's easy
to come up with answers to those questions if 'array' were replaced with
'pointer', but I have no idea what you think the answers would be for an
array.

Not that I know of. That doesn't mean there isn't a difference to the
users of the phrase. That just means the difference isn't extensional.

Martin Shobe

 

[Keith Thompson]

With the first array, the elements are constant. We don't want anyone
messing about with the concept that in our system 1 is the first number
and replacing it with a 0 (or 42). With the second system, the array
is constant. We want ten and only ten numbers from 1 to 10, we don't
want anyone pre-pending a zero or chopping off the ten. Of course C,
like most languages, can't express the concept "this is a datum, not
data, it must be used whole or not at all". But we can at least make a
nod to it by outlawing passing a portion of the array to a subroutine.

In C as it is, you can't pass an array to a subroutine at all.

I don't think "const" or "constarray" is a reasonable way to express the
idea that you can't extract a subrange of an array. I'm not sure that's
a reason restriction to impose at all; surely you can do that with a
loop anyway.

In Ada, arrays are first-class types, and there's a syntax for taking a
slice of an array. There's no prohibition on taking a slice of a
constant array ("constant" here means the same thing as C's "const"):

X: constant String(1..5) := "abcde";
Y: array(2..4) of Integer := X(2..4);

 

[Keith Thompson]

The compiler is simply taking the easy option and obeying the minimal
rules of the language. In the two cases that puzzle you, the type of
the pointer 'target' is not const, so the pointers can be converted to
const void * (that memset wants) with no problem.

[...]

I think you meant "can be converted to (non-const) void*".

 

[Keith Thompson]

On 4/26/2014 4:39 AM, James Kuyper wrote: [...]
I don't know how to put it any more clearly. In the one case, the array
as a whole is what's const, and in the other, it's the elements of the
array that are const.

Isn't that circular? Perhaps it can't be put any more clearly
than that -- which implies, I think, that it's not a meaningful or
useful distinction.

[...]

Not that I know of. That doesn't mean there isn't a difference to the
users of the phrase. That just means the difference isn't extensional.

Just in case I'm not the only one having trouble with the word
"extensional", I'll quote a definition from Wikipedia.

http://en.wikipedia.org/wiki/Extensional_definition

An extensional definition of a concept or term formulates its
meaning by specifying its extension, that is, every object that
falls under the definition of the concept or term in question.

For example, an extensional definition of the term "nation of
the world" might be given by listing all of the nations of the
world, or by giving some other means of recognizing the members
of the corresponding class.

I suggest that if there's no definition of "const array" vs. "array
of const elements" that lets us distinguish between them, then it's
neither a useful distinction nor a meaningful phrase.

I can imagine a C-like language that makes the distinction, perhaps
in a way that has implications for type compatibility. But I don't
think such a language would be any more expressive than C, and I
don't think it could be made compatible with C other than by adding
a new keyword like _Constarray, since any reasonable syntax for
defining a const array already defines an array of const elements.

Though it's still entirely possible that I'm missing something.

 

[Keith Thompson]

It's not an issue to pass a 'const int' argument to an 'int' parameter for
example (otherwise a huge amount of code would run into problems.). Because
the callee can do what it likes to its copy without affecting the caller's
version.

Right -- because you *can't* pass a "const int" argument to a function.

An example:

void func(const int param0, const int param1) {
/* ... */
}

const int c = 10;
int nc = 20;
func(c, nc);

The "const" qualifiers on param0 and param1 mean only that func is not
allowed to modify its parameters, which are local objects; they have no
effect on callers.

The constness of c does not survive the evaluation of the expression
`c`. Evaluating the name of an object in a context that does
not require an lvalue yields the *value* of the object. Once the
expressions c and nc are evaluated, there is no further connection
to the objects whose values were extracted, and their constness or
non-constness is irrelevant.

N1570 6.3.2.1p2:

Except when it is the operand of the sizeof operator, the
_Alignof operator, the unary & operator, the ++ operator, the --
operator, or the left operand of the . operator or an assignment
operator, an lvalue that does not have array type is converted
to the value stored in the designated object (and is no longer
an lvalue); this is called *lvalue conversion*. If the lvalue
has qualified type, the value has the unqualified version of
the type of the lvalue [...]

(The reference to _Alignof was removed from the final C11 standard,
since _Alignof, for some unknown reason, cannot be applied to an
expression.)

 

[Kenny McCormack]

In C as it is, you can't pass an array to a subroutine at all.

(Pedantic, CLC-ish answer, which should make Kiki proud)

Because C doesn't have "subroutines".

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

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

 

[Martin Shobe]

On 4/26/2014 4:39 AM, James Kuyper wrote: [...]
I don't know how to put it any more clearly. In the one case, the array
as a whole is what's const, and in the other, it's the elements of the
array that are const.

Isn't that circular? Perhaps it can't be put any more clearly
than that -- which implies, I think, that it's not a meaningful or
useful distinction.

I haven't expressed an opinion about how "meaningful", "useful", or
"real" the difference is. I've just been trying (and failing) to explain
it. Anyway, it's reached the point where it's not worth it to me to try
any longer.

Martin Shobe

 

[glen herrmannsfeldt]

(snip)

My guess he is referring to the fact that in C we have just "functions",
but nothing called a "subroutine". Some languages make a distinction,
but in C we have "function returning void", where some other language
may call it a subroutine.

In languages without reserved words, there usually needs to be a
way to call a "subroutine" other than to put its name at the
beginning of the line. One has to have some way to keep it from
being ambiguous. Fortran and PL/I have the CALL statement for
subroutines (or procedures that don't return a value).

-- glen

 

[Seungbeom Kim]

So you can apply const to elements, but not to arrays (at least not
without the trick that Martin posted).

Yes you can, though it might be considered to be a mere word play:

(6.7.3/9) "If the specification of an array type includes any type
qualifiers, the element type is so-qualified, not the array type."
(And the footnote specifically mentions it can occur through typedefs.)

So you can apply const to arrays, but the language just automatically
transfers it to the elements.

 

[Seungbeom Kim]

My guess he is referring to the fact that in C we have just "functions",
but nothing called a "subroutine". Some languages make a distinction,
but in C we have "function returning void", where some other language
may call it a subroutine.

I've seen languages that differentiate procedures and functions,
but I've always thought that subroutines are a general term referring
to reusable program units, including procedures and functions and
even any portion of a BASIC program, without a clear block structure,
that can be called by GOSUB <line number>.

 

[Ben Bacarisse]

The compiler is simply taking the easy option and obeying the minimal
rules of the language. In the two cases that puzzle you, the type of
the pointer 'target' is not const, so the pointers can be converted to
const void * (that memset wants) with no problem.

[...]

I think you meant "can be converted to (non-const) void*".

Yes, thanks.

 

[Kenny McCormack]

I've seen languages that differentiate procedures and functions,
but I've always thought that subroutines are a general term referring
to reusable program units, including procedures and functions and
even any portion of a BASIC program, without a clear block structure,
that can be called by GOSUB <line number>.

I would venture that the word "subroutine" does not occur in the C
standards documents (Note: I may be wrong about this - it might be in there
somewhere for some reason or another - but the point still stands. There
is nothing in the C universe, as it is defined in this newsgroup, that is a
"subroutine"). In any case, I'm sure Kiki is grepping it already as we
speak...

As an illustration, think about what a feeding frenzy all the regs go into
everytime some hapless soul mentions "references" or "call by reference"
here. The sharks circle for the chance to be the first to crow that these
things don't exist in C. But anyone with any self-awareness knows
perfectly well what we mean when we talk about them in the context of C,
just as here anyone with any self-awareness knows what we mean when we talk
about a subroutine in C.

But this shouldn't stop the regs from having their little feeding frenzy.

--
Both the leader of the Mormon Church and the leader of the Catholic
church claim infallibility. Is it any surprise that these two orgs
revile each other? Anybody with any sense knows that 80-yr old codgers
are hardly infallible. Some codgers this age do well to find the crapper
in time and remember to zip-up.

 

[Ben Bacarisse]

Yes you can, though it might be considered to be a mere word play:

(6.7.3/9) "If the specification of an array type includes any type
qualifiers, the element type is so-qualified, not the array type."
(And the footnote specifically mentions it can occur through
typedefs.)

Thanks for posting this. After commenting on this topic I had a feeling
that I'd once seen something like this, but I could not find it.

<snip>

 

[Kaz Kylheku]

(Pedantic, CLC-ish answer, which should make Kiki proud)

Because C doesn't have "subroutines".

The likely intended meaning is that C doesn't support passing arrays to
functions, or returning arrays from functions.

 

[James Kuyper]

On 4/26/2014 4:39 AM, James Kuyper wrote: ....

I don't know how to put it any more clearly. In the one case, the array
as a whole is what's const, and in the other, it's the elements of the
array that are const.

No, that doesn't help. Without a specific consequence that follows from
an array being const, that wouldn't follow from it's elements being
const (or vice versa), it's just words being rearranged in pleasing
patterns.

I was prepared to hear that, if it an array's elements are not const,
but only the array itself, then those element can be written to. That
interpretation would make a "const array of int" indistinguishable from
an "array of int". Given the history that's been given for "B", "C"'s
ancestor, that would even make sense - the thing that was changeable in
B is, in C, only changeable for pointers, not arrays, so all C arrays
could b e considered 'const' in that sense. But you've made no such
assertions.

....

Not that I know of. That doesn't mean there isn't a difference to the
users of the phrase. That just means the difference isn't extensional.

I've looked up the term "extensional"
<http://en.wikipedia.org/wiki/Extensional>, which I've not seen used
with this meaning before. The definitions I found left me just as
confused about what you meant as I was before I read that definition. I
can understand the examples given in that article - I don't see the
applicability in this context. That article explains that, if Lois Lane
believes that Clark Kent will be investigating a given case with her,
then it is not true that she believes Superman will be investigating the
case with her, because she's unaware that they're the same person.
That's because statements about what her beliefs are, are inherently
intensional.

So, if someone believes that a const array of int is in some way
different from an array of const int, the are intensionally different,
even if that person is mistaken? If that's what you're talking about,
then I don't see any point in worrying about intensional differences;
only the extensional ones really matter to me. If there are intensional
difference without corresponding extensional differences, that is an
issue of great importance to those, such as teachers, whose job it is to
correct that discrepancy, but even for them, the intensional difference
is important only in a very negative sense.

Since I don't remember having ever heard of these terms before, it could
be I'm totally misunderstanding the extensional/intensional distinction,
and therefore radically misusing it in the preceding paragraph. If so,
I'd a appreciate a better explanation of it.

 

[glen herrmannsfeldt]

(snip)

But only a complete dickhead would differentiate when talking amongst
peer programmers, right?

I think it depends on context. In a discussion including a language
where they are different, it is confusing to use a term with a
different meaning than it has in that language. I sometimes use
the term 'procedure' as a generic term, though that could be
confusing in some contexts.

I ask because as a programmer for 30 years it would be plainly obvious
what was meant and would not alter *anything* even if used alternatively
when discussing a C code base.

In the case of C, I suppose so. In mixed language context, it can
get confusing.

-- glen

 

[Kenny McCormack]

The likely intended meaning is that C doesn't support passing arrays to
functions, or returning arrays from functions.

1) Whooosh!!!

2) (But seriously folks...) But it does. In all senses that matter.
Only a Kikian (or one who is, like me in this thread, pretending to be so
for comedic effect) would argue otherwise.

3) Just to be clear, C supports passing arrays to functions and supports
returning arrays from functions - every bit as much as it supports
"subroutines". You can quote me on that.

 

[BartC]

No, that doesn't help. Without a specific consequence that follows from
an array being const, that wouldn't follow from it's elements being
const (or vice versa), it's just words being rearranged in pleasing
patterns.

I've given at least one possible example elsewhere.

Where A is 'const int A[]', then A as an expression as type 'pointer to
const int' while &A as an expression has type 'pointer to array of const
int'.

This was sufficient to give a different diagnostic (when being passed as a
void* parameter) on one well-known compiler. Not an official difference, but
different behaviour nonetheless.

Having 'pointer to const array of int' would likely have produced the same
diagnostic as 'pointer to const int' (through making it easier to detect
that a pointer has a const target, compared with a possible 'pointer to
array of array of .... array of const T').

I was prepared to hear that, if it an array's elements are not const,
but only the array itself, then those element can be written to. That
interpretation would make a "const array of int" indistinguishable from
an "array of int".

Would the behaviour of such an array be different from that of a const
struct with all-const members? What about a const struct with all non-const
members, compared with a non-const struct with all-const members?

My point (which I've mentioned at least once elsewhere) is that language
allows structs to have const outside, (all) inside, or both (or none), which
could have allowed the same for arrays, with similar semantics.

--
Bartc







Given the history that's been given for "B", "C"'s

 

[Ben Bacarisse]

On 04/26/2014 09:05 AM, Martin Shobe wrote:

I've looked up the term "extensional"
<http://en.wikipedia.org/wiki/Extensional>, which I've not seen used
with this meaning before. The definitions I found left me just as
confused about what you meant as I was before I read that definition.

It might help to consider the meaning in (formal) logic which is
probably closer to what Martin means:

http://en.wikipedia.org/wiki/Extensionality

Applying that definition directly to C

long int a;
signed long a;

are different definitions, but the difference resides entirely in the
definition itself, and is not manifest in any property of 'a' that a
programmer might cares about. It would be reasonable to describe the
two definitions as different, but not extensionally different.

Using this context (where extensionality refers to differences in
program semantics) non-extensional differences matter in programming.
We carefully choose variable names thought it makes not a bit of
difference to the semantics; people argue over 'if (2 == x)' vs.
'if (x == 2)' and even over the order of 'const int' vs 'int const'.

However, because arrays play such a small role in the semantics of C, it
is very hard to see the value in even the non-extensional (i.e.
non-semantic) distinction between a const array and an array with const
elements.

So, if someone believes that a const array of int is in some way
different from an array of const int, the are intensionally different,
even if that person is mistaken?

I think it's more a matter of focus. When someone argues that it makes
no difference if you write 2 == x or x == 2 they are probably thinking
extensionally. They are intensionally different (in the technical
sense) and some people care. Similarly, it is logically possible to
imagine a situation in which some one might want to make the
non-extensional distinction between and const array and an array of
consts (though I can't think of one off hand).

If that's what you're talking about,
then I don't see any point in worrying about intensional differences;
only the extensional ones really matter to me.

I think I've seen you argue for things that have no semantic
consequences, such as expression order in equality tests, but the upshot
is that there are two separate cases to be made: do the two notions
differ in any way that is detectable within C, and are there any other
reasons why the distinction might matter?

<snip>

 

[Malcolm McLean]

My guess he is referring to the fact that in C we have just "functions",
but nothing called a "subroutine". Some languages make a distinction,
but in C we have "function returning void", where some other language
may call it a subroutine.

void was tacked on the the language later.

In original C, if you wanted a function that was inherently not returning a
value, like busy_idle(), you''d write

busy_idle(int N)
{
while(N--);
}

it would then return whatever happened to be in its return value register.

So
while(buy_idle(1));

was legal, but would give you odd results.

With void, the function would be declared void and this became illegal.
Which was a good thing. But it did add another rule for compiler writers to
be aware of.
The practical programming difference between a function which returns a
value in its return type and one that returns one through a passed pointers
is almost nothing, however. It's not a distinction that people who care
about good software design should be interested in, just people who
write formal grammars for compilers.