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

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

who invented static?

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

Contents

  who invented static? fir <profesor.fir@gmail.com> - 2015-08-29 11:40 -0700
    Re: who invented static? David Kleinecke <dkleinecke@gmail.com> - 2015-08-29 13:36 -0700
      Re: who invented static? fir <profesor.fir@gmail.com> - 2015-08-29 13:46 -0700
        Re: who invented static? David Kleinecke <dkleinecke@gmail.com> - 2015-08-29 13:53 -0700
          Re: who invented static? James Kuyper <jameskuyper@verizon.net> - 2015-08-29 17:08 -0400
            Re: who invented static? David Brown <david.brown@hesbynett.no> - 2015-08-30 16:56 +0200
              Re: who invented static? James Kuyper <jameskuyper@verizon.net> - 2015-08-30 12:18 -0400
                Re: who invented static? David Brown <david.brown@hesbynett.no> - 2015-08-30 19:00 +0200
                  Re: who invented static? Richard Damon <Richard@Damon-Family.org> - 2015-08-30 13:23 -0400
                    Re: who invented static? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-30 21:18 +0100
                      Re: who invented static? Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 19:33 -0700
                    Re: who invented static? Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 19:26 -0700
                  Re: who invented static? James Kuyper <jameskuyper@verizon.net> - 2015-08-30 13:40 -0400
                    Re: who invented static? supercat@casperkitty.com - 2015-08-31 06:47 -0700
                    Re: who invented static? Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 19:20 -0700
                  Re: who invented static? Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 18:59 -0700
                    Re: who invented static? David Brown <david.brown@hesbynett.no> - 2015-09-07 10:25 +0200
                      Re: who invented static? Keith Thompson <kst-u@mib.org> - 2015-09-07 01:59 -0700
                        Re: who invented static? David Brown <david.brown@hesbynett.no> - 2015-09-07 12:22 +0200
                          Re: who invented static? James Kuyper <jameskuyper@verizon.net> - 2015-09-07 13:04 -0400
                            Re: who invented static? David Brown <david.brown@hesbynett.no> - 2015-09-07 21:25 +0200
                              Re: who invented static? James Kuyper <jameskuyper@verizon.net> - 2015-09-07 15:47 -0400
                                Re: who invented static? Philip Lantz <prl@canterey.us> - 2015-09-07 13:27 -0700
                                  Re: who invented static? James Kuyper <jameskuyper@verizon.net> - 2015-09-07 17:31 -0400
                                    Re: who invented static? David Brown <david.brown@hesbynett.no> - 2015-09-08 09:16 +0200
                              Re: who invented static? Keith Thompson <kst-u@mib.org> - 2015-09-07 13:27 -0700
                                Re: who invented static? David Brown <david.brown@hesbynett.no> - 2015-09-08 09:12 +0200
                              Re: who invented static? Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-07 16:06 -0700
                                Re: who invented static? David Brown <david.brown@hesbynett.no> - 2015-09-08 09:08 +0200
                                Re: who invented static? Keith Thompson <kst-u@mib.org> - 2015-09-08 10:18 -0700
                                  Re: who invented static? James Kuyper <jameskuyper@verizon.net> - 2015-09-08 13:28 -0400
          Re: who invented static? fir <profesor.fir@gmail.com> - 2015-08-29 14:18 -0700
            Re: who invented static? fir <profesor.fir@gmail.com> - 2015-09-01 01:36 -0700
      Re: who invented static? Keith Thompson <kst-u@mib.org> - 2015-08-29 14:27 -0700
    Re: who invented static? Siri Cruz <chine.bleu@yahoo.com> - 2015-08-29 14:32 -0700
      Re: who invented static? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-29 23:03 +0000
      Re: who invented static? fir <profesor.fir@gmail.com> - 2015-09-01 01:52 -0700
        Re: who invented static? Robert Wessel <robertwessel2@yahoo.com> - 2015-09-01 23:42 -0500
          Re: who invented static? fir <profesor.fir@gmail.com> - 2015-09-02 00:14 -0700
            Re: who invented static? Richard Heathfield <rjh@cpax.org.uk> - 2015-09-02 08:24 +0100
          Re: who invented static? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-04 04:25 +0000
            Re: who invented static? fir <profesor.fir@gmail.com> - 2015-09-04 00:45 -0700
              Re: who invented static? Robert Wessel <robertwessel2@yahoo.com> - 2015-09-04 04:09 -0500
                Re: who invented static? fir <profesor.fir@gmail.com> - 2015-09-04 02:35 -0700
                  Re: who invented static? Robert Wessel <robertwessel2@yahoo.com> - 2015-09-04 23:58 -0500
                    Re: who invented static? fir <profesor.fir@gmail.com> - 2015-09-05 03:02 -0700
                    Re: who invented static? wssimms@gmail.com - 2015-09-05 13:14 -0700
                      Re: who invented static? fir <profesor.fir@gmail.com> - 2015-09-05 13:49 -0700
                      Re: who invented static? Siri Cruz <chine.bleu@yahoo.com> - 2015-09-05 14:09 -0700
                        Re: who invented static? gazelle@shell.xmission.com (Kenny McCormack) - 2015-09-05 22:30 +0000
                          Re: who invented static? wssimms@gmail.com - 2015-09-05 20:41 -0700
                            Re: who invented static? gazelle@shell.xmission.com (Kenny McCormack) - 2015-09-06 05:28 +0000
                              Re: who invented static? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-05 22:40 -0700
                            Re: who invented static? James Kuyper <jameskuyper@verizon.net> - 2015-09-06 11:42 -0400
                      Re: who invented static? Robert Wessel <robertwessel2@yahoo.com> - 2015-09-05 23:38 -0500
              Re: who invented static? Siri Cruz <chine.bleu@yahoo.com> - 2015-09-04 02:34 -0700
                Re: who invented static? fir <profesor.fir@gmail.com> - 2015-09-04 02:43 -0700
                Re: who invented static? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-05 01:30 +0000
                  Re: who invented static? Siri Cruz <chine.bleu@yahoo.com> - 2015-09-04 20:52 -0700
                    Re: who invented static? Robert Wessel <robertwessel2@yahoo.com> - 2015-09-05 00:03 -0500
                    Re: who invented static? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-05 09:04 +0000
                      Re: who invented static? fir <profesor.fir@gmail.com> - 2015-09-05 03:02 -0700
                      Re: who invented static? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-05 04:33 -0700
                        Re: who invented static? Reinhardt Behm <rbehm@hushmail.com> - 2015-09-05 20:08 +0800
                          Re: who invented static? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-05 05:21 -0700
                            Re: who invented static? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-05 06:37 -0700
                          Re: who invented static? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-05 16:54 +0000
                    Re: who invented static? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-05 11:06 +0100
                      Re: who invented static? fir <profesor.fir@gmail.com> - 2015-09-05 03:17 -0700
                    Re: who invented static? raltbos@xs4all.nl (Richard Bos) - 2015-09-05 19:14 +0000
                      Re: who invented static? fir <profesor.fir@gmail.com> - 2015-09-05 12:59 -0700
              Re: who invented static? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-05 01:24 +0000

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

