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

#169031

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> [...]
>>> It would be nice if some energetic person would enter a bug
>>> report on the gcc bug list site, regarding the missing imaginary
>>> types.  I have put in gcc bug reports in the past but don't have
>>> as much time for that now.
>>
>> *raises hand*
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108531
> "Imaginary types are not supported, violating ISO C Annex G"

Thanks. Clear enough.

> After I submitted that, I found that it's probably a duplicate of
> https://sourceware.org/bugzilla/show_bug.cgi?id=15720
> which was resolved as "INVALID".  I disagree with that resolution.

Agree. It almost seems as if precedent for having a type of
bug is justification for more such bugs.

I guess this explains a lot of the world of software generally.

Phil
-- 
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

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

#169042

Phil Carmody <pc+usenet@asdf.org> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> [...]
>>>> It would be nice if some energetic person would enter a bug
>>>> report on the gcc bug list site, regarding the missing imaginary
>>>> types.  I have put in gcc bug reports in the past but don't have
>>>> as much time for that now.
>>>
>>> *raises hand*
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108531
>> "Imaginary types are not supported, violating ISO C Annex G"
>
> Thanks. Clear enough.
>
>> After I submitted that, I found that it's probably a duplicate of
>> https://sourceware.org/bugzilla/show_bug.cgi?id=15720
>> which was resolved as "INVALID".  I disagree with that resolution.
>
> Agree. It almost seems as if precedent for having a type of
> bug is justification for more such bugs.
>
> I guess this explains a lot of the world of software generally.

I've also sent a suggestion to the C standard editors (the email
addresses at the top of the N3054 draft) suggesting that imaginary types
should be optional even if __STDC_IEC_559_COMPLEX__ and
__STDC_IEC_60559_COMPLEX__ are defined.  But it's probably too late to
make such a change for C23.

(__STDC_IEC_60559_COMPLEX__ is the new name for
__STDC_IEC_559_COMPLEX__, which is being made obsolescent.)

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

#169106

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

> Phil Carmody <pc+usenet@asdf.org> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>> [...]
>>>>
>>>>> It would be nice if some energetic person would enter a bug
>>>>> report on the gcc bug list site, regarding the missing imaginary
>>>>> types.  I have put in gcc bug reports in the past but don't have
>>>>> as much time for that now.
>>>>
>>>> *raises hand*

Thank you for taking that up.

>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108531
>>> "Imaginary types are not supported, violating ISO C Annex G"
>>
>> Thanks.  Clear enough.
>>
>>> After I submitted that, I found that it's probably a duplicate of
>>> https://sourceware.org/bugzilla/show_bug.cgi?id=15720
>>> which was resolved as "INVALID".  I disagree with that resolution.
>>
>> Agree.  It almost seems as if precedent for having a type of
>> bug is justification for more such bugs.
>>
>> I guess this explains a lot of the world of software generally.
>
> I've also sent a suggestion to the C standard editors (the email
> addresses at the top of the N3054 draft) suggesting that imaginary types
> should be optional even if __STDC_IEC_559_COMPLEX__ and
> __STDC_IEC_60559_COMPLEX__ are defined.  But it's probably too late to
> make such a change for C23.

Are imaginary types included in the IEC_559/IEC_60559 materials?  If
they are then I think imaginary types should be mandatory for any C
implementation that defines the __STDC_IEC_{559,60559}_COMPLEX__
symbol(s).

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

#169126

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>> I've also sent a suggestion to the C standard editors (the email
>> addresses at the top of the N3054 draft) suggesting that imaginary types
>> should be optional even if __STDC_IEC_559_COMPLEX__ and
>> __STDC_IEC_60559_COMPLEX__ are defined.  But it's probably too late to
>> make such a change for C23.
>
> Are imaginary types included in the IEC_559/IEC_60559 materials?  If
> they are then I think imaginary types should be mandatory for any C
> implementation that defines the __STDC_IEC_{559,60559}_COMPLEX__
> symbol(s).

I don't have a copy, but I presume they're included.  Perhaps someone
who has access to the standard can comment.

I speculate that IEC 60559 (which is a language-indepedent standard)
specifies complex arithmetic, but doesn't make it mandatory; an
implementation can claim conformance to the real part of 60559 without
supporting complex types.

I speculate, with much less foundation, that IEC 60559 specifies
imaginary types, but doesn't make them mandatory, so an implementation
can claim conformance to the real and complex parts of 60559 without
supporting imaginary types.  (Of course an imaginary value can also be
supported as a complex value with a zero real part, but a true
imaginary type has the same size as the corresponding real type.)

