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 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#147544

On 03/11/2019 16:31, David Brown wrote:
> On 03/11/2019 00:47, Bart wrote:

>> I'm pointing out that my 500x bigger gcc installation has exactly same 
>> problem.
>>
> 
> The emphasis being on "my" here - other people have gcc installations 
> without that problem.  You seem to have a special talent for getting 
> this kind of thing wrong and mixed up, but I believe it is mainly due to 
> determined effort on your part.
> 
>>> Earlier today, I installed MinGW-w64.  "%zu" worked correctly.
>>> If you don't care why, I certainly don't.

One hack I saw on the internet involves defining this macro before stdio.h:

     #define __USE_MINGW_ANSI_STDIO  1
     #include <stdio.h>

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

With that, then gcc-compiled code recognises %zu (the macro redirects 
printf to mingw_printf or something).

But the fact that such a workaround is necessary, suggests it was a real 
problem that needed a fix, and not due to my incompetence. I don't know 
why it works out of the box for other people's installations, but they 
haven't posted actual programs with actual gcc invocations with actual 
details of their versions, for me to compare.

Note that the fix doesn't work with tcc (or my bcc). Neither will it 
work with existing, unmodified code that uses %zu. (Although it can be 
put as a -D option in a makefile, that counts as a modification.)

So it is not a viable solution. Even if my gcc magically worked, now 
that I know it can very easily not work for other people, I would not 
rely on "%zu" in an application.

And I know it wouldn't work with tcc. (I write/generate C code that is 
tested across gcc, tcc and bcc, so "%zu" wouldn't pass.)

>> I tell gcc - and its bundled headers, assembler, linkers and what-not 
>> - that I want to call printf("%zu",sizeof(T)), it's its job to make it 
>> work.
>>
> 
> I suggest you complain to your vendor and demand your money back.

So the software is free; it's still not my job to fix it. If I 
distributed a library with my compiler that supported %zu, I would not 
go out of my way to make sure my compiler avoids using that library so 
as to create the maximum hassle for the user.

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

#147545

On Saturday, November 2, 2019 at 2:04:47 PM UTC+2, 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.
> 
> 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>

Actually, last time I looked, Microsoft's library used by Mingw-64 was also hopelessly outdated. Something like 6 y.o. That's enough to get %z working, but not enough for few other things.
It seems, the simplest (or the only) method to get relatively recent Microsoft's library is to use relatively recent (2015 or later) Microsoft's tools.
Which are free, available, but VERY bloated.
But, then again, so is gcc under MINGW-64, but somewhat less.
As to clang under MINGW-64, it's the same order of bloat as Microsoft's tools.

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

#147554

already5chosen@yahoo.com writes:
[...]
> Actually, last time I looked, Microsoft's library used by Mingw-64 was
> also hopelessly outdated. Something like 6 y.o. That's enough to get
> %z working, but not enough for few other things.  It seems, the
> simplest (or the only) method to get relatively recent Microsoft's
> library is to use relatively recent (2015 or later) Microsoft's tools.
> Which are free, available, but VERY bloated.  But, then again, so is
> gcc under MINGW-64, but somewhat less.  As to clang under MINGW-64,
> it's the same order of bloat as Microsoft's tools.

Does installing MinGW-w64 install a C library if one isn't already
present?

On my system, when I installed MinGW-w64 I had already installed
the free (as in beer) version of Visual Studio 2019.  I think it
used that C library, which is why "%zu" worked for me.

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

#147559

On Sunday, November 3, 2019 at 10:32:17 PM UTC+2, Keith Thompson wrote:
> already5chosen@yahoo.com writes:
> [...]
> > Actually, last time I looked, Microsoft's library used by Mingw-64 was
> > also hopelessly outdated. Something like 6 y.o. That's enough to get
> > %z working, but not enough for few other things.  It seems, the
> > simplest (or the only) method to get relatively recent Microsoft's
> > library is to use relatively recent (2015 or later) Microsoft's tools.
> > Which are free, available, but VERY bloated.  But, then again, so is
> > gcc under MINGW-64, but somewhat less.  As to clang under MINGW-64,
> > it's the same order of bloat as Microsoft's tools.
> 
> Does installing MinGW-w64 install a C library if one isn't already
> present?
> 
> On my system, when I installed MinGW-w64 I had already installed
> the free (as in beer) version of Visual Studio 2019.  I think it
> used that C library, which is why "%zu" worked for me.
> 
> -- 
> 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 */

