misleading statement in bugs.html#known

misleading statement in bugs.html#known

[Per Bothner]

The bugs.html files says 'FILE *yyin = stdin' "will not compile with GNU 
libc (GNU/Linux libc6), because stdin is not a constant. This was done 
deliberately, in order for there to be no limit on the number of open 
FILE objects."

The latter has nothing to do with it.  It is easy to make stdin be
a constant while still having no limit on the number of open FILE
objects.  For example:

	extern FILE __stdin;
         @define stdin (&__stdin)

The point is that glibc allows you to *assign* to stdin, so it is
no longer constant.  This is a questionable feature..
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: misleading statement in bugs.html#known

[Geoff Keating]

Per Bothner <per@bothner.com> writes:

> The bugs.html files says 'FILE *yyin = stdin' "will not compile with GNU 
> libc (GNU/Linux libc6), because stdin is not a constant. This was done 
> deliberately, in order for there to be no limit on the number of open 
> FILE objects."
> 
> The latter has nothing to do with it.  It is easy to make stdin be
> a constant while still having no limit on the number of open FILE
> objects.  For example:
> 
> 	extern FILE __stdin;
>          @define stdin (&__stdin)
> 
> The point is that glibc allows you to *assign* to stdin, so it is
> no longer constant.  This is a questionable feature..

Actually, neither of these are the real reason.  I believe the
definition of stdin was changed so that user programs didn't need to
know the size of 'FILE'.  If a user program writes

printf (&__stdin, ...)

then this works with dynamic linking by creating space in the
executable for '__stdin', resolving the address of __stdin at link
time, and copying at startup time the initial contents of __stdin to
that space (this is done because addresses in applications are not
resolved at run time).  If __stdin grows in size in future glibc
versions, the space reserved in old applications will be too small,
and special compatibility code is required.  So instead, 'stdin' is
made a variable of type 'FILE *', which is not likely to change in
size in future versions.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: misleading statement in bugs.html#known

[Andreas Schwab]

Per Bothner <per@bothner.com> writes:

|> The bugs.html files says 'FILE *yyin = stdin' "will not compile with GNU
|> libc (GNU/Linux libc6), because stdin is not a constant. This was done
|> deliberately, in order for there to be no limit on the number of open FILE
|> objects."
|> 
|> The latter has nothing to do with it.  It is easy to make stdin be
|> a constant while still having no limit on the number of open FILE
|> objects.  For example:
|> 
|> 	extern FILE __stdin;
|>          @define stdin (&__stdin)
|> 
|> The point is that glibc allows you to *assign* to stdin, so it is
|> no longer constant.  This is a questionable feature..

No.  The real reason is that using the address of a static object is a
nightmare in context of maintaining binary compatibility.  Platforms that
use copy relocations will lose if the size of the FILE type changes.

In any way, the C standard does not *require* stdin to be a constant.
Thus using it as an initializer at file scope is broken no matter what.

Andreas.

-- 
Andreas Schwab                                  "And now for something
Andreas.Schwab@suse.de				completely different."
SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

Re: misleading statement in bugs.html#known

[Gerald Pfeifer]

On 5 Dec 2001, Andreas Schwab wrote:
>|> The point is that glibc allows you to *assign* to stdin, so it is
>|> no longer constant.  This is a questionable feature..
> No.  The real reason is that using the address of a static object is a
> nightmare in context of maintaining binary compatibility.  Platforms that
> use copy relocations will lose if the size of the FILE type changes.

Would (one of) you (who knows this stuff) mind updating bugs.html?

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: misleading statement in bugs.html#known

[Andreas Schwab]

Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

|> On 5 Dec 2001, Andreas Schwab wrote:
|> >|> The point is that glibc allows you to *assign* to stdin, so it is
|> >|> no longer constant.  This is a questionable feature..
|> > No.  The real reason is that using the address of a static object is a
|> > nightmare in context of maintaining binary compatibility.  Platforms that
|> > use copy relocations will lose if the size of the FILE type changes.
|> 
|> Would (one of) you (who knows this stuff) mind updating bugs.html?

How about this:

--- bugs.html.~1.45.~	Sun Nov  4 00:14:32 2001
+++ bugs.html	Thu Dec  6 13:29:35 2001
@@ -276,10 +276,10 @@
 </code></blockquote>
 
 will not compile with GNU libc (GNU/Linux libc6), because
-<code>stdin</code> is not a constant.  This was done deliberately, in
-order for there to be no limit on the number of open <code>FILE</code>
-objects.  It is surprising for people used to traditional Unix C
-libraries, but it is permitted by the C standard.</p>
+<code>stdin</code> is not a constant.  This was done deliberately, to make
+it easier to maintain binary compatibility when the type <code>FILE</code>
+needs to be changed.  It is surprising for people used to traditional Unix
+C libraries, but it is permitted by the C standard.</p>
 
 <p>This construct commonly occurs in code generated by old versions of
 lex or yacc.  We suggest you try regenerating the parser with a

Andreas.

-- 
Andreas Schwab                                  "And now for something
Andreas.Schwab@suse.de				completely different."
SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

Re: misleading statement in bugs.html#known

[Gerald Pfeifer]

On 6 Dec 2001, Andreas Schwab wrote:
> How about this:

This looks fine, thanks!

> +C libraries, but it is permitted by the C standard.</p>
                                          ^^^
Perhaps we should mention *which* C standard? ISO C?

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: misleading statement in bugs.html#known

[Andreas Schwab]

Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

|> On 6 Dec 2001, Andreas Schwab wrote:
|> > How about this:
|> 
|> This looks fine, thanks!
|> 
|> > +C libraries, but it is permitted by the C standard.</p>
|>                                           ^^^
|> Perhaps we should mention *which* C standard? ISO C?

Is there any other C standard?  Even C89 had this.

Andreas.

-- 
Andreas Schwab                                  "And now for something
Andreas.Schwab@suse.de				completely different."
SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

Re: misleading statement in bugs.html#known

[Gerald Pfeifer]

On 6 Dec 2001, Andreas Schwab wrote:
>|>> +C libraries, but it is permitted by the C standard.</p>
>|>                                           ^^^
>|> Perhaps we should mention *which* C standard? ISO C?
> Is there any other C standard?  Even C89 had this.

This I didn't know. In that case, the patch seems fine as is.

Thanks,
Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: misleading statement in bugs.html#known

[Per Bothner]

Geoff Keating wrote:

> printf (&__stdin, ...)
> 
> then this works with dynamic linking by creating space in the
> executable for '__stdin', resolving the address of __stdin at link
> time, and copying at startup time the initial contents of __stdin to
> that space


Ugh.  Ick.  This is unfortunate mechanism, not that I know enough
about dynamic linking to know if there is (or could be) a better
way.  But it seems we're stuck with it.

Thanks for the replies and explanations.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: misleading statement in bugs.html#known

[Richard Henderson]

On Thu, Dec 06, 2001 at 12:14:55PM -0800, Per Bothner wrote:
> Ugh.  Ick.  This is unfortunate mechanism, not that I know enough
> about dynamic linking to know if there is (or could be) a better
> way.  But it seems we're stuck with it.

The "better way" is defaulting to PIC for any symbol not known
to be defined locally.  We do this on Alpha and IA-64.  It's not
really practical to do the same for x86 though.  :-/


r~