#69834

On 07/09/15 19:04, James Kuyper wrote:
> On 09/07/2015 06:22 AM, David Brown wrote:
> ...
>> However, as far as I can see, "void func(int x[static 100])" means
>> almost exactly the same to the compiler as "void func(int x[100])".  The
>> compiler is quite happy to view the declaration with the "static" as
>> being entirely compatible with those you listed without the "static",
>> and it is quite happy to have multiple declarations of the same function
>> with different static sizes of the array.
>
> The key difference is that without the "static", there's undefined
> behavior only if the code for func(p) tries to access x[i] for values of
> i such that p[i] would have undefined behavior. With "static 100", it's
> also undefined behavior to call the function with a pointer to less than
> 100 consecutive accessible 'int' objects, regardless of what func()
> actually does with x.

That's what I thought was the case, but then Tim confused me by saying 
that without the "static" there is still undefined behaviour if you call 
the function with a pointer to less than 100 ints, even if the function 
does not attempt to access them.  If I was merely mistaken in my 
interpretation of Tim (or if Time made a mistake in his description), 
then I believe I understand the point.

> I don't fully understand what opportunities this
> opens up for optimization, but if Tim says there are some, I'm willing
> to guess that he might be right.

Tim's example was that the compiler could issue cache prefetches for 
data without worrying about whether or not it was accessible.  Usually 
prefetches are not dangerous operations - even if, for example, the 
cpu's MMU was set up to trap on accesses beyond the array then a 
prefetch would typically not trap until the addresses are accessed by 
non-prefetch instructions.  But maybe on some cpus it /would/ trap.

However, other possibilities include loop unrolling, converting the loop 
to run backwards (if that happened to be more efficient), or loading 
data in larger lumps into SIMD registers.

I doubt if there are many opportunities to make significant speed 
improvements, but there always some.

> But for me, the only useful aspect of
> this feature is one not guaranteed by the standard - the possibility of
> getting a warning message during compilation of the program.
>

I agree - that's what would be most useful for me.  That is why I find 
it particularly disappointing that not only does the standard not 
specify any diagnostics, it does not even require the code to be 
consistent in the size of the static array parameters.

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

#69838

On 09/07/2015 03:25 PM, David Brown wrote:
> On 07/09/15 19:04, James Kuyper wrote:
>> On 09/07/2015 06:22 AM, David Brown wrote:
>> ...
>>> However, as far as I can see, "void func(int x[static 100])" means
>>> almost exactly the same to the compiler as "void func(int x[100])".  The
>>> compiler is quite happy to view the declaration with the "static" as
>>> being entirely compatible with those you listed without the "static",
>>> and it is quite happy to have multiple declarations of the same function
>>> with different static sizes of the array.
>>
>> The key difference is that without the "static", there's undefined
>> behavior only if the code for func(p) tries to access x[i] for values of
>> i such that p[i] would have undefined behavior. With "static 100", it's
>> also undefined behavior to call the function with a pointer to less than
>> 100 consecutive accessible 'int' objects, regardless of what func()
>> actually does with x.
> 
> That's what I thought was the case, but then Tim confused me by saying 
> that without the "static" there is still undefined behaviour if you call 
> the function with a pointer to less than 100 ints, even if the function 
> does not attempt to access them. ...

Could you cite text written by him that you believe expresses that
opinion? I went to Google Groups to review his conversations with you,
and didn't see anything like that; but it's a fairly large amount of
text, and I might have missed something.

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

#69846

James Kuyper wrote:
> On 09/07/2015 03:25 PM, David Brown wrote:
> > On 07/09/15 19:04, James Kuyper wrote:
> >> On 09/07/2015 06:22 AM, David Brown wrote:
> >> ...
> >>> However, as far as I can see, "void func(int x[static 100])" means
> >>> almost exactly the same to the compiler as "void func(int x[100])".  The
> >>> compiler is quite happy to view the declaration with the "static" as
> >>> being entirely compatible with those you listed without the "static",
> >>> and it is quite happy to have multiple declarations of the same function
> >>> with different static sizes of the array.
> >>
> >> The key difference is that without the "static", there's undefined
> >> behavior only if the code for func(p) tries to access x[i] for values of
> >> i such that p[i] would have undefined behavior. With "static 100", it's
> >> also undefined behavior to call the function with a pointer to less than
> >> 100 consecutive accessible 'int' objects, regardless of what func()
> >> actually does with x.
> > 
> > That's what I thought was the case, but then Tim confused me by saying 
> > that without the "static" there is still undefined behaviour if you call 
> > the function with a pointer to less than 100 ints, even if the function 
> > does not attempt to access them. ...
> 
> Could you cite text written by him that you believe expresses that
> opinion? I went to Google Groups to review his conversations with you,
> and didn't see anything like that; but it's a fairly large amount of
> text, and I might have missed something.

