(printf) ("hello world\n");

(printf) ("hello world\n");

[Michael Elizabeth Chastain]

I have a language lawyer question.

  int main ()
  {
    (printf) ("hello world\n");
    return 0;
  }

Is this a conforming C program?

There is no "#include <stdio.h>" so there is no declaration
in scope for printf.

gcc 2.95.3 and gcc 3.3.2 both say:

  hello.c: In function `main':
  hello.c:3: `printf' undeclared (first use in this function)
  hello.c:3: (Each undeclared identifier is reported only once
  hello.c:3: for each function it appears in.)

This happens with each of:

  -std=iso9899:1990
  -std=iso9899:199409
  -std=iso9899:1999

But the HP ansi-c and aCC compilers accept it just fine.

This kind of code comes out of a macro expansion with readline 4.3
and gcc 3.3.2 on native hppa2.0w-hp-hpux11.11.  It's the end
result of an interaction between multibyte support in hpux11
and a strange-looking workaround in readline.

Of course the question "is this conforming ..." depends on a particular
standard.  So I think I am asking three questions, one for each of the
three standards.

If the program is not conforming, then I can work on a patch for
readline.  But if the program is conforming, then I can file a PR
against gcc (and I'll still have to patch readline).

(Personally I would be happier if this program is not conforming.)

Michael C

Re: (printf) ("hello world\n");

[Dale Johannesen]

On Dec 9, 2003, at 12:40 PM, Michael Elizabeth Chastain wrote:

> I have a language lawyer question.
>
>   int main ()
>   {
>     (printf) ("hello world\n");
>     return 0;
>   }
>
> Is this a conforming C program?

c89 3.3.2.2:
"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 the implicit declaration is not supposed to happen when the function 
identifier
is surrounded by parentheses, and this is not conforming.

Re: (printf) ("hello world\n");

[Geoff Keating]

mec.gnu@mindspring.com (Michael Elizabeth Chastain) writes:

> I have a language lawyer question.
> 
>   int main ()
>   {
>     (printf) ("hello world\n");
>     return 0;
>   }
> 
> Is this a conforming C program?
> 
> There is no "#include <stdio.h>" so there is no declaration
> in scope for printf.

This would be nonconforming even if it was

int main()
{
  printf ("hello world\n");
}

since printf is a varargs function and so must be prototyped before it
is called (ISO C 6.5.2.2 paragraph 6).

(I think Dale answered the question you really wanted to ask.)

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

Re: (printf) ("hello world\n");

[Eyal Lebedinsky]

Geoff Keating wrote:
> 
> mec.gnu@mindspring.com (Michael Elizabeth Chastain) writes:
> 
> > I have a language lawyer question.
> >
> >   int main ()
> >   {
> >     (printf) ("hello world\n");
> >     return 0;
> >   }
> >
> > Is this a conforming C program?
> >
> > There is no "#include <stdio.h>" so there is no declaration
> > in scope for printf.
> 
> This would be nonconforming even if it was
> 
> int main()
> {
>   printf ("hello world\n");
> }
> 
> since printf is a varargs function and so must be prototyped before it
> is called (ISO C 6.5.2.2 paragraph 6).

But without <stdio.h> the varargs attribute is not present and all is
well. Naturally, it may very well fail to execute correctly, but this
is not the issue here.

--
Eyal Lebedinsky (eyal@eyal.emu.id.au) <http://samba.org/eyal/>

Re: (printf) ("hello world\n");

[Andreas Schwab]

Eyal Lebedinsky <eyal@eyal.emu.id.au> writes:

> But without <stdio.h> the varargs attribute is not present

A varargs function is always a varargs function, whether it is prototyped
or not.  But without a proper prototype the behaviour is undefined.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: (printf) ("hello world\n");

[Robert Dewar]

Andreas Schwab wrote:

> Eyal Lebedinsky <eyal@eyal.emu.id.au> writes:
> 
> 
>>But without <stdio.h> the varargs attribute is not present
> 
> 
> A varargs function is always a varargs function, whether it is prototyped
> or not.  But without a proper prototype the behaviour is undefined.

Is it really true that the name printf is reserved? Is a C program not
allowed to define its own printf function (which might or might not be
varargs)? What's the story here?

Re: (printf) ("hello world\n");

[Segher Boessenkool]

On 10-dec-03, at 13:27, Robert Dewar wrote:
> Is it really true that the name printf is reserved? Is a C program not
> allowed to define its own printf function (which might or might not be
> varargs)? What's the story here?

It is reserved only in translation units that have stdio.h #include'd.


Segher

Re: (printf) ("hello world\n");

[Robert Dewar]

Segher Boessenkool wrote:

> On 10-dec-03, at 13:27, Robert Dewar wrote:
> 
>> Is it really true that the name printf is reserved? Is a C program not
>> allowed to define its own printf function (which might or might not be
>> varargs)? What's the story here?
> 
> 
> It is reserved only in translation units that have stdio.h #include'd.

Well that's not a matter of being reserved, just normal visibility
rules ...

Re: (printf) ("hello world\n");

[Gabriel Dos Reis]

Segher Boessenkool <segher@kernel.crashing.org> writes:

| On 10-dec-03, at 13:27, Robert Dewar wrote:
| > Is it really true that the name printf is reserved? Is a C program not
| > allowed to define its own printf function (which might or might not be
| > varargs)? What's the story here?

Put Andreas' statement in context and use

       7.1.3  Reserved identifiers

[...]
  
         -- All identifiers with external linkage  in  any  of  the
            following  subclauses  (including  the  future  library
            directions) are always reserved for use as  identifiers
            with external linkage.154)
