Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #147447 > unrolled thread

memcpy not memcpying?

Back to article view | Back to comp.lang.c

Contents

  memcpy not memcpying? DFS <nospam@dfs.com> - 2019-11-01 08:42 -0400
    Re: memcpy not memcpying? DFS <nospam@dfs.com> - 2019-11-01 08:49 -0400
      Re: memcpy not memcpying? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-01 09:24 -0400
        Re: memcpy not memcpying? DFS <nospam@dfs.com> - 2019-11-01 09:46 -0400
          Re: memcpy not memcpying? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-01 09:49 -0400
          Re: memcpy not memcpying? Keith Thompson <kst-u@mib.org> - 2019-11-01 10:19 -0700
            Re: memcpy not memcpying? David Brown <david.brown@hesbynett.no> - 2019-11-01 21:14 +0100
            Re: memcpy not memcpying? DFS <nospam@dfs.com> - 2019-11-01 17:16 -0400
              Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-01 22:42 +0000
                Re: memcpy not memcpying? Richard Damon <Richard@Damon-Family.org> - 2019-11-01 21:10 -0400
                  Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-02 11:36 +0000
              Re: memcpy not memcpying? Keith Thompson <kst-u@mib.org> - 2019-11-02 02:15 -0700
              Re: memcpy not memcpying? David Brown <david.brown@hesbynett.no> - 2019-11-02 13:04 +0100
                Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-02 13:43 +0000
                  Re: memcpy not memcpying? David Brown <david.brown@hesbynett.no> - 2019-11-02 17:24 +0100
                    Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-02 17:00 +0000
                      Re: memcpy not memcpying? Keith Thompson <kst-u@mib.org> - 2019-11-02 13:06 -0700
                        Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-02 21:05 +0000
                          Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-02 22:40 +0000
                          Re: memcpy not memcpying? Keith Thompson <kst-u@mib.org> - 2019-11-02 15:59 -0700
                            Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-02 23:47 +0000
                              Re: memcpy not memcpying? Keith Thompson <kst-u@mib.org> - 2019-11-02 18:22 -0700
                                Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-03 13:27 +0000
                                  Re: memcpy not memcpying? David Brown <david.brown@hesbynett.no> - 2019-11-03 17:46 +0100
                                    Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-03 17:20 +0000
                                      Re: memcpy not memcpying? Manfred <noname@add.invalid> - 2019-11-03 19:44 +0100
                                        Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-03 19:36 +0000
                                          Re: memcpy not memcpying? Manfred <noname@add.invalid> - 2019-11-03 22:57 +0100
                                          Re: memcpy not memcpying? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-03 22:39 +0000
                                      Re: memcpy not memcpying? David Brown <david.brown@hesbynett.no> - 2019-11-03 23:06 +0100
                                        Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-03 23:28 +0000
                                          Re: memcpy not memcpying? David Brown <david.brown@hesbynett.no> - 2019-11-04 11:00 +0100
                                            Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-04 11:14 +0000
                                            Re: memcpy not memcpying? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-04 11:22 +0000
                                              Re: memcpy not memcpying? David Brown <david.brown@hesbynett.no> - 2019-11-04 13:10 +0100
                                              Re: memcpy not memcpying? Keith Thompson <kst-u@mib.org> - 2019-11-04 10:03 -0800
                                                Re: memcpy not memcpying? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-04 19:36 +0000
                                                  Re: memcpy not memcpying? Keith Thompson <kst-u@mib.org> - 2019-11-05 10:04 -0800
                                                Re: memcpy not memcpying? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-04 20:58 -0800
                                              Re: memcpy not memcpying? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-04 22:01 -0800
                                            Re: memcpy not memcpying? Autist <autist69@gmail.com> - 2019-11-04 12:56 +0100
                                              Re: memcpy not memcpying? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-04 09:50 -0500
                                                Re: memcpy not memcpying? scott@slp53.sl.home (Scott Lurndal) - 2019-11-04 20:26 +0000
                                            Re: memcpy not memcpying? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-04 04:34 -0800
                                              Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-04 13:05 +0000
                                                Re: memcpy not memcpying? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-04 14:09 +0000
                                                  Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-04 15:11 +0000
                                                    Re: memcpy not memcpying? Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-04 15:15 +0000
                                                    Re: memcpy not memcpying? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-04 15:43 +0000
                                    Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-03 20:20 +0000
                              Re: memcpy not memcpying? Ian Collins <ian-news@hotmail.com> - 2019-11-03 14:37 +1300
                                Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-03 11:01 +0000
                                  Re: memcpy not memcpying? Öö Tiib <ootiib@hot.ee> - 2019-11-03 04:03 -0800
                                    Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-03 12:52 +0000
                                      Re: memcpy not memcpying? Öö Tiib <ootiib@hot.ee> - 2019-11-03 23:34 -0800
                                        Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-04 09:36 +0000
                                          Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-04 16:20 +0000
                                  Re: memcpy not memcpying? Ian Collins <ian-news@hotmail.com> - 2019-11-04 07:46 +1300
                                    Re: memcpy not memcpying? Keith Thompson <kst-u@mib.org> - 2019-11-03 12:26 -0800
                              Re: memcpy not memcpying? David Brown <david.brown@hesbynett.no> - 2019-11-03 17:31 +0100
                                Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-03 17:05 +0000
                Re: memcpy not memcpying? already5chosen@yahoo.com - 2019-11-03 09:14 -0800
                  Re: memcpy not memcpying? Keith Thompson <kst-u@mib.org> - 2019-11-03 12:32 -0800
                    Re: memcpy not memcpying? already5chosen@yahoo.com - 2019-11-03 14:59 -0800
                      Re: memcpy not memcpying? already5chosen@yahoo.com - 2019-11-03 15:19 -0800
                        Re: memcpy not memcpying? already5chosen@yahoo.com - 2019-11-03 17:00 -0800
            Re: memcpy not memcpying? DFS <nospam@dfs.com> - 2019-11-02 11:16 -0400
              Re: memcpy not memcpying? David Brown <david.brown@hesbynett.no> - 2019-11-02 17:26 +0100
      Re: memcpy not memcpying? Barry Schwarz <schwarzb@delq.com> - 2019-11-01 06:39 -0700
        Re: memcpy not memcpying? DFS <nospam@dfs.com> - 2019-11-01 09:56 -0400
          Re: memcpy not memcpying? Barry Schwarz <schwarzb@delq.com> - 2019-11-01 12:39 -0700
      Re: memcpy not memcpying? guinness.tony@gmail.com - 2019-11-01 06:49 -0700
      Re: memcpy not memcpying? jak <nospam@please.ty> - 2019-11-01 20:40 +0100
    Re: memcpy not memcpying? Autist <autist69@gmail.com> - 2019-11-01 14:26 +0100
      Re: memcpy not memcpying? Keith Thompson <kst-u@mib.org> - 2019-11-01 10:22 -0700
      Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-01 19:44 +0000
        Re: memcpy not memcpying? Autist <autist69@gmail.com> - 2019-11-01 21:31 +0100
    Re: memcpy not memcpying? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-01 09:39 -0400
      Re: memcpy not memcpying? Autist <autist69@gmail.com> - 2019-11-01 14:42 +0100
        Re: memcpy not memcpying? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-01 09:48 -0400
    Re: memcpy not memcpying? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-01 06:47 -0700
      Re: memcpy not memcpying? Autist <autist69@gmail.com> - 2019-11-01 14:58 +0100
        Re: memcpy not memcpying? DFS <nospam@dfs.com> - 2019-11-01 10:22 -0400
          Re: memcpy not memcpying? Autist <autist69@gmail.com> - 2019-11-01 18:38 +0100
            Re: memcpy not memcpying? scott@slp53.sl.home (Scott Lurndal) - 2019-11-01 17:54 +0000
              Re: memcpy not memcpying? Autist <autist69@gmail.com> - 2019-11-01 20:24 +0100
            Re: memcpy not memcpying? DFS <nospam@dfs.com> - 2019-11-01 15:24 -0400
          Re: memcpy not memcpying? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-01 23:19 +0000

