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

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

structs passed by copy

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

Contents

  structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-01-20 10:41 -0800
    Re: structs passed by copy gazelle@shell.xmission.com (Kenny McCormack) - 2023-01-20 19:01 +0000
      Re: structs passed by copy Anton Shepelev <anton.txt@gmail.com> - 2023-01-20 23:01 +0300
        Re: structs passed by copy gazelle@shell.xmission.com (Kenny McCormack) - 2023-01-20 21:28 +0000
          Re: structs passed by copy Kaz Kylheku <864-117-4973@kylheku.com> - 2023-01-21 09:14 +0000
          Re: structs passed by copy Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2023-01-21 10:58 -0700
            Re: structs passed by copy gazelle@shell.xmission.com (Kenny McCormack) - 2023-01-21 18:00 +0000
            Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-21 16:14 -0800
              Re: structs passed by copy James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-01-22 16:00 -0500
                Re: structs passed by copy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-22 13:07 -0800
                Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-22 13:27 -0800
                  Re: structs passed by copy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-22 13:51 -0800
                    Re: structs passed by copy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-22 13:51 -0800
                  Re: structs passed by copy James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-01-22 17:11 -0500
                    Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-22 16:01 -0800
                      Re: structs passed by copy Richard Damon <Richard@Damon-Family.org> - 2023-01-22 21:22 -0500
                      Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-01-23 10:46 +0100
                        Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-23 12:15 -0800
                          Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-01-23 21:47 +0100
                            Re: structs passed by copy Michael S <already5chosen@yahoo.com> - 2023-01-23 13:21 -0800
                              Re: structs passed by copy Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-23 23:49 +0000
                                Re: structs passed by copy Michael S <already5chosen@yahoo.com> - 2023-01-24 02:46 -0800
                                  Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-24 04:18 -0800
                                    Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-24 04:45 -0800
                                      Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-24 04:54 -0800
                                        Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-24 05:26 -0800
                                          Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-24 05:38 -0800
                                            Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-24 05:53 -0800
                                              Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-24 06:20 -0800
                                                Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-24 06:56 -0800
                                                  Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-24 07:17 -0800
                                  Re: structs passed by copy Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-24 12:56 +0000
                                    Re: structs passed by copy Michael S <already5chosen@yahoo.com> - 2023-01-24 07:29 -0800
                      Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-01-23 15:44 -0800
                        Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-23 16:37 -0800
                          Re: structs passed by copy James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-01-23 20:13 -0500
                            Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-23 17:58 -0800
                          Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-01-24 07:53 -0800
                            Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-24 11:14 -0800
                              Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-24 12:02 -0800
                                Re: structs passed by copy Phil Carmody <pc+usenet@asdf.org> - 2023-01-25 10:18 +0200
                                  Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-25 10:53 -0800
                                    Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-01-29 13:30 -0800
                                      Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-29 17:42 -0800
                                        Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-02-17 07:19 -0800
                                          Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-17 09:35 -0800
                                      Re: structs passed by copy John Forkosh <forkosh@panix.com> - 2023-01-30 04:24 +0000
                                        Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-29 21:10 -0800
                                        Re: structs passed by copy Michael S <already5chosen@yahoo.com> - 2023-01-30 13:55 -0800
                                        Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-02-17 05:57 -0800
        Re: structs passed by copy James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-01-21 05:00 -0500
          Re: structs passed by copy Anton Shepelev <anton.txt@gmail.com> - 2023-01-21 23:00 +0300
            Re: structs passed by copy Richard Damon <Richard@Damon-Family.org> - 2023-01-21 17:10 -0500
      Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-01-20 18:12 -0800
      Re: structs passed by copy antispam@math.uni.wroc.pl - 2023-01-21 02:28 +0000
    Re: structs passed by copy Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2023-01-20 14:09 -0500
      Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-20 11:26 -0800
    Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-20 11:22 -0800
    Re: structs passed by copy Bart <bc@freeuk.com> - 2023-01-20 20:16 +0000
      Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-01-20 19:16 -0800
        Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-20 21:08 -0800
        Re: structs passed by copy Bart <bc@freeuk.com> - 2023-01-21 13:30 +0000
          Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-22 10:27 -0800
    Re: structs passed by copy Richard Damon <Richard@Damon-Family.org> - 2023-01-20 21:35 -0500
    Re: structs passed by copy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-20 19:01 -0800
      Re: structs passed by copy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-21 17:01 -0800
    Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-01-21 14:59 +0100
    Re: structs passed by copy Opus <ifonly@youknew.org> - 2023-01-21 19:59 +0100
    Re: structs passed by copy Michael S <already5chosen@yahoo.com> - 2023-01-21 16:55 -0800
      Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-01-22 02:32 -0800
        Re: structs passed by copy Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-22 15:54 +0000
          Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-22 09:17 -0800
            Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-22 09:56 -0800
              Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-22 10:19 -0800
                Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-22 11:01 -0800
                  Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-22 11:08 -0800
                    Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-22 11:17 -0800
                    Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-22 13:27 -0800
          Re: structs passed by copy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-22 13:04 -0800
            Re: structs passed by copy Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-22 21:43 +0000
              Re: structs passed by copy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-22 14:10 -0800
                Re: structs passed by copy Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-22 22:29 +0000
                  Re: structs passed by copy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-22 14:39 -0800
                  Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-01-22 19:06 -0800
                    Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-01-23 10:54 +0100
          Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-01-22 19:00 -0800
            Re: structs passed by copy Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-23 12:14 +0000
    Re: structs passed by copy Jorgen Grahn <grahn+nntp@snipabacken.se> - 2023-02-11 19:35 +0000
      Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-11 15:08 -0800
        Re: structs passed by copy Öö Tiib <ootiib@hot.ee> - 2023-02-11 15:56 -0800
          Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-11 16:32 -0800
            Re: structs passed by copy James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-02-12 01:23 -0500
              Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-02-12 11:24 +0100
                Re: structs passed by copy Vir Campestris <vir.campestris@invalid.invalid> - 2023-02-12 22:11 +0000
                  Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-02-13 10:25 +0100
                    Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-02-13 06:41 -0800
                      Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-02-13 06:50 -0800
                        Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-02-13 17:22 +0100
                          Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-02-13 10:47 -0800
                            Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-02-13 21:50 +0100
                              Re: structs passed by copy bart c <bart4858@gmail.com> - 2023-02-15 17:14 -0800
                                Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-02-16 10:53 +0100
                                  Re: structs passed by copy scott@slp53.sl.home (Scott Lurndal) - 2023-02-16 15:22 +0000
              Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-12 11:04 -0800
            Re: structs passed by copy Öö Tiib <ootiib@hot.ee> - 2023-02-12 12:41 -0800
            Re: structs passed by copy Andrey Tarasevich <andreytarasevich@hotmail.com> - 2023-02-16 22:49 -0800
        Re: structs passed by copy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-02-11 17:49 -0800
        Grammar nitpick (Was: structs passed by copy) gazelle@shell.xmission.com (Kenny McCormack) - 2023-02-12 06:30 +0000
        Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-03-06 09:32 -0800
          Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-06 09:58 -0800
            Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-03-06 11:30 -0800
              Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-06 12:59 -0800
      Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-02-15 01:52 -0800
        Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-02-16 05:20 -0800
          Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-02-16 16:49 +0100
          Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-02-26 08:12 -0800
            Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-02-28 05:38 -0800
              Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-28 14:18 -0800
                Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-03-01 05:02 -0800
                  Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-01 10:23 -0800
                    Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-01 10:42 -0800
                    Re: structs passed by copy bart c <bart4858@gmail.com> - 2023-03-01 15:13 -0800
                      Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-03-02 04:17 -0800
                      Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-03-05 04:17 -0800
                        Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-03-05 04:55 -0800
                    Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-03-02 10:48 +0100
                      Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-03-02 04:07 -0800
                        Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-03-02 15:08 +0100
                          Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-03-02 09:22 -0800
                Re: structs passed by copy gazelle@shell.xmission.com (Kenny McCormack) - 2023-03-01 13:34 +0000
                  Re: structs passed by copy Richard Damon <Richard@Damon-Family.org> - 2023-03-01 21:42 -0500
              Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-03-06 09:36 -0800
    Re: structs passed by copy Maciej Zelma <maciej.projectmanager@gmail.com> - 2023-02-17 14:10 -0800
      Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-17 15:45 -0800
        Re: structs passed by copy scott@slp53.sl.home (Scott Lurndal) - 2023-02-18 00:12 +0000
          Re: structs passed by copy bart c <bart4858@gmail.com> - 2023-02-18 02:33 -0800
      Re: structs passed by copy James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-02-18 00:44 -0500
        Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-17 22:21 -0800
    Re: structs passed by copy Bonita Montero <Bonita.Montero@gmail.com> - 2023-03-01 18:00 +0100
      Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-03-01 09:18 -0800
        Re: structs passed by copy Bonita Montero <Bonita.Montero@gmail.com> - 2023-03-05 14:05 +0100

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