*If* my speculation is correct, then it would be perfectly appropriate
for the C standard (Annex G) to permit a C implementation to support
complex types but not imaginary types.

If not, if IEC 60559 requires imaginary type support for any
implementation that supports complex types, I still suggest that it
could be appropriate for C to permit a conforming C implementation to
support complex types, and to assert (partial) conformance to IEC 60559,
without supporting imaginary types.  Perhaps the macro names would be a
trifle misleading, but that shouldn't prevent the C standard from
supporting useful options.

In particular, both gcc and clang, given appropriate library support,
implement IEC 60559 real and complex types but not imaginary types --
and apparently adding support for imaginary types would be non-trivial
(in ways I haven't looked into).  It would be good for them to have a
set of macro definitions that can express that.

(On the other hand, I generally dislike optional language features, and
it would be in some sense cleaner if all C compilers supported both
complex and imaginary types -- but I'm not going to do the work to make
that happen.)

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

#169294

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:
>
> [...]
>
>>> I've also sent a suggestion to the C standard editors (the email
>>> addresses at the top of the N3054 draft) suggesting that imaginary types
>>> should be optional even if __STDC_IEC_559_COMPLEX__ and
>>> __STDC_IEC_60559_COMPLEX__ are defined.  But it's probably too late to
>>> make such a change for C23.
>>
>> Are imaginary types included in the IEC_559/IEC_60559 materials?  If
>> they are then I think imaginary types should be mandatory for any C
>> implementation that defines the __STDC_IEC_{559,60559}_COMPLEX__
>> symbol(s).
>
> I don't have a copy, but I presume they're included.  Perhaps
> someone who has access to the standard can comment.
>
> I speculate that IEC 60559 (which is a language-indepedent
> standard) specifies complex arithmetic, but doesn't make it
> mandatory;  an implementation can claim conformance to the real
> part of 60559 without supporting complex types.

After reviewing what the C standard says in Annex F and Annex G,
it seems plausible that IEC 60559 doesn't say anything about
complex types or complex arithmetic.  Since neither of us has any
facts, I will leave my earlier question there.

Considering what Annex G does say, and has said for more than ten
years, and since imaginary types represent such a small increment
beyond an implementation of complex types, I continue to think
that imaginary types should be mandatory for any C implementation
that defines the __STDC_IEC_{559,60559}_COMPLEX__ symbol(s).

> [...]
>
> In particular, both gcc and clang, given appropriate library
> support, implement IEC 60559 real and complex types but not
> imaginary types -- and apparently adding support for imaginary
> types would be non-trivial (in ways I haven't looked into).  It
> would be good for them to have a set of macro definitions that
> can express that.
>
> (On the other hand, I generally dislike optional language features,
> and it would be in some sense cleaner if all C compilers supported
> both complex and imaginary types -- but I'm not going to do the work
> to make that happen.)

Let me be clear that I am not asking you to do anything so gcc
and/or clang (and/or any other C compilers) become conforming
with respect to supporting imaginary types.  I think we agree
on the main point that optional language features are generally
best avoided, and in particular that the C standard is better
left as is in that regard with respect to imaginary types.  That
by itself is sufficient cause for a modest celebration.

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

#169300

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:
>> [...]
>>
>>>> I've also sent a suggestion to the C standard editors (the email
>>>> addresses at the top of the N3054 draft) suggesting that imaginary types
>>>> should be optional even if __STDC_IEC_559_COMPLEX__ and
>>>> __STDC_IEC_60559_COMPLEX__ are defined.  But it's probably too late to
>>>> make such a change for C23.
>>>
>>> Are imaginary types included in the IEC_559/IEC_60559 materials?  If
>>> they are then I think imaginary types should be mandatory for any C
>>> implementation that defines the __STDC_IEC_{559,60559}_COMPLEX__
>>> symbol(s).
>>
>> I don't have a copy, but I presume they're included.  Perhaps
>> someone who has access to the standard can comment.
>>
>> I speculate that IEC 60559 (which is a language-indepedent
>> standard) specifies complex arithmetic, but doesn't make it
>> mandatory;  an implementation can claim conformance to the real
>> part of 60559 without supporting complex types.
>
> After reviewing what the C standard says in Annex F and Annex G,
> it seems plausible that IEC 60559 doesn't say anything about
> complex types or complex arithmetic.
[...]