Here's the place:
On 07/09/15 03:59, Tim Rentsch wrote:
> David Brown <david.brown@hesbynett.no> writes:
> > On 30/08/15 18:18, James Kuyper wrote:
> >> Given:
> >>
> >>      void f(int array[static 3]);
> >>      int large_array[6];
> >>      int small_array[2];
> >>      int *p = small_array;
> >>
> >> then f(large_array) is fine, because large_array has more than 3
> >> elements.  However, f(small_array) violates a "shall" that occurs outside
> >> of a constraint, because small_array has fewer than 3 elements.  The
> >> behavior is therefore undefined.  I would have preferred that this be a
> >> constraint violation, and I would expect any decent implementation of
> >> C99 or later to issue the diagnostic message that would be mandatory if
> >> it were a constraint violation - in my opinion, that possibility is the
> >> only thing that makes this feature worthwhile.  I think that the reason
> >> why it cannot be made a constraint violation is that f(p) is also a
> >> violation of the same rule, and unlike f(small_array), it's not in
> >> general easy for a compiler to identify the fact that an arbitrary
> >> pointer points at location which violates this rule.
> >
> > But surely if g were defined:
> >
> >     void g(int array[3]);
> >
> > Then g(small_array) would still be a constraint violation?
> 
> No, it isn't.
> 
> > Or is it
> > defined behaviour to call g(small_array), and only becomes undefined
> > if g() accesses array[2] ?
> 
> No.  A call like g(small_array) is undefined behavior whether
> code in g() accesses that parameter or not.

My guess is that when Tim wrote that, he meant to refer to f rather than 
g. If not, then I'm confused too.

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

#69850

On 09/07/2015 04:27 PM, Philip Lantz wrote:
...
> On 07/09/15 03:59, Tim Rentsch wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 30/08/15 18:18, James Kuyper wrote:
>>>> Given:
>>>>
>>>>      void f(int array[static 3]);
>>>>      int large_array[6];
>>>>      int small_array[2];
...
>>> But surely if g were defined:
>>>
>>>     void g(int array[3]);
>>>
>>> Then g(small_array) would still be a constraint violation?
>>
>> No, it isn't.
>>
>>> Or is it
>>> defined behaviour to call g(small_array), and only becomes undefined
>>> if g() accesses array[2] ?
>>
>> No.  A call like g(small_array) is undefined behavior whether
>> code in g() accesses that parameter or not.
> 
> My guess is that when Tim wrote that, he meant to refer to f rather than 
> g. If not, then I'm confused too.

I read precisely that paragraph, looking for precisely that kind of
answer, and didn't notice that Tim gave it. Proofreading is not one of
my strong points.

I gave David a contrary answer to the same question, and now that I've
looked on Google Groups, I see that Tim disagreed with me:

> Someone might want to tell James ... 

The reason he put it that way was that he knows I've got him kill-filed,
even though he's not a troll and is very knowledgeable about C, because
I've found that we often tend to get stuck in long unproductive
arguments. He was hoping someone would quote his message so I could see
it, but nobody did. I hope that this doesn't turn into one of those
arguments.

> ... that the behavior of this call
> is undefined behavior no matter which elements of 'array' g()
> accesses (eg, even if g() function body is empty).  6.7.6.3 p7. 

6.7.6.3p7 indicates that "If the keyword static also appears within the
[ and ] of the array type derivation, then for each call to the
function, the value of the corresponding actual argument shall provide
access to the first element of an array with at least as many
elements as specified by the size expression.". This is "... a shall ...
that appears outside of a constraint ...", so "... the behavior is
undefined." (4p2) when it is violated, but I don't see how that applies
to g(), since "... the keyword static ... " does NOT appear "... within
the [ and ] of the array type derivation ..." in the declaration of g().

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

#69875

On 07/09/15 23:31, James Kuyper wrote:
> On 09/07/2015 04:27 PM, Philip Lantz wrote:
> ...
>> On 07/09/15 03:59, Tim Rentsch wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 30/08/15 18:18, James Kuyper wrote:
>>>>> Given:
>>>>>
>>>>>      void f(int array[static 3]);
>>>>>      int large_array[6];
>>>>>      int small_array[2];
> ...
>>>> But surely if g were defined:
>>>>
>>>>     void g(int array[3]);
>>>>
>>>> Then g(small_array) would still be a constraint violation?
>>>
>>> No, it isn't.
>>>
>>>> Or is it
>>>> defined behaviour to call g(small_array), and only becomes undefined
>>>> if g() accesses array[2] ?
>>>
>>> No.  A call like g(small_array) is undefined behavior whether
>>> code in g() accesses that parameter or not.
>>
>> My guess is that when Tim wrote that, he meant to refer to f rather than 
>> g. If not, then I'm confused too.
> 
> I read precisely that paragraph, looking for precisely that kind of
> answer, and didn't notice that Tim gave it. Proofreading is not one of
> my strong points.
> 
> I gave David a contrary answer to the same question, and now that I've
> looked on Google Groups, I see that Tim disagreed with me:
> 
>> Someone might want to tell James ... 
> 
> The reason he put it that way was that he knows I've got him kill-filed,
> even though he's not a troll and is very knowledgeable about C, because
> I've found that we often tend to get stuck in long unproductive
> arguments. He was hoping someone would quote his message so I could see
> it, but nobody did. I hope that this doesn't turn into one of those
> arguments.
> 