#169285

On Monday, 13 February 2023 at 20:50:21 UTC, David Brown wrote:

> Jumbled random calling conventions is a PITA that plagues Windows 
> development. MS almost managed to eliminate it with x86-64

Which bit did they leave out?

Bear in mind that ABI compliance of generated code is always optional on any platform; it is just a question on whether all the pieces of software involved can agree how to call each other. If any imports are of unknown provenance, or they export to unknown software, then the ABI should be used.

> - no one 
> wants it brought back. On other platforms, ABI's are well specified and 
> everyone sticks to them,

SYS V ABI is a mess compared to Win64 ABI; I wouldn't even know how to stick to it! (Look at the myriad possibilities for dealing with objects that are not 1,2,4,8 bytes in size.)

> meaning that static and dynamic libraries can 
> be mixed and matched, even object files can often be used with different 
> compilers. 

Windows has used DLLs, which allow binaries from different binaries from different languages and compilers to call each other, since 1992 (possibly earlier, but I first encountered them then).

Personally I've eliminated object files, as well as 'archive' and 'lib' formats, from my stuff (I only talk to other software via DLLs). But if you want to write a standard OBJ format on Windows, you use COFF64, which is built on PE+ format that also lays out EXE files.

Not the simplest of formats, but no worse than ELF that I can see.