I had assumed that Annex G must be based on a specification of complex
arithmetic in IEC 60559, but G.6.1p2 says:

    This subclause contains specifications for the <complex.h> functions
    that are particularly suited to IEC 60559 implementations.

And the Wikipedia article <https://en.wikipedia.org/wiki/IEEE_754>
(redirected from IEC 60559) doesn't mention imaginary or complex
numbers at all, nor do the IEEE and ISO web pages for the standards.
So I agree that the IEC 60559 very probably does not say anything
about complex or imaginary arithmetic.

Given how widely complex numbers are used in some fields, and given
the subtlety of some of the operations, I'm surprised that there
doesn't seem to be a language-independent standard for complex
arithmetic, either as a companion to IEC 60559 or as part of it.
Instead, it seems that each language (Fortran, C, C++, etc.) can
adopt IEC 60559 for floating-point but has to reinvent the wheel
for complex arithmetic.

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

#169131

Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> <snip>
> Are imaginary types included in the IEC_559/IEC_60559 materials?  If
> they are then I think imaginary types should be mandatory for any C
> implementation that defines the __STDC_IEC_{559,60559}_COMPLEX__
> symbol(s).

To the extent that C is thought of as a portable assemby language,
e.g., https://stackoverflow.com/questions/3040276/
why would/should it provide low-level implementation of
a complex variable type? Seems way beyond that self-defined scope.
I've programmed in assembly for various architectures, and never
seen any assembler that provides complex variables.
(And note that I have an ms in physics, and often have occasion
to use complex variables in my programming. So I've got nothing
against them, so to speak. But it's completely trivial to define
them and to implement all their basic operations.)
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

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

#169133

John Forkosh <forkosh@panix.com> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>> <snip>
>> Are imaginary types included in the IEC_559/IEC_60559 materials?  If
>> they are then I think imaginary types should be mandatory for any C
>> implementation that defines the __STDC_IEC_{559,60559}_COMPLEX__
>> symbol(s).
>
> To the extent that C is thought of as a portable assemby language,
> e.g., https://stackoverflow.com/questions/3040276/
> why would/should it provide low-level implementation of
> a complex variable type? Seems way beyond that self-defined scope.
> I've programmed in assembly for various architectures, and never
> seen any assembler that provides complex variables.
> (And note that I have an ms in physics, and often have occasion
> to use complex variables in my programming. So I've got nothing
> against them, so to speak. But it's completely trivial to define
> them and to implement all their basic operations.)

Some people think of C as a "portable assembly language".  They're
wrong.

The distinguishing feature of an assembly language is that a program in
the language defines a sequence of CPU instructions.  A C program
defines run-time behavior.

In any case, the decision to add complex numbers to the language was
made in 1999, 24 years ago.  Yes, complex numbers and their operations
*could* be defined in a library, but without operator overloading they
would be awkward to use.  For example, you'd need three distinct
function names just for complex addition (float, double, and long
double).

(That's why C++ was able to define complex numbers in the library rather
than in the core language.)

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

#169141

On Monday, January 30, 2023 at 6:24:42 AM UTC+2, John Forkosh wrote:
> Tim Rentsch <tr.1...@z991.linuxsc.com> wrote: 
> > <snip>
> > Are imaginary types included in the IEC_559/IEC_60559 materials? If 
> > they are then I think imaginary types should be mandatory for any C 
> > implementation that defines the __STDC_IEC_{559,60559}_COMPLEX__ 
> > symbol(s).
> To the extent that C is thought of as a portable assemby language, 
> e.g., https://stackoverflow.com/questions/3040276/ 
> why would/should it provide low-level implementation of 
> a complex variable type? Seems way beyond that self-defined scope. 
> I've programmed in assembly for various architectures, and never 
> seen any assembler that provides complex variables. 

You're welcome:
https://developer.arm.com/documentation/ddi0596/2020-12/SIMD-FP-Instructions/FCMLA--Floating-point-Complex-Multiply-Accumulate-

> (And note that I have an ms in physics, and often have occasion 
> to use complex variables in my programming. So I've got nothing 
> against them, so to speak. But it's completely trivial to define 
> them and to implement all their basic operations.) 
> -- 
> John Forkosh ( mailto: j...@f.com where j=john and f=forkosh )

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

#169292