I believe it is all sorted out now, and there is no need for a long
argument.  (Not that people in c.l.c. need a reason for having long
arguments...).

I have certainly learning something new from this thread, especially
thanks to you and Tim.  I am not sure this use of "static" will find
much use in my own code - it does not offer the strong checking that it
could do, but it is good to know about it.

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

#69845

David Brown <david.brown@hesbynett.no> writes:
> On 07/09/15 19:04, James Kuyper wrote:
[...]
>> The key difference is that without the "static", there's undefined
>> behavior only if the code for func(p) tries to access x[i] for values of
>> i such that p[i] would have undefined behavior. With "static 100", it's
>> also undefined behavior to call the function with a pointer to less than
>> 100 consecutive accessible 'int' objects, regardless of what func()
>> actually does with x.
>
> That's what I thought was the case, but then Tim confused me by saying 
> that without the "static" there is still undefined behaviour if you call 
> the function with a pointer to less than 100 ints, even if the function 
> does not attempt to access them.  If I was merely mistaken in my 
> interpretation of Tim (or if Time made a mistake in his description), 
> then I believe I understand the point.

I don't know whether the mistake was yours or Tim's, but that particular
undefined behavior occurs only when the "static" keyword is present.

[...]

> I agree - that's what would be most useful for me.  That is why I find 
> it particularly disappointing that not only does the standard not 
> specify any diagnostics, it does not even require the code to be 
> consistent in the size of the static array parameters.

A diagnostic cannot be required in all cases, since the size of the
array is not necessarily known at compile time:

    void func(int arr[static 100]);
    int *ptr = malloc(N);
    func(ptr);

In such cases, the standard generally leaves it to individual compilers
to issue warnings when they can.

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

#69874

On 07/09/15 22:27, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 07/09/15 19:04, James Kuyper wrote:
> [...]
>>> The key difference is that without the "static", there's undefined
>>> behavior only if the code for func(p) tries to access x[i] for values of
>>> i such that p[i] would have undefined behavior. With "static 100", it's
>>> also undefined behavior to call the function with a pointer to less than
>>> 100 consecutive accessible 'int' objects, regardless of what func()
>>> actually does with x.
>>
>> That's what I thought was the case, but then Tim confused me by saying 
>> that without the "static" there is still undefined behaviour if you call 
>> the function with a pointer to less than 100 ints, even if the function 
>> does not attempt to access them.  If I was merely mistaken in my 
>> interpretation of Tim (or if Time made a mistake in his description), 
>> then I believe I understand the point.
> 
> I don't know whether the mistake was yours or Tim's, but that particular
> undefined behavior occurs only when the "static" keyword is present.
> 
> [...]
> 
>> I agree - that's what would be most useful for me.  That is why I find 
>> it particularly disappointing that not only does the standard not 
>> specify any diagnostics, it does not even require the code to be 
>> consistent in the size of the static array parameters.
> 
> A diagnostic cannot be required in all cases, since the size of the
> array is not necessarily known at compile time:
> 
>     void func(int arr[static 100]);
>     int *ptr = malloc(N);
>     func(ptr);
> 
> In such cases, the standard generally leaves it to individual compilers
> to issue warnings when they can.
> 

I agree that the compiler cannot see such cases.  But it certainly /can/
see a case like this:

void func(int arr[static 100]);
void func(int arr[static 200]);
void func(int arr[300]);

All the numbers involved have to be available at compile time.  Yet not
only are diagnostics not mandatory, the code is actually perfectly
acceptable by the standards.  That is a missed opportunity by the
standards folk, IMHO.

Of course, compilers can offer addition (non-default) warning options to
help spot that kind of thing too.

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

#69855

David Brown <david.brown@hesbynett.no> writes:

> On 07/09/15 19:04, James Kuyper wrote:
>> On 09/07/2015 06:22 AM, David Brown wrote:
>> ...
>>> However, as far as I can see, "void func(int x[static 100])" means
>>> almost exactly the same to the compiler as "void func(int x[100])".  The
>>> compiler is quite happy to view the declaration with the "static" as
>>> being entirely compatible with those you listed without the "static",
>>> and it is quite happy to have multiple declarations of the same function
>>> with different static sizes of the array.
>>
>> The key difference is that without the "static", there's undefined
>> behavior only if the code for func(p) tries to access x[i] for values of
>> i such that p[i] would have undefined behavior.  With "static 100", it's
>> also undefined behavior to call the function with a pointer to less than
>> 100 consecutive accessible 'int' objects, regardless of what func()
>> actually does with x.
>
> That's what I thought was the case, but then Tim confused me by saying
> that without the "static" there is still undefined behaviour if you
> call the function with a pointer to less than 100 ints, even if the
> function does not attempt to access them.  [snip]

I need to give a mea culpa here.  I overlooked that the only
declaration of g() lacked the static attribute.  I have a partial
explanation for why that may have happened, but it was a mistake
on my part.  My apologies to James, to David, and also anyone
else who may have been mislead or confused.  Also I hope someone
will arrange for James to get a copy of my apology.

Now here is the original context:

[taken from a posting by David Brown]