> I really do not think having multiple different calling conventions ...

It's actually not that big a deal. You simply prefix an imported function declaration with the name of the call convention; job done.

For a decade or so, I used 'windows' or 'clang' prefixes when calling C functions via my FFI. Now I don't bother. However compilers can cope with this easily.

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

#169286

On 16/02/2023 02:14, bart c wrote:
> On Monday, 13 February 2023 at 20:50:21 UTC, David Brown wrote:
> 
>> Jumbled random calling conventions is a PITA that plagues Windows 
>> development. MS almost managed to eliminate it with x86-64
> 

My point - that adding new multiple calling conventions to a C compiler 
is a very bad idea, especially for something that can be trivially 
avoided by using pointer-to-struct parameters instead of struct value 
parameters - seems to have been lost here.


> Which bit did they leave out?


I don't know if they left anything out in Win x86-64, in the calling 
conventions or ABI in general (I don't know the details enough to 
comment).  But they did two things wrong:

1. They made their own calling convention, instead of using the 
established one agreed upon by everyone else in the x86-64 world long 
before x86-64 Windows was established.  I don't know why, but from MS's 
history it is unlikely to be for good technical reasons.  (Credit where 
credit is due - MS has got a lot better at being a team player in more 
recent times.)

2. Having established a single consistent calling convention for 
everything on Win-64, they then made a second one - "vectorcall".  It is 
not as bad as the half-dozen different variants found in 32-bit Windows, 
but this is the main reason I said MS /almost/ managed to eliminate 
multiple calling conventions for Win-64.

> 
> Bear in mind that ABI compliance of generated code is always optional
> on any platform; it is just a question on whether all the pieces of
> software involved can agree how to call each other. If any imports
> are of unknown provenance, or they export to unknown software, then
> the ABI should be used.

Yes.  Internally in a language or tool, you can use anything you want - 
ABI's are for interaction such as exporting or importing functions.  (Of 
course, if you don't have a good reason for using something else, it is 
usually convenient to follow the platform ABI internally as well.)

> 
>> - no one wants it brought back. On other platforms, ABI's are well
>> specified and everyone sticks to them,
> 
> SYS V ABI is a mess compared to Win64 ABI; I wouldn't even know how
> to stick to it! (Look at the myriad possibilities for dealing with
> objects that are not 1,2,4,8 bytes in size.)
> 

Perhaps that is true - though the SYS V ABI documents cover far more 
than just calling conventions.  But it doesn't matter in the big 
picture, as the details of the ABI are primarily only of concern to 
developers of compilers and other related tools.  What matters to 
programmers - who outnumber compiler developers by many orders of 
magnitude and are therefore far more important - is the usage.  I 
realise this works out badly for you personally, as a one-man compiler 
writer, because you have to work through these kinds of documents alone. 
  But in the list of priorities for what is important when making 
something like an ABI standard, the effort needed for compiler 
developers to read and understand the document is /way/ down the list.


>> meaning that static and dynamic libraries can be mixed and matched,
>> even object files can often be used with different compilers.
> 
> Windows has used DLLs, which allow binaries from different binaries
> from different languages and compilers to call each other, since 1992
> (possibly earlier, but I first encountered them then).
> 