John Forkosh <forkosh@panix.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> <snip>
>> Are imaginary types included in the IEC_559/IEC_60559 materials?  If
>> they are then I think imaginary types should be mandatory for any C
>> implementation that defines the __STDC_IEC_{559,60559}_COMPLEX__
>> symbol(s).
>
> To the extent that C is thought of as a portable assemby language,
> e.g., https://stackoverflow.com/questions/3040276/
> why would/should it provide low-level implementation of
> a complex variable type?  Seems way beyond that self-defined scope.
> I've programmed in assembly for various architectures, and never
> seen any assembler that provides complex variables.

These days very few people think of C as a portable assembly
language, and that's been true for more than 30 years (for
example, Numerical Recipes in C came out in 1985).  It is my
understanding that support for complex operations was added to C
(in C99) as a result of demand from the Fortran community.  It
seems reasonable for C to want to appeal to users of Fortran,
which is a similarly low-level language.

> (And note that I have an ms in physics, and often have occasion
> to use complex variables in my programming.  So I've got nothing
> against them, so to speak.  But it's completely trivial to define
> them and to implement all their basic operations.)

It's easy to write the mathematical formulas for the basic
operations (+, -, *, /).  Language support is much harder, both
because library functions for complex operands take a lot of
care to implement, and because even the basic operations are
tricky, due to problems with cancellation and intermediate
overflows.  It might be easy to do a half-assed implementation
of the basic operations;  providing a more robust set of basic
operation implementations, along with library support for
standard operations in the complex plane, is a lot harder.

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

#168854

On 1/20/23 15:01, Anton Shepelev wrote:
> Kenny McCormack:
> 
>> I never really understood *why* they changed the language
>> to allow structs to be passed as actual objects.  Anyone
>> care to comment?
> 
> Integers, floats, and doubles can be passed by value.  If I
> were to implement complex numbers, I should do it as a
> struct with a .re (real) and .im (imaginary) fields.  I
> should want to pass it by value whenever I pass real types
> by value.

Note that this argument can be applied to any struct which can be seen
as implementing a type that is, in some way, an extension of the scalar
types, because the scalar types are also passed by value. I could, and
have, had reason to use this approach for things like quaternions,
vectors or tensors with a small fixed dimensions (<= 4), and smart
pointers. It's much easier to do such things in C++, where I can create
corresponding operator overloads.

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

#168860

James Kuyper to Anton Shepelev:

> > Integers, floats, and doubles can be passed by value.
> > If I were to implement complex numbers, I should do it
> > as a struct with a .re (real) and .im (imaginary)
> > fields.  I should want to pass it by value whenever I
> > pass real types by value.
>
> Note that this argument can be applied to any struct which
> can be seen as implementing a type that is, in some way,
> an extension of the scalar types, because the scalar types
> are also passed by value. I could, and have, had reason to
> use this approach for things like quaternions, vectors or
> tensors with a small fixed dimensions (<= 4), and smart
> pointers. It's much easier to do such things in C++, where
> I can create corresponding operator overloads.

Indeed. My specific example demostrates a general deficiency
of C and other similar languages: implementing one's own
"scalar-like" types is impossibe or cumbersome, whereas
those types are often very useful. All right, modern C has
built-in complex type, but that only shows that it cannot
be implemented by the programmer *in* C!

-- 
()  ascii ribbon campaign -- against html e-mail 
/\  www.asciiribbon.org   -- against proprietary attachments

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

#168861

On 1/21/23 3:00 PM, Anton Shepelev wrote:
> James Kuyper to Anton Shepelev:
> 
>>> Integers, floats, and doubles can be passed by value.
>>> If I were to implement complex numbers, I should do it
>>> as a struct with a .re (real) and .im (imaginary)
>>> fields.  I should want to pass it by value whenever I
>>> pass real types by value.
>>
>> Note that this argument can be applied to any struct which
>> can be seen as implementing a type that is, in some way,
>> an extension of the scalar types, because the scalar types
>> are also passed by value. I could, and have, had reason to
>> use this approach for things like quaternions, vectors or
>> tensors with a small fixed dimensions (<= 4), and smart
>> pointers. It's much easier to do such things in C++, where
>> I can create corresponding operator overloads.
> 
> Indeed. My specific example demostrates a general deficiency
> of C and other similar languages: implementing one's own
> "scalar-like" types is impossibe or cumbersome, whereas
> those types are often very useful. All right, modern C has
> built-in complex type, but that only shows that it cannot
> be implemented by the programmer *in* C!
> 

No, they CAN be implemented, they just don't completely work like the 
built in types because the operators don't work on them.


