Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Text processing

Reply
Thread Tools

Text processing

 
 
Alan Curry
Guest
Posts: n/a
 
      09-27-2011
In article <0.f4943ccb47e4d12fc453.20110926225852BST.87pqinot (E-Mail Removed)>,
Ben Bacarisse <(E-Mail Removed)> wrote:
>
>Yes, it's very odd. I assume there is some advantage in knowing the
>complete type of objects with internal linkage at the get go. I can't
>think of one, though.


I asked about this recently (good luck finding the thread on DejaGoo)
and the conclusion was that static int foo[] was originally forbidden
because classic single-pass compilers didn't support it. (The linker would
take care of resolving the non-static equivalent.) It remains forbidden in
the standard because nobody on the committee noticed it and cared enough to
formally propose removing it.

--
Alan Curry
 
Reply With Quote
 
 
 
 
Harald van Dijk
Guest
Posts: n/a
 
      09-27-2011
On Sep 27, 3:05*am, (E-Mail Removed) (Alan Curry) wrote:
> In article <0.f4943ccb47e4d12fc453.20110926225852BST.87pqinot (E-Mail Removed)>,
> Ben Bacarisse *<(E-Mail Removed)> wrote:
> >Yes, it's very odd. *I assume there is some advantage in knowing the
> >complete type of objects with internal linkage at the get go. *I can't
> >think of one, though.

>
> I asked about this recently (good luck finding the thread on DejaGoo)
> and the conclusion was that static int foo[] was originally forbidden
> because classic single-pass compilers didn't support it. (The linker would
> take care of resolving the non-static equivalent.) It remains forbidden in
> the standard because nobody on the committee noticed it and cared enough to
> formally propose removing it.


Ah, thank you, that actually makes sense.
 
Reply With Quote
 
 
 
 
Ben Bacarisse
Guest
Posts: n/a
 
      09-27-2011
Harald van Dijk <(E-Mail Removed)> writes:

> On Sep 27, 2:41*am, Ben Bacarisse <(E-Mail Removed)> wrote:
>> Harald van Dijk <(E-Mail Removed)> writes:
>> > On Sep 26, 11:58*pm, Ben Bacarisse <(E-Mail Removed)> wrote:
>> >> However, I don't think 6.9.2p3 makes much sense if the final composite
>> >> type is assumed to be the intended meaning because, I don't think the
>> >> final composite type *can* be incomplete? *For example, a translation
>> >> union with nothing other than

>>
>> >> * int array[];

>>
>> >> is fine and causes the type of array to be int [1] by at the end.

>>
>> > I was thinking of incomplete structure and union types.

>>
>> I'd considered that and ruled them out. *Composite types must be
>> compatible, and an incomplete struct type is not compatible with a
>> complete one declared in the same translation unit (I think!).

>
> An incomplete struct type is completed by a struct definition with the
> same tag in the same scope, see 6.7.2.3p4 for the official wording and
> p12 for an example.
>
> struct X x; /* tentative definition with incomplete type */
> struct X { int a; }; /* completed here */


Right. I've now confused myself! What matters is types that remain
incomplete, not completed ones, because the question was whether the
type referred to in 6.9.2 p3 (the one that must not be incomplete) is in
fact the composite type referred to in the previous paragraph. (We know
it isn't, but that was the speculation -- was that the intended
meaning).

We know that one or more tentative definitions of an array do not yield
an incomplete composite type -- the implied = {0} makes it an array of
length one. What happens with structs? Can the composite type remain
incomplete? I don't think so.

Somewhat separately, I need to ask you about your citations because
6.7.2.3 p12 does not have an example of a tentative definition. All I
can see is a forward declaration of the tag. And 6.7.2.3 p4 just says
when a struct declaration becomes complete. It does not say anything
about one or more tentative definitions and the final composite type
that results from them. In other words, I can't reconcile your example
with 6.9.2 p2. As you have it, there is only the one tentative
definition with an incomplete type. I presume that you would say that
the composite type is the complete struct because the type as been
completed by the end of the translation unit. But what about the slight
variant:

struct X x; /* tentative definition with incomplete type */
struct X { int a; } x; /* another one that also completes the type */

I can't find the wording the says these two struct types are compatible.

--
Ben.
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      09-27-2011
On 09/26/2011 05:58 PM, Ben Bacarisse wrote:
....
> However, I don't think 6.9.2p3 makes much sense if the final composite
> type is assumed to be the intended meaning because, I don't think the
> final composite type *can* be incomplete? For example, a translation
> union with nothing other than
>
> int array[];
>
> is fine and causes the type of array to be int [1] by at the end.


Citation please? I'm not familiar with that feature, and I have not
managed to find any specification of it in the standard.
--
James Kuyper
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      09-27-2011
James Kuyper <(E-Mail Removed)> writes:

