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

C Construction Problem

Started by	"F. Russell" <fr@random.info>
First post	2018-02-20 13:51 +0000
Last post	2018-02-26 11:21 -0800
Articles	20 on this page of 105 — 25 participants

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

  C Construction Problem "F. Russell" <fr@random.info> - 2018-02-20 13:51 +0000
    Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-20 14:42 +0000
      Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-20 15:06 +0000
        Re: C Construction Problem Manfred <noname@invalid.add> - 2018-02-20 18:07 +0100
    Re: C Construction Problem Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-20 14:54 +0000
    Re: C Construction Problem "James R. Kuyper" <jameskuyper@verizon.net> - 2018-02-20 10:06 -0500
      Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-20 16:11 +0000
    Re: C Construction Problem Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-20 15:08 +0000
      Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-20 16:22 +0000
        Re: C Construction Problem Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-20 17:03 +0000
          Re: C Construction Problem Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-20 09:23 -0800
          Re: C Construction Problem Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-20 11:11 -0700
          Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-20 18:30 +0000
            Re: C Construction Problem Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-20 23:37 +0000
              Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-21 00:45 +0000
                Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-21 01:46 +0000
                  Re: C Construction Problem David Brown <david.brown@hesbynett.no> - 2018-02-21 08:49 +0100
                    Re: C Construction Problem Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-21 09:29 +0000
                      [OT] Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-21 11:24 +0000
                        Re: [OT] Re: C Construction Problem Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-21 14:41 +0300
                        Re: [OT] Re: C Construction Problem David Brown <david.brown@hesbynett.no> - 2018-02-21 15:10 +0100
                        Re: [OT] Re: C Construction Problem Robert Wessel <robertwessel2@yahoo.com> - 2018-02-21 12:36 -0600
                          Re: [OT] Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-21 21:04 +0000
                            Re: [OT] Re: C Construction Problem Robert Wessel <robertwessel2@yahoo.com> - 2018-02-21 18:20 -0600
                  Re: C Construction Problem Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-21 11:09 +0300
                  Re: C Construction Problem Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-21 02:29 -0800
                  Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-21 11:32 +0000
                  Re: C Construction Problem Geoff <geoff@invalid.invalid> - 2018-02-26 11:02 -0800
                    Re: C Construction Problem David Brown <david.brown@hesbynett.no> - 2018-02-27 09:22 +0100
                      Re: C Construction Problem Geoff <geoff@invalid.invalid> - 2018-02-27 11:18 -0800
                        Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-27 19:51 +0000
                          Re: C Construction Problem Robert Wessel <robertwessel2@yahoo.com> - 2018-02-28 01:54 -0600
                        Re: C Construction Problem Robert Wessel <robertwessel2@yahoo.com> - 2018-02-28 01:43 -0600
                          Re: C Construction Problem Geoff <geoff@invalid.invalid> - 2018-02-28 12:54 -0800
                    Re: archive decompressor Noob <root@127.0.0.1> - 2018-03-04 12:34 +0100
                Re: C Construction Problem Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-21 11:04 +0300
                  Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-21 11:27 +0000
                    Re: C Construction Problem Anton Shepelev <anton.txt@gmail.com> - 2018-02-28 22:59 +0300
                  Re: C Construction Problem supercat@casperkitty.com - 2018-02-21 08:49 -0800
              Re: C Construction Problem Geoff <geoff@invalid.invalid> - 2018-02-26 11:08 -0800
                Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-26 23:51 +0000
                  Re: C Construction Problem Geoff <geoff@invalid.invalid> - 2018-02-27 11:24 -0800
            Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 08:07 -0800
              Re: C Construction Problem fr314159@gmail.com - 2018-02-21 09:16 -0800
                Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 21:26 -0800
              Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-21 09:43 -0800
                Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 22:47 -0800
                  Re: C Construction Problem Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-22 13:09 +0000
                    Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-24 13:37 -0800
                  Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-22 10:50 -0800
                    Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-24 13:58 -0800
                      Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-24 15:05 -0800
                        Re: C Construction Problem Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-25 03:21 -0800
                          Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-25 11:51 +0000
                            Re: C Construction Problem Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-25 04:06 -0800
                              Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-25 12:47 +0000
                              Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-25 13:20 +0000
                                Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-25 17:46 +0000
                                  Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-25 18:58 +0000
                                    Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-25 20:01 +0000
                                      Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-25 20:25 +0000
                                  Re: C Construction Problem Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-26 02:49 -0800
                              Re: C Construction Problem Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-25 20:02 +0000
                              Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-25 15:13 -0800
                          Re: C Construction Problem Robert Wessel <robertwessel2@yahoo.com> - 2018-02-25 11:50 -0600
                          Re: C Construction Problem Ian Collins <ian-news@hotmail.com> - 2018-02-26 07:38 +1300
                            Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-25 15:15 -0800
                            Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-26 22:02 -0800
                              Re: C Construction Problem jameskuyper@verizon.net - 2018-02-27 06:32 -0800
                                Re: C Construction Problem GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-27 16:56 +0100
                                  Re: C Construction Problem jameskuyper@verizon.net - 2018-02-27 08:27 -0800
                                    Re: C Construction Problem GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-27 18:02 +0100
                                      Re: C Construction Problem jameskuyper@verizon.net - 2018-02-27 10:23 -0800
                                        Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-03 01:09 -0800
                                      Re: C Construction Problem David Brown <david.brown@hesbynett.no> - 2018-02-28 10:37 +0100
                                    Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-03 01:29 -0800
                                      Re: C Construction Problem Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 02:00 -0800
                                Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-27 08:46 -0800
                                  Re: C Construction Problem jameskuyper@verizon.net - 2018-02-27 09:15 -0800
                                Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-03 02:08 -0800
                                  Re: C Construction Problem Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 02:31 -0800
                                  Re: C Construction Problem Ian Collins <ian-news@hotmail.com> - 2018-03-04 10:34 +1300
                                    Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-19 10:27 -0700
                                  Re: C Construction Problem jameskuyper@verizon.net - 2018-03-03 21:35 -0800
                                    Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-17 10:29 -0700
                                      Re: C Construction Problem Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-18 08:14 -0700
                          Re: C Construction Problem David Brown <david.brown@hesbynett.no> - 2018-02-25 21:49 +0100
                          Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-25 15:09 -0800
                          Re: C Construction Problem gazelle@shell.xmission.com (Kenny McCormack) - 2018-02-26 13:46 +0000
                            Re: C Construction Problem David Brown <david.brown@hesbynett.no> - 2018-02-26 14:57 +0100
                        Re: C Construction Problem Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-26 22:14 -0800
              Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-22 00:11 +0000
                Re: C Construction Problem Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-21 17:27 -0700
      Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-20 09:30 -0800
        Re: C Construction Problem Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-21 00:23 +0000
    Re: C Construction Problem Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-20 09:11 -0700
      Re: C Construction Problem "F. Russell" <fr@random.info> - 2018-02-20 16:38 +0000
        Re: C Construction Problem bartc <bc@freeuk.com> - 2018-02-20 17:07 +0000
        Re: C Construction Problem John Bode <jfbode1029@gmail.com> - 2018-02-20 09:09 -0800
        Re: C Construction Problem "James R. Kuyper" <jameskuyper@verizon.net> - 2018-02-20 12:18 -0500
          Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-20 09:38 -0800
        Re: C Construction Problem Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-20 11:08 -0700
        Re: C Construction Problem Gordon Burditt <gordon@hammy.burditt.org> - 2018-02-20 21:47 -0600
          Re: C Construction Problem Keith Thompson <kst-u@mib.org> - 2018-02-21 09:36 -0800
            Re: C Construction Problem Geoff <geoff@invalid.invalid> - 2018-02-26 11:21 -0800

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

