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

Groups > comp.lang.c > #70412

Re: who invented static?

Show all headers | View raw

On 12/09/15 21:30, Tim Rentsch wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> 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:
>>>>> 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.
>>>
>>> It's pretty disappointing that you haven't gotten better replies
>>> to your query on this.  The replies I've seen aren't very helpful
>>> and get several things wrong.  Let's see if we can do a little
>>> better here.
>>
>> I'm ready to take notes.
>
> I'm following up here after posting my downstream response
> correcting the mistake I made.  I am not repeating that but there
> are some other comments that may be useful.
>
>>> First, the point of using 'static' in this way is to allow some
>>> optimizations to take place that wouldn't be allowed otherwise.
>>> If we have a function definition like this
>>>
>>>      void
>>>      foo( int x[ static 100 ] ){
>>>          ...
>>>      }
>>>
>>> then when compiling foo() the compiler is allowed to assume
>>> that the pointer 'x' (which is a pointer, because of rules
>>> about function parameter types) points to an array with at
>>> least 100 elements.  That proviso enables the code to, eg,
>>> initiate some prefetching if that seems like a good thing to
>>> do.
>>
>> I assume that as well as optimising here, the compiler can also
>> use the information for extra checking.  (However I am a little
>> disappointed that a quick test with gcc 4.9 does not seem to give
>> any warnings when this foo is called with an array of less than
>> 100.)
>
> There are two problems with the idea that using the 'static'
> attribute this way is (even partly) for compile-time error
> reporting.  One, because the 'static' can be there on a
> definition but not on a declaration, there is no guarantee that
> the call site knows to do the check.

Agreed.  I think this is a major flaw in the way this static attribute 
was introduced, and means it loses much of its potential benefits.  But 
compilers (and programmers) have to live with what the standards say.

Still, a compiler could warn (when the appropriate flag enabled it) for 
cases that it /could/ see - and also for inconsistencies between the 
definition and declaration(s).

>  Two, like most conditions
> that depend on run-time values, what we're interested in cannot
> be checked in the general case.

Also agreed.  But being unable to warn in the general case does not mean 
a compiler cannot warn in specific cases when information is available.

For a normal array, compilers cannot in general see if you are accessing 
them outside their bounds - but compilers /can/ (and recent versions of 
gcc do) warn if it can see that code definitely accesses them outside 
there bounds.

So being unable to identify problems in the general case is not an 
excuse for not warning about bad uses of "static" function parameters.

(On the other hand, lack of time, money, volunteers, etc., is of course 
a perfectly good excuse for it - especially for a relatively little-used 
feature.)

>  In all such cases (AFAIAA), the
> C standard relegates these to undefined behavior, leaving the
> question of any compile-time diagnostics as a QOI matter, not
> part of the official language definition.  IMO this choice is
> the right decision for C (and I prefer not to consider the
> question more generally, at least as far as comp.lang.c goes).

Also agreed, at least partly.  I think it would not be unreasonable to 
require a diagnostic in some cases where the behaviour is clearly 
undefined, but I can understand why the C standards are reluctant to do so.

>
>>> Second, using 'static' in this way resembles how 'restrict' works
>>> with pointer parameters.  The 'static'-ness of the array is not
>>> part of the type of the function, and it doesn't have to be the
>>> same in declarations as it is in the definition.  Normally any
>>> functions defined with this use of 'static' will also have
>>> 'static' in their declarations, but doing that is really just for
>>> documentation, not anything else.
>>
>> I am a big fan of such documentation - and I am very strict about
>> declarations and definitions matching exactly (stricter than the
>> compiler requires).
>
> I agree everything should be in sync.  My preference, when
> possible, is to auto-generate the appropriate declarations based
> on the corresponding definitions.  If you can get other people
> to buy into that, I find it enormously effective in terms of
> both productivity and confidence in the result.

I always insist that any functions (or variables) exported in a module 
are declared with an "extern" in a matching header, that the module 
imports its own header, and that any non-exported functions (or 
variables) are declared "static".  gcc warnings can enforce that, at 
least to the level of making sure that the declarations and definitions 
are compatible.  I'm not so keen on automatically generating the 
declarations, but I guess that works too.