Page 1 of 5  [1] 2 3 4 5  Next page →

#147447 — memcpy not memcpying?

Just trying to combine 2 arrays:
====================================================================
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int i = 0;

void combinearrays(int a, int b, char *x[], char *y[], char *z[]) {
	memcpy(z,   x, a);
	memcpy(z+a, y, b);
}	

int main(int argc, char *argv[]) {
	char *x[] = {"adf1","fg7","Dxx","eff","Mnn","opp","zaa"};
	char *y[] = {"A","c","p","S","x"};
	int j = sizeof(x)/sizeof(x[0]);
	int k = sizeof(y)/sizeof(y[0]);

         char **z = malloc(j+k);
	
	i=0;
	while (i<j)   printf("%s ",x[i++]);
	printf("\n");
	
	i=0;
	while (i<k)   printf("%s ",y[i++]);
	printf("\n");
	
	i=0;
	while (i<j+k) printf("%s ",z[i++]);
	
	free(z);
	exit(0);
}
=========================================================================

$combineXY
adf1 fg7 Dxx eff Mnn opp zaa
A c p S x

  a   ÇnP

[toc] | [next] | [standalone]

#147448

On 11/1/2019 8:42 AM, DFS wrote:
> Just trying to combine 2 arrays:
> ====================================================================
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> 
> int i = 0;
> 
> void combinearrays(int a, int b, char *x[], char *y[], char *z[]) {
>      memcpy(z,   x, a);
>      memcpy(z+a, y, b);
> }
> 
> int main(int argc, char *argv[]) {
>      char *x[] = {"adf1","fg7","Dxx","eff","Mnn","opp","zaa"};
>      char *y[] = {"A","c","p","S","x"};
>      int j = sizeof(x)/sizeof(x[0]);
>      int k = sizeof(y)/sizeof(y[0]);
> 
>          char **z = malloc(j+k);

         combinearrays(j,k,x,y,z);   //forgot this line


>      i=0;
>      while (i<j)   printf("%s ",x[i++]);
>      printf("\n");
> 
>      i=0;
>      while (i<k)   printf("%s ",y[i++]);
>      printf("\n");
> 
>      i=0;
>      while (i<j+k) printf("%s ",z[i++]);
> 
>      free(z);
>      exit(0);
> }
> =========================================================================
> 
> $combineXY
> adf1 fg7 Dxx eff Mnn opp zaa
> A c p S x
> 
>   a   ÇnP

adf1 fg7 Dxx eff Mnn opp zaa
A c p S x
adf1 Çn

[toc] | [prev] | [next] | [standalone]

#147449

