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

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

Untyped Variables

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

Contents

  Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-07 18:19 -0700
    Re: Untyped Variables Lőrinczy Zsigmond <nospam@for.me> - 2015-08-08 06:53 +0200
    Re: Untyped Variables James Kuyper <jameskuyper@verizon.net> - 2015-08-08 11:09 -0400
      Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-08 12:09 -0700
        Re: Untyped Variables James Kuyper <jameskuyper@verizon.net> - 2015-08-08 14:24 -0400
      Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-08 12:54 -0700
        Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-08 16:06 -0700
          Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-08 17:29 -0700
            Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-09 17:52 -0700
              Re: Untyped Variables Ian Collins <ian-news@hotmail.com> - 2015-08-10 12:57 +1200
              Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-10 08:41 -0700
                Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-10 17:06 -0700
          Re: Untyped Variables Richard Damon <Richard@Damon-Family.org> - 2015-08-08 19:44 -0400
          Re: Untyped Variables James Kuyper <jameskuyper@verizon.net> - 2015-08-08 20:34 -0400
            Re: Untyped Variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-09 02:03 +0000
              Re: Untyped Variables Richard Damon <Richard@Damon-Family.org> - 2015-08-08 22:52 -0400
                Re: Untyped Variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-09 04:57 +0000
                  Re: Untyped Variables Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-08-09 09:58 -0600
                    Re: Untyped Variables Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-10 03:54 -0700
                  Re: Untyped Variables Richard Damon <Richard@Damon-Family.org> - 2015-08-09 16:59 -0400
            Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-09 18:02 -0700
              Re: Untyped Variables James Kuyper <jameskuyper@verizon.net> - 2015-08-10 11:01 -0400
                Re: Untyped Variables James Kuyper <jameskuyper@verizon.net> - 2015-08-10 13:20 -0400
                Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-10 16:54 -0700
                  Re: Untyped Variables James Kuyper <jameskuyper@verizon.net> - 2015-08-11 00:20 -0400
              Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-10 08:11 -0700
                Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-10 17:15 -0700
                  Re: Untyped Variables James Kuyper <jameskuyper@verizon.net> - 2015-08-11 00:30 -0400
                    Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-11 16:50 -0700
                      Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-11 17:24 -0700
                        Re: Untyped Variables Richard Heathfield <rjh@cpax.org.uk> - 2015-08-12 01:37 +0100
                        Re: Untyped Variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-12 04:46 +0000
                        Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-12 18:12 -0700
                          Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-13 12:08 -0700
                            Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-13 16:25 -0700
                              Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-14 10:36 -0700
                        Re: Untyped Variables Bartc <bc@freeuk.com> - 2015-08-14 19:13 +0100
                  Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-11 07:58 -0700
            Re: Untyped Variables richard@cogsci.ed.ac.uk (Richard Tobin) - 2015-08-10 13:53 +0000
              Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-10 08:29 -0700
                Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-10 17:01 -0700
                  Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-10 17:42 -0700
                    Re: Untyped Variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-11 02:56 +0000
              Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-10 16:50 -0700
                Re: Untyped Variables Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-11 01:39 +0100
                  Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-10 19:03 -0700
                    Re: Untyped Variables Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-11 11:21 +0100
                  Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-11 16:37 -0700

Page 1 of 3  [1] 2 3  Next page →

#66984 — Untyped Variables

In another newsgroup it was stated that C will accept the declaration
   a;
and create an integer variable.

As I read the standard (I used 1990) this is not possible in the syntax.
By 6.5 a declaration must start with "declaration specifiers" so a bare
"a;" is a syntax error. So far so good.

The reason I am bringing this up is that
   auto a;
   constant a;
      etc. 
are not syntactic errors. I feel sure the standard addresses these
structures (and outlaws them - as undefined perhaps) but I can't
find where it does. Perhaps someone will direct me to the
appropriate place in the standard.     

 

[toc] | [next] | [standalone]

#66988

> The reason I am bringing this up is that
>     auto a;
>     constant a;

They are legal because they do start with a declaration specifier.
That's why compilers allow them. What is the question again?

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

#67002

On 08/07/2015 09:19 PM, David Kleinecke wrote:
> In another newsgroup it was stated that C will accept the declaration
>    a;
> and create an integer variable.
> 
> As I read the standard (I used 1990) this is not possible in the syntax.
> By 6.5 a declaration must start with "declaration specifiers" so a bare
> "a;" is a syntax error. So far so good.
> 
> The reason I am bringing this up is that
>    auto a;
>    constant a;