Yes, to make a completely "act like a native" type, you need to be able 
to overload the operators, and then you need to be able to define 
'conversion' functions to convert one type to another, and so on and you 
get to the beginnings of something like C++.

Once you let that "Nosse of the Camel" in, you tend to get a lot of the 
base language of C++ following.

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

#168847

On Friday, January 20, 2023 at 4:02:59 PM UTC-3, Kenny McCormack wrote:
> In article <76ec6d87-0f5d-4671...@googlegroups.com>,
> Thiago Adams <thiago...@gmail.com> wrote: 
> >At first edition of "The C programming language" we can see 
> >that structs could not be passed directly as function arguments. 
> >They also could not be returned from functions and assigned. 
> > 
> >Soon after [1], the language changed to allow assignment and make 
> >structs arguments passed by copy by default. 
> > 
> >Today, I have 0% of structs being passed by copy in my code. 
> >So for me this is a very bad default.
> Two comments: 
> 1) I never really understood *why* they changed the language to allow 
> structs to be passed as actual objects. Anyone care to comment? 

I guess is to make structs work as other basic types. 

But they didn't realise the common case is passing without copy.
const also was added latter, making references safer.

At 2 edition of c programming language, page 128, they added a "struct point" 
sample, passing and returning point by copy.
This is a very specific cases where using copy may make sense.

This sample was not present at first edition. So it kind of justifying the feature.

At pag 168 of Byte magazine 1983 [2] has a interesting comment that some compilers
use to pass address of struct even without operator &.

[2] pag 168
https://ia800309.us.archive.org/26/items/byte-magazine-1983-08/1983_08_BYTE_08-08_The_C_Language.pdf

This shows me that this behaviour was common sense, at least for some compilers.

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

#168848

Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <76ec6d87-0f5d-4671-b4c8-7023e3da787an@googlegroups.com>,
> Thiago Adams  <thiago.adams@gmail.com> wrote:
> >At first edition of "The C programming language" we can see
> >that structs could not be passed directly as function arguments.
> >They also could not be returned from functions and assigned.
> >
> >Soon after [1], the language changed to allow assignment and make
> >structs arguments passed by copy by default.
> >
> >Today, I have 0% of structs being passed by copy in my code.
> >So for me this is a very bad default.
> 
> Two comments:
>     1) I never really understood *why* they changed the language to allow
>         structs to be passed as actual objects.  Anyone care to comment?

Why not?  Argument passing in C is releated to assignment.  Once you
allow structure assignment it is natural to allow passing of
structs.  If compiler passes arguments on the stack, then
implementation is allmost for free, just generate code as for
assignment to fill stack slot.  If some arguments are passed in
registers, then implementation gets more complicated.  OTOH
small structures that fit into one or two registers are more
efficient to pass by value, so it makes sense to spend some
effort to pass them in registers.

>     2) The usual method for passing structs around is to pass a pointer to
>         the struct.  That works just fine in all cases and, thus, as above,
>         I don't understand why the change.

If you pass address of the struct, than there is no change.  The
rest is just making struct into "first class objects".
 
> Like you, I've never needed (or used) this ability in my code, so have not
> ever used it.  I wonder if it came about because they made some other
> changes (enhancements) in what you could legally do with a struct, and this
> ended up coming for free.

Once you have structurs assignment passing them as arguments is only
logical thing.

Few times are used structures with one member to get stronger type
checking (free of default C rules for argument compatibility).  I did
appropriate change temporarly, using macros and for this use it was
essential that structures were passed by value.  Few times I used
small structures and passed them by value.  It made code slightly
simpler and probably more efficient than passing address.

-- 
                              Waldek Hebisch

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

#168841

[Multipart message — attachments visible in raw view] — view raw

On 1/20/23 13:41, Thiago Adams wrote:
> <snip/>
> 
> If structs where passed by reference this would not be the only
> exception  on the type system because arrays are already passed
> as pointers.
> 
> <snip/>

​The only reason arrays are the exception is because arrays aren't a 
first-class construct, and are just a syntactic wrapper around pointers 
to contiguous storage.

-- 
⚗︎ | /blu.mɛin.dʰak/ | shortens to "Hawk" | he/him/his/himself/Mr.
bluemanedhawk.github.io
Apologies if this message got encoded into octoctal.  Blame Thunderbird 
for not behaving correctly with Unicode and PGP.

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

#168843