> On 09/26/2011 05:58 PM, Ben Bacarisse wrote:
> ...
>> However, I don't think 6.9.2p3 makes much sense if the final composite
>> type is assumed to be the intended meaning because, I don't think the
>> final composite type *can* be incomplete? For example, a translation
>> union with nothing other than
>>
>> int array[];
>>
>> is fine and causes the type of array to be int [1] by at the end.

>
> Citation please? I'm not familiar with that feature, and I have not
> managed to find any specification of it in the standard.


6.9.2 p2 and p5 for an example.

--
Ben.
 
Reply With Quote
 
Harald van Dijk
Guest
Posts: n/a
 
      09-27-2011
On Sep 27, 3:41*am, Ben Bacarisse <(E-Mail Removed)> wrote:
> We know that one or more tentative definitions of an array do not yield
> an incomplete composite type -- the implied = {0} makes it an array of
> length one. *What happens with structs? *Can the composite type remain
> incomplete? *I don't think so.


If the composite type remains incomplete, then the implied = {0} is an
invalid initializer, so the composite type cannot remain incomplete in
a valid program. I'm not sure if I'm understanding you right:

extern struct never_defined x; /* no tentative definition, valid */
struct never_defined y; /* tentative definition, invalid if struct is
never defined */

> Somewhat separately, I need to ask you about your citations because
> 6.7.2.3 p12 does not have an example of a tentative definition. *All I
> can see is a forward declaration of the tag.


Yes, it was merely an example of an incomplete struct being completed.

>*And 6.7.2.3 p4 just says
> when a struct declaration becomes complete. *It does not say anything
> about one or more tentative definitions and the final composite type
> that results from them.


What p4 says is that

struct X; /* 1 */
struct X x; /* a */
struct X { int a; }; /* 2 */
struct X x; /* b */

lines 1 and 2 declare the *same* type. Because of that, there is no
question of what the composite type of tentative definitions a and b
is, because the type is identical: it is struct X.

>*In other words, I can't reconcile your example
> with 6.9.2 p2. *As you have it, there is only the one tentative
> definition with an incomplete type. *I presume that you would say that
> the composite type is the complete struct because the type as been
> completed by the end of the translation unit. *But what about the slight
> variant:
>
> * struct X x; /* tentative definition with incomplete type */
> * struct X { int a; } x; /* another one that also completes the type **/
>
> I can't find the wording the says these two struct types are compatible.


To be slightly more thorough: 6.2.7 starts with
"Two types have compatible type if their types are the same."
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      09-27-2011
Harald van Dijk <(E-Mail Removed)> writes:

> On Sep 27, 3:41*am, Ben Bacarisse <(E-Mail Removed)> wrote:
>> We know that one or more tentative definitions of an array do not yield
>> an incomplete composite type -- the implied = {0} makes it an array of
>> length one. *What happens with structs? *Can the composite type remain
>> incomplete? *I don't think so.

>
> If the composite type remains incomplete, then the implied = {0} is an
> invalid initializer, so the composite type cannot remain incomplete in
> a valid program. I'm not sure if I'm understanding you right:
>
> extern struct never_defined x; /* no tentative definition, valid */
> struct never_defined y; /* tentative definition, invalid if struct is
> never defined */