I presume you mean 'const' rather than 'constant'?

>       etc. 
> are not syntactic errors. I feel sure the standard addresses these
> structures (and outlaws them - as undefined perhaps) but I can't
> find where it does. Perhaps someone will direct me to the
> appropriate place in the standard.

The feature that those declarations rely upon is "implicit int", and it
is a feature only of your preferred version of the C standard,
C89(==C90). I've never owned a copy of that version of the standard, so
I can't tell you precisely how this feature is defined, but I'll do the
best that I can, by comparing with the current version of the standard.

In C2011, the standard imposes the following constraint (6.7.2p2):
> At least one type specifier shall be given in the declaration specifiers in each declaration,
> and in the specifier-qualifier list in each struct declaration and type name. Each list of
> type specifiers shall be one of the following multisets (delimited by commas, when there
> is more than one multiset per item); the type specifiers may occur in any order, possibly
> intermixed with the other declaration specifiers.
> — void
> — char
> — signed char
> — unsigned char
> — short, signed short, short int, or signed short int
> — unsigned short, or unsigned short int
> — int, signed, or signed int
> — unsigned, or unsigned int
> — long, signed long, long int, or signed long int
> — unsigned long, or unsigned long int
> — long long, signed long long, long long int, or
> signed long long int
> — unsigned long long, or unsigned long long int
> — float
> — double
> — long double
> — _Bool
> — float _Complex
> — double _Complex
> — long double _Complex
> — atomic type specifier
> — struct or union specifier
> — enum specifier
> — typedef name


Note: 'long long', _Bool and _Complex were introduced in C99, and
support for _Complex is optional. "atomic types" other than sig_atomic_t
were not added until C2011, where it became urgent in combination with
C2011's support for multi-threaded programs.

If you examine that list, you'll find every one of those multisets that
applied in C90 and doesn't involve a user-defined identifier includes at
least one of the following five keywords: void, char, int, float,
double. My understanding of the implicit int feature is that, in C90,

a) There was no wording equivalent to the first sentence of 6.7.2p2.

b) Any declaration that doesn't include one of those five keywords was
implicitly treated as though it included 'int'. There is a residue of
this rule in more recent standards, in the fact that, for every
multi-set that contains both 'int' and at least one other
type-specifier, there is another multi-set with the same meaning that
differs only by the removal of 'int'.

c) Any use of a previously undeclared identifier was treated, if
possible, as if it were the name of a function with external linkage
returning 'int'. If arguments were given for the function, it was
treated as though the corresponding declaration had parameters of the
same type.

Thus
	auto a;
	const b;
	c;

Were equivalent to
	auto int a;
	const int b;
	int c();
	c;	// expression statement consisting of the name of a
 		// function, implicitly converted to a pointer to the
		// function type. Useless, but legal.

The implicit-int feature reflects the fact that C was developed from
earlier languages in which there was only one integer type. Since C very
quickly acquired a number of other types, this feature has been the
cause of innumerable errors, and is now considered to be a mistake. When
I first learned C in 1979, I was taught how to understand the
implicit-int rule, but I was also taught that it was a bad idea: I
should avoid writing code that relied upon it, and if I was in a
position to do so, I should correct existing code that relied upon it.
Despite the fact that awareness of the problem existed that far back, it
was not until C99 that implicit int was removed from the standard.

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

#67007

James Kuyper <jameskuyper@verizon.net> writes:
[...]
> c) Any use of a previously undeclared identifier was treated, if
> possible, as if it were the name of a function with external linkage
> returning 'int'. If arguments were given for the function, it was
> treated as though the corresponding declaration had parameters of the
> same type.
>
> Thus
> 	auto a;
> 	const b;
> 	c;
>
> Were equivalent to
> 	auto int a;
> 	const int b;
> 	int c();
> 	c;	// expression statement consisting of the name of a
>  		// function, implicitly converted to a pointer to the
> 		// function type. Useless, but legal.

No, the last one is an undeclared identifier error; the rule applies
only to function *calls*.

The C90 rule for function calls is/was:

    If the expression that precedes the parenthesized argument list in a
    function call consists solely of an identifier. and if no
    declaration is visible for this identifier, the identifier is
    implicitly declared exactly as if, in the innermost block containing
    the function call, the declaration
        extern int identifier () ;
    appeared.