Yes - dynamic libraries have been around for a /long/ time (since 
Windows 1.0 in the MS world, but far longer in the mainframe and 
minicomputer world before that).  They work when you have a consistent 
ABI.  (And even in Win32, MS had a set of calling conventions that was 
always used for DLL's.)

> Personally I've eliminated object files, as well as 'archive' and
> 'lib' formats, from my stuff (I only talk to other software via
> DLLs). But if you want to write a standard OBJ format on Windows, you
> use COFF64, which is built on PE+ format that also lays out EXE
> files.
> 

Fair enough.  I think it is reasonable to argue that the traditional 
object file is somewhat outdated as a concept.  For many projects 
(perhaps not monsters like Firefox or LibreOffice), leaving the actual 
code generation until link time can result in noticeably more efficient 
code and many more opportunities for static analysis and error checking.

> Not the simplest of formats, but no worse than ELF that I can see.
> 

ELF is a lot more flexible and capable than COFF as an object file 
format.  That of course means it is complex, but it has a consistent, 
structured and extendable format.  Modern COFF variants suffer from 
different inconsistent extensions added as afterthoughts.  It is not 
surprising that pretty much every other object and executable file 
format has died out - except on Windows.  (Windows extensions to COFF 
did add a fair amount of extra flexibility to the format, and I guess it 
is good enough for Windows needs - so there is no point in changing it.)




>> I really do not think having multiple different calling conventions
>> ...
> 
> It's actually not that big a deal. You simply prefix an imported
> function declaration with the name of the call convention; job done.
> 
> For a decade or so, I used 'windows' or 'clang' prefixes when calling
> C functions via my FFI. Now I don't bother. However compilers can
> cope with this easily.

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

#169289

David Brown <david.brown@hesbynett.no> writes:
>On 16/02/2023 02:14, bart c wrote:
>> On Monday, 13 February 2023 at 20:50:21 UTC, David Brown wrote:

>> 
>> SYS V ABI is a mess compared to Win64 ABI; I wouldn't even know how
>> to stick to it! (Look at the myriad possibilities for dealing with
>> objects that are not 1,2,4,8 bytes in size.)
>> 
>
>Perhaps that is true - though the SYS V ABI documents cover far more 
>than just calling conventions.  

Come now, it's Bart.  The System V ABI for the various processor families
has been a success by any measure.

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

#169248

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 2/11/23 19:32, Keith Thompson wrote:
> ...
>> I wouldn't say there's that much difference between passing by copy and
>> passing by pointer-to-const.  The former does allow the function to
>> modify its copy of the parameter, but in my experience that's not a
>> common requirement.  And the discussion was about parameters, not return
>> values.
>
> It might not be a common requirement, but in my experience the existence
> of such a requirement is, in C, the main reason why I'd use
> pass-by-value rather than a pointer-to-const.
>
>> I can't think of a case where pass-by-copy *can't* be replaced by
>> pass-by-pointer-to-const.  If you need a local modifiable copy, you can
>> make one.  (And again, I'm not suggesting such a replacement *should* be
>> done in any particular case.)
>
> So, you would replace pass-by-copy with pass-by-reference followed by
> copy? I don't see the point. I wouldn't do that for the same reason I
> wouldn't do the following:

No, I wouldn't replace pass-by-copy with pass-by-reference followed by
copy.  I never said I would.

Here's the context that triggered my request for clarification:

    Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
    > On Fri, 2023-01-20, Thiago Adams wrote:
    [...]
    >> Do  you have structs passed by copy in your code?
    >
    > Yes, a lot. I don't write C these days, but last time I got to design
    > new C code, in 2014 or so, I used the feature heavily, to get some
    > properties I'd normally get from C++. I think call by value is one of
    > the great things about the C family of languages.
    >
    >> Could it be replaced by const * ?
    >
    > No.

Jorgen said it *couldn't* be replaced by const *.  I think it could, and
I asked Jorgen to explain what he meant.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

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

#169249

On Sunday, 12 February 2023 at 02:33:07 UTC+2, Keith Thompson wrote:
> Öö Tiib <oot...@hot.ee> writes: 
> > On Sunday, 12 February 2023 at 01:08:24 UTC+2, Keith Thompson wrote: 
> >> Jorgen Grahn <grahn...@snipabacken.se> writes: 
> >> > On Fri, 2023-01-20, Thiago Adams wrote: 
> >> [...] 
> >> >> Do you have structs passed by copy in your code? 
> >> > 
> >> > Yes, a lot. I don't write C these days, but last time I got to design 
> >> > new C code, in 2014 or so, I used the feature heavily, to get some 
> >> > properties I'd normally get from C++. I think call by value is one of 
> >> > the great things about the C family of languages. 
> >> > 
> >> >> Could it be replaced by const * ? 
> >> > 
> >> > No. 
> >> 
> >> Could you expand on that? I would think that any instance of passing a 
> >> struct by copy could be straightforwardly replaced by passing it by 
> >> const*, assuming your able to modify both the caller and the callee. 
> >> I'm not suggesting that this *should* be done, but you seem to be saying 
> >> that it *couldn't*. (I could be a good idea for large structs.) 
> >> 
> > Because the meanings differ heavily. On case of pointer to const parameter 
> > the function says that it needs immutable access to something, possibly 
> > optional and possibly array, (that needs to be further documented). On 
> > case of by value parameter function says that it needs a single non-optional 
> > mutable copy. And returning everything by pointer would make C rather 
> > inconvenient to use ... but that they realised already at 1978.
> I was actually asking Jorgen what *he* meant. 
> 
I do not know what he meant. I only said what I think about difference in
semantics.
> 
> I wouldn't say there's that much difference between passing by copy and 
> passing by pointer-to-const. The former does allow the function to 
> modify its copy of the parameter, but in my experience that's not a 
> common requirement. And the discussion was about parameters, not return 
> values. 
> 
I feel there are 3 main differences that I listed.
> 
> I can't think of a case where pass-by-copy *can't* be replaced by 
> pass-by-pointer-to-const. If you need a local modifiable copy, you can 
> make one. (And again, I'm not suggesting such a replacement *should* be 
> done in any particular case.)
> 
You are right that the hypothetical language that does not have passing
of arguments by value would be possible to transpile to. As passing by
value has different semantic meaning I suspect that only few would
think of that change as progressive.  

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

#169291

On 02/11/23 4:32 PM, Keith Thompson wrote:
> 
> I can't think of a case where pass-by-copy *can't* be replaced by
> pass-by-pointer-to-const.  If you need a local modifiable copy, you can
> make one.  (And again, I'm not suggesting such a replacement *should* be
> done in any particular case.)
> 

In C++'s semantics, when arguments are passed-by-value the parameters 
(i.e. the copies) are actually created in the context of the caller and 
are owned by the caller. In other words, even though the identifier of 
the parameter is local to the function, the actual object that 
identifier refers to belongs to the caller and lives in the caller. This 
was done that way because, among other things, it opens some valuable 
optimization opportunities in expressions with functions that pass and 
return by value. And, of course, C++ specifies this because in C++ this 
is potentially observable (constructors, destructors, exceptions etc.)

If I'm not missing anything, in C it impossible to detect whether a 
passed-by-value copy was created by the caller or by the callee. So, in 
terms of observable behavior passing-by-const-pointer and then making a 
late local copy is equivalent to passing-by-value.

But it is quite possible that at least some optimization opportunities 
(which C++ is after) are also present in C as well. Could it be that C 
was designed with these in mind? (Can't quite remember what they are and 
whether they are C++-specific).

-- 
Best regards,
Andrey

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

#169239

On 2/11/2023 3:08 PM, Keith Thompson wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>> On Fri, 2023-01-20, Thiago Adams wrote:
> [...]
>>> Do  you have structs passed by copy in your code?
>>
>> Yes, a lot. I don't write C these days, but last time I got to design
>> new C code, in 2014 or so, I used the feature heavily, to get some
>> properties I'd normally get from C++. I think call by value is one of
>> the great things about the C family of languages.
>>
>>> Could it be replaced by const * ?
>>
>> No.
> 
> Could you expand on that?  I would think that any instance of passing a
> struct by copy could be straightforwardly replaced by passing it by
> const*, assuming your able to modify both the caller and the callee.
> I'm not suggesting that this *should* be done, but you seem to be saying
> that it *couldn't*.  (I could be a good idea for large structs.)

Take a copy:

void foo(struct foo const* self)
{
     struct foo bar = *self;
}

Sorry for any typos...

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

#169241 — Grammar nitpick (Was: structs passed by copy)

In article <87o7pzdcmj.fsf@nosuchdomain.example.com>,
Keith Thompson  <Keith.S.Thompson+u@gmail.com> wrote:
...
>Could you expand on that?  I would think that any instance of passing a
>struct by copy could be straightforwardly replaced by passing it by
>const*, assuming your able to modify both the caller and the callee.

you're

>I'm not suggesting that this *should* be done, but you seem to be saying
>that it *couldn't*.  (I could be a good idea for large structs.)

(Normally, I wouldn't bother, but we expect better from leader Keith.
Also, I think that a lot of the your/you're/yore and there/their/they're
confusion comes from people dictating stuff into their phones, but I don't
think leader Keith does that; I think he sticks to the old ways of actually
typing stuff in)

-- 
The randomly chosen signature file that would have appeared here is more than 4
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
	http://user.xmission.com/~gazelle/Sigs/Aspergers

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

#169540

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>
>> On Fri, 2023-01-20, Thiago Adams wrote:
>
> [...]
>
>>> Do  you have structs passed by copy in your code?
>>
>> Yes, a lot.  I don't write C these days, but last time I got to design
>> new C code, in 2014 or so, I used the feature heavily, to get some
>> properties I'd normally get from C++.  I think call by value is one of
>> the great things about the C family of languages.
>>
>>> Could it be replaced by const * ?
>>
>> No.
>
> Could you expand on that?  I would think that any instance of passing a
> struct by copy could be straightforwardly replaced by passing it by
> const*, assuming your able to modify both the caller and the callee.
> I'm not suggesting that this *should* be done, but you seem to be saying
> that it *couldn't*.  (I could be a good idea for large structs.)

It *could* be done, but it's clunky for struct arguments that are
not lvalues, as for example a struct returned by a function call,
or a struct that comes out of a ?: expression.

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

#169542

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>>> On Fri, 2023-01-20, Thiago Adams wrote:
>> [...]
>>>> Could it be replaced by const * ?
>>>
>>> No.
>>
>> Could you expand on that?
[...]
>
> It *could* be done,
[...]

I see.

Perhaps next time you could expand on the nuances in your initial reply
rather than waiting a few weeks to explain what you mean.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

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

#169544

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>>>
>>>> On Fri, 2023-01-20, Thiago Adams wrote:
>>>
>>> [...]
>>>
>>>>> Could it be replaced by const * ?
>>>>
>>>> No.
>>>
>>> Could you expand on that?
>
> [...]
>
>> It *could* be done,
>
> [...]
>
> I see.
>
> Perhaps next time you could expand on the nuances in your initial reply
> rather than waiting a few weeks to explain what you mean.

I don't know what you mean.  That was my initial and only
reply to this question.  Might you be confusing me with
another poster?

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

#169546

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>>>>
>>>>> On Fri, 2023-01-20, Thiago Adams wrote:
>>>>
>>>> [...]
>>>>
>>>>>> Could it be replaced by const * ?
>>>>>
>>>>> No.
>>>>
>>>> Could you expand on that?
>>
>> [...]
>>
>>> It *could* be done,
>>
>> [...]
>>
>> I see.
>>
>> Perhaps next time you could expand on the nuances in your initial reply
>> rather than waiting a few weeks to explain what you mean.
>
> I don't know what you mean.  That was my initial and only
> reply to this question.  Might you be confusing me with
> another poster?

You're right, it was someone else.

You replied directly to my question "Could you expand on that?",
and I assumed that you had written the previous message.  My mistake.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

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

#169272

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:

> I think call by value is one of the great things about the C
> family of languages.

+1

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

#169288

On Wednesday, February 15, 2023 at 6:52:51 AM UTC-3, Tim Rentsch wrote:
> Jorgen Grahn <grahn...@snipabacken.se> writes: 
> 
> > I think call by value is one of the great things about the C 
> > family of languages. 
> 
> +1

The idea of passing structs by value is a weak concept because
the struct copy is only "superficial".

struct person {
   char* name;
};

void f(struct person person) {
  person.name[0] = '1';
}

int main() 
{
  char buffer[] = "abc";
  struct person person = { .name = buffer };
  f(person);
  printf("%s", person.name);  //prints  1bc
}

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

#169290

On 16/02/2023 14:20, Thiago Adams wrote:
> On Wednesday, February 15, 2023 at 6:52:51 AM UTC-3, Tim Rentsch wrote:
>> Jorgen Grahn <grahn...@snipabacken.se> writes:
>>
>>> I think call by value is one of the great things about the C
>>> family of languages.
>>
>> +1
> 
> The idea of passing structs by value is a weak concept because
> the struct copy is only "superficial".
> 

"Shallow" is the common term.

If you want something more, C++ is just around the corner.

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

#169384

Thiago Adams <thiago.adams@gmail.com> writes:

> On Wednesday, February 15, 2023 at 6:52:51 AM UTC-3, Tim Rentsch wrote:
>
>> Jorgen Grahn <grahn...@snipabacken.se> writes:
>>
>>> I think call by value is one of the great things about the C
>>> family of languages.
>>
>> +1
>
> The idea of passing structs by value is a weak concept because
> the struct copy is only "superficial".
>
> struct person {
>    char* name;
> };
>
> void f(struct person person) {
>   person.name[0] = '1';
> }
>
> int main()
> {
>   char buffer[] = "abc";
>   struct person person = { .name = buffer };
>   f(person);
>   printf("%s", person.name);  //prints  1bc
> }

This argument even less convincing than saying automatic
transmissions are a bad idea because someone might put the
car in reverse while driving on the freeway.  In short,
idiotic.

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

#169406

On Sunday, February 26, 2023 at 1:12:18 PM UTC-3, Tim Rentsch wrote:
> Thiago Adams <thiago...@gmail.com> writes: 
> 
> > On Wednesday, February 15, 2023 at 6:52:51 AM UTC-3, Tim Rentsch wrote: 
> > 
> >> Jorgen Grahn <grahn...@snipabacken.se> writes: 
> >> 
> >>> I think call by value is one of the great things about the C 
> >>> family of languages. 
> >> 
> >> +1 
> > 
> > The idea of passing structs by value is a weak concept because 
> > the struct copy is only "superficial". 
> > 
> > struct person { 
> > char* name; 
> > }; 
> > 
> > void f(struct person person) { 
> > person.name[0] = '1'; 
> > } 
> > 
> > int main() 
> > { 
> > char buffer[] = "abc"; 
> > struct person person = { .name = buffer }; 
> > f(person); 
> > printf("%s", person.name); //prints 1bc 
> > }
> This argument even less convincing than saying automatic 
> transmissions are a bad idea because someone might put the 
> car in reverse while driving on the freeway. In short, 
> idiotic.

My argument was more about the consistence of the type system
not about security.

Two situations where I can see the C type system is not very strict:

1 - Arrays arguments already "looks like" references.
      So we cannot say all arguments are passed by copy in C.

2 - We also cannot say structs are copied because it is actually a 
    "shallow copy"

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

#169407

Thiago Adams <thiago.adams@gmail.com> writes:
[...]
> 1 - Arrays arguments already "looks like" references.
>       So we cannot say all arguments are passed by copy in C.

Yes, all arguments are passed by copy in C.

Array arguments do not exist.  Something that looks like an array
argument or an array parameter is actually a pointer argument or
parameter, and of course pointers are passed by copy.

The language has some syntactic sugar^H^H^H^H high-fructose corn syrup
that makes it *look* like arrays are being passed by reference.  In
20/20^H^H^H^H^H 2023 hindsight, I wouldn't have designed the language
that way -- but I'm not at all sure what changes I would make if it were
possible.

(Aside: That could be an interesting exercise: design a C-like language
that keeps C's treatment of arrays and pointers without the ugliness of
array parameter adjustment and implicit array-to-pointer conversion.
Hmm.)

> 2 - We also cannot say structs are copied because it is actually a 
>     "shallow copy"

Structs are copied.  A shallow copy is a copy.

It's not at all clear how a deep copy at the language level would even
work.  Say you have a linked list where each node contains a pointer to
its associated data.  Does a deep copy copy all the nodes, or all the
nodes and what they point to?  What if a node points to some huge
recursive data structure?  What if the linked list is circular?  And if
the language specified a deep copy, how would I do a shallow copy if I
wanted one?

C supports deep copies by letting programmers implement them in code, in
accordance with whatever the requirements happen to be.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

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

#169410

On Tuesday, February 28, 2023 at 7:18:22 PM UTC-3, Keith Thompson wrote:
> Thiago Adams <thiago...@gmail.com> writes: 
> [...]
> > 1 - Arrays arguments already "looks like" references. 
> > So we cannot say all arguments are passed by copy in C.
> Yes, all arguments are passed by copy in C. 
> 
> Array arguments do not exist. Something that looks like an array 
> argument or an array parameter is actually a pointer argument or 
> parameter, and of course pointers are passed by copy. 
> 
> The language has some syntactic sugar^H^H^H^H high-fructose corn syrup 
> that makes it *look* like arrays are being passed by reference. In 
> 20/20^H^H^H^H^H 2023 hindsight, I wouldn't have designed the language 
> that way -- but I'm not at all sure what changes I would make if it were 
> possible. 
> 
> (Aside: That could be an interesting exercise: design a C-like language 
> that keeps C's treatment of arrays and pointers without the ugliness of 
> array parameter adjustment and implicit array-to-pointer conversion. 
> Hmm.)

Something that can be done easily in C compilers, is to add warnings for 
some conversions from array to pointers.

For instance:

int a[2];
1 + a;

"1+a" is a valid expression in C. Just like "a + 1" but
I would never write 1 + a in my code, instead I would write &a[1], so for me a 
warning here  is welcome.
"a + 1" is more common but also in this situation I prefer &a[1].

Also:
int f(int a[]){}
f(0);

We can call f(0). No warning here. Of course this reflects
the fact argument a is a pointer. But I think C compilers can
have a warning here. I prefer to consider that arrays in function
arguments are "references" to valid, non null, arrays.

Even sizeof() could be fixed to me, this would not affect my code.
int f(int a[2]){ sizeof(a) }

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

#169414

Thiago Adams <thiago.adams@gmail.com> writes:
> On Tuesday, February 28, 2023 at 7:18:22 PM UTC-3, Keith Thompson wrote:
>> Thiago Adams <thiago...@gmail.com> writes: 
>> [...]
>> > 1 - Arrays arguments already "looks like" references. 
>> > So we cannot say all arguments are passed by copy in C.
>> Yes, all arguments are passed by copy in C. 
>> 
>> Array arguments do not exist. Something that looks like an array 
>> argument or an array parameter is actually a pointer argument or 
>> parameter, and of course pointers are passed by copy. 
>> 
>> The language has some syntactic sugar^H^H^H^H high-fructose corn syrup 
>> that makes it *look* like arrays are being passed by reference. In 
>> 20/20^H^H^H^H^H 2023 hindsight, I wouldn't have designed the language 
>> that way -- but I'm not at all sure what changes I would make if it were 
>> possible. 
>> 
>> (Aside: That could be an interesting exercise: design a C-like language 
>> that keeps C's treatment of arrays and pointers without the ugliness of 
>> array parameter adjustment and implicit array-to-pointer conversion. 
>> Hmm.)
>
> Something that can be done easily in C compilers, is to add warnings for 
> some conversions from array to pointers.
>
> For instance:
>
> int a[2];
> 1 + a;
>
> "1+a" is a valid expression in C. Just like "a + 1" but
> I would never write 1 + a in my code, instead I would write &a[1], so for me a 
> warning here  is welcome.

I'm not sure that writing i + p, where i is an integer and p is a
pointer, is common enough to be worth warning about, but sure, warning
about it would be mostly harmless.  Likewise for 1[a], which is also
perfectly valid.  I discussed this here:
    https://stackoverflow.com/a/18393343/827263

> "a + 1" is more common but also in this situation I prefer &a[1].
>
> Also:
> int f(int a[]){}
> f(0);
>
> We can call f(0). No warning here. Of course this reflects
> the fact argument a is a pointer. But I think C compilers can
> have a warning here. I prefer to consider that arrays in function
> arguments are "references" to valid, non null, arrays.

C99 added "static" for this:

    int f(int a[static 10]){}

It requires the argument to be a pointer to the first element of an
array with at least 10 elements.  `[static 1]` requires the argument to
be a non-null pointer (since a single object is treated as a 1-element
array).

Note that it "requires" this in the sense that a program that violates
the requirement has undefined behavior.  The point is to encourage
compilers to warn about invalid parameters.

gcc does warn about `f(NULL)` (possibly requiring a command-line option
depending on the version).

    $ cat c.c
    #include <stddef.h>

    int f(int a[static 7]){ return 0; }

    int main(void) {
        f(NULL);
    }
    $ gcc -c c.c
    c.c: In function ‘main’:
    c.c:6:5: warning: argument 1 to ‘int[static 28]’ is null where non-null expected [-Wnonnull]
        6 |     f(NULL);
          |     ^~~~~~~
    c.c:3:5: note: in a call to function ‘f’
        3 | int f(int a[static 7]){ return 0; }
          |     ^
    $

(The warning refers to the size of the array, not its length.  I'll
report this bug if someone else hasn't already done so.)

> Even sizeof() could be fixed to me, this would not affect my code.
> int f(int a[2]){ sizeof(a) }

That would break existing code, so it ain't gonna happen.

Walter Bright, of Digital Mars and D, has a proposal for C in this
article from 2009:

    https://www.digitalmars.com/articles/C-biggest-mistake.html
    
The declaration

    void foo(char a[..])

would cause an array argument to be passed as a fat pointer, a pair
consisting of a pointer to the first element and a size_t holding its
length.  I tentatively like the idea, and I can't think of anything that
it would break.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

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

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

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

csiph-web