>
>>> Third, what happens with such 'static' parameters when compiling
>>> calls to the function is analogous to compiling calls to
>>> functions whose parameters have 'restrict' qualifiers.  It
>>> doesn't imply any extra checking or constraint validation.  (Of
>>> course implementations are free to do extra checking if they
>>> want, but none is required.)  What using 'static' does is
>>> impose an additional /un/checked requirement that any actual
>>> argument have at least that many elements;  not meeting that
>>> requirement makes the call be undefined behavior.
>>
>> Fair enough.
>>
>> It is nice if the compiler (or possibly other static error
>> checkers) can check it.
>
> Any diagnostic of this sort (ie, which is undecidable in the
> general case) comes with problems - false positives, false
> negatives, or possibly both.  Also, something that may not
> have occured to you, the array bound after the 'static' might
> not be a constant.  C99 has variable length arrays, which
> means that this
>
>      int
>      foo( int n, int v[ static n ] ){
>          ...
>      }
>
> is legal.  Cases like this are much harder to check.

I had noticed that too, and agree that these are even harder to check.

>
> I sympathize with your desire to have diagnostics produced, where
> possible.  But this is a QOI concern, not a language concern, and
> ANSI/ISO made a deliberate choice to not address QOI matters in
> the C standard.  Because of that, it doesn't surprise me, or
> disappoint me, that the possibility of doing such a check for
> 'static' parameters was ignored in defining the C language.

I think the C standards could have been stricter in their definition of 
static parameters, and therefore allow better diagnostics - without 
necessary requiring them.

I suppose compiler developers can make warnings that enforce stronger 
rules on static parameters than the standards - there is nothing to stop 
a compiler warning if there are multiple declarations that don't match 
the definition with regard to the size of the static parameters (as long 
as it accepts legal, but silly and inconsistent code by default).

>
>>> Incidentally, note that the length parameter is also not part of
>>> the parameter type, and hence may be different between a function
>>> declaration and its definition.  Thus we might have
>>>
>>>      int foo( int x[ static 200 ] );
>>>
>>>      ...
>>>
>>>      int
>>>      foo( int x[ static 100 ] ){
>>>          ...
>>>      }
>>>
>>> which the Standard allows.  What I believe is true in such
>>> cases is that both conditions must be met, ie, the larger
>>> value is the one that the compiler may assume.  However
>>> the Standard is not completely clear on the matter, so for
>>> safety the different values should all agree (and probably
>>> expect the value on the function /definition/ to take
>>> precedence, although again the Standard isn't completely
>>> clear on the matter).
>>
>> All in all, it sounds like a nice idea, but a little disappointing
>> in practice.  I would have preferred the standards (and compiler)
>> to be a lot stricter in checking such things.
>
> I explained above why the Standard doesn't address it.  As for
> compilers, of course they could, but I expect there isn't much
> call to do so, especially since there is no guarantee that the
> declarations used match the definitions.
>
>> I can understand
>> that for backward compatibility, and the way arrays are handled
>> and passed in C, that it is hard for the compiler to enforce or
>> assume anything about array parameters that are not declared with
>> this "static".  But I had hoped that it could do more with the
>> added "static".
>
> The problem is undecidable.  Anything that might be done is
> a compromise that some people will be happy with and others
> will not.  Unless the user community cries out for something
> I don't think anything will be done, especially since the
> problem is not just undecidable but difficult to do even
> fairly well.  I believe the perception is that the ROI is
> just not very high.
>
>> As far as I can tell, the explicit undefined behaviour gives the
>> compiler a freer hand for optimisation, and that's about it.
>
> Yes, that is it, exactly it!
>
>> (Compilers /could/ implement a little more static error checking,
>> but extrapolating wildly from my sample of 1 test, they apparently
>> don't do so.  Perhaps it's simply because this use of "static" is
>> not common, so it is not a feature that the gcc folk have
>> implemented.)
>
> And that it is hard to do well.
>
>> As for documentation - and therefore "manual" enforcement, I don't
>> see that the use of "static" adds anything, at least for my own
>> code.  If I declare a function to have a parameter "int x[100]",
>> then it is clear to me that this function wants an array of at
>> least 100 int's.  The "static" is superfluous from the
>> documentation viewpoint.
>
> I think you might want to re-think this position.  By way of
> analogy, there's a difference between saying "I'm not going
> to drive faster than 35 miles per hour" and saying "I'm not
> going to drive faster than 35 miles per hour, and if I do
> I agree to pay you as much money as you ask for."  Without
> the 'static', there may be some cases, eg based on the values
> of other parameters, that are still okay.  With the 'static',
> any transgression is irredeemable.  You may choose not to
> make these kinds of distinctions, but other people might,
> and IMO it is worth keeping that in mind.

It is certainly worth knowing that "static" can be used in this way. 
But I am not convinced that it is useful in code.  Because there is no 
enforced consistency in it, and the optimisation possibilities it gives 
are minimal, all it means is that if a function is declared with a 
static array of size 100 then calling that function with a smaller array 
is undefined behaviour even if the non-existent elements are never accessed.