So this:
    c();
creates an implicit function declaration:
    int c();

And if such a call has arguments, any arguments narrower than int or
double are promoted -- and if the resulting argument types are
inconsistent with the types in the actual function *definition*, the
behavior is undefined.

[...]

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

#67008

On 08/08/2015 03:09 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
> [...]
>> c) Any use of a previously undeclared identifier was treated, if
>> possible, as if it were the name of a function with external linkage
>> returning 'int'. If arguments were given for the function, it was
>> treated as though the corresponding declaration had parameters of the
>> same type.
>>
>> Thus
>> 	auto a;
>> 	const b;
>> 	c;
>>
>> Were equivalent to
>> 	auto int a;
>> 	const int b;
>> 	int c();
>> 	c;	// expression statement consisting of the name of a
>>  		// function, implicitly converted to a pointer to the
>> 		// function type. Useless, but legal.
> 
> No, the last one is an undeclared identifier error; the rule applies
> only to function *calls*.

Not have the exact text of the relevant rule, and having spent 35 years
avoiding making use of it, I anticipated that I'd get something wrong.
Thanks for the correction!

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

#67009

James Kuyper <jameskuyper@verizon.net> writes:
[...]
> The feature that those declarations rely upon is "implicit int", and it
> is a feature only of your preferred version of the C standard,
> C89(==C90). I've never owned a copy of that version of the standard, so
> I can't tell you precisely how this feature is defined, but I'll do the
> best that I can, by comparing with the current version of the standard.

http://flash-gordon.me.uk/ansi.c.txt

is a draft of the C89 standard (including the ANSI section numbering).

I own a PDF copy of the ISO C90 standard.  It doesn't have a PDF index,
and it appears to have been scanned and OCRed from a printed copy (which
makes both searching and copy-and-pasting difficult).

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

#67015

On Saturday, August 8, 2015 at 12:04:25 PM UTC-7, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
> [...]
> > The feature that those declarations rely upon is "implicit int", and it
> > is a feature only of your preferred version of the C standard,
> > C89(==C90). I've never owned a copy of that version of the standard, so
> > I can't tell you precisely how this feature is defined, but I'll do the
> > best that I can, by comparing with the current version of the standard.
> 
> http://flash-gordon.me.uk/ansi.c.txt
> 
> is a draft of the C89 standard (including the ANSI section numbering).
> 
> I own a PDF copy of the ISO C90 standard.  It doesn't have a PDF index,
> and it appears to have been scanned and OCRed from a printed copy (which
> makes both searching and copy-and-pasting difficult).
 
Thanks, guys, for the help. I must have wasted a whole half-hour looking 
in all the wrong places for something that I was sure existed before I
made the post.

The answer is in the list of possible types given as a constraint in 
6.5.2 which in the 1990 standard includes:
    int, signed, signed 1nt, or no type specifier.
I haven't been thinking of constraints as part of syntax. I like to keep
a clear separation between syntax and semantics so I imagine some
constraints are syntactic and some semantic. I need to do some research
because it is not obvious that there is no third possibility lying 
between syntax and semantics.

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

#67018

David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> The answer is in the list of possible types given as a constraint in 
> 6.5.2 which in the 1990 standard includes:
>     int, signed, signed 1nt, or no type specifier.
> I haven't been thinking of constraints as part of syntax. I like to keep
> a clear separation between syntax and semantics so I imagine some
> constraints are syntactic and some semantic. I need to do some research
> because it is not obvious that there is no third possibility lying 
> between syntax and semantics.

There are two kinds of rules whose violation requires a diagnostic,
syntax rules and contraints.  Syntax rules are expressed in the grammar
in something resembling BNF.  Constraints are expressed in English text
in sections labeled "Constraints".

A compiler may include a parser which accepts all those source files,
and only those source files, that do not violate any syntax rules,
paying no attention to constraints.  (Typedefs make parsing C
difficult, but we can ignore that for now.)  Constraints would then be
detected and diagnosed by the portions of the compiler that perform
semantic analysis.

If a compiler finds it more convenient to handle some constraints in the
parser, or to handle some syntax rules as part of semantic analysis, it
can do so a long as it produces any required diagnostics.  For example,
a C99 or C11 compiler might use a grammar that permits implicit int,
allowing it to diagnose errors more clearly.