On 11/1/19 8:49 AM, DFS wrote:
> On 11/1/2019 8:42 AM, DFS wrote:
>> Just trying to combine 2 arrays:
>> ====================================================================
>> #include <stdio.h>
>> #include <stdlib.h>
>> #include <string.h>
>>
>> int i = 0;
>>
>> void combinearrays(int a, int b, char *x[], char *y[], char *z[]) {
>>      memcpy(z,   x, a);

It would appear from context that you intend to copy a elements from the
array x to the array z. The third element of memcpy() indicates how many
bytes to copy, not the number of elements to copy. What is the element
type of those arrays? Do you have any particular reason to think that
the size of that type is 1?

>>      memcpy(z+a, y, b);
>> }
>>
>> int main(int argc, char *argv[]) {
>>      char *x[] = {"adf1","fg7","Dxx","eff","Mnn","opp","zaa"};
>>      char *y[] = {"A","c","p","S","x"};
>>      int j = sizeof(x)/sizeof(x[0]);
>>      int k = sizeof(y)/sizeof(y[0]);
>>
>>          char **z = malloc(j+k);
> 
>          combinearrays(j,k,x,y,z);   //forgot this line

On a typical modern implementation of C, sizeof(char*) is often 4, so
I'll use that value in the following explanation.
At this point, j should have a value of 7, while k should have a value of 5.

Therefore, your first memcpy() call copies the first 7 bytes of x into
z. That would copy x[0] into z[0], and the first three bytes of x[1]
into z[1]. The last byte of z[1], and all of the bytes of z[2], z[3],
z[4], z[5] and z[6] would remain uninitialized.

The second memcpy() call copies the first 5 bytes of y into z, starting
at z+7. That would copy y[0] into z[7], and the first byte of y[1] into
z[8]. The remaining 3 bytes of z[8], and all of the bytes of z[9],
z[10], and z[11] are uninitialized.

>>      i=0;
>>      while (i<j)   printf("%s ",x[i++]);
>>      printf("\n");
>>
>>      i=0;
>>      while (i<k)   printf("%s ",y[i++]);
>>      printf("\n");
>>
>>      i=0;

As a result of those uninitialized bytes, z[1] isn't even required to
contain a valid pointer value, and the behavior of z[i++] is therefore
undefined as soon as i==1.

>>      while (i<j+k) printf("%s ",z[i++]);
>>
>>      free(z);
>>      exit(0);
>> }
...
> adf1 fg7 Dxx eff Mnn opp zaa
> A c p S x
> adf1 Çn

[toc] | [prev] | [next] | [standalone]

#147454