[...]

       [#2] No other identifiers  are  reserved.   If  the  program
       declares  or  defines an identifier in a context in which it
       is reserved (other than as allowed by 7.1.4), or  defines  a
       reserved  identifier  as  a  macro  name,  the  behavior  is
       undefined.

Re: (printf) ("hello world\n");

[Joseph S. Myers]

On Wed, 10 Dec 2003, Segher Boessenkool wrote:

> On 10-dec-03, at 13:27, Robert Dewar wrote:
> > Is it really true that the name printf is reserved? Is a C program not
> > allowed to define its own printf function (which might or might not be
> > varargs)? What's the story here?
> 
> It is reserved only in translation units that have stdio.h #include'd.

It is reserved (in a hosted environment) as an identifier with external
linkage regardless of what headers are included (7.1.3#1).  If <stdio.h>
is included then it is alse reserved as a macro name (which however you
may #undef) and as an identifier with file scope.

(C94 reserved certain identifiers with external linkage iff the
corresponding header was included in _any translation unit in the
program_.  This was not carried forward into C99; the functions added in
C94 are now unconditionally reserved as identifiers with external linkage
regardless of the headers included.)

-- 
Joseph S. Myers
jsm@polyomino.org.uk

Re: (printf) ("hello world\n");

[Segher Boessenkool]

On 10-dec-03, at 14:36, Joseph S. Myers wrote:
> On Wed, 10 Dec 2003, Segher Boessenkool wrote:
>> On 10-dec-03, at 13:27, Robert Dewar wrote:
>>> Is it really true that the name printf is reserved? Is a C program 
>>> not
>>> allowed to define its own printf function (which might or might not 
>>> be
>>> varargs)? What's the story here?
>>
>> It is reserved only in translation units that have stdio.h #include'd.
>
> It is reserved (in a hosted environment) as an identifier with external
> linkage regardless of what headers are included (7.1.3#1).

That does not prevent you from declaring and defining your own
printf() function (with a different prototype) though; it only requires
that you make that function have external linkage.


Segher

Re: (printf) ("hello world\n");

[Andreas Schwab]

Segher Boessenkool <segher@kernel.crashing.org> writes:

> On 10-dec-03, at 14:36, Joseph S. Myers wrote:
>> On Wed, 10 Dec 2003, Segher Boessenkool wrote:
>>> On 10-dec-03, at 13:27, Robert Dewar wrote:
>>>> Is it really true that the name printf is reserved? Is a C program not
>>>> allowed to define its own printf function (which might or might not be
>>>> varargs)? What's the story here?
>>>
>>> It is reserved only in translation units that have stdio.h #include'd.
>>
>> It is reserved (in a hosted environment) as an identifier with external
>> linkage regardless of what headers are included (7.1.3#1).
>
> That does not prevent you from declaring and defining your own
> printf() function (with a different prototype) though; it only requires
> that you make that function have external linkage.

Which requires that you declare it in the first place, otherwise it will
have implicitly external linkage.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: (printf) ("hello world\n");

[Geoff Keating]

Segher Boessenkool <segher@kernel.crashing.org> writes:

> On 10-dec-03, at 14:36, Joseph S. Myers wrote:
> > On Wed, 10 Dec 2003, Segher Boessenkool wrote:
> >> On 10-dec-03, at 13:27, Robert Dewar wrote:
> >>> Is it really true that the name printf is reserved? Is a C program
> >>> not
> >>> allowed to define its own printf function (which might or might
> >>> not be
> >>> varargs)? What's the story here?
> >>
> >> It is reserved only in translation units that have stdio.h #include'd.
> >
> > It is reserved (in a hosted environment) as an identifier with external
> > linkage regardless of what headers are included (7.1.3#1).
> 
> That does not prevent you from declaring and defining your own
> printf() function (with a different prototype) though; it only requires
> that you make that function have external linkage.

You mean 'internal linkage'.  You can define your own function named
printf only if you (a) do not include stdio.h and (b) declare it
'static'.

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

Re: (printf) ("hello world\n");

[Segher Boessenkool]

>>>> It is reserved only in translation units that have stdio.h 
>>>> #include'd.
>>>
>>> It is reserved (in a hosted environment) as an identifier with 
>>> external
>>> linkage regardless of what headers are included (7.1.3#1).
>>
>> That does not prevent you from declaring and defining your own
>> printf() function (with a different prototype) though; it only 
>> requires
>> that you make that function have external linkage.
>
> You mean 'internal linkage'.  You can define your own function named
> printf only if you (a) do not include stdio.h and (b) declare it
> 'static'.

That makes more sense, yes.  I think I misinterpreted what "reserved as
an identifier with external linkage" means.  Whoops.


Segher

Re: (printf) ("hello world\n");

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1247 bytes --]

On Thu, 2003-12-11 09:01:51 -0800, Geoff Keating <geoffk@geoffk.org>
wrote in message <jmllpjxp8g.fsf@desire.geoffk.org>:
> Segher Boessenkool <segher@kernel.crashing.org> writes:

> > That does not prevent you from declaring and defining your own
> > printf() function (with a different prototype) though; it only requires
> > that you make that function have external linkage.
> 
> You mean 'internal linkage'.  You can define your own function named
> printf only if you (a) do not include stdio.h and (b) declare it
> 'static'.

Um, I think:
	- You may include <stdio.h> as long as your new printf() has
	  compatible arguments. It's a Bad Thing, though, because
	  declaration in <stdio.h> doesn't really belong to your new
	  function.
	- You may also have your own function non-static. Then, it
	  depends on link-order which function (yours or libc's) is
	  used. Of course, that's horrible, too:)

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: (printf) ("hello world\n");

[Gabriel Dos Reis]

Jan-Benedict Glaw <jbglaw@lug-owl.de> writes:

| On Thu, 2003-12-11 09:01:51 -0800, Geoff Keating <geoffk@geoffk.org>
| wrote in message <jmllpjxp8g.fsf@desire.geoffk.org>:
| > Segher Boessenkool <segher@kernel.crashing.org> writes:
| 
| > > That does not prevent you from declaring and defining your own
| > > printf() function (with a different prototype) though; it only requires
| > > that you make that function have external linkage.
| > 
| > You mean 'internal linkage'.  You can define your own function named
| > printf only if you (a) do not include stdio.h and (b) declare it
| > 'static'.
| 
| Um, I think:
| 	- You may include <stdio.h> as long as your new printf() has
| 	  compatible arguments. It's a Bad Thing, though, because
| 	  declaration in <stdio.h> doesn't really belong to your new
| 	  function.
| 	- You may also have your own function non-static. Then, it
| 	  depends on link-order which function (yours or libc's) is
| 	  used. Of course, that's horrible, too:)

If the printf function does not have an internal linkage, then it is
an undefined behaviour.  That rules out both points.

-- Gaby

Register Spilling

[Umar Janjua]

Are the register spilled values laid out in memory following 
 some particular scheme or randomly?

Re: Register Spilling

[Jim Wilson]

Umar Janjua wrote:
> Are the register spilled values laid out in memory following 
>  some particular scheme or randomly?

They are first come first served.  The first one spilled gets the first 
available stack slot, etc.

There have been some proposals to sort them, offhand I don't know if 
there are patches available anywhere for this.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

RE: Register Spilling

[Sanjiv Gupta]

> There have been some proposals to sort them, offhand I don't know if 
> there are patches available anywhere for this.
> -- 
> Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
> 
>
One of them is
http://gcc.gnu.org/ml/gcc-patches/2003-01/msg00019.html

--Sanjiv