(I'm also ignoring the #error directive.)

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

#67047

On Saturday, August 8, 2015 at 4:37:47 PM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> [...]
> > The answer is in the list of possible types given as a constraint in 
> > 6.5.2 which in the 1990 standard includes:
> >     int, signed, signed 1nt, or no type specifier.
> > I haven't been thinking of constraints as part of syntax. I like to keep
> > a clear separation between syntax and semantics so I imagine some
> > constraints are syntactic and some semantic. I need to do some research
> > because it is not obvious that there is no third possibility lying 
> > between syntax and semantics.
> 
> There are two kinds of rules whose violation requires a diagnostic,
> syntax rules and contraints.  Syntax rules are expressed in the grammar
> in something resembling BNF.  Constraints are expressed in English text
> in sections labeled "Constraints".
 
I would expect semantic rules to also issue diagnostic messages. But, at 
least in theory, we could make two passes - a syntax pass and a semantic 
pass because semantic failures do not impact on syntax (except, of course,
in the case of tydef names). 

So, roughly, I would group those constraints that cause a parsing failure
with syntax and the rest with semantics. But I am still unsure that any  
constraints are syntactic. 

> A compiler may include a parser which accepts all those source files,
> and only those source files, that do not violate any syntax rules,
> paying no attention to constraints.  (Typedefs make parsing C
> difficult, but we can ignore that for now.)  Constraints would then be
> detected and diagnosed by the portions of the compiler that perform
> semantic analysis.
> 
> If a compiler finds it more convenient to handle some constraints in the
> parser, or to handle some syntax rules as part of semantic analysis, it
> can do so a long as it produces any required diagnostics.  For example,
> a C99 or C11 compiler might use a grammar that permits implicit int,
> allowing it to diagnose errors more clearly.
 
So you're agreeing with me that there is no third stage - constraints
are either syntactic or semantic  - and, putting words into your mouth,
expeted to be semantic.

PS: Typedef names appear to require semantic feedback into syntax. It
is inelegant but unescapable.

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

#67048

David Kleinecke wrote:
> On Saturday, August 8, 2015 at 4:37:47 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> [...]
>>> The answer is in the list of possible types given as a constraint in
>>> 6.5.2 which in the 1990 standard includes:
>>>      int, signed, signed 1nt, or no type specifier.
>>> I haven't been thinking of constraints as part of syntax. I like to keep
>>> a clear separation between syntax and semantics so I imagine some
>>> constraints are syntactic and some semantic. I need to do some research
>>> because it is not obvious that there is no third possibility lying
>>> between syntax and semantics.
>>
>> There are two kinds of rules whose violation requires a diagnostic,
>> syntax rules and contraints.  Syntax rules are expressed in the grammar
>> in something resembling BNF.  Constraints are expressed in English text
>> in sections labeled "Constraints".
>
> I would expect semantic rules to also issue diagnostic messages.

In this case they do, if you compile to a standard less than sixteen 
years old...

-- 
Ian Collins

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

#67072

David Kleinecke <dkleinecke@gmail.com> writes:
> On Saturday, August 8, 2015 at 4:37:47 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> [...]
>> > The answer is in the list of possible types given as a constraint in 
>> > 6.5.2 which in the 1990 standard includes:
>> >     int, signed, signed 1nt, or no type specifier.
>> > I haven't been thinking of constraints as part of syntax. I like to keep
>> > a clear separation between syntax and semantics so I imagine some
>> > constraints are syntactic and some semantic. I need to do some research
>> > because it is not obvious that there is no third possibility lying 
>> > between syntax and semantics.
>> 
>> There are two kinds of rules whose violation requires a diagnostic,
>> syntax rules and contraints.  Syntax rules are expressed in the grammar
>> in something resembling BNF.  Constraints are expressed in English text
>> in sections labeled "Constraints".
>  
> I would expect semantic rules to also issue diagnostic messages. But, at 
> least in theory, we could make two passes - a syntax pass and a semantic 
> pass because semantic failures do not impact on syntax (except, of course,
> in the case of tydef names). 

In theory, the grammar could specify that a translation unit is a
sequence of characters, with all rules expressed in English as
constraints.  Such a description would be extraordinarily unwieldy.

> So, roughly, I would group those constraints that cause a parsing failure
> with syntax and the rest with semantics. But I am still unsure that any  
> constraints are syntactic. 

I'm not sure either.  The boundary between syntax rules and constraints
is somewhat arbitrary, though there are many constraints that cannot be
expressed as syntax (for example those restricting the types of
operands).  It's possible that some rules are expressed as constraints
rather than as syntax rules simply for convenience.

It's easy enough to search the standard for the word "Constraints" to
see if any of them could have been expressed in syntax.  I haven't taken
the time to do so.

[...]

> So you're agreeing with me that there is no third stage - constraints
> are either syntactic or semantic  - and, putting words into your mouth,
> expeted to be semantic.

I'm not sure what a "third state" would be.  Certainly *most*
constraints are semantic (meaning that they can't, or can't easily, be
expressed in the grammar).

> PS: Typedef names appear to require semantic feedback into syntax. It
> is inelegant but unescapable.

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

#67096

On Monday, August 10, 2015 at 8:35:27 AM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> > On Saturday, August 8, 2015 at 4:37:47 PM UTC-7, Keith Thompson wrote:
> >> David Kleinecke <dkleinecke@gmail.com> writes:
> >> [...]
> >> > The answer is in the list of possible types given as a constraint in 
> >> > 6.5.2 which in the 1990 standard includes:
> >> >     int, signed, signed 1nt, or no type specifier.
> >> > I haven't been thinking of constraints as part of syntax. I like to keep
> >> > a clear separation between syntax and semantics so I imagine some
> >> > constraints are syntactic and some semantic. I need to do some research
> >> > because it is not obvious that there is no third possibility lying 
> >> > between syntax and semantics.
> >> 
> >> There are two kinds of rules whose violation requires a diagnostic,
> >> syntax rules and contraints.  Syntax rules are expressed in the grammar
> >> in something resembling BNF.  Constraints are expressed in English text
> >> in sections labeled "Constraints".
> >  
> > I would expect semantic rules to also issue diagnostic messages. But, at 
> > least in theory, we could make two passes - a syntax pass and a semantic 
> > pass because semantic failures do not impact on syntax (except, of course,
> > in the case of tydef names). 
> 
> In theory, the grammar could specify that a translation unit is a
> sequence of characters, with all rules expressed in English as
> constraints.  Such a description would be extraordinarily unwieldy.
> 
> > So, roughly, I would group those constraints that cause a parsing failure
> > with syntax and the rest with semantics. But I am still unsure that any  
> > constraints are syntactic. 
> 
> I'm not sure either.  The boundary between syntax rules and constraints
> is somewhat arbitrary, though there are many constraints that cannot be
> expressed as syntax (for example those restricting the types of
> operands).  It's possible that some rules are expressed as constraints
> rather than as syntax rules simply for convenience.
> 
> It's easy enough to search the standard for the word "Constraints" to
> see if any of them could have been expressed in syntax.  I haven't taken
> the time to do so.

I have the same problem.

> 
> [...]
> 
> > So you're agreeing with me that there is no third stage - constraints
> > are either syntactic or semantic  - and, putting words into your mouth,
> > expeted to be semantic.
> 
> I'm not sure what a "third state" would be.  Certainly *most*
> constraints are semantic (meaning that they can't, or can't easily, be
> expressed in the grammar).
 
Perhaps "semantic" means "not in syntax" but I wouuld have to study
the situation before I agree.

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

#67020

On 8/8/15 7:06 PM, David Kleinecke wrote:
> On Saturday, August 8, 2015 at 12:04:25 PM UTC-7, Keith Thompson wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
>> [...]
>>> The feature that those declarations rely upon is "implicit int", and it
>>> is a feature only of your preferred version of the C standard,
>>> C89(==C90). I've never owned a copy of that version of the standard, so
>>> I can't tell you precisely how this feature is defined, but I'll do the
>>> best that I can, by comparing with the current version of the standard.
>>
>> http://flash-gordon.me.uk/ansi.c.txt
>>
>> is a draft of the C89 standard (including the ANSI section numbering).
>>
>> I own a PDF copy of the ISO C90 standard.  It doesn't have a PDF index,
>> and it appears to have been scanned and OCRed from a printed copy (which
>> makes both searching and copy-and-pasting difficult).
>
> Thanks, guys, for the help. I must have wasted a whole half-hour looking
> in all the wrong places for something that I was sure existed before I
> made the post.
>
> The answer is in the list of possible types given as a constraint in
> 6.5.2 which in the 1990 standard includes:
>      int, signed, signed 1nt, or no type specifier.
> I haven't been thinking of constraints as part of syntax. I like to keep
> a clear separation between syntax and semantics so I imagine some
> constraints are syntactic and some semantic. I need to do some research
> because it is not obvious that there is no third possibility lying
> between syntax and semantics.
>

C is not totally defined by a simple grammar, so you do get a few things 
like this creeping in.

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

#67022

On 08/08/2015 07:06 PM, David Kleinecke wrote:
...
> I haven't been thinking of constraints as part of syntax. ...

It would be more accurate to say that some constraints constrain the
syntax. For example (6.4.3p1):


> 1     universal-character-name:
>              \u hex-quad
>              \U hex-quad hex-quad
>       hex-quad:
>             hexadecimal-digit hexadecimal-digit
>                            hexadecimal-digit hexadecimal-digit
>
>   Constraints
> 2 A universal character name shall not specify a character whose short identifier is less than
>   00A0 other than 0024 ($), 0040 (@), or 0060 (‘), nor one in the range D800 through
>   DFFF inclusive.73)