I think a closer analogy would be that a non-static array parameter is 
like a speed limit sign of 35 miles per hour - you can drive any car you 
want on the road, but if you go about 35 miles an hour you will be 
fined, arrested, or other undefined behaviour.  Putting the "static" in 
the array parameter means that you will be fined or arrested if your car 
is capable of going over 35 miles per hour, even if you stick to the 
speed limit.  Now, that can have its uses - such as cycle tracks or 
pavements - but it's not what you want on a typical road.

(It is difficult to make such analogies accurate.  But the key point for 
/me/ is that it is good to know about this use of "static", even though 
I doubt if it will give any real benefit in my own code.)

>
>> [here was the part that I already addressed]
>>
>>>> Is this a use of "static" that you have seen in real code?  Is
>>>> it used much?
>>>
>>> Now that you know what it's for, especially with your general
>>> concerns for performance, I expect you will finds lots of
>>> occasions where it might be useful.
>>
>> I don't actually pass array parameters around that much, and
>> when I do they are often part of a struct anyway.
>
> This statement surprised me.  Do you mean you hardly ever
> pass pointer values as function parameters?  Or types
> like 'char *'?  Both of these cases have some potential
> benefit using 'static'.

I pass pointers around a good deal less than you might expect in more 
typical C code.  Most of my work is with small embedded systems, and the 
type of code is quite different from what one might find on a PC.  For 
example, I almost never have any sort of dynamic memory in my code.  And 
for some of the cpus I use, any sort of pointer is quite inefficient - I 
would avoid them if possible.

But I don't quite see why static array parameters would be of benefit 
when I have a function using pointers.  For example, if I have the function:

	void displayMessage(int length, const char* msg);

I /could/ change it to:

	void displayMessage(int length, const char[static length]);

And it would work the same.  But I don't see any benefit here.  There is 
no benefit in documentation or clarity of code - the original function 
would be clear already based on its name, its parameter names, the 
context and surrounding comments.  So unless the compiler can give me 
additional help in spotting errors, it is of no advantage.


However, times change - my work involves a greater proportion of bigger 
cpus than it used to, and I am seeing more pointer usage.  It may be 
that I will also see more use of array parameters for which "static" 
could be appropriate.

>
>> And while
>> performance and optimisation opportunities are often a concern
>> (smaller and faster code can mean smaller and cheaper
>> microcontrollers, or lower power or less electrical noise), I
>> see it as unlikely that this "static" qualifier will actually
>> lead to faster code on the types of cpus and with the types of
>> code that I use.  Still, I am always on the lookout for new
>> tools in the toolbox, especially if it can (in theory at least)
>> lead to more precise specification and more static error
>> analysis.
>
> A pointer parameter declared like 'T x[ static 1 ]' is one that
> the compiler may assume is non-null, which may very well help
> code generation even on very low-end CPU's.  (Disclaimer:  I
> am certainly not an expect on optimization, but I see gcc do
> some amazing things based on such "facts", so it seems fair
> to say that the scenario is at least plausible.)
>

I can see that as a possibility.

On the other hand, I can use the gcc attribute "nonnull" on the function 
to tell it that the pointer may not be null.  And then the compiler not 
only will optimise using that information, it will also check it (where 
possible at compile-time) and issue diagnostics.  Additionally, I think 
the "nonnull" attribute expresses the intent a lot more directly and 
clearly than using a static array parameter.

But of course the nonnull attribute is gcc-specific (possibly supported 
by clang).

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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? Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-12 11:29 -0700
                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? Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-11 10:07 -0700
                Re: who invented static? Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-12 12:30 -0700
                Re: who invented static? David Brown <david.brown@hesbynett.no> - 2015-09-13 15:48 +0200
                Re: who invented static? supercat@casperkitty.com - 2015-09-29 09:04 -0700
                Re: who invented static? Keith Thompson <kst-u@mib.org> - 2015-09-29 09:18 -0700
                Re: who invented static? supercat@casperkitty.com - 2015-09-29 09:57 -0700
        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? raltbos@xs4all.nl (Richard Bos) - 2015-09-27 21:25 +0000
                Re: who invented static? Siri Cruz <chine.bleu@yahoo.com> - 2015-09-27 14:53 -0700
                Re: who invented static? Thomas Richter <thor@math.tu-berlin.de> - 2015-09-29 01:46 +0200
                Re: who invented static? raltbos@xs4all.nl (Richard Bos) - 2015-10-02 12:52 +0000
            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

csiph-web