#127313

From	Steven Petruzzellis <frelwizzen@gmail.com>
Date	2018-03-03 02:31 -0800
Message-ID	<5f1e2f3d-ac83-4103-83f0-2b524f621931@googlegroups.com>
In reply to	#127309

On Saturday, March 3, 2018 at 3:08:23 AM UTC-7, Tim Rentsch wrote:
> jameskuyper@verizon.net writes:
> 
> > On Tuesday, February 27, 2018 at 1:02:54 AM UTC-5, Tim Rentsch wrote:
> >
> >> Ian Collins <ian-news@hotmail.com> writes:
> >>
> >>> Due to C++11 using C99 rather than C89 as its base, [...]
> >>
> >> In C++11 and later, C++ uses the C99 library as its base
> >> library.  It does not use the C99 language as its base
> >> language.
> >
> > "C ++ is a general purpose programming language based on the C
> > programming language as described in ISO/IEC 9899:2011 Programming
> > languages ?  C (hereinafter referred to as the C standard).  In
> > addition to the facilities provided by C, C ++ provides ..."
> > (n4659.pdf 1p2).
> >
> > n3690.pdf refers to 9899:1999 instead of 9899:2011.
> >
> > Are you making a distinction between saying "C++ is ... based on
> > ...  ISO/IEC 9899:1999", and "C99 is the base language for C++"?
> > If so, could you explain that distinction?
> 
> C99 has variable length arrays.  C++ does not.
> 
> C99 has designated initializers.  C++ does not.
> 
> C99 has compound literals.  C++ does not.
> 
> C99 has inline functions.  C++ also has inline functions,
> but with different semantics.
> 
> C11 has anonymous structs and unions.  C++ does not.
> 
> C11 has _Generic.  C++ does not.
> 
> There are other differences;  those are some of the more
> obvious ones.
> 
> Somewhat recently I have done some work on an interface (in
> particular, a .h file) that targets C++ as well as C.  Even in
> just an interface file, writing C that is acceptable to C++ meant
> pretty much writing C90 rather than C99.  I was surprised by
> that, because the code in the .h file wasn't doing anything very
> exotic.  Yet it had to be changed (written originally assuming
> C99) to make it C++ compatible.
> 
> Finally, let me point out Annex C, "Compatibility", in n4659.
> Paragraph 1 of C.1 says
> 
>     This subclause lists the differences between C++ and ISO C,
>     by the chapters of this document.
> 
> Despite that introduction, AFAICT no language features new to C99
> or C11 are among those compared.  In fact one of the items listed
> is implicit declaration of functions, which hasn't been part of
> standard C for almost 20 years.  Also inline functions are not
> listed.  So the C++ standard itself tacitly concedes the point
> that, as far as the language goes, C++ is based on C90 and not on
> C99 or C11.



You're clueless! 

No no. He never agreed to stop trolling. He lied about his trolling just as you would expect. Seriously, those of you who troll are not able to restrain yourselves anymore. 

Are you being like Audra 'The Shill' Moore on purpose? 

-- 
Live on Kickstarter!
http://www.5z8.info/mydick_x6g9hr_nakedgrandmas.jpg
https://www.reddit.com/r/linux/comments/6sfhq6/what_desktop_tasks_does_linux_handle_better_than/
http://www.5z8.info/dogs-being-eaten_g0w7hf_molotovcocktail
Jonas Eklundh Communication

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

#127339

From	Ian Collins <ian-news@hotmail.com>
Date	2018-03-04 10:34 +1300
Message-ID	<fg0infF9fjuU1@mid.individual.net>
In reply to	#127309

On 03/03/2018 11:08 PM, Tim Rentsch wrote:
> 
> Somewhat recently I have done some work on an interface (in
> particular, a .h file) that targets C++ as well as C.  Even in
> just an interface file, writing C that is acceptable to C++ meant
> pretty much writing C90 rather than C99.  I was surprised by
> that, because the code in the .h file wasn't doing anything very
> exotic.  Yet it had to be changed (written originally assuming
> C99) to make it C++ compatible.

I'm curious, what did you have to avoid?  On the platforms I use, the 
system headers and the standard library headers are C99 with some C11.

Going back to the toot of this sub-thread, it was the inclusion of the 
C99 standard library in C++11 that forced Microsoft to improve their C99 
support. C++ has to work with the C99 standard library headers.  They 
will have to go further with C++20, which will add designated initialisers.

-- 
Ian.

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

#128013

From	Tim Rentsch <txr@alumni.caltech.edu>
Date	2018-03-19 10:27 -0700
Message-ID	<kfnefkgnfh0.fsf@x-alumni2.alumni.caltech.edu>
In reply to	#127339

Ian Collins <ian-news@hotmail.com> writes:

> On 03/03/2018 11:08 PM, Tim Rentsch wrote:
>
>> Somewhat recently I have done some work on an interface (in
>> particular, a .h file) that targets C++ as well as C.  Even in
>> just an interface file, writing C that is acceptable to C++ meant
>> pretty much writing C90 rather than C99.  I was surprised by
>> that, because the code in the .h file wasn't doing anything very
>> exotic.  Yet it had to be changed (written originally assuming
>> C99) to make it C++ compatible.
>
> I'm curious, what did you have to avoid?  On the platforms I use, the
> system headers and the standard library headers are C99 with some C11.

The ones I ran into are these:

  * Using _Bool as a type name - can't use 'bool' because clients
    may not want to

  * restrict keyword - not important for semantics, but important
    for documentation purposes

  * inline functions - semantics of non-static inline functions
    are different in C and C++

  * array extent in parameter declaration (for 1D array) - again
    not important for semantics but has documentation value.
    Example:  int foo( size_t n, char out[n] );

I was able to fix all these using preprocessor tests and suitable
macro definitions, but the result is pretty ugly.  And, since I
also wanted the interface to be usable by a .c includer compiled
under C90 rules, it kind of leapt out at me that what I had to
do for C++ was pretty much the same as what I had to do for C90
(the _Bool case was an exception to that, since C++ has bool).