In general, the constrained syntax could alternatively have been
described using only syntax rules. If a constraint was used, it's
generally because expressing the same idea with syntax rules would have
made it much more complex. For example:

universal-character-name:
	\u ucn-hex-quad
	\U hex-quad hex-quad

hex-quad:
	hexadecimal-digit hexadecimal-digit
                      hexadecimal-digit hexadecimal-digit

ucn-hex-quad:
	0 0 2 4
	0 0 4 0
	0 0 6 0
	0 0 a-f hexadecimal-digit
	0 one-f hexadecimal-digit hexadecimal-digit
	one-c-e-f hexadecimal-digit hexadecimal-digit hexadecimal-digit
	D zero-six hexadecimal-digit hexadecimal-digit
	D 7 zero-eight hexadecimal-digit
	D 7 9 digit

a-f: One of
	A B C D E F

one-f: One of
        1 2 3 4 5 6 7 8 9 0 A B C D E F

one-c-e-f: One of
	1 2 3 4 5 6 7 8 9 A B C E F

zero-six: One of
	0 1 2 3 4 5 6

zero-eight: One of
	0 1 2 3 4 5 6 7 8
	
Which is easier to understand - the constrained syntax rules, or the
alternative expressed purely in the form of syntax rules?
Note: if there's any error in my syntax rules for ucn-hex-quad, I won't
be surprised. That merely emphasizes the advantages of using a
constraint rather syntax rules for this kind of thing.

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

