Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@redhat.com>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: gdb-patches@sourceware.org
Subject: Re: RFC: Relax checking of garbage struct return values
Date: Wed, 12 Oct 2005 17:53:00 -0000	[thread overview]
Message-ID: <vt2k6gisjth.fsf@theseus.home.> (raw)
In-Reply-To: <200510092032.j99KWGYO030371@elgar.sibelius.xs4all.nl> (Mark Kettenis's message of "Sun, 9 Oct 2005 22:32:16 +0200 (CEST)")


Mark Kettenis <mark.kettenis@xs4all.nl> writes:
>> From: Jim Blandy <jimb@redhat.com>
>> Date: Thu, 06 Oct 2005 10:44:29 -0700
>> 
>> The comments are supposed to have the story.  Tested on
>> x86_64-pc-linux-gnu.
>> 
>> 2005-10-05  Jim Blandy  <jimb@redhat.com>
>> 
>> 	* gdb.base/structs.exp (any): New function.
>> 	(test_struct_returns): Don't make any assumptions at all about
>> 	what value the function returns when GDB can't set the return
>> 	value.
>
> I remember having a discussion about this with Andrew some time ago.
> I believe Andrew argued that if the compiler doesn't pass L<n> as the
> buffer, this should be considered a compiler bug.

I don't agree with that at all.

The compiler is free to generate any code it pleases, as long as the
machine code behaves the way the semantics of C require it to.  An
ordinary assignment of one int to another could go through seven
temporaries, get xor'd with 55 twice, pushed on the stack, and then
popped into its destination, and that's correct.  It's just lousy
code.

> Anyway, there is another case where things fail.  Some compilers use a
> "static" buffer to store function values.  On those systems these
> tests fail too.

It's a pretty losing convention, because it isn't reentrant.  But I
know of such a compiler, too.

> I think your patch is ok: gdb is not a compiler testsuite.

Okay --- thanks for the review.


      reply	other threads:[~2005-10-12 17:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-07 20:38 Jim Blandy
2005-10-09 20:30 ` Daniel Jacobowitz
2005-10-09 20:32 ` Mark Kettenis
2005-10-12 17:53   ` Jim Blandy [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=vt2k6gisjth.fsf@theseus.home. \
    --to=jimb@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=mark.kettenis@xs4all.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox