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

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

Can a variable be both static and extern

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

Contents

  Can a variable be both static and extern acidlategamer@gmail.com - 2017-03-24 04:23 -0700
    Re: Can a variable be both static and extern Richard Heathfield <rjh@cpax.org.uk> - 2017-03-24 11:40 +0000
      Re: Can a variable be both static and extern acidlategamer@gmail.com - 2017-03-24 04:54 -0700
        Re: Can a variable be both static and extern Richard Heathfield <rjh@cpax.org.uk> - 2017-03-24 12:09 +0000
          Re: Can a variable be both static and extern James Kuyper <jameskuyper@verizon.net> - 2017-03-24 11:45 -0400
            Re: Can a variable be both static and extern raltbos@xs4all.nl (Richard Bos) - 2017-03-25 22:27 +0000
      Re: Can a variable be both static and extern Keith Thompson <kst-u@mib.org> - 2017-03-24 11:35 -0700
    Re: Can a variable be both static and extern Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-24 12:11 +0000
    Re: Can a variable be both static and extern raltbos@xs4all.nl (Richard Bos) - 2017-03-24 12:14 +0000
      Re: Can a variable be both static and extern David Brown <david.brown@hesbynett.no> - 2017-03-24 17:11 +0100
        Re: Can a variable be both static and extern scott@slp53.sl.home (Scott Lurndal) - 2017-03-24 16:22 +0000
          Re: Can a variable be both static and extern David Brown <david.brown@hesbynett.no> - 2017-03-24 17:38 +0100
        Re: Can a variable be both static and extern James Kuyper <jameskuyper@verizon.net> - 2017-03-24 12:23 -0400
          Re: Can a variable be both static and extern David Brown <david.brown@hesbynett.no> - 2017-03-24 17:41 +0100
            Re: Can a variable be both static and extern jameskuyper@verizon.net - 2017-03-24 09:57 -0700
            Re: Can a variable be both static and extern supercat@casperkitty.com - 2017-03-24 10:38 -0700
            Re: Can a variable be both static and extern Richard Heathfield <rjh@cpax.org.uk> - 2017-03-24 18:24 +0000
              Re: Can a variable be both static and extern "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-25 10:47 -0400
                Re: Can a variable be both static and extern Richard Heathfield <rjh@cpax.org.uk> - 2017-03-25 16:48 +0000
                  Re: Can a variable be both static and extern Keith Thompson <kst-u@mib.org> - 2017-03-25 10:31 -0700
                    Re: Can a variable be both static and extern Richard Heathfield <rjh@cpax.org.uk> - 2017-03-25 18:23 +0000
                      Re: Can a variable be both static and extern supercat@casperkitty.com - 2017-03-25 12:28 -0700
                        Re: Can a variable be both static and extern Ike Naar <ike@iceland.freeshell.org> - 2017-03-25 19:50 +0000
                          Re: Can a variable be both static and extern supercat@casperkitty.com - 2017-03-25 13:20 -0700
                  Re: Can a variable be both static and extern jameskuyper@verizon.net - 2017-03-25 10:44 -0700
                  Re: Can a variable be both static and extern supercat@casperkitty.com - 2017-03-25 12:13 -0700

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

#107051

On 25/03/17 17:31, Keith Thompson wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
> [...]
>> ISO/IEC 9899 is such an Authority. Even where it lies, it tells the
>> truth, and even where it is mistaken, it is correct until the
>> application of a DR, whereupon it effortlessly changes its mind and is
>> /still/ correct.
>
> And what if the Authority contradicts itself?

It's still right, but a DR will hopefully emerge and make it rather more 
sensibly right at some point in the near future.

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

#107054

On Saturday, March 25, 2017 at 1:24:03 PM UTC-5, Richard Heathfield wrote:
> It's still right, but a DR will hopefully emerge and make it rather more 
> sensibly right at some point in the near future.

Maybe, though a DR may instead muddy the water.