> On 30/08/15 18:18, James Kuyper wrote:
> > On 08/30/2015 10:56 AM, David Brown wrote:
> >> On 29/08/15 23:08, James Kuyper wrote:
> >>
> >>> The following use of "static" is new in C99, and can only occur in the
> >>> leading dimension of a function parameter declared as an array:
> >>> "If the keyword static also appears within the [ and ] of the array type
> >>> derivation, then for each call to the function, the value of the
> >>> corresponding actual argument shall provide access to the first element
> >>> of an array with at least as many elements as specified by the size
> >>> expression."  6.7.6.3p7
> >>>
> >>> This obviously should have no counterpart in K&R C.
> >>
> >> This last use of "static" is completely new to me.  I can see the
> >> corresponding paragraph in the C11 standards (since that's the one I
> >> have handy), but I can't figure out what it means or what it is for.
> >
> > Given:
> >
> >      void f(int array[static 3]);
> >      int large_array[6];
> >      int small_array[2];
> >      int *p = small_array;
> >
> > then f(large_array) is fine, because large_array has more than 3
> > elements.  However, f(small_array) violates a "shall" that occurs outside
> > of a constraint, because small_array has fewer than 3 elements.  The
> > behavior is therefore undefined.  I would have preferred that this be a
> > constraint violation, and I would expect any decent implementation of
> > C99 or later to issue the diagnostic message that would be mandatory if
> > it were a constraint violation - in my opinion, that possibility is the
> > only thing that makes this feature worthwhile.  I think that the reason
> > why it cannot be made a constraint violation is that f(p) is also a
> > violation of the same rule, and unlike f(small_array), it's not in
> > general easy for a compiler to identify the fact that an arbitrary
> > pointer points at location which violates this rule.
> 
> But surely if g were defined:
> 
>     void g(int array[3]);
> 
> Then g(small_array) would still be a constraint violation?  Or is it
> defined behaviour to call g(small_array), and only becomes undefined
> if g() accesses array[2] ?
> 
> It seems to me that even without the "static", g is asking for a
> parameter with particular characteristics, and calling g(small_array)
> is breaking that requirement.

Since the discussion was about the static attribute, I assumed
that the parameter of g() was marked in this way, despite (or
overlooking) the given declaration.  This impression was further
led astray by the paragraph that starts "It seems to me that even
without the "static", g is asking for ...", which sounds like it
is offering a contrast to the previous paragraph, ie, that g()
/did/ have static for that question.  To be clear on the point,
if all the declarations for g() don't have 'static' as part of
the first parameter declaration, then g(small_array) is indeed
defined behavior, and the behavior is undefined only if accesses
are made outside the actual bounds of the array argument (eg,
array[2]).

Also, I think it's important to add another remark.  This isn't
meant to excuse my earlier oversight, but I think it's important
to note here.  If g() is declared as above, and various files
are compiled using that declaration, but where g() is defined
in another translation unit, it is defined like so:

    void
    g( int array[static 3] ){
        ...
    }

then calling g(small_array) /is/ undefined behavior, even though
the "static-ness" of that parameter is not visible at those call
sites.  In fact it goes farther than that.  As I read the
Standard, if /any/ declaration of g() gives a 'static' attribute,
it's the same as if they all did.  Note that this is different
than how, eg, 'restrict' or 'const', behaves:  with qualifiers,
the governing occurrence is the function definition, and nothing
else counts.  But how 'static' works is described slightly
differently, and appears to apply no matter which declaration it
occurs in.  (I admit this question is not addressed as clearly as
I would like, ie, I think reasonable arguments could be made with
different conclusions.  IMO the interpretation I have given is
the most natural one, but in the interest of fairness I have to
add that other interpretations are plausibly defensible.)  So the
phrasing of questions related to array "static-ness" is more
delicate than it is for qualifiers like 'restrict' or 'const.

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

#69873

