Re: When parameters to printf are in memory

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Newsgroups	comp.lang.c
Subject	Re: When parameters to printf are in memory
Date	2016-10-04 13:42 +0100
Organization	A noiseless patient Spider
Message-ID	<874m4s2smc.fsf@bsb.me.uk> (permalink)
References	(10 earlier) <nsnqsn$lsj$1@dont-email.me> <87y4285q9a.fsf@bsb.me.uk> <nsvlm7$3r7$1@dont-email.me> <87fuoc33dx.fsf@bsb.me.uk> <nt013r$961$1@dont-email.me>

Show all headers | View raw

BartC <bc@freeuk.com> writes:

> On 04/10/2016 09:49, Ben Bacarisse wrote:
>> James Harris <james.harris.1@gmail.com> writes:
>
>>> It would have been an array where each element was a union. So no
>>> problem with endianness etc.
>>
>> The mechanism that is used to pass a union may not work the for all the
>> types that union might contain.  Take an imaginary example where int are
>> passed by pushing two bytes onto the stack and long by pushing four.
>> The %d format will use the the "next" two bytes and %ld will use the
>> next four.  Passing a union of an int and long will have to push four
>> bytes but whether the "next" two correspond to the short in the union
>> depends on endianness.
>
> union {
>    uint32_t u32;
>    uint64_t u64;
> } u;
>
> Assuming big-endian, then:
>
>   u.u64 = 0x1234_5678;
>
> will result in a 16-bit memory layout of:
>
>   (0x1234, 0x5678)     memory addresses increasing left-to-right
>
> inside the union. And the same layout when pushed onto a stack (when
> it isn't just passed in a register anyway).
>
> For 32 bits, then:
>
>   u.u32 = 0x2016;
>
> will result in the layout (0x2016, 0x????). When pushed (by always
> passing u.u64 rather than the whole union u), the stack layout will
> still have 0x2016 first.

I should have stuck with my first thought -- short and int.  The format
for short (%hd) must assume that the short has been promoted by the
default argument conversions.  That won't happen when the union is
pushed.  That will probably work on a little-endian system, hence by
original remark about that.

> The main problem would be with passing two arguments for "%d %d", then
> passing two ints like this means they are 8 bytes apart rather than
> 4. But it might be workable for a single argument at a time.

Actually the main problem is simply that type is wrong.  I should
probably not have tried to come up with a specific example, because the
problem is more general than any one potential pitfall.  Once you you've
lied the compiler, you are its mercy.

-- 
Ben.

Thread

When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-09-29 16:20 +0100
  Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-09-29 16:43 +0100
    Re: When parameters to printf are in memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-29 20:30 +0100
    Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-09-29 21:23 +0100
    Re: When parameters to printf are in memory BartC <bc@freeuk.com> - 2016-09-29 22:03 +0100
      Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-09-29 22:35 +0100
        Re: When parameters to printf are in memory BartC <bc@freeuk.com> - 2016-09-29 23:11 +0100
          Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-09-30 19:53 +0100
            Re: When parameters to printf are in memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-30 20:53 +0100
              Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-10-01 09:08 +0100
                Re: When parameters to printf are in memory BartC <bc@freeuk.com> - 2016-10-01 11:15 +0100
                Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-10-04 08:32 +0100
                Re: When parameters to printf are in memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-01 11:15 +0100
                Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-10-04 08:28 +0100
                Re: When parameters to printf are in memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-04 09:49 +0100
                Re: When parameters to printf are in memory BartC <bc@freeuk.com> - 2016-10-04 11:43 +0100
                Re: When parameters to printf are in memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-04 13:42 +0100
                Re: When parameters to printf are in memory BartC <bc@freeuk.com> - 2016-10-04 14:03 +0100
                Re: When parameters to printf are in memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-04 14:16 +0100
                Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-10-04 20:01 +0100
                Re: When parameters to printf are in memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-04 20:24 +0100
                Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-10-04 20:40 +0100
                Re: When parameters to printf are in memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-04 22:51 +0100
            Re: When parameters to printf are in memory "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-04 14:25 -0400
              Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-10-04 20:31 +0100
  Re: When parameters to printf are in memory BartC <bc@freeuk.com> - 2016-09-29 17:03 +0100
    Re: When parameters to printf are in memory gazelle@shell.xmission.com (Kenny McCormack) - 2016-09-30 12:20 +0000
      Re: When parameters to printf are in memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-30 05:55 -0700
      Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-09-30 20:06 +0100
        Re: When parameters to printf are in memory gazelle@shell.xmission.com (Kenny McCormack) - 2016-09-30 22:01 +0000
          Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-10-01 09:15 +0100
        Re: When parameters to printf are in memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-30 23:18 -0700
          Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-10-01 09:32 +0100
  Re: When parameters to printf are in memory jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-29 18:35 +0200
    Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-09-29 19:55 +0100
      Re: When parameters to printf are in memory jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-29 21:22 +0200
  Re: When parameters to printf are in memory Barry Schwarz <schwarzb@dqel.com> - 2016-09-29 11:20 -0700
    Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-09-29 20:08 +0100
  Re: When parameters to printf are in memory Lőrinczy Zsigmond <nospam@for.me> - 2016-10-02 20:15 +0200
    Re: When parameters to printf are in memory Lőrinczy Zsigmond <nospam@for.me> - 2016-10-02 20:19 +0200
      Re: When parameters to printf are in memory gazelle@shell.xmission.com (Kenny McCormack) - 2016-10-02 18:29 +0000
        Re: When parameters to printf are in memory Lőrinczy Zsigmond <nospam@for.me> - 2016-10-03 07:04 +0200
          Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-10-04 08:36 +0100
    Re: When parameters to printf are in memory jacobnavia <jacob@jacob.remcomp.fr> - 2016-10-02 21:27 +0200

csiph-web