It depends:
https://msdn.microsoft.com/en-us/ie/aa297182(v=vs.100)

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

#147560

On Monday, November 4, 2019 at 1:00:07 AM UTC+2, already...@yahoo.com wrote:
> On Sunday, November 3, 2019 at 10:32:17 PM UTC+2, Keith Thompson wrote:
> > already5chosen@yahoo.com writes:
> > [...]
> > > Actually, last time I looked, Microsoft's library used by Mingw-64 was
> > > also hopelessly outdated. Something like 6 y.o. That's enough to get
> > > %z working, but not enough for few other things.  It seems, the
> > > simplest (or the only) method to get relatively recent Microsoft's
> > > library is to use relatively recent (2015 or later) Microsoft's tools.
> > > Which are free, available, but VERY bloated.  But, then again, so is
> > > gcc under MINGW-64, but somewhat less.  As to clang under MINGW-64,
> > > it's the same order of bloat as Microsoft's tools.
> > 
> > Does installing MinGW-w64 install a C library if one isn't already
> > present?
> > 
> > On my system, when I installed MinGW-w64 I had already installed
> > the free (as in beer) version of Visual Studio 2019.  I think it
> > used that C library, which is why "%zu" worked for me.
> > 
> > -- 
> > 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 */
> 
> It depends:
> https://msdn.microsoft.com/en-us/ie/aa297182(v=vs.100)

Well, on the system that I am sitting now it does not depend.
On this version of mingw64 gcc and clang are linking to version of MSCRT that is older than VS2015. Those old versions all have different names for DLLs so they are not affected by installation of VS2015 or newer.
Since VS2015 it works differently.

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

#147563

On Monday, November 4, 2019 at 1:19:56 AM UTC+2, already...@yahoo.com wrote:
> On Monday, November 4, 2019 at 1:00:07 AM UTC+2, already...@yahoo.com wrote:
> > On Sunday, November 3, 2019 at 10:32:17 PM UTC+2, Keith Thompson wrote:
> > > already5chosen@yahoo.com writes:
> > > [...]
> > > > Actually, last time I looked, Microsoft's library used by Mingw-64 was
> > > > also hopelessly outdated. Something like 6 y.o. That's enough to get
> > > > %z working, but not enough for few other things.  It seems, the
> > > > simplest (or the only) method to get relatively recent Microsoft's
> > > > library is to use relatively recent (2015 or later) Microsoft's tools.
> > > > Which are free, available, but VERY bloated.  But, then again, so is
> > > > gcc under MINGW-64, but somewhat less.  As to clang under MINGW-64,
> > > > it's the same order of bloat as Microsoft's tools.
> > > 
> > > Does installing MinGW-w64 install a C library if one isn't already
> > > present?
> > > 
> > > On my system, when I installed MinGW-w64 I had already installed
> > > the free (as in beer) version of Visual Studio 2019.  I think it
> > > used that C library, which is why "%zu" worked for me.
> > > 
> > > -- 
> > > 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 */
> > 
> > It depends:
> > https://msdn.microsoft.com/en-us/ie/aa297182(v=vs.100)
> 
> Well, on the system that I am sitting now it does not depend.
> On this version of mingw64 gcc and clang are linking to version of MSCRT that is older than VS2015. Those old versions all have different names for DLLs so they are not affected by installation of VS2015 or newer.
> Since VS2015 it works differently.

Newer libraries (i.e. UCRT) are supposed to work with the latest version of MINGW-64, but as far as I can see, they do not work.
Nothing about UCRT support is documented except in wondrously complicated post of Martin Storsjö:
https://sourceforge.net/p/mingw-w64/mailman/message/36621319/

I'd guess there exist people capable to understand what he wanted to say, but I am certainly not among them.

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

#147505

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".
> 
> Using "%d" can appear to work depending on how arguments are passed, but
> it's unreliable.


%d can be unreliable for reporting the sizeof(datatype)?

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

#147508