On 08/09/15 01:06, Tim Rentsch wrote:
> David Brown <david.brown@hesbynett.no> writes:
> 
>> On 07/09/15 19:04, James Kuyper wrote:
>>> On 09/07/2015 06:22 AM, David Brown wrote:
>>> ...
>>>> However, as far as I can see, "void func(int x[static 100])" means
>>>> almost exactly the same to the compiler as "void func(int x[100])".  The
>>>> compiler is quite happy to view the declaration with the "static" as
>>>> being entirely compatible with those you listed without the "static",
>>>> and it is quite happy to have multiple declarations of the same function
>>>> with different static sizes of the array.
>>>
>>> The key difference is that without the "static", there's undefined
>>> behavior only if the code for func(p) tries to access x[i] for values of
>>> i such that p[i] would have undefined behavior.  With "static 100", it's
>>> also undefined behavior to call the function with a pointer to less than
>>> 100 consecutive accessible 'int' objects, regardless of what func()
>>> actually does with x.
>>
>> That's what I thought was the case, but then Tim confused me by saying
>> that without the "static" there is still undefined behaviour if you
>> call the function with a pointer to less than 100 ints, even if the
>> function does not attempt to access them.  [snip]
> 
> I need to give a mea culpa here.  I overlooked that the only
> declaration of g() lacked the static attribute.  I have a partial
> explanation for why that may have happened, but it was a mistake
> on my part.  My apologies to James, to David, and also anyone
> else who may have been mislead or confused.  Also I hope someone
> will arrange for James to get a copy of my apology.
> 
> Now here is the original context:
> 
> [taken from a posting by David Brown]
> 
>> On 30/08/15 18:18, James Kuyper wrote:
>>> On 08/30/2015 10:56 AM, David Brown wrote:
>>>> On 29/08/15 23:08, James Kuyper wrote:
>>>>
>>>>> The following use of "static" is new in C99, and can only occur in the
>>>>> leading dimension of a function parameter declared as an array:
>>>>> "If the keyword static also appears within the [ and ] of the array type
>>>>> derivation, then for each call to the function, the value of the
>>>>> corresponding actual argument shall provide access to the first element
>>>>> of an array with at least as many elements as specified by the size
>>>>> expression."  6.7.6.3p7
>>>>>
>>>>> This obviously should have no counterpart in K&R C.
>>>>
>>>> This last use of "static" is completely new to me.  I can see the
>>>> corresponding paragraph in the C11 standards (since that's the one I
>>>> have handy), but I can't figure out what it means or what it is for.
>>>
>>> Given:
>>>
>>>      void f(int array[static 3]);
>>>      int large_array[6];
>>>      int small_array[2];
>>>      int *p = small_array;
>>>
>>> then f(large_array) is fine, because large_array has more than 3
>>> elements.  However, f(small_array) violates a "shall" that occurs outside
>>> of a constraint, because small_array has fewer than 3 elements.  The
>>> behavior is therefore undefined.  I would have preferred that this be a
>>> constraint violation, and I would expect any decent implementation of
>>> C99 or later to issue the diagnostic message that would be mandatory if
>>> it were a constraint violation - in my opinion, that possibility is the
>>> only thing that makes this feature worthwhile.  I think that the reason
>>> why it cannot be made a constraint violation is that f(p) is also a
>>> violation of the same rule, and unlike f(small_array), it's not in
>>> general easy for a compiler to identify the fact that an arbitrary
>>> pointer points at location which violates this rule.
>>
>> But surely if g were defined:
>>
>>     void g(int array[3]);
>>
>> Then g(small_array) would still be a constraint violation?  Or is it
>> defined behaviour to call g(small_array), and only becomes undefined
>> if g() accesses array[2] ?
>>
>> It seems to me that even without the "static", g is asking for a
>> parameter with particular characteristics, and calling g(small_array)
>> is breaking that requirement.
> 
> Since the discussion was about the static attribute, I assumed
> that the parameter of g() was marked in this way, despite (or
> overlooking) the given declaration.  This impression was further
> led astray by the paragraph that starts "It seems to me that even
> without the "static", g is asking for ...", which sounds like it
> is offering a contrast to the previous paragraph, ie, that g()
> /did/ have static for that question.  To be clear on the point,
> if all the declarations for g() don't have 'static' as part of
> the first parameter declaration, then g(small_array) is indeed
> defined behavior, and the behavior is undefined only if accesses
> are made outside the actual bounds of the array argument (eg,
> array[2]).
> 
> Also, I think it's important to add another remark.  This isn't
> meant to excuse my earlier oversight, but I think it's important
> to note here.  If g() is declared as above, and various files
> are compiled using that declaration, but where g() is defined
> in another translation unit, it is defined like so:
> 
>     void
>     g( int array[static 3] ){
>         ...
>     }
> 
> then calling g(small_array) /is/ undefined behavior, even though
> the "static-ness" of that parameter is not visible at those call
> sites.  In fact it goes farther than that.  As I read the
> Standard, if /any/ declaration of g() gives a 'static' attribute,
> it's the same as if they all did.  Note that this is different
> than how, eg, 'restrict' or 'const', behaves:  with qualifiers,
> the governing occurrence is the function definition, and nothing
> else counts.  But how 'static' works is described slightly
> differently, and appears to apply no matter which declaration it
> occurs in.  (I admit this question is not addressed as clearly as
> I would like, ie, I think reasonable arguments could be made with
> different conclusions.  IMO the interpretation I have given is
> the most natural one, but in the interest of fairness I have to
> add that other interpretations are plausibly defensible.)  So the
> phrasing of questions related to array "static-ness" is more
> delicate than it is for qualifiers like 'restrict' or 'const.
> 

(I'm quoting everything here without snipping, to make sure everyone
sees it.)

Thanks for clearing that up, Tim.  I've missed enough small details in
posts about the "letter of the law" in C standards to know how easy it
is.  I'm grateful that you took the time to sort out the confusion and
explain it all.


Mismatches between function declarations and function definitions should
not occur in my code - I am very strict about how this is done, and use
compiler warnings to enforce my rules as tightly as possible.  But it is
useful to know of such possibilities, especially as C accepts small but
significant variations in the function declarations as being compatible
(a poor design decision, IMHO, but one we have to live with).

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

#69943

James: See the parent article.

Tim Rentsch <txr@alumni.caltech.edu> writes:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 07/09/15 19:04, James Kuyper wrote:
>>> On 09/07/2015 06:22 AM, David Brown wrote:
>>> ...
>>>> However, as far as I can see, "void func(int x[static 100])" means
>>>> almost exactly the same to the compiler as "void func(int x[100])".  The
>>>> compiler is quite happy to view the declaration with the "static" as
>>>> being entirely compatible with those you listed without the "static",
>>>> and it is quite happy to have multiple declarations of the same function
>>>> with different static sizes of the array.
>>>
>>> The key difference is that without the "static", there's undefined
>>> behavior only if the code for func(p) tries to access x[i] for values of
>>> i such that p[i] would have undefined behavior.  With "static 100", it's
>>> also undefined behavior to call the function with a pointer to less than
>>> 100 consecutive accessible 'int' objects, regardless of what func()
>>> actually does with x.
>>
>> That's what I thought was the case, but then Tim confused me by saying
>> that without the "static" there is still undefined behaviour if you
>> call the function with a pointer to less than 100 ints, even if the
>> function does not attempt to access them.  [snip]
>
> I need to give a mea culpa here.  I overlooked that the only
> declaration of g() lacked the static attribute.  I have a partial
> explanation for why that may have happened, but it was a mistake
> on my part.  My apologies to James, to David, and also anyone
> else who may have been mislead or confused.  Also I hope someone
> will arrange for James to get a copy of my apology.

[...]

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

#69945

On 09/08/2015 01:18 PM, Keith Thompson wrote:
> James: See the parent article.
> 
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 07/09/15 19:04, James Kuyper wrote:
>>>> On 09/07/2015 06:22 AM, David Brown wrote:
>>>> ...
>>>>> However, as far as I can see, "void func(int x[static 100])" means
>>>>> almost exactly the same to the compiler as "void func(int x[100])".  The
>>>>> compiler is quite happy to view the declaration with the "static" as
>>>>> being entirely compatible with those you listed without the "static",
>>>>> and it is quite happy to have multiple declarations of the same function
>>>>> with different static sizes of the array.
>>>>
>>>> The key difference is that without the "static", there's undefined
>>>> behavior only if the code for func(p) tries to access x[i] for values of
>>>> i such that p[i] would have undefined behavior.  With "static 100", it's
>>>> also undefined behavior to call the function with a pointer to less than
>>>> 100 consecutive accessible 'int' objects, regardless of what func()
>>>> actually does with x.
>>>
>>> That's what I thought was the case, but then Tim confused me by saying
>>> that without the "static" there is still undefined behaviour if you
>>> call the function with a pointer to less than 100 ints, even if the
>>> function does not attempt to access them.  [snip]
>>
>> I need to give a mea culpa here.  I overlooked that the only
>> declaration of g() lacked the static attribute.  I have a partial
>> explanation for why that may have happened, but it was a mistake
>> on my part.  My apologies to James, to David, and also anyone
>> else who may have been mislead or confused.  Also I hope someone
>> will arrange for James to get a copy of my apology.

Received, and accepted. I make that same kind of mistake all the time.
-- 
James Kuyper

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

#68660

W dniu sobota, 29 sierpnia 2015 22:53:27 UTC+2 użytkownik David Kleinecke napisał:
> On Saturday, August 29, 2015 at 1:46:40 PM UTC-7, fir wrote:
> > W dniu sobota, 29 sierpnia 2015 22:37:02 UTC+2 użytkownik David Kleinecke napisał:
> > > On Saturday, August 29, 2015 at 11:41:03 AM UTC-7, fir wrote:
> > > > i know it may be hard to answer but as
> > > > i vaguelly know (maybe wrong), static sields (i mean like static ints or arrays in functions) are absent in previous version of the language I mean b  by thompson (69/70) and c by ritchie (72/73)..it was added later* - if so WHO invented it? has it some derivative from previous language or something?
> > > > 
> > > > * which year it was added?
> > > 
> > > There are four entries in the index of my copy of K&R 1974 for "static"
> > > this or that.
> > 
> > but for what static - old static means that function is internal to module/(compilation unit)
> > 
> > im not sure but probably the other static was not yet ready present in 74
> 

> static storeage class 28, 80, 191

then i would have to be sure that this "static storage class" dont just mean  'module level variables that are of internal visibility' but the second meaning... becouse both might be maybe understood storage class

does it for sure mean this function level non-stack storage there?
could you look up to this pages maybe
to see?

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

#68803

W dniu sobota, 29 sierpnia 2015 23:18:59 UTC+2 użytkownik fir napisał:
> could you look up to this pages maybe
> to see?

to be honest both those parts of answers are unclear

1) in this algol (65? date here needed) this static is same static i mean here (like global living time but function body scope only)

2) in this c-73 is this static i mean present for SURE? (quotations form index with word ststic doeas say to much as 
static is duplicated meaning in c)

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

#68657

David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> There are four entries in the index of my copy of K&R 1974 for "static"
> this or that.

K&R1 was published in 1978.  But "static" does appear with its current
meaning in the 1974 and 1975 versions of the C Reference Manual.

It doesn't appear in B.

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

#68662

In article <661ee2d4-d23e-4602-a48b-86c669001de6@googlegroups.com>,
 fir <profesor.fir@gmail.com> wrote:

> i know it may be hard to answer but as
> i vaguelly know (maybe wrong), static sields (i mean like static ints or 
> arrays in functions) are absent in previous version of the language I mean b  
> by thompson (69/70) and c by ritchie (72/73)..it was added later* - if so WHO 
> invented it? has it some derivative from previous language or something?
> 
> * which year it was added?

1960 and they were called 'own'. And they were in Algol.

Fortran had static allocation earlier, but it only had static allocation. Algol 
was the first to allow static and local allocation and recursion.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
'I desire mercy, not sacrifice.'
When is a Kenyan not a Kenyan? When he's a Canadian.
That's People's Commissioner Siri Cruz now. Punch!

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

#68666

Siri Cruz <chine.bleu@yahoo.com> wrote:
> In article <661ee2d4-d23e-4602-a48b-86c669001de6@googlegroups.com>,
> fir <profesor.fir@gmail.com> wrote:
 
>> i know it may be hard to answer but as
>> i vaguelly know (maybe wrong), static sields (i mean like static ints or 
>> arrays in functions) are absent in previous version of the language 
>> I mean b  
(snip)

> 1960 and they were called 'own'. And they were in Algol.

PL/I has the STATIC keyword, along with AUTOMATIC and CONTROLLED,
from about 1964.  For STATIC and CONTROLLED, there are the INTERNAL
and EXTERNAL attributes. 

The early Fortran compilers only did static allocation. 
The Fortran 66 standard pretty much ignores the question, but seems
to allow automatic except for initialized (DATA statement) variables.

Fortran 77 added the SAVE attribute to request static allocation,
and initialized variables automatically get SAVE. Fortran COMMON
is pretty much equivalent to a C struct at file scope, though
maybe only with one function per file.

Fortran 95 added recursion (but you have to ask for it), which
pretty much requires automatic allocation for local variables
that don't have SAVE. Otherwise, they go either way.

> Fortran had static allocation earlier, but it only had static 
> allocation. Algol was the first to allow static and local 
> allocation and recursion.

-- glen

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

#68804