#67023

On 08/08/2015 07:06 PM, David Kleinecke wrote:
(snip) 
> 1     universal-character-name:
>              \u hex-quad
>              \U hex-quad hex-quad
>       hex-quad:
>             hexadecimal-digit hexadecimal-digit
>                            hexadecimal-digit hexadecimal-digit

>   Constraints
> 2 A universal character name shall not specify a character whose 
>   short identifier is less than
>   00A0 other than 0024 ($), 0040 (@), or 0060 (???), nor one in 
>   the range D800 through DFFF inclusive.73)

Interesting way to do it.

Java allows \u escapes everywhere, and without such restrictions.

You can start a string with " and end with \u0022.

You can terminate lines with \u000a, but not put \u000a inside
a string. 

Instead of complicated rules, Java syntax is defined in
unicode, and input is converted before parsing.

-- glen
 

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

#67024

On 8/8/15 10:03 PM, glen herrmannsfeldt wrote:
> On 08/08/2015 07:06 PM, David Kleinecke wrote:
> (snip)
>> 1     universal-character-name:
>>               \u hex-quad
>>               \U hex-quad hex-quad
>>        hex-quad:
>>              hexadecimal-digit hexadecimal-digit
>>                             hexadecimal-digit hexadecimal-digit
>
>>    Constraints
>> 2 A universal character name shall not specify a character whose
>>    short identifier is less than
>>    00A0 other than 0024 ($), 0040 (@), or 0060 (???), nor one in
>>    the range D800 through DFFF inclusive.73)
>
> Interesting way to do it.
>
> Java allows \u escapes everywhere, and without such restrictions.
>
> You can start a string with " and end with \u0022.
>
> You can terminate lines with \u000a, but not put \u000a inside
> a string.
>
> Instead of complicated rules, Java syntax is defined in
> unicode, and input is converted before parsing.
>
> -- glen