Blue-Maned_Hawk <bluemanedhawk@gmail.com> writes:
> On 1/20/23 13:41, Thiago Adams wrote:
>> <snip/>
>> If structs where passed by reference this would not be the only
>> exception  on the type system because arrays are already passed
>> as pointers.
>> <snip/>
>
> ​The only reason arrays are the exception is because arrays aren't a
> first-class construct, and are just a syntactic wrapper around
> pointers to contiguous storage.

That's incorrect.

Array objects and array types are entirely distinct from pointer objects
and pointer types.

An array *expressions* is, in most but not all contexts, implicitly
"converted" to a pointer to the array object's 0th element.  And a
function parameter of array type is "adjusted" to a parameter of pointer
type.  Together, these rules can make it seem like array objects are
being passed by reference, but that's not what's really happening.

I find it useful to treat the words "array" and "pointer" as adjectives,
not nounds: "array object", not just "array".

See section 6 of the comp.lang.c FAQ, <https://www.c-faq.com/>.

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

#168842

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

> At first edition of "The C programming language" we can see
> that structs could not be passed directly as function arguments.
> They also could not be returned from functions and assigned.
>
> Soon after [1], the language changed to allow assignment and make
> structs arguments passed by copy by default.
>
> Today, I have 0% of structs being passed by copy in my code.
> So for me this is a very bad default.
>
> If structs where passed by reference this would not be the only
> exception  on the type system because arrays are already passed
> as pointers.
>
> Do  you have structs passed by copy in your code?
> Could it be replaced by const * ?
> Considering your answer would you agree with me that this is a bad default?
>
> Returning function by copy is common in my code.
>
> [1]
> https://www.bell-labs.com/usr/dmr/www/cchanges.pdf

All function arguments are passed by copy.  Arrays are not an exception
to that rule because they're passed by pointer.  They're an exception
because there are no arguments of array type.  There is some syntactic
sugar that can make it look like arrays are being passed by reference,
but that's not what's happening.


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

#168845

On 20/01/2023 18:41, Thiago Adams wrote:
> At first edition of "The C programming language" we can see
> that structs could not be passed directly as function arguments.
> They also could not be returned from functions and assigned.
> 
> Soon after [1], the language changed to allow assignment and make
> structs arguments passed by copy by default.
> 
> Today, I have 0% of structs being passed by copy in my code.
> So for me this is a very bad default.
> 
> If structs where passed by reference this would not be the only
> exception  on the type system because arrays are already passed
> as pointers.

If S is a struct instance, and A is an array instance, then here:

    S;       // is the struct itself; not a reference;
    A;       // is a pointer to A[0]; not the array itself

So the default is already part of the language, and exists in nearly 
every place where you use S and A within an expression.

Including expressions like f(S) and S=g().

So to me it makes sense.

Bear in mind that on modern ABIs, most structs tend to be passed by 
reference behind the scenes anyway. Although it may still require some 
copying to protect the caller's original data if that is at risk.


> 
> Do  you have structs passed by copy in your code?
> Could it be replaced by const * ?
> Considering your answer would you agree with me that this is a bad default?
> 
> Returning function by copy is common in my code.

If you use libraries like Raylib, then pretty much every struct is 
passed and return by-value, or notionally by-value.

Like you I prefer by-reference, but I also prefer that that was explicit 
in the language.

(My own language manipulates arrays by-value too. For some decades I had 
structs and arrays passed by actual copying, but I NEVER used that 
feature. That is still the case, but now behind the scenes it uses 
pointers. I still use explicit pointer-to or by-reference passing modes.)

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

#168851

On Friday, January 20, 2023 at 5:16:58 PM UTC-3, Bart wrote:
> On 20/01/2023 18:41, Thiago Adams wrote: 
> > At first edition of "The C programming language" we can see 
> > that structs could not be passed directly as function arguments. 
> > They also could not be returned from functions and assigned. 
> > 
> > Soon after [1], the language changed to allow assignment and make 
> > structs arguments passed by copy by default. 
> > 
> > Today, I have 0% of structs being passed by copy in my code. 
> > So for me this is a very bad default. 
> > 
> > If structs where passed by reference this would not be the only 
> > exception on the type system because arrays are already passed 
> > as pointers.
> If S is a struct instance, and A is an array instance, then here: 
> 
> S; // is the struct itself; not a reference; 
> A; // is a pointer to A[0]; not the array itself 

If you use sizeof of an array (not function argument) then
you get the correct size. 

int a[2];
sizeof(a); // will not give the sizeof a[0]

So, in some cases it is not equivalent of first element.

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

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

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

csiph-web