W dniu sobota, 29 sierpnia 2015 23:32:37 UTC+2 użytkownik Siri Cruz napisał:
> In article <661ee2d4-d23e-4602-a48b-86c669001de6@googlegroups.com>,
>  fir <profesor.fir@gmail.com> wrote:
> 
> > i know it may be hard to answer but as
> > i vaguelly know (maybe wrong), static sields (i mean like static ints or 
> > arrays in functions) are absent in previous version of the language I mean b  
> > by thompson (69/70) and c by ritchie (72/73)..it was added later* - if so WHO 
> > invented it? has it some derivative from previous language or something?
> > 
> > * which year it was added?
> 
> 1960 and they were called 'own'. And they were in Algol.
> 
> Fortran had static allocation earlier, but it only had static allocation. Algol 
> was the first to allow static and local allocation and recursion.
> 
> -- 
> :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
> 'I desire mercy, not sacrifice.'
> When is a Kenyan not a Kenyan? When he's a Canadian.
> That's People's Commissioner Siri Cruz now. Punch!

what do you mean 'static allocation'?
global like?

I mean two things
1) global like physical (non volatile) global ram storage
2) function limited scope of visibility

do fortran/algol have it in sixties?

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

#68954

On Tue, 1 Sep 2015 01:52:10 -0700 (PDT), fir <profesor.fir@gmail.com>
wrote:

>W dniu sobota, 29 sierpnia 2015 23:32:37 UTC+2 u?ytkownik Siri Cruz napisa?:
>> In article <661ee2d4-d23e-4602-a48b-86c669001de6@googlegroups.com>,
>>  fir <profesor.fir@gmail.com> wrote:
>> 
>> > i know it may be hard to answer but as
>> > i vaguelly know (maybe wrong), static sields (i mean like static ints or 
>> > arrays in functions) are absent in previous version of the language I mean b  
>> > by thompson (69/70) and c by ritchie (72/73)..it was added later* - if so WHO 
>> > invented it? has it some derivative from previous language or something?
>> > 
>> > * which year it was added?
>> 
>> 1960 and they were called 'own'. And they were in Algol.
>> 
>> Fortran had static allocation earlier, but it only had static allocation. Algol 
>> was the first to allow static and local allocation and recursion.
>> 
>> -- 
>> :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
>> 'I desire mercy, not sacrifice.'
>> When is a Kenyan not a Kenyan? When he's a Canadian.
>> That's People's Commissioner Siri Cruz now. Punch!
>
>what do you mean 'static allocation'?
>global like?
>
>I mean two things
>1) global like physical (non volatile) global ram storage
>2) function limited scope of visibility
>
>do fortran/algol have it in sixties?


Algol-60 allowed variables in a block to be declared "own", which
produced roughly the same result as static.  For example:

  own integer a

In PL/I, also from the 60s, we have STATIC INTERNAL and STATIC
EXTERNAL, which define persistent items, but different visibility
(within the block for the former, global for the later, although it
was a bit more like Fortran COMMON in that case).

In both cases the external visibility of procedures/functions was a
bit more convoluted, as the programming model was more a single large
source file than many smaller ones.  in PL/I you had to explicitly
declare a function INTERNAL or EXTERNAL, and then the importing module
needed a DECLARE ENTRY, but the default was never external visibility.
Similar, but not standardized approaches were implemented by numerous
Algol-60 compilers, I think that was standardized in Algol-68, but I'm
not certain.

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

#68958

W dniu środa, 2 września 2015 06:41:59 UTC+2 użytkownik robert...@yahoo.com napisał:
> On Tue, 1 Sep 2015 01:52:10 -0700 (PDT), fir <profesor.fir@gmail.com>
> wrote:
> 
> >W dniu sobota, 29 sierpnia 2015 23:32:37 UTC+2 u?ytkownik Siri Cruz napisa?:
> >> In article <661ee2d4-d23e-4602-a48b-86c669001de6@googlegroups.com>,
> >>  fir <profesor.fir@gmail.com> wrote:
> >> 
> >> > i know it may be hard to answer but as
> >> > i vaguelly know (maybe wrong), static sields (i mean like static ints or 
> >> > arrays in functions) are absent in previous version of the language I mean b  
> >> > by thompson (69/70) and c by ritchie (72/73)..it was added later* - if so WHO 
> >> > invented it? has it some derivative from previous language or something?
> >> > 
> >> > * which year it was added?
> >> 
> >> 1960 and they were called 'own'. And they were in Algol.
> >> 
> >> Fortran had static allocation earlier, but it only had static allocation. Algol 
> >> was the first to allow static and local allocation and recursion.
> >> 
> >> -- 
> >> :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
> >> 'I desire mercy, not sacrifice.'
> >> When is a Kenyan not a Kenyan? When he's a Canadian.
> >> That's People's Commissioner Siri Cruz now. Punch!
> >
> >what do you mean 'static allocation'?
> >global like?
> >
> >I mean two things
> >1) global like physical (non volatile) global ram storage
> >2) function limited scope of visibility
> >
> >do fortran/algol have it in sixties?
> 
> 
> Algol-60 allowed variables in a block to be declared "own", which
> produced roughly the same result as static.  For example:
> 
>   own integer a
> 
> In PL/I, also from the 60s, we have STATIC INTERNAL and STATIC
> EXTERNAL, which define persistent items, but different visibility
> (within the block for the former, global for the later, although it
> was a bit more like Fortran COMMON in that case).
> 
> In both cases the external visibility of procedures/functions was a
> bit more convoluted, as the programming model was more a single large
> source file than many smaller ones.  in PL/I you had to explicitly
> declare a function INTERNAL or EXTERNAL, and then the importing module
> needed a DECLARE ENTRY, but the default was never external visibility.
> Similar, but not standardized approaches were implemented by numerous
> Algol-60 compilers, I think that was standardized in Algol-68, but I'm
> not certain.

what is block..
I said quite clearly that subjet of my asking is this 'other' static - the one
with wisibility of the function scope

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

#68960

On 02/09/2015 08:14, fir wrote:

<snip>

> I said quite clearly

:-)

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

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

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

csiph-web