Yes, I think we are on the same page. The point I was trying to make
(and got all messed up) was that either the composite type ends up
complete because of the implied initialiser (for arrays) or the program
is invalid because the composite type remains incomplete. (I said
"can't be incomplete" which is ambiguous at best -- I meant "can't be
incomplete in a valid program".)

The reason for making that point is now entirely redundant since
everyone agrees that 6.9.2. p3 is making a special exception motivated
by concern for limited compiler abilities.

>> Somewhat separately, I need to ask you about your citations because
>> 6.7.2.3 p12 does not have an example of a tentative definition. *All I
>> can see is a forward declaration of the tag.

>
> Yes, it was merely an example of an incomplete struct being completed.
>
>>*And 6.7.2.3 p4 just says
>> when a struct declaration becomes complete. *It does not say anything
>> about one or more tentative definitions and the final composite type
>> that results from them.

>
> What p4 says is that
>
> struct X; /* 1 */
> struct X x; /* a */
> struct X { int a; }; /* 2 */
> struct X x; /* b */
>
> lines 1 and 2 declare the *same* type. Because of that, there is no
> question of what the composite type of tentative definitions a and b
> is, because the type is identical: it is struct X.
>
>>*In other words, I can't reconcile your example
>> with 6.9.2 p2. *As you have it, there is only the one tentative
>> definition with an incomplete type. *I presume that you would say that
>> the composite type is the complete struct because the type as been
>> completed by the end of the translation unit. *But what about the slight
>> variant:
>>
>> * struct X x; /* tentative definition with incomplete type */
>> * struct X { int a; } x; /* another one that also completes the type **/
>>
>> I can't find the wording the says these two struct types are compatible.

>
> To be slightly more thorough: 6.2.7 starts with
> "Two types have compatible type if their types are the same."


Sometimes (often?) I miss the obvious. By concentrating on the
completion of the type, I missed that fact p4 makea the types
the same so of course they are compatible.

--
Ben.
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      03-07-2012
Harald van Dijk <(E-Mail Removed)> writes:

> On Sep 26, 9:36 pm, Harald van Dijk <(E-Mail Removed)> wrote:
>> On Sep 26, 2:18 pm, Ben Bacarisse <(E-Mail Removed)> wrote:
>>
>> > And, second, the
>> > output does not compile because the initial

>>
>> > static char *StringTable[];

>>
>> > is a tentative definition of an object with incomplete type (that's a
>> > constraint violation).

>>
>> 6.9.2p3 says the declared type of a tentative definition with internal
>> linkage must not be an incomplete type, but it isn't a constraint,
>> which matters because it means compilers are not required to issue any
>> diagnostics. And I wonder if that is really meant to apply to the
>> declared type, rather than the composite type for the final implicit
>> definition mentioned in p2. Compilers are already required to accept
>> "int array[]; int array[20] = {1};" -- without the static keyword --
>> and they would surely need to treat the static keyword specially to
>> reject it if present.

>
> I feel I should add that the standard does clearly and unambiguously
> disallow this, [snip]


A more accurate statement is that the Standard clearly
and unambiguously allows it. The construct isn't
required to work portably (or at all), but it is
allowed - any implementation is free to accept it
and treat it as most people would expect.
 
Reply With Quote
 
hormelfree@gmail.com
Guest
Posts: n/a
 
      03-08-2012
On Monday, September 26, 2011 10:36:49 AM UTC-7, Nobody wrote:
> On Mon, 26 Sep 2011 08:34:03 -0500, Mark Storkamp wrote:
>
> >> A widely used application of text files are program files. Most
> >> programming languages (and here C is not an exception) store the
> >> program in text format.

> >
> > I'm not sure who your target audience is, but I find this to be less
> > precise than I believe it should be. I think most people, when they
> > think of programs, are thinking of the executable binaries, not the
> > source code. While some languages, like BASIC, and other interpreted
> > languages do indeed save their programs as text files, C and most others
> > do not.

>
> Another counter-example is that many older dialects of BASIC *didn't*
> store their programs as text files, but used a tokenised format for the
> sake of space and performance.


I think that was called "Java(TM)"...

---
William Ernest Reid
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      03-08-2012
http://www.velocityreviews.com/forums/(E-Mail Removed) writes:
> On Monday, September 26, 2011 10:36:49 AM UTC-7, Nobody wrote:
>> On Mon, 26 Sep 2011 08:34:03 -0500, Mark Storkamp wrote:
>>
>> >> A widely used application of text files are program files. Most
>> >> programming languages (and here C is not an exception) store the
>> >> program in text format.
>> >
>> > I'm not sure who your target audience is, but I find this to be less
>> > precise than I believe it should be. I think most people, when they
>> > think of programs, are thinking of the executable binaries, not the
>> > source code. While some languages, like BASIC, and other interpreted
>> > languages do indeed save their programs as text files, C and most others
>> > do not.

>>
>> Another counter-example is that many older dialects of BASIC *didn't*
>> store their programs as text files, but used a tokenised format for the
>> sake of space and performance.

>
> I think that was called "Java(TM)"...


I didn't see a smiley, so ...

No, that's not the same thing at all.

Java source code is text. It's typically *compiled* to byte code,
referred to as "Java bytecode". Other languages can be, and are,
compiled to the same byte code used by Java implementations, and
Java source can be compiled to things other than Java bytecode.

What "Nobody" is referring to is that there have been implementations
of BASIC where the program *source*, though it might be displayed as
text, is never actually stored as text. For example, the keyword
"GOSUB" would not be stored as the 5 characters 'G', 'O', 'S',
'U', 'B', but as a single encoded byte (that's displayed as "GOSUB"
by the specialized editor used to create and modify BASIC programs).

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Controlling text in a Text Area or Text leo ASP General 1 12-05-2005 01:13 AM
Processing pathnames listed in a text file. Jason Heyes C++ 4 03-24-2005 11:47 AM
Post-Processing RAW vs Post-Processing TIFF Mike Henley Digital Photography 42 01-30-2005 08:26 AM
Question: processing HTML, re-write default processing action of many tags Hubert Hung-Hsien Chang Python 2 09-17-2004 03:10 PM
"Text Processing in Python" review on Slashdot Joe Francia Python 0 07-08-2003 04:30 AM



Advertisments