On 02/11/2019 16: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".
>>
>> Using "%d" can appear to work depending on how arguments are passed, but
>> it's unreliable.
> 
> 
> %d can be unreliable for reporting the sizeof(datatype)?
> 

%d is for "int".  "%zu" is for size_t.  If you are on a platform (like 
Windows) where "int" and "size_t" are the same size, and easily 
converted back and forth, and your value fits in either "int" or 
"size_t", then you can expect "%d" to work for the size_t value.  On 
other platforms, it might not.

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

#147451

On Fri, 1 Nov 2019 08:49:49 -0400, DFS <nospam@dfs.com> 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);

a is 7.  You copy 7 bytes.  If a pointer to char is 4 bytes on your
system, you copy the first pointer plus 3 bytes of the second.

>>      memcpy(z+a, y, b);

z is an array of char*.  z+a evaluates the same a &z[a].  If a pointer
to char is four bytes on your system, this evaluates to the address of
the 28th byte after the start of z.  Since z points to an allocation
of only 12 bytes, this points beyond the bounds of your allocated
memory and you now have undefined behavior.

>> }
>> 
>> 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);

You have not allocated enough memory.  j is 7; k is 5.  You allocate
12 bytes.  If a pointer to char is 4 bytes on your system, you need at
least 48 bytes to hold the 12 pointers.

The argument to malloc should be sizeof x + sizeof y	

>         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++]);

Since z[0] is the only element of z containing a valid pointer, all
subsequent iterations of the loop produce undefined behavior.

>>      free(z);

On many systems, trying to free allocated memory after you have
modified memory beyond the allocation causes fatal errors.

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

-- 
Remove del for email

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

#147459

On 11/1/2019 9:39 AM, Barry Schwarz wrote:
> On Fri, 1 Nov 2019 08:49:49 -0400, DFS <nospam@dfs.com> 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);
> 
> a is 7.  You copy 7 bytes.  If a pointer to char is 4 bytes on your
> system, you copy the first pointer plus 3 bytes of the second.
> 
>>>       memcpy(z+a, y, b);
> 
> z is an array of char*.  z+a evaluates the same a &z[a].  If a pointer
> to char is four bytes on your system, this evaluates to the address of
> the 28th byte after the start of z.  Since z points to an allocation
> of only 12 bytes, this points beyond the bounds of your allocated
> memory and you now have undefined behavior.
> 
>>> }
>>>
>>> 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);
> 
> You have not allocated enough memory.  j is 7; k is 5.  You allocate
> 12 bytes.  If a pointer to char is 4 bytes on your system, you need at
> least 48 bytes to hold the 12 pointers.
> 
> The argument to malloc should be sizeof x + sizeof y	

char **z  = malloc(sizeof j  + sizeof k);
char **z  = malloc(sizeof(j) + sizeof(k));

Neither work on my system (tcc on Windows)

this does, though:
char **z  = malloc(sizeof(char*) * (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++]);
> 
> Since z[0] is the only element of z containing a valid pointer, all
> subsequent iterations of the loop produce undefined behavior.
> 
>>>       free(z);
> 
> On many systems, trying to free allocated memory after you have
> modified memory beyond the allocation causes fatal errors.

Gotcha.

Thanks

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

#147483

On Fri, 1 Nov 2019 09:56:00 -0400, DFS <nospam@dfs.com> wrote:

>On 11/1/2019 9:39 AM, Barry Schwarz wrote:
>> On Fri, 1 Nov 2019 08:49:49 -0400, DFS <nospam@dfs.com> 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);
>> 
>> a is 7.  You copy 7 bytes.  If a pointer to char is 4 bytes on your
>> system, you copy the first pointer plus 3 bytes of the second.
>> 
>>>>       memcpy(z+a, y, b);
>> 
>> z is an array of char*.  z+a evaluates the same a &z[a].  If a pointer
>> to char is four bytes on your system, this evaluates to the address of
>> the 28th byte after the start of z.  Since z points to an allocation
>> of only 12 bytes, this points beyond the bounds of your allocated
>> memory and you now have undefined behavior.
>> 
>>>> }
>>>>
>>>> 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);
>> 
>> You have not allocated enough memory.  j is 7; k is 5.  You allocate
>> 12 bytes.  If a pointer to char is 4 bytes on your system, you need at
>> least 48 bytes to hold the 12 pointers.
>> 
>> The argument to malloc should be sizeof x + sizeof y	
>
>char **z  = malloc(sizeof j  + sizeof k);
>char **z  = malloc(sizeof(j) + sizeof(k));
>
>Neither work on my system (tcc on Windows)