> Going back to the toot of this sub-thread, it was the inclusion of the
> C99 standard library in C++11 that forced Microsoft to improve their
> C99 support.  C++ has to work with the C99 standard library headers.
> They will have to go further with C++20, which will add designated
> initialisers.

What I really would like is if code between

    extern "C" {

and the corresponding closing were taken as having C syntax and
semantics rather than C++ syntax and semantics.  Then writing
these kinds of interfaces would be a snap.

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

#127344

From	jameskuyper@verizon.net
Date	2018-03-03 21:35 -0800
Message-ID	<e1e345da-d15d-4276-88e0-2c6ef7de04d1@googlegroups.com>
In reply to	#127309

On Saturday, March 3, 2018 at 5:08:23 AM UTC-5, Tim Rentsch wrote:
> jameskuyper@verizon.net writes:
> 
> > On Tuesday, February 27, 2018 at 1:02:54 AM UTC-5, Tim Rentsch wrote:
> >
> >> Ian Collins <ian-news@hotmail.com> writes:
> >>
> >>> Due to C++11 using C99 rather than C89 as its base, [...]
> >>
> >> In C++11 and later, C++ uses the C99 library as its base
> >> library.  It does not use the C99 language as its base
> >> language.
> >
> > "C ++ is a general purpose programming language based on the C
> > programming language as described in ISO/IEC 9899:2011 Programming
> > languages ?  C (hereinafter referred to as the C standard).  In
> > addition to the facilities provided by C, C ++ provides ..."
> > (n4659.pdf 1p2).
> >
> > n3690.pdf refers to 9899:1999 instead of 9899:2011.
> >
> > Are you making a distinction between saying "C++ is ... based on
> > ...  ISO/IEC 9899:1999", and "C99 is the base language for C++"?

I'm presuming, from the nature of your reply below, that your answer to
that question, had you bothered to make one, would have been "No". Let
me know (by explicitly stating what your answer would actually have
been) if I'm wrong about that.

> > If so, could you explain that distinction?
> 
> C99 has variable length arrays.  C++ does not.
> 
> C99 has designated initializers.  C++ does not.
> 
> C99 has compound literals.  C++ does not.
> 
> C99 has inline functions.  C++ also has inline functions,
> but with different semantics.
> 
> C11 has anonymous structs and unions.  C++ does not.
> 
> C11 has _Generic.  C++ does not.
> 
> There are other differences;  those are some of the more
> obvious ones.

Let me extend that list for you. I took the list of changes from C90
listed in the C11 foreword, and removed those parts that involved the C
standard library. All of the following are C11 differences from C90 that
are either not present, or implemented differently, in C++17:

— querying and specifying alignment of objects
— no-return functions
— more precise aliasing rules via effective type
— restricted pointers
— static and type qualifiers in parameter array declarators
— complex (and imaginary) support in <complex.h>
— type-generic math macros in <tgmath.h>
— increased minimum translation limits
— hexadecimal floating-point constants and %a and %A printf/scanf
conversion specifiers
— IEC 60559 (also known as IEC 559 or IEEE arithmetic) support
— new structure type compatibility rules (tag compatibility)
— additional predefined macro names
— LIA compatibility annex

However, even with those additions, that list still represent only a
tiny fraction of the total list of features of C11.

Before deciding whether C++17 is closer to C99 or C11, you should also
look at the features of C11 that were changes from C90, and are
supported in the same way in C++17:

— Unicode characters and strings
— static assertions
— restricted character set support via digraphs
— the long long int type 
— remove implicit int
— reliable integer division
— universal character names (\u and \U)
— // comments
— extended integer types
— remove implicit function declaration
— preprocessor arithmetic done in intmax_t/uintmax_t
— mixed declarations and code
- declaration in first part of for().
— integer constant type rules
— integer promotion rules
— macros with a variable number of arguments
— trailing comma allowed in enum declaration
— idempotent type qualifiers
— empty macro arguments
— _Pragma preprocessing operator
— standard pragmas
— _ _func_ _ predefined identifier
— conversion of array to pointer not limited to lvalues
— relaxed constraints on aggregate and union initialization
— relaxed restrictions on portable header names
— return without expression not permitted in function that returns a
value (and vice versa)

Disclaimer: that's a long list, and I didn't spend a lot of time to look
into each item; it might contain mistakes, or cases where there's
differences between the C11 and C++17 feature that I didn't notice.

Whether the items on the second list are more important than the items
on the first list is a judgment call, and as such, inherently subjective.
I have no interest in arguing with you about judgment calls. I'm not even claiming that are more important - I didn't bother trying to make that
judgment. I'll limit myself to pointing out the objective fact that there
are more items in the second list.
The key point is that the C++ committee deliberately chose to change 1p2
to refer to C11 rather than C90, implying that, in their judgment,
there's enough features that were added in C99 and C11 that are also in
C++17 to justify making that change. You can disagree with their
judgment on that matter - but it's not an issue I'm willing to bother
discussing.

...
> Finally, let me point out Annex C, "Compatibility", in n4659.
> Paragraph 1 of C.1 says
> 
>     This subclause lists the differences between C++ and ISO C,
>     by the chapters of this document.
> 
> Despite that introduction, AFAICT no language features new to C99
> or C11 are among those compared.  In fact one of the items listed
> is implicit declaration of functions, which hasn't been part of
> standard C for almost 20 years.  Also inline functions are not
> listed.  So the C++ standard itself tacitly concedes the point
> that, as far as the language goes, C++ is based on C90 and not on
> C99 or C11.

At best, it does so indirectly, and only after having explicitly stating
that it is based on C11.

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

#127950

From	Tim Rentsch <txr@alumni.caltech.edu>
Date	2018-03-17 10:29 -0700
Message-ID	<kfnzi36objt.fsf@x-alumni2.alumni.caltech.edu>
In reply to	#127344

jameskuyper@verizon.net writes:

> On Saturday, March 3, 2018 at 5:08:23 AM UTC-5, Tim Rentsch wrote:
>
>> jameskuyper@verizon.net writes:
>>
>>> On Tuesday, February 27, 2018 at 1:02:54 AM UTC-5, Tim Rentsch wrote:
>>>
>>>> Ian Collins <ian-news@hotmail.com> writes:
>>>>
>>>>> Due to C++11 using C99 rather than C89 as its base, [...]
>>>>
>>>> In C++11 and later, C++ uses the C99 library as its base
>>>> library.  It does not use the C99 language as its base
>>>> language.
>>>
>>> "C ++ is a general purpose programming language based on the C
>>> programming language as described in ISO/IEC 9899:2011 Programming
>>> languages ?  C (hereinafter referred to as the C standard).  In
>>> addition to the facilities provided by C, C ++ provides ..."
>>> (n4659.pdf 1p2).
>>>
>>> n3690.pdf refers to 9899:1999 instead of 9899:2011.
>>>
>>> Are you making a distinction between saying "C++ is ... based on
>>> ...  ISO/IEC 9899:1999", and "C99 is the base language for C++"?
>
> I'm presuming, from the nature of your reply below, that your answer to
> that question, had you bothered to make one, would have been "No".  Let
> me know (by explicitly stating what your answer would actually have
> been) if I'm wrong about that.

I am neither making a distinction nor not making a distinction.
I didn't understand how your question related to my statement so
I simply tried to explain that earlier statement further.

>>> If so, could you explain that distinction?
>>
>> C99 has variable length arrays.  C++ does not.
>>
>> C99 has designated initializers.  C++ does not.
>>
>> C99 has compound literals.  C++ does not.
>>
>> C99 has inline functions.  C++ also has inline functions,
>> but with different semantics.
>>
>> C11 has anonymous structs and unions.  C++ does not.
>>
>> C11 has _Generic.  C++ does not.
>>
>> There are other differences;  those are some of the more
>> obvious ones.
>
> Let me extend that list for you.  I took the list of changes from C90
> listed in the C11 foreword, and removed those parts that involved the C
> standard library.  All of the following are C11 differences from C90 that
> are either not present, or implemented differently, in C++17:
>
> ? querying and specifying alignment of objects
> ? no-return functions
> ? more precise aliasing rules via effective type
> ? restricted pointers
> ? static and type qualifiers in parameter array declarators
> ? complex (and imaginary) support in <complex.h>
> ? type-generic math macros in <tgmath.h>
> ? increased minimum translation limits
> ? hexadecimal floating-point constants and %a and %A printf/scanf
> conversion specifiers
> ? IEC 60559 (also known as IEC 559 or IEEE arithmetic) support
> ? new structure type compatibility rules (tag compatibility)
> ? additional predefined macro names
> ? LIA compatibility annex

This list includes some library features and also is incomplete
with respect to language features.

> However, even with those additions, that list still represent only a
> tiny fraction of the total list of features of C11.

Yes, but a large fraction of the differences between C11 and C90,
which is the relevant metric when deciding between whether the
C++ language is more aptly described as based on the C90 language
or the C11 language.

> Before deciding whether C++17 is closer to C99 or C11, you should also
> look at the features of C11 that were changes from C90, and are
> supported in the same way in C++17:
>
> ? Unicode characters and strings
> ? static assertions
> ? restricted character set support via digraphs
> ? the long long int type
> ? remove implicit int
> ? reliable integer division
> ? universal character names (\u and \U)
> ? // comments
> ? extended integer types
> ? remove implicit function declaration
> ? preprocessor arithmetic done in intmax_t/uintmax_t
> ? mixed declarations and code
> - declaration in first part of for().
> ? integer constant type rules
> ? integer promotion rules
> ? macros with a variable number of arguments
> ? trailing comma allowed in enum declaration
> ? idempotent type qualifiers
> ? empty macro arguments
> ? _Pragma preprocessing operator
> ? standard pragmas
> ? _ _func_ _ predefined identifier
> ? conversion of array to pointer not limited to lvalues
> ? relaxed constraints on aggregate and union initialization
> ? relaxed restrictions on portable header names
> ? return without expression not permitted in function that returns a
> value (and vice versa)

What makes you think I hadn't looked at these already?

> Disclaimer: that's a long list, and I didn't spend a lot of time to look
> into each item;  it might contain mistakes, or cases where there's
> differences between the C11 and C++17 feature that I didn't notice.
>
> Whether the items on the second list are more important than the items
> on the first list is a judgment call, and as such, inherently subjective.
> I have no interest in arguing with you about judgment calls.  I'm not
> even claiming that are more important - I didn't bother trying to
> make that
> judgment.  I'll limit myself to pointing out the objective fact that there
> are more items in the second list.

In graduate school I heard a very interesting statement about
universities making decisions regarding whether to award tenure:
"Some places count papers, some places weigh papers, and some
places read papers."

> The key point is that the C++ committee deliberately chose to change 1p2
> to refer to C11 rather than C90, implying that, in their judgment,
> there's enough features that were added in C99 and C11 that are also in
> C++17 to justify making that change.  You can disagree with their
> judgment on that matter - but its not an issue I'm willing to bother
> discussing.

I don't have any reason at this moment to think they are
considering the same question that I was considering.

>> Finally, let me point out Annex C, "Compatibility", in n4659.
>> Paragraph 1 of C.1 says
>>
>>     This subclause lists the differences between C++ and ISO C,
>>     by the chapters of this document.
>>
>> Despite that introduction, AFAICT no language features new to C99
>> or C11 are among those compared.  In fact one of the items listed
>> is implicit declaration of functions, which hasn't been part of
>> standard C for almost 20 years.  Also inline functions are not
>> listed.  So the C++ standard itself tacitly concedes the point
>> that, as far as the language goes, C++ is based on C90 and not on
>> C99 or C11.
>
> At best, it does so indirectly, and only after having
> explicitly stating that it is based on C11.

Yes, the tacit admission gives lie to the explicit statement.

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

#127972

From	Steven Petruzzellis <frelwizzen@gmail.com>
Date	2018-03-18 08:14 -0700
Message-ID	<a5f37d1f-2cb6-4067-94bc-525bbfb3335f@googlegroups.com>
In reply to	#127950

On Saturday, March 17, 2018 at 10:29:53 AM UTC-7, Tim Rentsch wrote:
> jameskuyper@verizon.net writes:
> 
> > On Saturday, March 3, 2018 at 5:08:23 AM UTC-5, Tim Rentsch wrote:
> >
> >> jameskuyper@verizon.net writes:
> >>
> >>> On Tuesday, February 27, 2018 at 1:02:54 AM UTC-5, Tim Rentsch wrote:
> >>>
> >>>> Ian Collins <ian-news@hotmail.com> writes:
> >>>>
> >>>>> Due to C++11 using C99 rather than C89 as its base, [...]
> >>>>
> >>>> In C++11 and later, C++ uses the C99 library as its base
> >>>> library.  It does not use the C99 language as its base
> >>>> language.
> >>>
> >>> "C ++ is a general purpose programming language based on the C
> >>> programming language as described in ISO/IEC 9899:2011 Programming
> >>> languages ?  C (hereinafter referred to as the C standard).  In
> >>> addition to the facilities provided by C, C ++ provides ..."
> >>> (n4659.pdf 1p2).
> >>>
> >>> n3690.pdf refers to 9899:1999 instead of 9899:2011.
> >>>
> >>> Are you making a distinction between saying "C++ is ... based on
> >>> ...  ISO/IEC 9899:1999", and "C99 is the base language for C++"?
> >
> > I'm presuming, from the nature of your reply below, that your answer to
> > that question, had you bothered to make one, would have been "No".  Let
> > me know (by explicitly stating what your answer would actually have
> > been) if I'm wrong about that.
> 
> I am neither making a distinction nor not making a distinction.
> I didn't understand how your question related to my statement so
> I simply tried to explain that earlier statement further.
> 
> >>> If so, could you explain that distinction?
> >>
> >> C99 has variable length arrays.  C++ does not.
> >>
> >> C99 has designated initializers.  C++ does not.
> >>
> >> C99 has compound literals.  C++ does not.
> >>
> >> C99 has inline functions.  C++ also has inline functions,
> >> but with different semantics.
> >>
> >> C11 has anonymous structs and unions.  C++ does not.
> >>
> >> C11 has _Generic.  C++ does not.
> >>
> >> There are other differences;  those are some of the more
> >> obvious ones.
> >
> > Let me extend that list for you.  I took the list of changes from C90
> > listed in the C11 foreword, and removed those parts that involved the C
> > standard library.  All of the following are C11 differences from C90 that
> > are either not present, or implemented differently, in C++17:
> >
> > ? querying and specifying alignment of objects
> > ? no-return functions
> > ? more precise aliasing rules via effective type
> > ? restricted pointers
> > ? static and type qualifiers in parameter array declarators
> > ? complex (and imaginary) support in <complex.h>
> > ? type-generic math macros in <tgmath.h>
> > ? increased minimum translation limits
> > ? hexadecimal floating-point constants and %a and %A printf/scanf
> > conversion specifiers
> > ? IEC 60559 (also known as IEC 559 or IEEE arithmetic) support
> > ? new structure type compatibility rules (tag compatibility)
> > ? additional predefined macro names
> > ? LIA compatibility annex
> 
> This list includes some library features and also is incomplete
> with respect to language features.
> 
> > However, even with those additions, that list still represent only a
> > tiny fraction of the total list of features of C11.
> 
> Yes, but a large fraction of the differences between C11 and C90,
> which is the relevant metric when deciding between whether the
> C++ language is more aptly described as based on the C90 language
> or the C11 language.
> 
> > Before deciding whether C++17 is closer to C99 or C11, you should also
> > look at the features of C11 that were changes from C90, and are
> > supported in the same way in C++17:
> >
> > ? Unicode characters and strings
> > ? static assertions
> > ? restricted character set support via digraphs
> > ? the long long int type
> > ? remove implicit int
> > ? reliable integer division
> > ? universal character names (\u and \U)
> > ? // comments
> > ? extended integer types
> > ? remove implicit function declaration
> > ? preprocessor arithmetic done in intmax_t/uintmax_t
> > ? mixed declarations and code
> > - declaration in first part of for().
> > ? integer constant type rules
> > ? integer promotion rules
> > ? macros with a variable number of arguments
> > ? trailing comma allowed in enum declaration
> > ? idempotent type qualifiers
> > ? empty macro arguments
> > ? _Pragma preprocessing operator
> > ? standard pragmas
> > ? _ _func_ _ predefined identifier
> > ? conversion of array to pointer not limited to lvalues
> > ? relaxed constraints on aggregate and union initialization
> > ? relaxed restrictions on portable header names
> > ? return without expression not permitted in function that returns a
> > value (and vice versa)
> 
> What makes you think I hadn't looked at these already?
> 
> > Disclaimer: that's a long list, and I didn't spend a lot of time to look
> > into each item;  it might contain mistakes, or cases where there's
> > differences between the C11 and C++17 feature that I didn't notice.
> >
> > Whether the items on the second list are more important than the items
> > on the first list is a judgment call, and as such, inherently subjective.
> > I have no interest in arguing with you about judgment calls.  I'm not
> > even claiming that are more important - I didn't bother trying to
> > make that
> > judgment.  I'll limit myself to pointing out the objective fact that there
> > are more items in the second list.
> 
> In graduate school I heard a very interesting statement about
> universities making decisions regarding whether to award tenure:
> "Some places count papers, some places weigh papers, and some
> places read papers."
> 
> > The key point is that the C++ committee deliberately chose to change 1p2
> > to refer to C11 rather than C90, implying that, in their judgment,
> > there's enough features that were added in C99 and C11 that are also in
> > C++17 to justify making that change.  You can disagree with their
> > judgment on that matter - but its not an issue I'm willing to bother
> > discussing.
> 
> I don't have any reason at this moment to think they are
> considering the same question that I was considering.
> 
> >> Finally, let me point out Annex C, "Compatibility", in n4659.
> >> Paragraph 1 of C.1 says
> >>
> >>     This subclause lists the differences between C++ and ISO C,
> >>     by the chapters of this document.
> >>
> >> Despite that introduction, AFAICT no language features new to C99
> >> or C11 are among those compared.  In fact one of the items listed
> >> is implicit declaration of functions, which hasn't been part of
> >> standard C for almost 20 years.  Also inline functions are not
> >> listed.  So the C++ standard itself tacitly concedes the point
> >> that, as far as the language goes, C++ is based on C90 and not on
> >> C99 or C11.
> >
> > At best, it does so indirectly, and only after having
> > explicitly stating that it is based on C11.
> 
> Yes, the tacit admission gives lie to the explicit statement.



If Vennie Bowden calls having his ass handed to him time and time again day in and day out by Allie Higley and me (and completely ruining his reputation and any reason for advocates to give credence to anything he has to say) effective 'trolling', then whatever... he is a great troll. I do not personally agree with that meaning, I use another term. I call Vennie Bowden a total loon. Vennie Bowden must grasp Allie Higley knows he is just being a moron. Vennie Bowden is just thrilled that Allie Higley is on the other end. Imagine if Vennie Bowden walked up to a lobster and delivered the punch line. It wouldn't be amusing in any way. Your system will crawl while this takes place. 

Plasma is definitely my second favorite DE and the only one I suggest to Linux morons. Primary interface is Trinity, though. Low memory use is all you need after dealing with Pulseaudio. It was Vennie Bowden who forged me (and Allie Higley) and did not even try to hide it. 

I shall not ask Vennie Bowden how any part of Allie Higley's body tastes no matter how habitually Vennie Bowden kisses it. I reported him years ago. As expected, it did nothing to attenuate the chowderhead. 

--
Top 15 Ways Vennie Bowden Trolls
http://tinyurl.com/gsleb4p
https://youtu.be/TETJEkaUoY4
http://jeff-relf.me/Cola_Regs.HTM
Jonas Eklundh Communication AB

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

#127048

From	David Brown <david.brown@hesbynett.no>
Date	2018-02-25 21:49 +0100
Message-ID	<p6v7hm$to$1@dont-email.me>
In reply to	#127029

On 25/02/18 12:21, Malcolm McLean wrote:
> On Saturday, February 24, 2018 at 11:06:12 PM UTC, Keith Thompson wrote:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> Keith Thompson <kst-u@mib.org> writes:
>> [...]
>>>> My own preference is to use the current standard unless there's a good
>>>> reason not to.  [...]
>>>
>>> Do you have some reasoning to offer that might explain this bias?
>>> Or do you think of it as just axiomatic?
>>
>> Any attempt to explain my preference would likely lead to a debate that
>> I'm not interested in having.
>>
> The main reason for sticking to C89 is that Microsoft doesn't support
> the more recent standards. But now C89 support in Visual Studio is
> going to be removed too.
> 

That may be /your/ main reason for sticking to C89 - but that does not 
mean it applies to everyone else who uses C89/C90.  Other reasons 
include widest portability (as there are plenty of compilers in current 
use that are C90 only - the world is bigger than x86), coding standards, 
company policy, personal preference, C++ compatibility (compound 
literals are not standard C++), compatibility with additional tools, etc.

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

#127051

From	Keith Thompson <kst-u@mib.org>
Date	2018-02-25 15:09 -0800
Message-ID	<lnlgfgk6nw.fsf@kst-u.example.com>
In reply to	#127029

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Saturday, February 24, 2018 at 11:06:12 PM UTC, Keith Thompson wrote:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> > Keith Thompson <kst-u@mib.org> writes:
>> [...]
>> >> My own preference is to use the current standard unless there's a good
>> >> reason not to.  [...]
>> >
>> > Do you have some reasoning to offer that might explain this bias?
>> > Or do you think of it as just axiomatic?
>> 
>> Any attempt to explain my preference would likely lead to a debate that
>> I'm not interested in having.
>> 
> The main reason for sticking to C89 is that Microsoft doesn't support
> the more recent standards. But now C89 support in Visual Studio is
> going to be removed too.

This answer on Stack Overflow:
    https://stackoverflow.com/a/42043182/827263
refers to this page:
    https://msdn.microsoft.com/en-CA/library/hh409293.aspx
which says that:

    Visual Studio 2015 fully implements the C99 Standard Library, with
    the exception of any library features that depend on compiler
    features not yet supported by the Visual C++ compiler (for example,
    <tgmath.h> is not implemented).

There's no mention of C89/C90 conformance -- but it only refers to
the standard library, not the core language.

A C89/C90 conforming compiler would, for example, have to accept
implicit int and diagnose declarations in for loops.  I don't
know whether Microsoft's compiler can be made to do that.  But it
shouldn't be difficult to write code that conforms to both C89/C90
and C99.  It would make it inconvenient to compile old code, but
arguably such code should be fixed anyway.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#127074

From	gazelle@shell.xmission.com (Kenny McCormack)
Date	2018-02-26 13:46 +0000
Message-ID	<p7133d$c8m$1@news.xmission.com>
In reply to	#127029

In article <3e6e6bf9-d339-48d6-a615-d1ba8898ebc4@googlegroups.com>,
Malcolm McLean  <malcolm.arthur.mclean@gmail.com> wrote:
>On Saturday, February 24, 2018 at 11:06:12 PM UTC, Keith Thompson wrote:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> > Keith Thompson <kst-u@mib.org> writes:
>> [...]
>> >> My own preference is to use the current standard unless there's a good
>> >> reason not to.  [...]
>> >
>> > Do you have some reasoning to offer that might explain this bias?
>> > Or do you think of it as just axiomatic?
>> 
>> Any attempt to explain my preference would likely lead to a debate that
>> I'm not interested in having.
>> 
>The main reason for sticking to C89 is that Microsoft doesn't support
>the more recent standards. But now C89 support in Visual Studio is
>going to be removed too.

For the benefit of those who aren't totally au fait with Malcolm-speak,
what Malcolm is saying here is that MS is pretty much getting out of the C
compiler business entirely - at the retail/consumer level.

That is, their position is that normal people really have no need for C,
and that everyone should be programming in .NET (presumably, C#).  When
this change will actually happen is, of course, anyone's guess.

However, if/when it *does* happen, MS will be pretty much completely OT for
this newsgroup.  And that would be a good thing, certainly in the eyes of
people like Kiki and Dave.

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

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

#127075

From	David Brown <david.brown@hesbynett.no>
Date	2018-02-26 14:57 +0100
Message-ID	<p713p7$lqr$1@dont-email.me>
In reply to	#127074

On 26/02/18 14:46, Kenny McCormack wrote:
> In article <3e6e6bf9-d339-48d6-a615-d1ba8898ebc4@googlegroups.com>,
> Malcolm McLean  <malcolm.arthur.mclean@gmail.com> wrote:
>> On Saturday, February 24, 2018 at 11:06:12 PM UTC, Keith Thompson wrote:
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>> Keith Thompson <kst-u@mib.org> writes:
>>> [...]
>>>>> My own preference is to use the current standard unless there's a good
>>>>> reason not to.  [...]
>>>>
>>>> Do you have some reasoning to offer that might explain this bias?
>>>> Or do you think of it as just axiomatic?
>>>
>>> Any attempt to explain my preference would likely lead to a debate that
>>> I'm not interested in having.
>>>
>> The main reason for sticking to C89 is that Microsoft doesn't support
>> the more recent standards. But now C89 support in Visual Studio is
>> going to be removed too.
> 
> For the benefit of those who aren't totally au fait with Malcolm-speak,
> what Malcolm is saying here is that MS is pretty much getting out of the C
> compiler business entirely - at the retail/consumer level.
> 

As far as I understand it, MS have replaced their C compiler with clang
for the front end, but keeping their own backend from MSVC.  You still
get a C compiler from MS with MSVS, but it is no longer their own old
one.  Certainly they don't see C as a major language for Windows
programming, nor do they see C development tools as a source of income -
and therefore they don't want to put much effort into making or
supporting C tools.

But I don't believe they are moving out of the C++ business - they are
heavily involved in C++ standards, libraries, etc.  And as has been
pointed out, newer C++ is being re-based roughly on C99 rather than
roughly C89.  It is, of course, quite possible that they will move to
clang for the C++ frond end too, and maybe even llvm for the backend -
but I don't know anything about that.

> That is, their position is that normal people really have no need for C,
> and that everyone should be programming in .NET (presumably, C#).  When
> this change will actually happen is, of course, anyone's guess.

It will probably happen approximately at the time when MS starts trying
to move everyone over to a new and incompatible G# language that is a
bit like Go, or S# that is a bit like Swift :-)

> 
> However, if/when it *does* happen, MS will be pretty much completely OT for
> this newsgroup.  And that would be a good thing, certainly in the eyes of
> people like Kiki and Dave.
>

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

#127114

From	Tim Rentsch <txr@alumni.caltech.edu>
Date	2018-02-26 22:14 -0800
Message-ID	<kfnsh9nrmbf.fsf@x-alumni2.alumni.caltech.edu>
In reply to	#127025

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>
>> Keith Thompson <kst-u@mib.org> writes:
>
> [...]
>
>>> My own preference is to use the current standard unless there's a good
>>> reason not to.  [...]
>>
>> Do you have some reasoning to offer that might explain this bias?
>> Or do you think of it as just axiomatic?
>
> Any attempt to explain my preference would likely lead to a debate that
> I'm not interested in having.
>
> [...]
>
>>> So rather than a cast
>>>     printf("%p\n", (void*)some_pointer);
>>> you'd use a compound literal with exactly the same semantics?
>>>     printf("%p\n", (void*){ some_pointer });
>>>
>>> I've never seen that, and it would never have occurred to me.  After
>>> considering it, I'd still use the cast.
>>>
>>> An advantage of the compound literal is that it relies on the implicit
>>> conversion, so it will fail to compile if the expression isn't one that
>>> can be implicitly converted to void*.  In my opinion, that's not enough
>>> of an advantage to justify it.
>>>
>>> I agree that casting should almost always be avoided.  Arguments to
>>> variadic functions are one of the rare cases where I consider them
>>> appropriate.
>>
>> I'm mystified by your reasoning here.  You point out an advantage
>> for using a compound literal.  You don't point out any advantages
>> for using a cast.  If we're going to be using C99 or later then
>> ISTM that cast choice is all downside with no upside.  Or is what
>> you're saying something akin to "we should keep doing things the
>> older, riskier way because that's what people are used to"?
>> What's the point of switching to a more current standard if you
>> carry over all the old bad habits from the earlier standards?
>
> The compound literal form is in my opinion relatively obscure,
> and likely to be confusing to many readers.  I rarely use or see
> compound literals, and when I do they're usually for aggregate types.
> (No doubt that's largely the result of inertia.)  And the need
> to compile with a C90 compiler is rare these days, but not yet
> entirely nonexistent.

The combination of these different views is quite striking.

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

#126965

From	"F. Russell" <fr@random.info>
Date	2018-02-22 00:11 +0000
Message-ID	<p6l1r802prr@news1.newsguy.com>
In reply to	#126930

On Wed, 21 Feb 2018 08:07:25 -0800, Tim Rentsch wrote:

> 
> Okay I'm stopping here.  There may have been something else I
> wanted to mention but if so I don't remember what it is,
>

Maybe it was the "else" ambiguities that are found in peiConvolve.c:421
and peiCache.c:138.

Here is the one from peiConvolve.c:

	if (signMode==-1)
	    if (mode&MODE_MAG) signMode=0;
	    else signMode=peiGetSigned(src)||peiGetSigned(&ker)?1:0;
	if ((conv=peiCreateCachedConvolution("",src,&ker,mode,factor,signMode,1))==NULL) MFAIL(1149);

There are two possible ways to group the "else" cause and
unless one has intimate knowledge of the program details
there is no way to decide which is correct.

I have left things as written with the test being that images
are successfully processed.

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

#126968

From	Joe Pfeiffer <pfeiffer@cs.nmsu.edu>
Date	2018-02-21 17:27 -0700
Message-ID	<1b606p6f7g.fsf@pfeifferfamily.net>
In reply to	#126965

"F. Russell" <fr@random.info> writes:

> On Wed, 21 Feb 2018 08:07:25 -0800, Tim Rentsch wrote:
>
>> 
>> Okay I'm stopping here.  There may have been something else I
>> wanted to mention but if so I don't remember what it is,
>>
>
> Maybe it was the "else" ambiguities that are found in peiConvolve.c:421
> and peiCache.c:138.
>
> Here is the one from peiConvolve.c:
>
> 	if (signMode==-1)
> 	    if (mode&MODE_MAG) signMode=0;
> 	    else signMode=peiGetSigned(src)||peiGetSigned(&ker)?1:0;
> 	if ((conv=peiCreateCachedConvolution("",src,&ker,mode,factor,signMode,1))==NULL) MFAIL(1149);
>
> There are two possible ways to group the "else" cause and
> unless one has intimate knowledge of the program details
> there is no way to decide which is correct.

Except that else always groups with the closest if.  If there are no
braces you can assume that's what's meant, especially since (unless the
author used really screwy indentation) it's the grouping implied by the
indentation.

> I have left things as written with the test being that images
> are successfully processed.

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

#126899

From	Keith Thompson <kst-u@mib.org>
Date	2018-02-20 09:30 -0800
Message-ID	<lno9kjmuve.fsf@kst-u.example.com>
In reply to	#126883

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> There is another, optional, type -- intptr_32_t -- which, if provided,
> is guaranteed to be big enough to hold a pointer.  You probably need to
> use it here.

You mean intptr_t, not intptr_32_t.  (I generally prefer to use
uintptr_t, which I find conceptually a little clearer, but it probably
doesn't matter.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#126910

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2018-02-21 00:23 +0000
Message-ID	<87zi431987.fsf@bsb.me.uk>
In reply to	#126899

Keith Thompson <kst-u@mib.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> [...]
>> There is another, optional, type -- intptr_32_t -- which, if provided,
>> is guaranteed to be big enough to hold a pointer.  You probably need to
>> use it here.
>
> You mean intptr_t, not intptr_32_t.

Thanks, yes.  Too much typing of both int32_t and intptr_t.

> (I generally prefer to use
> uintptr_t, which I find conceptually a little clearer, but it probably
> doesn't matter.)

I do too when the integer has no other purpose but to hold a pointer,
but here the int32_t values are probably used as integers, so switching
to an unsigned type might introduce a range of mysterious misbehaviours.

-- 
Ben.

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

#126886

From	Joe Pfeiffer <pfeiffer@cs.nmsu.edu>
Date	2018-02-20 09:11 -0700
Message-ID	<1bpo4z63qj.fsf@pfeifferfamily.net>
In reply to	#126878

"F. Russell" <fr@random.info> writes:
>
> #define peiGetOps(image)	  (((imageType*)(image))->ops)
> #define peiGetWidth(image)	  (((imageType*)(image))->width)
> #define peiGetHeight(image)	  (((imageType*)(image))->height)
> #define peiGetDepth(image)	  (((imageType*)(image))->depth)
> #define peiGetLinebytes(image)	  (((imageType*)(image))->linebytes)

The original author of the program was either not careful about types,
or was overly cautious in ways that could hurt him.  All of these simply
cast the argument to type imageType* (which it should have been anyway),
and then access fields of the struct.

> Here, the variable "image" is a pointer to the struct "imageType"
> which is defined earlier in the file.  (To those who can't download
> a copy of the source I will append the code for the struct at the
> end of this message.)
>
> I can't understand the need for these constructions.  To fix the program,
> among other things, I was able to rewrite these as follows:
>
> #define peiGetOps(image)	  image->ops
> #define peiGetWidth(image)	  (*image).width
> #define peiGetHeight(image)	  (*image).height
> #define peiGetDepth(image)	  (*image).depth
> #define peiGetLinebytes(image)	  image->linebytes

He's also being careful to keep from being burned by the order of
evaluations in C, which is a good idea.  If the pointer is being
constructed with some sort of expression, the parentheses prevent
surprises in how things are compiled.  Suppose there are several images,
and (for reasons that don't matter here) you access the third one as
imageBase + 3.  Then if you apply your first macro as
peiGetOps(imageBase + 3), the code turns into imageBase + 3->ops.  Even
if your program doesn't actually do that, parenthesizing the arguments
appearing in a macro is a good habit to get into.

Your dereferencing of the pointer and then taking a field is equivalent
to his ->.  -> is the more normal way to do it, and people looking at
your code will wonder why you did it that way.

> Note that these 5 lines are just a few of many examples of
> this kind.
>
> But even more puzzling (to me) are the following lines:
>
> #define peiGetConvertSrc(image)		(*(imageType**)&(image)->clientData[0])
> #define peiGetConvertOp(image)		(*(int32_t*)&(image)->clientData[2])
>
> I can't even begin to deconstruct these.  Can someone explain what
> is going on?

These are indeed harder to understand; some more parenthese would be
helpful.  Let's take a look at the first one:

(image)->clientData[0]

Take the first element of array (array)->clientdata

&(image)->clientData[0])

Take its address

(imageType**)&(image)->clientData[0]

cast it to an imageType** (a pointer to a pointer to imageType)

(*(imageType**)&(image)->clientData[0])

Dereference the pointer, giving us an imageType*

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

#126889

From	"F. Russell" <fr@random.info>
Date	2018-02-20 16:38 +0000
Message-ID	<p6hitf21a6s@news1.newsguy.com>
In reply to	#126886

On Tue, 20 Feb 2018 09:11:00 -0700, Joe Pfeiffer wrote:

> 
> &(image)->clientData[0])
> 
> Take its address
> 

To me, this was the confusing part.  Why are the parentheses only
around image?  Shouldn't they be around the entire expression:

&(image->clientData[0])







> (imageType**)&(image)->clientData[0]
> 
> cast it to an imageType** (a pointer to a pointer to imageType)
> 
> (*(imageType**)&(image)->clientData[0])
> 
> Dereference the pointer, giving us an imageType*

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

#126893

From	bartc <bc@freeuk.com>
Date	2018-02-20 17:07 +0000
Message-ID	<yBYiC.1243174$w26.880280@fx47.am4>
In reply to	#126889

On 20/02/2018 16:38, F. Russell wrote:
> On Tue, 20 Feb 2018 09:11:00 -0700, Joe Pfeiffer wrote:
> 
>>
>> &(image)->clientData[0])
>>
>> Take its address
>>
> 
> To me, this was the confusing part.  Why are the parentheses only
> around image?  Shouldn't they be around the entire expression:
> 
> &(image->clientData[0])

Here it doesn't matter, as -> is evaluated before &.

But if this was a macro definition, 'image' is the parameter passed.

If the invocation of the macro passed X+1 instead of X, then without the 
brackets, it would expand to:

  &X+1->clientData[0]

which won't work. Adding the brackets as you say would make it 
&(X+1->clientData[0]), which is little better.

--
bartc

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

#126894

From	John Bode <jfbode1029@gmail.com>
Date	2018-02-20 09:09 -0800
Message-ID	<9c6a7bfa-6a1a-44ae-b97e-e583655b2ebd@googlegroups.com>
In reply to	#126889

On Tuesday, February 20, 2018 at 10:39:26 AM UTC-6, F. Russell wrote:
> On Tue, 20 Feb 2018 09:11:00 -0700, Joe Pfeiffer wrote:
> 
> > 
> > &(image)->clientData[0])
> > 
> > Take its address
> > 
> 
> To me, this was the confusing part.  Why are the parentheses only
> around image?  Shouldn't they be around the entire expression:
> 
> &(image->clientData[0])
> 
> 

Remember that macro arguments are not evaluated; they are merely expanded in place. 
If someone called that macro as

    peiGetConvertSrc(foo+1)

your version would expand to

    &(foo+1->clientData[0])

which would be a syntax error.  It's usually best practice to surround any macro argument
with parens.

Postfix -> has higher precedence than unary &, so 

    &(image)->clientData[0]

will be parsed as

    &((image)->clientData[0])


> 
> 
> 
> 
> 
> > (imageType**)&(image)->clientData[0]
> > 
> > cast it to an imageType** (a pointer to a pointer to imageType)
> > 
> > (*(imageType**)&(image)->clientData[0])
> > 
> > Dereference the pointer, giving us an imageType*

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

#126895

From	"James R. Kuyper" <jameskuyper@verizon.net>
Date	2018-02-20 12:18 -0500
Message-ID	<29be90f9-a095-3297-4450-2c58b58da957@verizon.net>
In reply to	#126889

On 02/20/2018 11:38 AM, F. Russell wrote:
> On Tue, 20 Feb 2018 09:11:00 -0700, Joe Pfeiffer wrote:
> 
>>
>> &(image)->clientData[0])
>>
>> Take its address
>>
> 
> To me, this was the confusing part.  Why are the parentheses only
> around image?  Shouldn't they be around the entire expression:
> 
> &(image->clientData[0])

The general rule for function-like macros that expands into a single 
expression is that you should parenthesize every occurrence of one of 
the macro's arguments, and also the entire expression.

Consider a simple case (too simple to actually be useful, but good for 
demonstrating the principle):

     #define EQ(a, b) ((a) == (b))

What would happen if you didn't parenthesize the arguments, but only the 
expression as a whole, and someone decided to write EQ(w&x, y&z)? Then 
the macro would expand as

     (w & x == y & z)

Which is equivalent to

     w & (x==y) & z

which is (presumably) not what was intended. The only time you can leave 
out the parenthesis on an argument is when there's no operator with a 
lower precedence than the one it's an operand of - which means it would 
have to be an operand of the comma operator.

Similarly, consider what would happen if you only parenthesized the 
arguments, and not the entire expression, and someone decided to write 
EQ(a, b) + EQ(c, d):

    (a) == (b) + (c) == (d)

which would parse as

    (a) == ((b) + (c)) == (d)

which, again, is probably not what was intended. The only time you can 
leave out the parentheses on the entire expression is when there is no 
operator with a higher precedence than the highest level operand in the 
expression, which means it must be a postfix expression.

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

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

csiph-web

C Construction Problem

Contents

#127313

#127339

#128013

#127344

#127950

#127972

#127048

#127051

#127074

#127075

#127114

#126965

#126968

#126899

#126910

#126886

#126889

#126893

#126894

#126895