In C89, the effect of writing one member and reading another is Implementation
Defined.  This would apply not only in cases like:

     someUnion.m1 = something;
     return someUnion.m2;

but also in cases like:

     type2 someFunction(type1 *p1, type2 *p2, type1 v)
     {
       *p1 = v;
       return *p1;
     }
     ... and then in some other function

     return someFunction(&someUnion.m1, &someUnion.m2);

An implementation would be free to specify e.g. that reading a member after
writing another will perform a bitwise interpretation when any lvalue
evaluation involving the union appeared between the write and the read
an arbitrary value when they don't, but have no side-effects in any case,
or it could specify that such actions may trap in a particular fashion.
The Standard doesn't require any particular behavior but does mandate that
any behavior be *documented*.  If an implementation specifies behavior in the
former case and doesn't say that it might vary in the latter, the former
definition would hold.

A defect report examining the latter scenario decided that since the Standard
didn't impose any particular behavioral requirement, the latter should be
considered Undefined Behavior.  I don't see how the authors of the Standard
morphed IDB into UB, and I don't know how many members reviewed that DR, but
such transformation seems to be the basis of C99's Effective Type rule.

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

#107059

On 2017-03-25, supercat@casperkitty.com <supercat@casperkitty.com> wrote:
>      type2 someFunction(type1 *p1, type2 *p2, type1 v)
>      {
>        *p1 = v;
>        return *p1;
>      }

It looks like what you wrote is not what you intended to write.
What is the purpose of the unused parameter p2?

>      ... and then in some other function
>
>      return someFunction(&someUnion.m1, &someUnion.m2);

Here a function that has three parameters is called with only two arguments.
Something must have gone wrong. Can you post an improved version?

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

#107066

On Saturday, March 25, 2017 at 2:54:03 PM UTC-5, Ike Naar wrote:
> On 2017-03-25, supercat wrote:
> >      type2 someFunction(type1 *p1, type2 *p2, type1 v)
> >      {
> >        *p1 = v;
> >        return *p1;
> >      }
> 
> It looks like what you wrote is not what you intended to write.
> What is the purpose of the unused parameter p2?

Mea culpa.  I meant "return *p2;".  Write the first union member using a
pointer of its type, and then read the second union member using a pointer
of its type.

> >      ... and then in some other function
> >
> >      return someFunction(&someUnion.m1, &someUnion.m2);
> 
> Here a function that has three parameters is called with only two arguments.
> Something must have gone wrong. Can you post an improved version?

Oops.  

     return someFunction(&someUnion.m1, &someUnion.m2, something);

Nothing I can see in any of the C Standards makes any distinction between:

    u.member1 = something;
and
    type1 *p1 = &u.member1;
    *p1 = something;

nor between

    return u.member2;
and
    type2 *p2 = &u.member2;
    return *p2;

nor between

    type1 *p1; type2 *p2;
    p1 = &u.member1;
    *p1 = something;
    p2 = &u.member2;
    return *p2;
and
    type1 *p1; type2 *p2;
    p1 = &u.member1;
    p2 = &u.member2;
    *p1 = something;
    return *p2;

Implementations under C89 had the freedom to define the behavior of
writing one member and reading another as being dependent upon the
circumstances of access, but nothing in the Standard itself does so
anywhere that I can see.  The very *meaning* of the unary-& operator is
that it yields a pointer which, when unary * is applied, will yield the
lvalue to which unary & was applied, and nothing in the Standard says
that union members are different from any other lvalue in that regard.

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

#107048