Since both j and k have type int (and are 4 probably bytes each), why
would you think allocating 8 bytes is any better than 12?  Why didn't
you try what I wrote?

>this does, though:
>char **z  = malloc(sizeof(char*) * (j+k));

Since sizeof x is exactly equal to sizeof(char*)*j (similarly for
sizeof y), your expression is numerically equal to the one I
suggested.

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

Until you change the third argument in your calls to memcpy (or change
the values of the first two arguments in your call to combinearrays,
your array z will not contain all the values from x and y and the
following printf will still cause undefined behavior

>>>>       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++]);
>> 
>> Since z[0] is the only element of z containing a valid pointer, all
>> subsequent iterations of the loop produce undefined behavior.
>> 
>>>>       free(z);
>> 
>> On many systems, trying to free allocated memory after you have
>> modified memory beyond the allocation causes fatal errors.
>
>Gotcha.
>
>Thanks

-- 
Remove del for email

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

#147457

On Friday, 1 November 2019 12:50:40 UTC, 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);
> >      memcpy(z+a, y, b);

memcpy(z,   x, a * sizeof x[0]);
memcpy(z+a, y, b * sizeof y[0]);

> > }
> > 
> > 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);

char **z = malloc((j+k) * sizeof *z);

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

memcpy() and malloc() deal with byte-counts, not array-element counts.

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

#147484

Il 01/11/2019 13:49, DFS ha scritto:
> 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
> 
> 
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

void combinearrays(int a, int b, char *x[], char *y[], char *z[]) {
     memcpy(z,   x, a * sizeof(char *)); /*  <= add size of element */
     memcpy(z+a, y, b * sizeof(char *)); /*  <= add size of element */
}

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]);
     int i; /* <= declare i */

     char **z = malloc((j + k) * sizeof(char *)); /*  <= add size of 
element */

     combinearrays(j, k, x, y, z);

     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);
}
----------------------------------
adf1 fg7 Dxx eff Mnn opp zaa
A c p S x
adf1 fg7 Dxx eff Mnn opp zaa A c p S x

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

#147450

> ====================================================================
> #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);
> }
> =========================================================================

Better use a superior language:

#include <vector>
#include <iostream>

using namespace std;
int main()
{
     vector<string> x = { "adf1", "fg7", "Dxx", "eff", "Mnn", "opp", 
"zaa" };
     vector<string> y = { "A", "c", "p", "S", "x" };
     vector<string> z;
     z.reserve( x.size() + y.size() );
     z.insert( z.end(), x.begin(), x.end() );
     z.insert( z.end(), y.begin(), y.end() );
     auto vstringFlush = []( vector<string> &vs )
     {
         for( string &s : vs )
             cout << s << " ";
         cout << endl;
     };
     vstringFlush( x );
     vstringFlush( y );
     vstringFlush( z );
}

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

#147474

Autist <autist69@gmail.com> writes:
[...]
> Better use a superior language:
>
> #include <vector>
> #include <iostream>
[...]

This is comp.lang.c.  If you want to discuss C++, there's
comp.lang.c++ -- where they're no more likely to tolerate your
unexplained removal of attribution lines than we are.

Speaking of which -- *PLONK*.

(If you're not familiar with the term, that means I'm adding you
to my killfile.)

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

#147485

On 01/11/2019 13:26, Autist wrote:
>> ====================================================================
>> #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);
>> }
>> =========================================================================
> 
> Better use a superior language:
> 
> #include <vector>
> #include <iostream>
> 
> using namespace std;
> int main()
> {
>      vector<string> x = { "adf1", "fg7", "Dxx", "eff", "Mnn", "opp", 
> "zaa" };
>      vector<string> y = { "A", "c", "p", "S", "x" };
>      vector<string> z;
>      z.reserve( x.size() + y.size() );
>      z.insert( z.end(), x.begin(), x.end() );
>      z.insert( z.end(), y.begin(), y.end() );
>      auto vstringFlush = []( vector<string> &vs )
>      {
>          for( string &s : vs )
>              cout << s << " ";
>          cout << endl;
>      };
>      vstringFlush( x );
>      vstringFlush( y );
>      vstringFlush( z );
> }

