(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

Re: Register Spilling

[Naveen Sharma, Noida]

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

This was the last post.
http://gcc.gnu.org/ml/gcc-patches/2003-01/msg02567.html

Do let me know if you are interesred to use this. This has
not been checked in the mainline. For patches like this
to go into mainline, they should be tested for atleast 5 gcc 
targets. I couldn't do that. But I can help, if you are 
interested.

Best Regards,
Naveen Sharma.

Re: Register Spilling

[Hans-Peter Nilsson]

On Thu, 11 Dec 2003, Naveen Sharma, Noida wrote:
> This was the last post.
> http://gcc.gnu.org/ml/gcc-patches/2003-01/msg02567.html
>
> Do let me know if you are interesred to use this.

(FWIW, I am.)

> This has
> not been checked in the mainline. For patches like this
> to go into mainline, they should be tested for atleast 5 gcc
> targets. I couldn't do that.

Yes you can: <URL:http://gcc.gnu.org/simtest-howto.html> tells
you how.

Certainly many of the target listed fail to build, but you
should be able to find five even without including your host
computer.  Last I checked, arm-elf, m32r-elf, mips-elf,
mn10300-elf, v850-elf and sh-elf worked (perhaps others do, but
I don't test all the listed ones).  Oh, you can test using MMIX
too; put Knuth's simulator named "mmix", linked from
<URL:http://www-cs-faculty.stanford.edu/~knuth/mmix-news.html>
somewhere in your PATH, use --target_board=mmixware-sim.

brgds, H-P

Re: Register Spilling

[Naveen Sharma, Noida]

> On Thu, 11 Dec 2003, Naveen Sharma, Noida wrote:
>> This was the last post.
>> http://gcc.gnu.org/ml/gcc-patches/2003-01/msg02567.html
>>
>> Do let me know if you are interesred to use this.
> 
> (FWIW, I am.)
> 
>> This has
>> not been checked in the mainline. For patches like this
>> to go into mainline, they should be tested for atleast 5 gcc
>> targets. I couldn't do that.
> 
>Yes you can: <URL:http://gcc.gnu.org/simtest-howto.html> tells
>you how.

Thanks, I knew this but for an optimization patch, we 
need to prove that it actually improves (or doesn't degrade) 
code for (N >= 5) targets. This IMHO requires significant effort.
But since there is interest on this, I can do simulator
test with latest version of the patch, but not in a position to 
fix problems except sh-elf.

> Certainly many of the target listed fail to build

This would probably have to be tested on tree-ssa branch now, right?
Let me check what additional problems arise.

Best Regards,
Naveen Sharma.

> should be able to find five even without including your host
> computer.
>   Last I checked, arm-elf, m32r-elf, mips-elf,
> mn10300-elf, v850-elf and sh-elf worked (perhaps others do, but
> I don't test all the listed ones).  Oh, you can test using MMIX
> too; put Knuth's simulator named "mmix", linked from
> <URL:http://www-cs-faculty.stanford.edu/~knuth/mmix-news.html>
> somewhere in your PATH, use --target_board=mmixware-sim.
> 
> brgds, H-P