On Saturday, March 25, 2017 at 12:48:39 PM UTC-4, Richard Heathfield wrote:
> On 25/03/17 14:47, James R. Kuyper wrote:
...
> > When the question is "What does Authority X say about statement q?",
> > then there is absolutely no evidence more relevant than the actual words
> > that came from X. Other evidence can be relevant: evidence that the
> > words were incorrectly recorded, or even faked, evidence indicating that
> > X was lying (as a document, rather than a person, the C standard can't
> > lie; but the C committee could), evidence about X's cultural background
> > which might change the meaning conveyed by X's words, etc., but the
> > actual words of X are always the primary source. And that is why the
> > Standard itself is the single most relevant source of information about
> > what the Standard says, with the C committee being the place to go if
> > there's any ambiguity about the meaning of those words.
> 
> Right so far...
> 
> > However, if the question is "Is statement q true?", arguments citing X's
> > belief that q is true are, at best, useful supporting arguments, no
> > matter how appropriate X is as an authority.
...
> C may be considered to be a formal system, and ISO/IEC 9899 constitutes 
> the definition of that system. Any question about C is therefore an 
> enquiry about the consequences of applying "the rules" (i.e. ISO/IEC 
> 9899) to a particular language construct.

That falls under the category I described before, questions about "What X says about statement q.". It doesn't matter whether it's stated directly or a conclusion validly derived from other things it does state directly (except, of course, that the validity of the derivation itself might need to be defended, and the standard itself won't help with that argument).

As the standard is a written document, it is capable of saying things (in writing, not speech), but it is incapable of holding beliefs, Therefore nothing I said about "what X believes" applies to the standard as X. It could apply to the Committee as X - but unless the statement q is outside the domain of the standard, citations of the standard are more relevant than committee opinions about the meaning of the standard (unless and until the committee makes those opinions official - in which case those official decisions should be considered as supplementing the standard). And for topics outside the domain of the standard, the Committee's beliefs are covered by everything I said about "what X believes".

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

#107053

On Saturday, March 25, 2017 at 11:48:39 AM UTC-5, Richard Heathfield wrote:
> C may be considered to be a formal system, and ISO/IEC 9899 constitutes 
> the definition of that system. Any question about C is therefore an 
> enquiry about the consequences of applying "the rules" (i.e. ISO/IEC 
> 9899) to a particular language construct.

In the years prior to the publication of C89, the name "C" was applied to a
number of language dialects which had a variety of features in common.  Such
dialects were sufficiently varied that it would have been impractical to
completely formally specify a single language which could handle all of the
things which "C" programs were called upon to do.

There have always been aspects of the Standard which were far too hand-wavy
to really constitute a "formal system".  Nothing would forbid a version of
printf which would require 2.5 gigs of stack space for every "o" in the
format string, even if that would make

    #include <stdio.h>
    int main(void)
    {
      printf("Hello world!");
      return 0;
    }

die with a stack overflow.  The Standard defines no means of identifying a
class of implementations upon which any particular program can be guaranteed
to run in defined fashion, save only for the possibly-empty set of
implementations for which a program happens to be the "One Program" that
an implementation is required to run in defined fashion.  Doing anything
useful thus requires going beyond the reals of a formal system.

I don't see any particular reason things couldn't be better defined.  It
would obviously be impractical to require that all implementations be capable
of behaving in defined fashion when power is removed or they're hit with an
atomic bomb, but it should be practical to define a class of implementations
which document environmental conditions sufficient to guarantee defined
behavior when given correct programs.  It should also be possible to define
a class of programs which would be guaranteed to yield defined behavior
when run on any such implementation whose environmental conditions were met.

Even things like stack overflow could be handled by saying that a safely-
conforming implementation must either statically verify stack usage and
refuse to run programs for which usage cannot be verified (a program could
include directives specifying the maximum depth of recursion for functions
where a compiler couldn't otherwise determine it) or else ensure a
controlled abnormal program termination in case of stack overflow.

While some implementations might be useful for various purposes without being
able to formally specify cases where behavior was guaranteed, I don't think
a formal specification would really be applicable to such implementations.
On the other hand, the C Standard in its present form doesn't really require
much of anything in the way of actual behavioral guarantees, and so doesn't
really qualify as a formal specification in many useful scenarios.

[toc] | [prev] | [standalone]

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

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

csiph-web