This looks heavy-handed even for C++. If the job is to simply 
concatenate two arrays, then a script solution is trivial:

      x := ("adf1", "fg7", "Dxx", "eff", "Mnn", "opp", "zaa")
      y := ( "A", "c", "p", "S", "x" )
      z := x concat y

      println x
      println y
      println z

Output is:

     (adf1,fg7,Dxx,eff,Mnn,opp,zaa)
     (A,c,p,S,x)
     (adf1,fg7,Dxx,eff,Mnn,opp,zaa,A,c,p,S,x)

This is what a static language above the level of C should be aiming at 
(and I think the vector class can do some or all of that).

As for the C code, it's mixing arrays and pointers is always a a bit of 
a nightmare, but this code seems to do the same (note that the strings 
in z will share memory with x and y; this is a detail the script version 
will take care of).

----------------------------------------------------
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define LEN(x) (sizeof(x)/sizeof(x[0]))

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

void printvector(char **A, int n) {
     while (n>0) {
         printf("%s ",*A);
         ++A; --n;
     }
     puts("");
}

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

     char **z = malloc((LEN(x)+LEN(y))*sizeof(char*));

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

     printvector(x,LEN(x));
     printvector(y,LEN(y));
     printvector(z,LEN(x)+LEN(y));
}

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

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

#147489

> This looks heavy-handed even for C++.

On one side there's much code generated from that. But on the other
side the sourcode itself is rather simple for someone who is halfway
familiar with C++11.

> This is what a static language above the level of C should be aiming
> at  (and I think the vector class can do some or all of that).

I wanted to give an example in language that has the lowlevel-properties
of C as well as a lot of high-level-properties and so could be an alter-
native to C. Scripting-languages are a totally different issue for pur-
poses with small or no overlap to C or C++.

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

#147452

On 11/1/19 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"};

I assume that these strings are all so small just because this is an
example. However, if that's not the case - if all of the strings in the
real code are less than MAX_STRING_SIZE, for some value of
MAX_STRING_SIZE that is relatively small - then unless you have some
other reason for preferring to use anarray of pointers, it might be more
efficient to use

    char [][MAX_STRING_SIZE+1] x =
        {"adf1","fg7","Dxx","eff","Mnn","opp","zaa"};

with corresponding changes to the rest of your code.

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

#147453

> I assume that these strings are all so small just because this is an
> example. However, if that's not the case - if all of the strings in the
> real code are less than MAX_STRING_SIZE, for some value of
> MAX_STRING_SIZE that is relatively small - then unless you have some
> other reason for preferring to use anarray of pointers, it might be more
> efficient to use
>      char [][MAX_STRING_SIZE+1] x =
>          {"adf1","fg7","Dxx","eff","Mnn","opp","zaa"};

Looks both cool and disgusting.

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

#147456

On 11/1/19 9:42 AM, Autist wrote:
> 
>> I assume that these strings are all so small just because this is an
>> example. However, if that's not the case - if all of the strings in the
>> real code are less than MAX_STRING_SIZE, for some value of
>> MAX_STRING_SIZE that is relatively small - then unless you have some
>> other reason for preferring to use anarray of pointers, it might be more
>> efficient to use
>>      char [][MAX_STRING_SIZE+1] x =
>>          {"adf1","fg7","Dxx","eff","Mnn","opp","zaa"};
> 
> Looks both cool and disgusting.

I can't imagine what the aesthetic judgments are that make you feel that
it is either cool or disgusting, but I don't really care, either.

All I care about is whether it works (and, in certain contexts, it can),
and how efficient it is (and, in certain contexts, if MAX_STRING_SIZE is
small enough, it can be significantly more efficient than an array of
pointers). That would be particularly likely to be true if
MAX_STRING_SIZE < sizeof(char*), which is unlikely to be the case here,
given that "adf1" is one of his example strings.

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

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

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

csiph-web