I think the difference is that C was designed to run on a non-unicode 
enabled machine (non-ascii even). These rules means that the 
implementation doesn't need to know that A and \u0041 are the same (the 
lower chars it allows are not required to be part of the implementation 
character set).

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

#67025

Richard Damon <Richard@damon-family.org> wrote:

(snip regarding \u and \U escapes in C99 and C11.)

>> Interesting way to do it.

>> Java allows \u escapes everywhere, and without such restrictions.

>> You can start a string with " and end with \u0022.

>> You can terminate lines with \u000a, but not put \u000a inside
>> a string.

>> Instead of complicated rules, Java syntax is defined in
>> unicode, and input is converted before parsing.

> I think the difference is that C was designed to run on a non-unicode 
> enabled machine (non-ascii even). These rules means that the 
> implementation doesn't need to know that A and \u0041 are the same (the 
> lower chars it allows are not required to be part of the implementation 
> character set).

It is easier to add features from the beginning, instead of adapting
them to fit later. 

But C wasn't really designed for non-ASCII, as the prime alternative,
EBCDIC, doesn't have ~ or ^. 

It doesn't seem that it would have been so hard to define A and \u0041
to be the same, though I didn't go through the standard to be sure.

-- glen

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

#67039

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> Richard Damon <Richard@damon-family.org> wrote:
>
> (snip regarding \u and \U escapes in C99 and C11.)
>
>>> Interesting way to do it.
>
>>> Java allows \u escapes everywhere, and without such restrictions.
>
>>> You can start a string with " and end with \u0022.
>
>>> You can terminate lines with \u000a, but not put \u000a inside
>>> a string.
>
>>> Instead of complicated rules, Java syntax is defined in
>>> unicode, and input is converted before parsing.
>
>> I think the difference is that C was designed to run on a non-unicode 
>> enabled machine (non-ascii even). These rules means that the 
>> implementation doesn't need to know that A and \u0041 are the same (the 
>> lower chars it allows are not required to be part of the implementation 
>> character set).
>
> It is easier to add features from the beginning, instead of adapting
> them to fit later. 
>
> But C wasn't really designed for non-ASCII, as the prime alternative,
> EBCDIC, doesn't have ~ or ^. 
>
> It doesn't seem that it would have been so hard to define A and \u0041
> to be the same, though I didn't go through the standard to be sure.

At the time C was developed, it would have been flatly impossible since
Unicode didn't exist.  I don't know of a better solution to adding
Unicode support without breaking existing code than the wide characters
in C99.

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

#67063

On Sunday, August 9, 2015 at 4:58:50 PM UTC+1, Joe Pfeiffer wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> 
> At the time C was developed, it would have been flatly impossible since
> Unicode didn't exist.  I don't know of a better solution to adding
> Unicode support without breaking existing code than the wide characters
> in C99.
>
UTF-8 is generally the best format for passing string data about. The vast majority
of string handling functions don't care about glyphs, and they all just work
transparently. Also, you'll often be passed ascii text from a non-unicode aware
data source, almost always that will simply work without any need for program 
modifications. The question is how to enter it and display it.

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

#67044

On 8/9/15 12:57 AM, glen herrmannsfeldt wrote:
> Richard Damon <Richard@damon-family.org> wrote:
>
>> I think the difference is that C was designed to run on a non-unicode
>> enabled machine (non-ascii even). These rules means that the
>> implementation doesn't need to know that A and \u0041 are the same (the
>> lower chars it allows are not required to be part of the implementation
>> character set).
>
> It is easier to add features from the beginning, instead of adapting
> them to fit later.
>
> But C wasn't really designed for non-ASCII, as the prime alternative,
> EBCDIC, doesn't have ~ or ^.
>
> It doesn't seem that it would have been so hard to define A and \u0041
> to be the same, though I didn't go through the standard to be sure.
>
> -- glen
>

But it does have characters that can substitute like ¬ (0x5F EBCDIC, 
\u00AC0, logical not) and EBCDIC 0xB0 is ^ (At least in one version of 
EBCDIC that I pulled up).

C also included the 'dreaded' trigraph codes, mostly to handle national 
varients of ASCII that didn't include some of the needed codes.

It appears that one of the goals in adding the Unicode escape characters 
was for an implementation to be able to be conforming while being 
totally Unicode ignorant, thus being able to place a symbol in its 
symbol table using the Unicode escape sequence literally, and not have 
to worry about some codes matching acceptable characters.

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web