On 11/1/2019 9:24 AM, James Kuyper wrote:
> On 11/1/19 8:49 AM, DFS wrote:
>> On 11/1/2019 8:42 AM, DFS wrote:
>>> Just trying to combine 2 arrays:
>>> ====================================================================
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>> #include <string.h>
>>>
>>> int i = 0;
>>>
>>> void combinearrays(int a, int b, char *x[], char *y[], char *z[]) {
>>>       memcpy(z,   x, a);
> 
> It would appear from context that you intend to copy a elements from the
> array x to the array z. The third element of memcpy() indicates how many
> bytes to copy, not the number of elements to copy. What is the element
> type of those arrays? Do you have any particular reason to think that
> the size of that type is 1?

Keith Thompson (clc): "Because sizeof (char) is 1 by definition."


but I see:
printf("%d\n",sizeof(char*));
8	



updated the commands and it works.

memcpy(z,   x, sizeof(char*) * a);
memcpy(z+a, y, sizeof(char*) * b);


Thanks James!

[toc] | [prev] | [next] | [standalone]

#147458

On 11/1/19 9:46 AM, DFS wrote:
> On 11/1/2019 9:24 AM, James Kuyper wrote:
>> On 11/1/19 8:49 AM, DFS wrote:
>>> On 11/1/2019 8:42 AM, DFS wrote:
>>>> Just trying to combine 2 arrays:
>>>> ====================================================================
>>>> #include <stdio.h>
>>>> #include <stdlib.h>
>>>> #include <string.h>
>>>>
>>>> int i = 0;
>>>>
>>>> void combinearrays(int a, int b, char *x[], char *y[], char *z[]) {
>>>>       memcpy(z,   x, a);
>>
>> It would appear from context that you intend to copy a elements from the
>> array x to the array z. The third element of memcpy() indicates how many
>> bytes to copy, not the number of elements to copy. What is the element
>> type of those arrays? Do you have any particular reason to think that
>> the size of that type is 1?
> 
> Keith Thompson (clc): "Because sizeof (char) is 1 by definition."
> 
> 
> but I see:
> printf("%d\n",sizeof(char*));
> 8

Yes - oddly enough, char and char* are different types, with typically
different sizes.

[toc] | [prev] | [next] | [standalone]

#147473

DFS <nospam@dfs.com> writes:
[...]
> printf("%d\n",sizeof(char*));
> 8	

sizeof yields a result of type size_t.  Use "%zu", not "%d".

Using "%d" can appear to work depending on how arguments are passed, but
it's unreliable.

If remembering all the formats is too much trouble (it is for me
sometimes), you can convert to a type that you know how to print
and that you're confident is wide enough to hold the value:

    printf("%lu\n", (unsigned long)sizeof(char*));

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#147487

On 01/11/2019 18:19, Keith Thompson wrote:
> DFS <nospam@dfs.com> writes:
> [...]
>> printf("%d\n",sizeof(char*));
>> 8	
> 
> sizeof yields a result of type size_t.  Use "%zu", not "%d".
> 
> Using "%d" can appear to work depending on how arguments are passed, but
> it's unreliable.
> 
> If remembering all the formats is too much trouble (it is for me
> sometimes), you can convert to a type that you know how to print
> and that you're confident is wide enough to hold the value:
> 
>      printf("%lu\n", (unsigned long)sizeof(char*));
> 

Or in this case, since you can be reasonably sure pointers don't take 
over 2 GB of memory (or even 32 KB, for portability to 16-bit systems), 
you can use:

	printf("%d\n", (int) sizeof(char *));

DFS - since you are using gcc, and have previously shown that you use 
-Wall, it should give you a warning when the printf format does not 
match the parameters.  Pay attention to the warning, and get in the 
habit of getting the parameter types correct.  Whether you fix the 
format characters or cast the parameters can depend a bit on how 
portable the code should be and how lazy you are feeling, but you will 
at least learn how you should do it when it matters.

[toc] | [prev] | [next] | [standalone]

#147492

On 11/1/2019 1:19 PM, Keith Thompson wrote:
> DFS <nospam@dfs.com> writes:
> [...]
>> printf("%d\n",sizeof(char*));
>> 8	
> 
> sizeof yields a result of type size_t.  Use "%zu", not "%d".


tcc 0.9.26 Windows

printf("%zu\n",sizeof(char*));
zu

printf("%d\n",sizeof(char*));
8

printf("%lu\n",sizeof(char*));
8

printf("%llu\n",sizeof(char*));
8

printf("%f\n",sizeof(char*));
0.000000

printf("%s\n",sizeof(char*));
(*.exe has stopped working)




> Using "%d" can appear to work depending on how arguments are passed, but
> it's unreliable.
> 
> If remembering all the formats is too much trouble (it is for me
> sometimes), you can convert to a type that you know how to print
> and that you're confident is wide enough to hold the value:
> 
>      printf("%lu\n", (unsigned long)sizeof(char*));


https://codeforwin.org/2015/05/list-of-all-format-specifiers-in-c-programming.html

[toc] | [prev] | [next] | [standalone]

#147493

On 01/11/2019 21:16, DFS wrote:
> On 11/1/2019 1:19 PM, Keith Thompson wrote:
>> DFS <nospam@dfs.com> writes:
>> [...]
>>> printf("%d\n",sizeof(char*));
>>> 8
>>
>> sizeof yields a result of type size_t.  Use "%zu", not "%d".
> 
> 
> tcc 0.9.26 Windows
> 
> printf("%zu\n",sizeof(char*));
> zu
> 
> printf("%d\n",sizeof(char*));
> 8
> 
> printf("%lu\n",sizeof(char*));
> 8
> 
> printf("%llu\n",sizeof(char*));
> 8
> 
> printf("%f\n",sizeof(char*));
> 0.000000
> 
> printf("%s\n",sizeof(char*));
> (*.exe has stopped working)
> 

Some Windows C libraries don't support %zu.

It looks like you have a 64-bit system where size_t is unsigned 64 bits, 
which is most likely the same as unsigned long long. Then a suitable 
format code would be %llu. But %lld will also work (provided the size of 
a type is under 9e18 bytes).

And probably also %u and %d, since on a 64-bit system, each parameter 
will always occupy a 64-bit slot, provided the size is under 2**32 or 2**31.

For portable code, care needs to be taken, but it doesn't matter too 
much for small, short-lived programs.

[toc] | [prev] | [next] | [standalone]

#147496

On 11/1/19 6:42 PM, Bart wrote:
> On 01/11/2019 21:16, DFS wrote:
>> On 11/1/2019 1:19 PM, Keith Thompson wrote:
>>> DFS <nospam@dfs.com> writes:
>>> [...]
>>>> printf("%d\n",sizeof(char*));
>>>> 8
>>>
>>> sizeof yields a result of type size_t.  Use "%zu", not "%d".
>>
>>
>> tcc 0.9.26 Windows
>>
>> printf("%zu\n",sizeof(char*));
>> zu
>>
>> printf("%d\n",sizeof(char*));
>> 8
>>
>> printf("%lu\n",sizeof(char*));
>> 8
>>
>> printf("%llu\n",sizeof(char*));
>> 8
>>
>> printf("%f\n",sizeof(char*));
>> 0.000000
>>
>> printf("%s\n",sizeof(char*));
>> (*.exe has stopped working)
>>
> 
> Some Windows C libraries don't support %zu.
> 
> It looks like you have a 64-bit system where size_t is unsigned 64 bits,
> which is most likely the same as unsigned long long. Then a suitable
> format code would be %llu. But %lld will also work (provided the size of
> a type is under 9e18 bytes).
> 
> And probably also %u and %d, since on a 64-bit system, each parameter
> will always occupy a 64-bit slot, provided the size is under 2**32 or
> 2**31.
> 
> For portable code, care needs to be taken, but it doesn't matter too
> much for small, short-lived programs.
> 

For Windows 64 bit, my memory is that
size_t == unsigned long long == 64 bit
long == 32 bit
int == 32 bit

so the sizeof is putting 64 bits off parameters but printf is only
taking 32, but since the machine is little endian, the extra data is
effectively ignored since there is only one parameter. If a second
parameter was used in the formatting, it would possibly cause problems,
unless the Windows ABI is forcing all parameters to be 64 bit wide for
alignment needs (I don't know that level of detail for it)

%d 'works' where you should be using %u since the processor is 2s
complement and doesn't do anything funny with representations.

%f is just looking at the bit pattern 0x0000000000000008 as a floating
point value, which will be seen as a very small denormal value, which
will round down to 0.

%s looks at location 8 in the address space for the string, which likely
causes a fault.

[toc] | [prev] | [next] | [standalone]

#147499

On 02/11/2019 01:10, Richard Damon wrote:
> On 11/1/19 6:42 PM, Bart wrote:

>> And probably also %u and %d, since on a 64-bit system, each parameter
>> will always occupy a 64-bit slot, provided the size is under 2**32 or
>> 2**31.
>>
>> For portable code, care needs to be taken, but it doesn't matter too
>> much for small, short-lived programs.
>>
> 
> For Windows 64 bit, my memory is that
> size_t == unsigned long long == 64 bit
> long == 32 bit
> int == 32 bit
> 
> so the sizeof is putting 64 bits off parameters but printf is only
> taking 32, but since the machine is little endian, the extra data is
> effectively ignored since there is only one parameter. If a second
> parameter was used in the formatting, it would possibly cause problems,
> unless the Windows ABI is forcing all parameters to be 64 bit wide for
> alignment needs (I don't know that level of detail for it)

Yes, each parameter occupies either a 64-bit register or stack entry as 
I said. Each %d will consume the bottom half of one such slot, and the 
next %d will use the bottom half of the next.

But %d is also likely to work on a 32-bit system system since size_t is 
probably 32 bits there.

(My own compiler still has the fix where you just write %? and it fills 
in the correct format that -printf functions expect; %llu in this case. 
Silly idea IMO to introduce weird formats such as %zu for one-off types, 
which are poorly supported anyway.)

[toc] | [prev] | [next] | [standalone]

#147498

DFS <nospam@dfs.com> writes:
> On 11/1/2019 1:19 PM, Keith Thompson wrote:
>> DFS <nospam@dfs.com> writes:
>> [...]
>>> printf("%d\n",sizeof(char*));
>>> 8	
>> 
>> sizeof yields a result of type size_t.  Use "%zu", not "%d".
>
> tcc 0.9.26 Windows
>
> printf("%zu\n",sizeof(char*));
> zu

Yes, if you have a pre-C99 implementation "%zu" might not work.
(tcc is a compiler; it doesn't include a runtime library.
It's probably using Microsoft's C library.)

> printf("%d\n",sizeof(char*));
> 8
> 
> printf("%lu\n",sizeof(char*));
> 8
>
> printf("%llu\n",sizeof(char*));
> 8

All those can work, but none of them are reliable.

> printf("%f\n",sizeof(char*));
> 0.000000
>
> printf("%s\n",sizeof(char*));
> (*.exe has stopped working)

"8", "0.000000", and "... has stopped working" are all possible
instances of undefined behavior.

> https://codeforwin.org/2015/05/list-of-all-format-specifiers-in-c-programming.html

Not a great source of information.  For example, all it says about
"%n" is that it prints nothing -- which is true, but not the point.
(It takes a pointer argument and stores the number of characters
printed so far in the object it points to.  Some C libraries don't
support "%n" because it's considered unsafe.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#147500

On 01/11/2019 22:16, DFS wrote:
> On 11/1/2019 1:19 PM, Keith Thompson wrote:
>> DFS <nospam@dfs.com> writes:
>> [...]
>>> printf("%d\n",sizeof(char*));
>>> 8
>>
>> sizeof yields a result of type size_t.  Use "%zu", not "%d".
> 
> 
> tcc 0.9.26 Windows
> 

That's your problem.  Tcc is a compiler, not a full C implementation - 
it uses MS's hopelessly outdated and inefficient C library DLL.

Get Mingw-64.  It is a full gcc-based toolchain, including a solid C 
library.  It is the normal compiler for msys2.

<http://mingw-w64.org/doku.php>

[toc] | [prev] | [next] | [standalone]

#147501

On 02/11/2019 12:04, David Brown wrote:
> On 01/11/2019 22:16, DFS wrote:
>> On 11/1/2019 1:19 PM, Keith Thompson wrote:
>>> DFS <nospam@dfs.com> writes:
>>> [...]
>>>> printf("%d\n",sizeof(char*));
>>>> 8
>>>
>>> sizeof yields a result of type size_t.  Use "%zu", not "%d".
>>
>>
>> tcc 0.9.26 Windows
>>
> 
> That's your problem.  Tcc is a compiler, not a full C implementation - 
> it uses MS's hopelessly outdated and inefficient C library DLL.

So does gcc:

    C:\c>type c.c
    #include <stdio.h>
    int main(void) {printf("%zu",sizeof(int));}

    C:\c>gcc c.c

    C:\c>a
    zu
    C:\c>gcc --version
    gcc (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0


 > it uses MS's hopelessly outdated and inefficient C library DLL.

Relying on a gimmick such as "%zu" just to print a number is what is 
hopelessly outdated.

[toc] | [prev] | [next] | [standalone]

#147507

On 02/11/2019 14:43, Bart wrote:
> On 02/11/2019 12:04, David Brown wrote:
>> On 01/11/2019 22:16, DFS wrote:
>>> On 11/1/2019 1:19 PM, Keith Thompson wrote:
>>>> DFS <nospam@dfs.com> writes:
>>>> [...]
>>>>> printf("%d\n",sizeof(char*));
>>>>> 8
>>>>
>>>> sizeof yields a result of type size_t.  Use "%zu", not "%d".
>>>
>>>
>>> tcc 0.9.26 Windows
>>>
>>
>> That's your problem.  Tcc is a compiler, not a full C implementation - 
>> it uses MS's hopelessly outdated and inefficient C library DLL.
> 
> So does gcc:

gcc is a compiler - it needs a library.  tcc is a build of gcc for 
Windows, which relies on MS's piss-poor C library.  The solution is to 
get a /decent/ C implementation for Windows - including a good compiler 
and a good library.  My recommendation is mingw64, which consists of gcc 
/and/ a good library.

You /know/ all this.  Why do you continually muddy the waters and 
attempt to confuse people?

> 
> 
>  > it uses MS's hopelessly outdated and inefficient C library DLL.
> 
> Relying on a gimmick such as "%zu" just to print a number is what is 
> hopelessly outdated.

That is the way printf works.  You don't have to like it, but it is not 
a "gimmick".  And no, neither "size_t" nor "%zu" is poorly supported. 
It is merely MS's C library that is poor.  (I think this was intentional 
from MS's viewpoint - their preference is for Windows developer to use 
Windows-specific tools and languages like C# rather than standard ones.)

[toc] | [prev] | [next] | [standalone]

#147509

On 02/11/2019 16:24, David Brown wrote:
> On 02/11/2019 14:43, Bart wrote:
>> On 02/11/2019 12:04, David Brown wrote:

>>> That's your problem.  Tcc is a compiler, not a full C implementation 
>>> - it uses MS's hopelessly outdated and inefficient C library DLL.
>>
>> So does gcc:
> 
> gcc is a compiler - it needs a library.  tcc is a build of gcc for 
> Windows, which relies on MS's piss-poor C library.  The solution is to 
> get a /decent/ C implementation for Windows - including a good compiler 
> and a good library.  My recommendation is mingw64, which consists of gcc 
> /and/ a good library.
> 
> You /know/ all this.  Why do you continually muddy the waters and 
> attempt to confuse people?

gcc, gnu, mingw, whatever the whole thing is supposed to be called, is a 
monstrosity.

My gcc/tdm installation consists of 666MB of 13,000 files including 900 
lib*.a files, and yet it hasn't bothered to include an up-to-date C 
runtime? It doesn't make sense does it.

Well, OK, let's download this mingw64 (which I thought I already had). 
It describes itself as a "complete runtime environment for gcc to 
support binaries", yet the 450MB, also 13,000-file installation 
confusingly also includes compilers such as gcc.exe and g++.exe. (So is 
it a runtime environment, or a C implementation, or can't it make its 
mind up?)

Anyway I might as well use them. This is the result (after hiding the 
directories of my tdm version) on a modified hello.c:

    C:\mingw\mingw64\bin>type hello.c
     #include <stdio.h>

     int main(void) {
         printf("%zu\n",sizeof(int*));
     }

    C:\mingw\mingw64\bin>gcc hello.c

    C:\mingw\mingw64\bin>a
    zu

Brilliant! So it looks like someone really has to do battle to get this 
%zu thing working.

(Remember we are just printing the value of a u64 number. Some people 
just do want to get drawn in to this entire gnu/gcc/mingw/msys thing; 
they just want to write programs and do things like print numbers.)

-----------------------------------

(This is how it can be done; first let's look at the TWO files involved:

C:\c>dir \windows\system32\msvcrt.dll
16/12/2011  08:46           634,880 msvcrt.dll

C:\c>dir \m\bcc.exe
19/10/2019  23:37           523,776 bcc.exe

Now let's run that first program again, but with a tweak:

    C:\c>type c.c
     #include <stdio.h>
     int main(void) {printf("%?",sizeof(int*));}

    C:\c>bcc c
    Compiling c.c to c.exe

    C:\c>c
    8

See how easy it can be? And this is still using that 'out-dated' 
library! Better yet, how to do it without using printfs at all:

     println ref int.bytes)


> That is the way printf works.  You don't have to like it, but it is not 
> a "gimmick".

The gimmick, or 'hack' which is a better word, is to introduce a 
dedicated format code for a very specific type, which then requires all 
libraries in the world to be revised. Even though there is nothing 
special about that type

[toc] | [prev] | [next] | [standalone]

#147513

Bart <bc@freeuk.com> writes:
> On 02/11/2019 16:24, David Brown wrote:
>> On 02/11/2019 14:43, Bart wrote:
>>> On 02/11/2019 12:04, David Brown wrote:
>>>> That's your problem.  Tcc is a compiler, not a full C implementation 
>>>> - it uses MS's hopelessly outdated and inefficient C library DLL.
>>>
>>> So does gcc:
>> 
>> gcc is a compiler - it needs a library.  tcc is a build of gcc for 
>> Windows, which relies on MS's piss-poor C library.  The solution is to 
>> get a /decent/ C implementation for Windows - including a good compiler 
>> and a good library.  My recommendation is mingw64, which consists of gcc 
>> /and/ a good library.
>> 
>> You /know/ all this.  Why do you continually muddy the waters and 
>> attempt to confuse people?
>
> gcc, gnu, mingw, whatever the whole thing is supposed to be called, is a 
> monstrosity.
>
> My gcc/tdm installation consists of 666MB of 13,000 files including 900 
> lib*.a files, and yet it hasn't bothered to include an up-to-date C 
> runtime? It doesn't make sense does it.

TDM is apparently based on MinGW, an implementation that uses the gcc
compiler and the Microsoft C runtime library.  No, it hasn't bothered to
include an up-to-date C runtime, preferring for whatever reason to use
the existing Microsoft C runtime.  Its failure to support "%zu" has
nothing to do with gcc.  Of course you know that, but you deliberately
refuse to acknowledge it.

> Well, OK, let's download this mingw64 (which I thought I already had). 
> It describes itself as a "complete runtime environment for gcc to 
> support binaries", yet the 450MB, also 13,000-file installation 
> confusingly also includes compilers such as gcc.exe and g++.exe. (So is 
> it a runtime environment, or a C implementation, or can't it make its 
> mind up?)

https://sourceforge.net/projects/mingw-w64/ says

    The mingw-w64 project is a complete runtime environment for
    gcc to support binaries native to Windows 64-bit and 32-bit
    operating systems.

Perhaps "runtime environment" isn't the best description.  It is,
as you know perfectly well, a C implementation that includes a
compiler, a (non-Microsoft) runtime library, and other components.
(Some of those components probably aren't part of what the standard
calls a C implementation.)

Naturally you seize on a single poorly worded description so you
can spread confusion.

Yes the old MinGW's use of the Microsoft C library is a problem.
That problem was corrected by the introduction of MinGW-w64.
(I'm not entirely sure to what extent MinGW-w64 is, or is intended
to be, a replacement for MinGW.)

But since the old MinGW still exists, you still have something to
complain about.

> Anyway I might as well use them. This is the result (after hiding the 
> directories of my tdm version) on a modified hello.c:
>
>     C:\mingw\mingw64\bin>type hello.c
>      #include <stdio.h>
>
>      int main(void) {
>          printf("%zu\n",sizeof(int*));
>      }
>
>     C:\mingw\mingw64\bin>gcc hello.c
>
>     C:\mingw\mingw64\bin>a
>     zu
>
> Brilliant! So it looks like someone really has to do battle to get this 
> %zu thing working.

I don't know why it doesn't work for you.  My guess is that either
you're not using the gcc provided by MinGW-w64, or you've managed
to use it along with the Microsoft runtime library.  It does work
for me.  What does "gcc --version" print?

Normally I'd suggest that you ask for help resolving the issue,
but I'm sure that would be futile.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#147517

On 02/11/2019 20:06, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:


> TDM is apparently based on MinGW, an implementation that uses the gcc
> compiler and the Microsoft C runtime library.  No, it hasn't bothered to
> include an up-to-date C runtime, preferring for whatever reason to use
> the existing Microsoft C runtime.  Its failure to support "%zu" has
> nothing to do with gcc.

What is it to do with then? I must have download a dozen versions of gcc 
over the years, %zu has never worked. And I have no idea what version of 
a C runtime should be used, how many versions there might be, how you 
check the version, where to get them from, or how you tell the compiler 
to use a specific version.

You'd think a 0.67GB language installation, whose job is to convert C 
files into executables, would take care of such details.

Note that lccwin /does/ support %zu, and that's just by installing 
lccwin. What's the equivalent /single/ thing that you have to do for 
.... you know, I don't even know what to call that thing. gcc is not the 
right term, neither is gnu, maybe it's mingw...?

Very poor user-friendliness on that compiler-thing. And a very poor 
'identity'. Compare 'pelles c', 'dmc', 'lccwin', even my 'bcc', which 
are well-defined products in what they do, and what they include.

('tcc' would be classed with those but it's trying to turn itself into a 
gcc clone, so on Linux it copies the same nonsense of requiring -lm and 
generating a.out.)

> Perhaps "runtime environment" isn't the best description.  It is,
> as you know perfectly well,


Actually, no I don't. People have gone to great pains here in the past 
to explain the difference between C compilers, standard header files, 
necessary utilities such as assemblers and linkers, and standard 
libraries, and that obtaining a C compiler need not imply that you will 
get anything else necessary to turn C source to an executable that will 
properly deal with "%zu".


> Naturally you seize on a single poorly worded description so you
> can spread confusion.

I /am/ confused. The description can be SO much better:

"This mingw64 download includes the gcc compiler, a set of standard 
include files, its own C library, the 'as' assembler needed by gcc, the 
'ld' linker, and a make utility"

Or not, as the case may be. (There is, for example, something called 
'mingw32-make.exe'; is that make? I really don't know.)



> Yes the old MinGW's use of the Microsoft C library is a problem.
> That problem was corrected by the introduction of MinGW-w64.
> (I'm not entirely sure to what extent MinGW-w64 is, or is intended
> to be, a replacement for MinGW.)

You would think that a 660MB download of gcc version 8.1.0, which is 
reasonably recent, would have included new libraries.

> I don't know why it doesn't work for you.  My guess is that either
> you're not using the gcc provided by MinGW-w64, or you've managed
> to use it along with the Microsoft runtime library.  It does work
> for me.  What does "gcc --version" print?

It shows:

gcc (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0

downloaded today. And as I said, I hide the tdm version, but which was 
also 8.1.0 anyway.

> Normally I'd suggest that you ask for help resolving the issue,

I don't want to resolve it because I don't care. gcc (gnu, mingw-W64 
whatever) is just too complex, THAT is the problem. Sorting out one 
tiny, tiny aspect (%zu support on one installation) will not fix that.

I just don't use %zu. The alternatives will work anywhere.

But I do wonder who came up with the idea of "%zu" for size_t, which 
requires these changes to decades-old *printf routines, while the 
equivalents for int64_t etc have to make do with those PRi64d macros.

[toc] | [prev] | [next] | [standalone]

#147518

On 02/11/2019 21:05, Bart wrote:
> On 02/11/2019 20:06, Keith Thompson wrote:

> I just don't use %zu. The alternatives will work anywhere.

Including, most importantly, for anyone else working with C on Windows 
who also hasn't succeeded in getting a gcc installation that supports %zu.

/My/ managing to do so, even after jumping through the requisite loops, 
doesn't mean everyone else will have done too. I don't want an 
application of mine to fail on such a narrow dependency that can easily 
be avoided.

[toc] | [prev] | [next] | [standalone]

#147519

Bart <bc@freeuk.com> writes:
> On 02/11/2019 20:06, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> TDM is apparently based on MinGW, an implementation that uses the gcc
>> compiler and the Microsoft C runtime library.  No, it hasn't bothered to
>> include an up-to-date C runtime, preferring for whatever reason to use
>> the existing Microsoft C runtime.  Its failure to support "%zu" has
>> nothing to do with gcc.
>
[21 lines deleted]
>
>> Perhaps "runtime environment" isn't the best description.  It is,
>> as you know perfectly well,
>
> Actually, no I don't. People have gone to great pains here in the past 
> to explain the difference between C compilers, standard header files, 
> necessary utilities such as assemblers and linkers, and standard 
> libraries, and that obtaining a C compiler need not imply that you will 
> get anything else necessary to turn C source to an executable that will 
> properly deal with "%zu".

A *compiler* doesn't implement "%zu".  A *library* does.  An
implementation includes a compiler, a library, and some other
components.

Some implementations (like lcc-win) are packaged with a tightly
integrated compiler and library, neither of which is intended to be used
separately.  Others (such as the common gcc/glibc implementation on
Linux-based system, or clang/glibc, or gcc/newlib, etc.) are put
together from separately developed components -- and sometimes the
integration is imperfect.

>> Naturally you seize on a single poorly worded description so you
>> can spread confusion.
>
> I /am/ confused. The description can be SO much better:
>
> "This mingw64 download includes the gcc compiler, a set of standard 
> include files, its own C library, the 'as' assembler needed by gcc, the 
> 'ld' linker, and a make utility"

That appears to be a correct description.  And yet you claim to be
confused.

> Or not, as the case may be. (There is, for example, something called 
> 'mingw32-make.exe'; is that make? I really don't know.)

Yes.  I just installed it, and running it with the "--version" option
prints
    GNU Make 4.2.1
    Built for x86_64-w64-mingw32
    ...

>> Yes the old MinGW's use of the Microsoft C library is a problem.
>> That problem was corrected by the introduction of MinGW-w64.
>> (I'm not entirely sure to what extent MinGW-w64 is, or is intended
>> to be, a replacement for MinGW.)
>
> You would think that a 660MB download of gcc version 8.1.0, which is 
> reasonably recent, would have included new libraries.
>
>> I don't know why it doesn't work for you.  My guess is that either
>> you're not using the gcc provided by MinGW-w64, or you've managed
>> to use it along with the Microsoft runtime library.  It does work
>> for me.  What does "gcc --version" print?
>
> It shows:
>
> gcc (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0
>
> downloaded today. And as I said, I hide the tdm version, but which was 
> also 8.1.0 anyway.

OK, that appears to be the right version of gcc.  Again, I don't know
why you're having problems.

>> Normally I'd suggest that you ask for help resolving the issue,
>
> I don't want to resolve it because I don't care.

Excellent.

>                                                  gcc (gnu, mingw-W64 
> whatever) is just too complex, THAT is the problem. Sorting out one 
> tiny, tiny aspect (%zu support on one installation) will not fix that.

And yet you continue to whine about it.  Have fun with that.

Earlier today, I installed MinGW-w64.  "%zu" worked correctly.
If you don't care why, I certainly don't.

> But I do wonder who came up with the idea of "%zu" for size_t, which 
> requires these changes to decades-old *printf routines, while the 
> equivalents for int64_t etc have to make do with those PRi64d macros.

That's actually not a bad question.  Since you asked, I'll pretend
that you care about the answer.  You probably don't, but others
might.

size_t, ptrdiff_t, and the [u]intN_t types declared in <stdint.h>
are all integer types, almost certainly typedefs for predefined
types chosen in an implementation-defined manner.  The C90 version
of printf didn't support formats for types other than the predefined
ones.

According to the C99 Rationale:
    <inttypes.h> was derived from the header of the same name found
    on several existing 64-bit systems. The Committee debated other
    methods for specifying integer sizes and other characteristics,
    but in the end decided to standardize existing practice rather
    than innovate in this area. (See also §7.18 <stdint.h>.)

<inttypes.h> defines a number of integer types and macros for *printf
and *scanf format conversions.  The Rationale doesn't mention the latter
-- nor does it mention the j, z, and t length modifiers (for
[u]intmax_t, size_t, and ptrdiff_t, respectively) that were also added
in C99.

The type size_t and ptrdiff_t already existed C90, but with no clean way
to print them.  Adding just three new length modifiers to support them
and [u]intmax_t seems like a minor burden.  The *printf and *scanf
functions has to be modified anyway, to support long long and a few
other enhancements added in C99.  I presume "%zu" was an invention of
the committee.

<stdint.h> defines a large number of integer types.  Defining printf and
scanf formats for *all* of them would, I think, have been an undue
burden.  The burden on library implementers would have been minor, but
defining the syntax in the tiny language of format strings and expecting
programmers to learn all the details would have been more difficult.

Sure, C99 *could* have defined macros for size_t, ptrdiff_t, and
[u]intmax_t formats similar to the ones defined for [u]intN_t et al.
That would have been more uniform, but IMHO less convenient.  I
personally *like* being able to write "%zu" to print a size_t value,
without having to include a header that defines a macro that expands to
whatever format would be used for whichever type size_t is defined as.
And the macros defined in <stdint.h> (which I personally find ugly, but
I don't know a good way to de-uglify them) were apparently invented
outside the standard process, and incorporated into C99.

If you expect C to be completely consistent, you're going to be
disappointed.  But in this particular case, I think the tradeoff (new
modifiers for a handful of types, macros for the rest) is a perfectly
reasonable one.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web