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

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

OT: improve this simple algorithm?

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

Contents

  OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-12 15:55 -0500
    Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-12 21:20 +0000
      Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-12 23:28 -0500
        Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-13 10:52 +0100
          Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-13 10:16 -0500
            Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-13 16:53 +0100
        Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-13 11:18 +0000
    Re: OT: improve this simple algorithm? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-12 23:30 +0000
      Re: OT: improve this simple algorithm? Ian Collins <ian-news@hotmail.com> - 2019-11-15 05:12 +1300
        Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 16:34 +0000
          Re: OT: improve this simple algorithm? Ian Collins <ian-news@hotmail.com> - 2019-11-15 10:07 +1300
            Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 22:25 +0000
              Re: OT: improve this simple algorithm? Ian Collins <ian-news@hotmail.com> - 2019-11-15 12:02 +1300
                Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 23:27 +0000
                  Re: OT: improve this simple algorithm? Ian Collins <ian-news@hotmail.com> - 2019-11-15 19:06 +1300
                    Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-15 10:45 +0000
                      Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-15 13:28 +0100
                        Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-15 12:58 +0000
                          Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-15 15:39 +0100
                            Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-15 15:04 +0000
                              Re: OT: improve this simple algorithm? Richard Damon <Richard@Damon-Family.org> - 2019-11-15 12:19 -0500
                                Re: OT: improve this simple algorithm? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-15 09:46 -0800
                                Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-15 18:59 +0000
                            Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-16 11:59 +0000
                      Re: OT: improve this simple algorithm? Ian Collins <ian-news@hotmail.com> - 2019-11-16 09:02 +1300
                Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-15 11:17 +0100
                  Re: OT: improve this simple algorithm? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-11-15 21:38 +0000
      Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-14 11:44 -0500
        Re: OT: improve this simple algorithm? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-14 18:11 +0000
          Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-14 13:33 -0500
            Re: OT: improve this simple algorithm? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-15 01:49 +0000
        Re: OT: improve this simple algorithm? Barry Schwarz <schwarzb@delq.com> - 2019-11-14 10:38 -0800
      Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-14 12:56 -0500
        Re: OT: improve this simple algorithm? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-14 13:50 -0500
          Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-14 14:42 -0500
            Re: OT: improve this simple algorithm? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-14 15:25 -0500
        Re: OT: improve this simple algorithm? Barry Schwarz <schwarzb@delq.com> - 2019-11-14 11:03 -0800
          Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-14 16:08 -0500
            Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-15 11:30 +0100
              Re: OT: improve this simple algorithm? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-15 11:17 +0000
                Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-15 17:35 -0500
                  Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-15 17:39 -0500
                  Re: OT: improve this simple algorithm? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-15 23:19 +0000
                    Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-15 18:53 -0500
                      Re: OT: improve this simple algorithm? Richard Damon <Richard@Damon-Family.org> - 2019-11-15 19:08 -0500
                      Re: OT: improve this simple algorithm? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-16 01:30 +0000
                        Re: OT: improve this simple algorithm? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-16 07:39 -0500
                  Re: OT: improve this simple algorithm? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-16 07:37 -0500
            Re: OT: improve this simple algorithm? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-15 09:46 -0500
              Re: OT: improve this simple algorithm? Richard Damon <Richard@Damon-Family.org> - 2019-11-15 12:38 -0500
                Re: OT: improve this simple algorithm? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-15 23:07 +0000
                Re: OT: improve this simple algorithm? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 16:54 -0800
                  Re: OT: improve this simple algorithm? Richard Damon <Richard@Damon-Family.org> - 2019-11-28 20:17 -0500
                    Re: OT: improve this simple algorithm? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-29 06:08 -0800
        Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 20:45 +0100
      Re: OT: improve this simple algorithm? Keith Thompson <kst-u@mib.org> - 2019-11-14 10:10 -0800
        Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 20:19 +0100
      Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-12 23:57 -0500
        Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-13 10:34 +0100
      Re: OT: improve this simple algorithm? DFS <nospam@dfs.com> - 2019-11-13 23:57 -0500
        Re: OT: improve this simple algorithm? Barry Schwarz <schwarzb@delq.com> - 2019-11-13 23:00 -0800
        Re: OT: improve this simple algorithm? Ike Naar <ike@sdf.lonestar.org> - 2019-11-14 07:53 +0000
          Re: OT: improve this simple algorithm? guinness.tony@gmail.com - 2019-11-14 02:34 -0800
        Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 10:01 +0100
          Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 11:27 +0000
            Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 12:46 +0100
              Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 12:01 +0000
                Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 14:05 +0100
    Re: OT: improve this simple algorithm? Barry Schwarz <schwarzb@delq.com> - 2019-11-12 18:34 -0800
      Re: OT: improve this simple algorithm? Keith Thompson <kst-u@mib.org> - 2019-11-12 19:01 -0800
        Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 17:08 +0100
          Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 17:06 +0000
          Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 19:11 +0000
        Re: OT: improve this simple algorithm? Ian Collins <ian-news@hotmail.com> - 2019-11-15 05:15 +1300
        Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 18:13 +0000
          Re: OT: improve this simple algorithm? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 20:16 +0100
            Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 20:03 +0000
              Re: OT: improve this simple algorithm? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-15 04:51 +0100
        Re: OT: improve this simple algorithm? Keith Thompson <kst-u@mib.org> - 2019-11-14 10:15 -0800
          Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 20:52 +0100
        Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-13 10:57 +0100
          Re: OT: improve this simple algorithm? Ian Collins <ian-news@hotmail.com> - 2019-11-13 23:23 +1300
          Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-13 11:53 +0000
            Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-13 14:02 +0100
              Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-13 13:40 +0000
                Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-13 17:01 +0100
                  Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-13 16:28 +0000
                    Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-13 22:49 +0100
                      Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-13 22:38 +0000
                        Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-13 23:06 +0000
                        Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 10:10 +0100
                          Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 10:42 +0000
                            Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 12:53 +0100
                              Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 12:28 +0000
                                Re: OT: improve this simple algorithm? David Brown <david.brown@hesbynett.no> - 2019-11-14 14:21 +0100
                                  Re: OT: improve this simple algorithm? Bart <bc@freeuk.com> - 2019-11-14 14:28 +0000
                                    Re: OT: improve this simple algorithm? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 15:38 +0100
                        Re: OT: improve this simple algorithm? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 13:37 +0100
                          Re: OT: improve this simple algorithm? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 13:38 +0100
            Re: OT: improve this simple algorithm? Thiago Adams <thiago.adams@gmail.com> - 2019-11-13 05:21 -0800

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

#148031

On 11/15/19 10:04 AM, Bart wrote:
> 
> It wouldn't make /my/ life easier.
> 
> /I/ find it annoying that if I'm having trouble building some open
> source program on Windows, the suggestions that are made involve using
> WSL; or MSYS2, or CYGWIN; or give up on that POS OS and use a real one
> like Linux. Or I get insulted as to my capabilities.
> 

Bart,
I will say this sort of highlight a base problem of a lot of your
statements. You want all of the stuff out there that were developed to
handle somewhat general problems to work exactly as YOU want for YOUR
specific situation. There are lots of reasons things are done the way
they are, and one needs to accept that, or be willing to do the work to
adapt.

A lot of open source software is developed in an open source based
environment, which include the OS. Some will make more effort than
others to adapt it to the closed Windows system, and it isn't THEIR
fault that they didn't provide an easy way to use it with Windows.

There are some standard problems writing tools that work over a variety
of systems, and one disadvantage of open source is that it is easy to
create a separate branch of the code base, and that branch will likely
develop differences to the 'main' version, and if several branches get
popular, other things that want to work with all of them need to adapt
to the differences.

There IS a learning curve to learn how to adapt those systems to bring
them into a foreign environment they weren't designed for. Some times it
seems like Microsoft intentionally made choices to be different and make
it hard, but I suspect that some were made by the open source side to be
different and many of them are just things where neither side cared to
make compatibility of high importance and just took different roads.

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

#148033

On Friday, 15 November 2019 17:20:15 UTC, Richard Damon  wrote:
> Some times it
> seems like Microsoft intentionally made choices to be different and make
> it hard, but I suspect that some were made by the open source side to be
> different and many of them are just things where neither side cared to
> make compatibility of high importance and just took different roads.
>
Apple won't accept software for the IPhone that runs an emulation
layer. It must use raw native GUI elements.

Partly this is quality control, emulation layers are generally a bit slower 
than writing to native functions. And they don't have quite the same "look
and feel". But also it is an attempt to differentiate the product, and
make it more expensive to port software between platforms. Apple doesn't
want to sell a commodity platform that runs the same software as every 
other phone manufacturer out there. It wants to sell special phones that
say something about the purchaser and have apps that you can't get for
other manufacturers' devices.

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

#148034

On 15/11/2019 17:19, Richard Damon wrote:
> On 11/15/19 10:04 AM, Bart wrote:
>>
>> It wouldn't make /my/ life easier.
>>
>> /I/ find it annoying that if I'm having trouble building some open
>> source program on Windows, the suggestions that are made involve using
>> WSL; or MSYS2, or CYGWIN; or give up on that POS OS and use a real one
>> like Linux. Or I get insulted as to my capabilities.
>>
> 
> Bart,
> I will say this sort of highlight a base problem of a lot of your
> statements. You want all of the stuff out there that were developed to
> handle somewhat general problems to work exactly as YOU want for YOUR
> specific situation.

No; what a lot of people want. Or rather, simply what is necessary.


  There are lots of reasons things are done the way
> they are, and one needs to accept that, or be willing to do the work to
> adapt.
> 
> A lot of open source software is developed in an open source based
> environment, which include the OS. Some will make more effort than
> others to adapt it to the closed Windows system, and it isn't THEIR
> fault that they didn't provide an easy way to use it with Windows.

What aspects of Windows' closed source cause difficulties? (As though 
people routinely trawl through Linux's tens of millions of lines of open 
source!)

> There IS a learning curve to learn how to adapt those systems to bring
> them into a foreign environment they weren't designed for. Some times it
> seems like Microsoft intentionally made choices to be different and make
> it hard,

Examples?

I've looked for a project simple enough, yet that can illustrate the 
problems I have. See https://github.com/jpoirier/picoc, a small C 
interpreter.

This has the usual makefile, that didn't work with the two make programs 
I tried, but looking at it closer, it's design to build for Unix. There 
is a project file for MSVC, but MSVC is a rather large and cumbersome 
download (actually, some 50,000 time bigger than the executable we're 
trying to build). And it probably wouldn't work, IME...

It turns out that building this app for Windows requires compiling and 
linking these 22 files:

  clibrary.c
  debug.c
  expression.c
  heap.c
  include.c
  lex.c
  parse.c
  picoc.c
  platform.c
  table.c
  type.c
  variable.c
  platform/library_msvc.c
  platform/platform_msvc.c
  cstdlib/ctype.c
  cstdlib/errno.c
  cstdlib/math.c
  cstdlib/stdbool.c
  cstdlib/stdio.c
  cstdlib/stdlib.c
  cstdlib/string.c
  cstdlib/time.c

Put them in a @file, and it's done. (The slashes have to be forward 
ones, otherwise gcc doesn't like it.)

I built it using bcc and gcc (tcc had a problem, which I may look at 
later, if only to compare the exes).

It can really be that simple. But I had to figure all this out by trial 
and error, when some suitable docs would have saved me some effort.

(It also needed this tweak, adding the stdint to the _WIN32 branch)

  /* host platform includes */
  #ifdef UNIX_HOST
  # include <stdint.h>
  # include <unistd.h>
  #elif defined(_WIN32) /*(predefined on MSVC)*/
  # include <stdint.h>
  #else
  # error ***** A platform must be explicitly defined! *****
  #endif


> but I suspect that some were made by the open source side to be
> different and many of them are just things where neither side cared to
> make compatibility of high importance and just took different roads.

No, the developers just assume everyone else will use Linux, so whatever 
they themselves use to build can be bundled unchanged, and it will 
probably work, because whoever builds it will have the same ecosystem.

As for Windows, sometimes you see these MSVC project files bundled, but 
I've never found them helpful.

As I showed here, you don't need to run MSVC. And you don't really need 
the makefile; just a more suitable readme.

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

#148047

On 15/11/2019 14:39, David Brown wrote:
> On 15/11/2019 13:58, Bart wrote:
> 
>> You like your tools, I like mine let's leave it at that.
>>
> 
> If you can leave it at that, then fair enough.  Stop spreading your fud,
> lies, exaggerations, and incompetence when other people are discussing
> other tools.  If there is a discussion about good tools to aid C
> development, and good software development processes, then please do not
> join in and cause irritation and confusion just because /you/ can't
> cope.  When people are asking for limited but tiny and fast tools, or
> about how to make a simple C compiler, or about private languages, then
> of course it makes sense to talk about your own tools.
> 
> It gets really annoying that whenever there is a thread or branch
> discussing tools, and ways to make developers' lives easier (whether
> they are beginners or serious developers), we /always/ have to fight
> your posts telling people how difficult it all is, why C is so terrible,
> how unfair it is that others can use compilers and build systems that
> are beyond your understanding, and how fantastic you find it to save
> milliseconds on compile times.
> 
> If you were selling your compilers and your languages, I could
> understand where you are coming from.  As it is, the only motivation I
> can think of is that you write to bug people.
> 

This is a rationale I wrote in August 2017 for my 'bcc' compiler (then 
called 'mcc'):

   https://github.com/sal55/langs/blob/master/aims.md

At the time, the only similar competition was the older version of tcc, 
last updated 2013 (and which didn't seem to be readily available on Linux).

Since then, bcc has become self-contained and able to build a whole 
project in one invocation (previously it could do a module at a time 
only). But then tcc has had significant updates too.

bcc is now only used in a private capacity (half the time, as a test 
program for my other compilers).

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

#148035

On 15/11/2019 23:45, Bart wrote:
> On 15/11/2019 06:06, Ian Collins wrote:
>> On 15/11/2019 12:27, Bart wrote:
>>> On 14/11/2019 23:02, Ian Collins wrote:
>>>> On 15/11/2019 11:25, Bart wrote:
>>>
>>>>> (My main machine is Windows 7.)
>>>>
>>>> That explains a lot...
>>>
>>> Sorry, it explains what?
>>
>> Why you [hit so] many problems.  More modern Windows is a much better
>> environment.
> 
> The problems occur trying to emulate or import Linux with all its
> multitudinous systems and utilities that your and others' software
> development seems to depend on.

Which is one of the reasons I suggested more modern Windows, you have 
have the best of both Windows and Linux worlds without all of the 
compromise packages that give you so much to complain about.

> I on the other hand have never got in to any of that. I'm used to
> development with zero or minimal other software to help out, and
> therefore used to being self-sufficient.
> 
> I think that is still a useful trait now, when you look at what people
> seem to need to build the simplest application.

I don't think anyone denies it's good to be able to work with zero or 
minimal other software to help out.  Certainly not anyone who has had to 
debug software on remote systems on a serial console over dial-up!  Mind 
you, you probably couldn't do that with a remote Windows 7 machine...

-- 
Ian

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

#148021

On 15/11/2019 00:02, Ian Collins wrote:
> On 15/11/2019 11:25, Bart wrote:

>>
>> (My main machine is Windows 7.)
> 
> That explains a lot...  You do realise that it will turn into a pumpkin
> in a couple of months on 14/01/20?
> 

<OT rant>

I'm somewhat with Bart on this one.  The biggest single gripe I have
with Windows is that you are practically forced into using the latest
version, and continuous useless "fixes", whether it is a good thing or
not.  I have seen endless problems over the years with newer Windows
versions working badly or interacting badly with particular hardware or
software.  Maybe the software or hardware is old - but why should we
have to stop using it just because some git at Microsoft decides we all
want computers that look like giant telephones?

Windows traditionally alternates between reasonably good versions, and
terrible versions.  Win 7 was one of the good ones.  Win 8 was terrible.
 In an attempt to break the pattern, MS skipped the expected good Win 9
and jumped straight to the PITA that is Win 10.  While there is no doubt
that there are some things Win 10 does better (there is always some
improvements), at my company we'd upgrade the Win 10 systems to Win 7
without a second thought, if it were possible.

People don't want "support" from MS for old Windows versions - they just
want availability.  (Actually, they don't usually want "support" from MS
anyway, it is rarely helpful and the only noticeable effect of almost
any update or "hotfix" is a disruption to your use of the computer.)


Blame Bart for his extraordinary ability to screw up compiler
installations, but don't blame him for choosing Win 7 over Win 10.

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

#148037

On Fri, 2019-11-15, David Brown wrote:
> On 15/11/2019 00:02, Ian Collins wrote:
>> On 15/11/2019 11:25, Bart wrote:
>
>>>
>>> (My main machine is Windows 7.)
>> 
>> That explains a lot...  You do realise that it will turn into a pumpkin
>> in a couple of months on 14/01/20?
>> 
>
> <OT rant>
>
> I'm somewhat with Bart on this one.  The biggest single gripe I have
> with Windows is that you are practically forced into using the latest
> version, and continuous useless "fixes", whether it is a good thing or
> not.

IMHO, it's a problem with a lot of software, e.g. Firefox and (to some
extent) Linux distributions.  Stuff like Gnome too I suspect.

https://xkcd.com/2224/

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#147985

On 11/14/2019 2:00 AM, Barry Schwarz wrote:
> On Wed, 13 Nov 2019 23:57:47 -0500, DFS <nospam@dfs.com> wrote:
> 
> <snip>
> 
>> That recursion is pretty cool.
>>
>> I was inspired to decrapify mine (still iterative tho):
>> ================================================================
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> int main(void) {
>>
>>    int seq[] = {1, 2, 4, 5, 7, 8, 12, 1300, 10000};
>>
>>    for(int i=0; i < (sizeof(seq) / sizeof(seq[0])); i++) {
> 
> That sizeof expression evaluates to 9.
> 
>>      if(seq[i + 1] - seq[i] > 1) {
> 
> The above statement causes undefined behavior when i is 8.

I got unlucky that seq[9] = 0.


>>        if( seq[i + 1] - (seq[i] + 1) >= 1) {
> 
> Ditto.
> 
> On the other hand, this statement serves no purpose.  When the first
> if is true, this one must be true also.  
>Consider -
> 
> When the first if is true:
>     seq[i] contains the value n
>     seq[i+1] - n  > 1 implies that seq[i+1] contains the value n+k
>    n+k - n is simply k and k > 1 means k >= 2
> 
> The second if evaluates n+k - (n+1) which is simply k-1 and since
> k >= 2 then k-1 >= 1.
> 
>>          printf("[%d,%d] ", seq[i] + 1, seq[i + 1] - 1);
>>        }
>>      }		
>>    }
>>
>> }
>> ================================================================


Nice analysis, Barry.  Thanks for looking at it.



Revision:
================================================================
#include <stdio.h>
#include <stdlib.h>

int main(void) {

   int seq[] = {1, 2, 4, 5, 7, 8, 12, 13, 1300, 10000};

   for(int i=0; i < (sizeof(seq) / sizeof(seq[0])) - 1; i++) {
     if(seq[i + 1] - seq[i] > 1) {
       printf("[%d,%d] ", seq[i] + 1, seq[i + 1] - 1);
     }		
   }

}
================================================================

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

#147989

DFS <nospam@dfs.com> writes:

> #include <stdio.h>
> #include <stdlib.h>
>
> int main(void) {
>
>   int seq[] = {1, 2, 4, 5, 7, 8, 12, 13, 1300, 10000};
>
>   for(int i=0; i < (sizeof(seq) / sizeof(seq[0])) - 1; i++) {
>     if(seq[i + 1] - seq[i] > 1) {
>       printf("[%d,%d] ", seq[i] + 1, seq[i + 1] - 1);
>     }

A small point...  When dealing with pairs, I like to run the loop from
1:

   for (int i = 1; i < sizeof seq / sizeof seq[0]; i++)

and change i+1 and i to i and i-1 in the body.  Don't know why, just
seem a little neater and more obvious to check.

>   }
> }

-- 
Ben.

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

#147992

On 11/14/2019 1:11 PM, Ben Bacarisse wrote:
> DFS <nospam@dfs.com> writes:
> 
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> int main(void) {
>>
>>    int seq[] = {1, 2, 4, 5, 7, 8, 12, 13, 1300, 10000};
>>
>>    for(int i=0; i < (sizeof(seq) / sizeof(seq[0])) - 1; i++) {
>>      if(seq[i + 1] - seq[i] > 1) {
>>        printf("[%d,%d] ", seq[i] + 1, seq[i + 1] - 1);
>>      }
> 
> A small point...  When dealing with pairs, I like to run the loop from
> 1:
> 
>     for (int i = 1; i < sizeof seq / sizeof seq[0]; i++)
> 
> and change i+1 and i to i and i-1 in the body.  Don't know why, just
> seem a little neater and more obvious to check.
> 
>>    }
>> }


I'm the opposite.

I like starting at 0, to match with the index address.

And I like to check the next value less the current, not the current 
less the previous.

You may be mentally ill.

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

#148014

DFS <nospam@dfs.com> writes:

> On 11/14/2019 1:11 PM, Ben Bacarisse wrote:
>> DFS <nospam@dfs.com> writes:
>>
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>>
>>> int main(void) {
>>>
>>>    int seq[] = {1, 2, 4, 5, 7, 8, 12, 13, 1300, 10000};
>>>
>>>    for(int i=0; i < (sizeof(seq) / sizeof(seq[0])) - 1; i++) {
>>>      if(seq[i + 1] - seq[i] > 1) {
>>>        printf("[%d,%d] ", seq[i] + 1, seq[i + 1] - 1);
>>>      }
>>
>> A small point...  When dealing with pairs, I like to run the loop from
>> 1:
>>
>>     for (int i = 1; i < sizeof seq / sizeof seq[0]; i++)
>>
>> and change i+1 and i to i and i-1 in the body.  Don't know why, just
>> seem a little neater and more obvious to check.
>>
>>>    }
>>> }
>
> I'm the opposite.

A range of views is healthy.

> I like starting at 0, to match with the index address.

Starting at 1 alerts the reader that something is up -- this no normal
"do X on every element" loop.

> And I like to check the next value less the current, not the current
> less the previous.

I was not suggesting swapping the subtraction round.

> You may be mentally ill.

Almost certainly.

-- 
Ben.

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

#147993

On Thu, 14 Nov 2019 11:44:38 -0500, DFS <nospam@dfs.com> wrote:

>On 11/14/2019 2:00 AM, Barry Schwarz wrote:
>> On Wed, 13 Nov 2019 23:57:47 -0500, DFS <nospam@dfs.com> wrote:
>> 
>> <snip>
>> 
>>> That recursion is pretty cool.
>>>
>>> I was inspired to decrapify mine (still iterative tho):
>>> ================================================================
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>>
>>> int main(void) {
>>>
>>>    int seq[] = {1, 2, 4, 5, 7, 8, 12, 1300, 10000};
>>>
>>>    for(int i=0; i < (sizeof(seq) / sizeof(seq[0])); i++) {
>> 
>> That sizeof expression evaluates to 9.
>> 
>>>      if(seq[i + 1] - seq[i] > 1) {
>> 
>> The above statement causes undefined behavior when i is 8.
>
>I got unlucky that seq[9] = 0.

Actually you got lucky that the undefined behavior did not reformat
your hard disk.  You got unlucky that it did not cause some kind of
error, such as a segfault, that would stop your program immediately
and alert you to the problem.

-- 
Remove del for email

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

#147987

On 11/14/2019 4:01 AM, David Brown wrote:
> On 14/11/2019 05:57, DFS wrote:
>>
>> That recursion is pretty cool.
>>
>> I was inspired to decrapify mine (still iterative tho):
>> ================================================================
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> int main(void) {
>>
>>    int seq[] = {1, 2, 4, 5, 7, 8, 12, 1300, 10000};
>>
>>    for(int i=0; i < (sizeof(seq) / sizeof(seq[0])); i++) {
>>      if(seq[i + 1] - seq[i] > 1) {
>>        if( seq[i + 1] - (seq[i] + 1) >= 1) {
>>          printf("[%d,%d] ", seq[i] + 1, seq[i + 1] - 1);
>>        }
>>      }
>>    }
>>
>> }
>> ================================================================


This is a really good analysis, David.  I'm embarrassed to mess up such 
a tiny bit of C code - but it works anyway?


The fix is subtract 1 from the seq size:

i < (sizeof(seq) / sizeof(seq[0])) - 1



> This is getting good, but is not bug-free yet.

It's not bloat-free, either.  Barry Schwarz pointed out the line before 
the printf() is redundant.

if( seq[i + 1] - (seq[i] + 1) >= 1) {

The code works with or without that line.



> Let's look at how tools can help, with this program saved as "seq.c".
> 
> 	tcc seq.c -Wall -o seq
> 
> No output - tcc is happy, and can't help you any more.
> 
> (But it runs in 4 ms on my machine.  Yeah!  That's more than ten times
> faster than gcc, saving me 50 milliseconds!  If I do this often enough,
> tcc will have saved me enough time to blink.)

ha!


> 	gcc -Wall -Wextra seq.c -o seq
> 
> seq.c: In function ‘main’:
> seq.c:8:18: warning: comparison between signed and unsigned integer
> expressions [-Wsign-compare]
>     for(int i=0; i < (sizeof(seq) / sizeof(seq[0])); i++) {
> 
> 
> gcc has found a potential problem.  It is not, in this case, a real
> problem in the code.  It is fine to compare a signed type and an
> unsigned type - /if/ you know the values will be valid after the integer
> promotions used by C to make both sides the same type.  These integer
> promotion rules are not always obvious, especially to someone new to the
> language, and it is easy to make mistakes.  So many compilers can warn
> you when you mix signed and unsigned types in comparisons, even though
> it is a false positive in this case.

Since sizeof(seq)/sizeof(seq[0]) can only be >= 0 the compiler? decides 
the result is unsigned, is that right?

Comparing int i to the (unsigned int) number of elements in the array is 
somehow worth a warning?  Not an egregious warning, but this is the kind 
of thing that makes some people dislike C.  It's like you can't write 
working, reasonable code without being smacked on the back of the hand 
with a ruler.



> So let's disable that particular warning for now.  (Alternatively, we
> could change the type of "i" to "unsigned int", or cast the sizeof
> expression to an int.)

Or we could run screaming from C... but that execution speed is very 
addicting.



> 	gcc -Wall -Wextra seq.c -o seq -Wno-sign-compare
> 
> No warnings now.  gcc has done all it can.
> 
> Or has it?

> Remember I told you to enable optimisation for better static analysis?
> 
> gcc -Wall -Wextra seq.c -o seq -Wno-sign-compare -O2
> 
> seq.c: In function ‘main’:
> seq.c:9:11: warning: iteration 8 invokes undefined behavior
> [-Waggressive-loop-optimizations]
>       if(seq[i + 1] - seq[i] > 1) {
>          ~~~^~~~~~~
> seq.c:8:3: note: within this loop
>     for(int i=0; i < (sizeof(seq) / sizeof(seq[0])); i++) {
>     ^~~


Bingo!

I've just been replaced by 3 letters in the compiler instruction.



> There we go.  gcc has found your bug.  It has pointed out exactly what
> is going wrong, and where.  

I'm sure you know python doesn't let you get away with running past the 
last element.

seq = [1, 2, 4, 5, 7, 8, 12, 13, 1300, 10000]
for i in range(len(seq)):
	if (seq[i + 1] - seq[i]) > 1:
		print("[%d,%d] " % (seq[i] + 1, seq[i + 1] - 1)),


$ python getintervals.py
[3,3]  [6,6]  [9,11]  [14,1299]  [1301,9999]
Traceback (most recent call last):
   File "getintervals2.py", line 3, in <module>
     if (seq[i + 1] - seq[i]) > 1:
IndexError: list index out of range


It's interesting that C will let you hang yourself in some ways, but is 
so demanding in others.



>/That/ is why you should use gcc (or clang,
> or MSVC) for development, with warnings enabled and with optimisation
> enabled.  Ignore the muppets who tell you you want a fast and simple
> compiler for development, and ignore the muppets who tell you to use
> "debug" builds with no optimisation.
> 
> 
> Let us progress - we will take the blasé attitude that "it's only a
> warning", and try the generated program:
> 
> ./seq
> [3,3] [6,6] [9,11] [13,1299] [1301,9999] [10001,32743]
> 
> We see two things here.  One is the unexpected extra interval at the
> end.  This shows that something has gone wrong.  (The value it shows for
> the last number will vary.)  


If I print each [seq[i],seq[i+1]], the last 2 are:

gcc in MSYS2: [1301,9999]     [10000,0]
tcc Windows : [10000,1310544] [10001,1310543]


> We also see that you should add a
> "printf("\n");" line at the end of the function.

a nit


> So (still pretending we did not see the warning from gcc showing the
> problem), we know something is wrong - but we don't know what.  That is
> where sanitizers come in:
> 
> gcc -Wall -Wextra seq.c -o seq -Wno-sign-compare -O2 -fsanitize=undefined
> 
> ./seq
> 
> seq.c:9:11: runtime error: index 9 out of bounds for type 'int [9]'
> seq.c:9:11: runtime error: load of address 0x7ffc5116f764 with
> insufficient space for an object of type 'int'
> 0x7ffc5116f764: note: pointer points here
>    10 27 00 00 00 00 00 00  00 9a ab 7b ce 5c 60 44  a0 d9 c2 c8 07 7f 00
> 00  00 00 00 00 00 00 00 00
> 
> The sanitizer has spotted the problem with the out of bounds access to
> the array, on line 9 of the seq.c file.  That is plenty of information
> for finding and fixing the error.

Yep.  Perfect.



> Give these gcc options a shot before you fix the program.  Then use them
> regularly in your development for checking your code.
> 
> Other useful sanitize options include:
> 
> 	-fsanitize=address
> 
> for checking memory and pointers,
> 
> 	-fsanitize=leak
> 
> for checking malloc/free leaks, and
> 
> 	-fsanitize=thread
> 
> for multi-threaded stuff.


I'll definitely look into them.

Thanks again for your in-depth assistance.  I appreciate you taking the 
time.

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

#147994

On 11/14/19 12:56 PM, DFS wrote:
> On 11/14/2019 4:01 AM, David Brown wrote:
>> On 14/11/2019 05:57, DFS wrote:
...
>>     for(int i=0; i < (sizeof(seq) / sizeof(seq[0])); i++) {
>>
>>
>> gcc has found a potential problem.  It is not, in this case, a real
>> problem in the code.  It is fine to compare a signed type and an
>> unsigned type - /if/ you know the values will be valid after the integer
>> promotions used by C to make both sides the same type.  These integer
>> promotion rules are not always obvious, especially to someone new to the
>> language, and it is easy to make mistakes.  So many compilers can warn
>> you when you mix signed and unsigned types in comparisons, even though
>> it is a false positive in this case.
> 
> Since sizeof(seq)/sizeof(seq[0]) can only be >= 0 the compiler? decides 
> the result is unsigned, is that right?

No, it's much simpler than that. sizeof expressions give a result whose
type is size_t, which is required to be an unsigned integer type. When
you divide two values, both of them the same unsigned integer type, the
result will have that same unsigned integer type. Exception: in the
unlikely (but not impossible) case that SIZE_MAX <= INT_MAX, then both
sizeof expressions will be promoted to "int", and the result of the
division will also be an int.

> Comparing int i to the (unsigned int) number of elements in the array is 
> somehow worth a warning?  Not an egregious warning, but this is the kind 
> of thing that makes some people dislike C.  It's like you can't write 
> working, reasonable code without being smacked on the back of the hand 
> with a ruler.

If the rank of the signed type is greater than the rank of the unsigned
type, and if the signed type is capable of representing all values of
the unsigned type, then the unsigned value is converted to the signed
type, and nothing confusing happens.
In all other cases, signed/unsigned comparison results in the signed
value being converted to an unsigned integer type, with a resulting
change of value if the signed value is negative. This strikes me as
something that justifies a warning. In your case, it can't have a
negative value, but the implementation is not obligated to notice that fact.

>> 	gcc -Wall -Wextra seq.c -o seq -Wno-sign-compare
>>
>> No warnings now.  gcc has done all it can.
>>
>> Or has it?
> 
>> Remember I told you to enable optimisation for better static analysis?
>>
>> gcc -Wall -Wextra seq.c -o seq -Wno-sign-compare -O2
>>
>> seq.c: In function ‘main’:
>> seq.c:9:11: warning: iteration 8 invokes undefined behavior
>> [-Waggressive-loop-optimizations]
>>       if(seq[i + 1] - seq[i] > 1) {
>>          ~~~^~~~~~~
>> seq.c:8:3: note: within this loop
>>     for(int i=0; i < (sizeof(seq) / sizeof(seq[0])); i++) {
>>     ^~~
> 
> 
> Bingo!
> 
> I've just been replaced by 3 letters in the compiler instruction.

Surely those three letters have not replaced you completely?

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

#147999

On 11/14/2019 1:50 PM, James Kuyper wrote:
> On 11/14/19 12:56 PM, DFS wrote:
>> On 11/14/2019 4:01 AM, David Brown wrote:
>>> On 14/11/2019 05:57, DFS wrote:
> ...
>>>      for(int i=0; i < (sizeof(seq) / sizeof(seq[0])); i++) {
>>>
>>>
>>> gcc has found a potential problem.  It is not, in this case, a real
>>> problem in the code.  It is fine to compare a signed type and an
>>> unsigned type - /if/ you know the values will be valid after the integer
>>> promotions used by C to make both sides the same type.  These integer
>>> promotion rules are not always obvious, especially to someone new to the
>>> language, and it is easy to make mistakes.  So many compilers can warn
>>> you when you mix signed and unsigned types in comparisons, even though
>>> it is a false positive in this case.
>>
>> Since sizeof(seq)/sizeof(seq[0]) can only be >= 0 the compiler? decides
>> the result is unsigned, is that right?
> 
> No, it's much simpler than that. sizeof expressions give a result whose
> type is size_t, which is required to be an unsigned integer type. When
> you divide two values, both of them the same unsigned integer type, the
> result will have that same unsigned integer type. Exception: in the
> unlikely (but not impossible) case that SIZE_MAX <= INT_MAX, then both
> sizeof expressions will be promoted to "int", and the result of the
> division will also be an int.
> 
>> Comparing int i to the (unsigned int) number of elements in the array is
>> somehow worth a warning?  Not an egregious warning, but this is the kind
>> of thing that makes some people dislike C.  It's like you can't write
>> working, reasonable code without being smacked on the back of the hand
>> with a ruler.
> 
> If the rank of the signed type is greater than the rank of the unsigned
> type, and if the signed type is capable of representing all values of
> the unsigned type, then the unsigned value is converted to the signed
> type, and nothing confusing happens.
> In all other cases, signed/unsigned comparison results in the signed
> value being converted to an unsigned integer type, with a resulting
> change of value if the signed value is negative. This strikes me as
> something that justifies a warning. In your case, it can't have a
> negative value, but the implementation is not obligated to notice that fact.


The compiler flags certain data type comparisons, but not invalid 
variable assignments that violate the range of the data type.

for(unsigned short i = -1; i < (sizeof(seq) / sizeof(seq[0])) - 1; i++)

gcc -Wall -Wextra -o seq.exe seq.c

doesn't throw any warnings

The code also doesn't output anything, or throw a runtime error.




David Brown said gcc gave this warning:

seq.c: In function ‘main’:
seq.c:8:18: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
    for(int i=0; i < (sizeof(seq) / sizeof(seq[0])); i++) {


gcc (9.1.0) on MSYS2 gives this:

seq.c: In function ‘main’:
seq.c:8:18: warning: comparison of integer expressions of different 
signedness: ‘int’ and ‘long unsigned int’ [-Wsign-compare]
     8 |   for(int i=0; i < (sizeof(seq) / sizeof(seq[0])) - 1; i++) {
       |                  ^


Unless he didn't paste the whole thing, my gcc warning is a little more 
verbose and specific than his.  Version difference I suppose.



>>> 	gcc -Wall -Wextra seq.c -o seq -Wno-sign-compare
>>>
>>> No warnings now.  gcc has done all it can.
>>>
>>> Or has it?
>>
>>> Remember I told you to enable optimisation for better static analysis?
>>>
>>> gcc -Wall -Wextra seq.c -o seq -Wno-sign-compare -O2
>>>
>>> seq.c: In function ‘main’:
>>> seq.c:9:11: warning: iteration 8 invokes undefined behavior
>>> [-Waggressive-loop-optimizations]
>>>        if(seq[i + 1] - seq[i] > 1) {
>>>           ~~~^~~~~~~
>>> seq.c:8:3: note: within this loop
>>>      for(int i=0; i < (sizeof(seq) / sizeof(seq[0])); i++) {
>>>      ^~~
>>
>>
>> Bingo!
>>
>> I've just been replaced by 3 letters in the compiler instruction.
> 
> Surely those three letters have not replaced you completely?


They taught me to stop at 8... but they can't paint my guest bath... so 
I guess I'm good for now.

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

#148003

On 11/14/19 2:42 PM, DFS wrote:
...
> The compiler flags certain data type comparisons, but not invalid 
> variable assignments that violate the range of the data type.
> 
> for(unsigned short i = -1; i < (sizeof(seq) / sizeof(seq[0])) - 1; i++)

That's because the range of the data type has not been violated. The
behavior of that code is well-defined: -1 gets implicitly converted to
unsigned short; the result of that conversion is USHRT_MAX. Since
USHRT_MAX is greater than sizeof seq/sizeof seq[0], the for condition
fails the very first time it is tested, and the loop never executes.

Unsigned types are a special case:
"A computation involving unsigned operands can never overflow, because a
result that cannot be represented by the resulting unsigned integer type
is reduced modulo the number that is one greater than the largest value
that can be represented by the resulting type" (6.2.5p9).

In general, out-of-range values cause problems, but they are never
required to result in a compile-time diagnostic:

Conversion to a signed integer type of an integer value that cannot be
represented in that type: "either the result is implementation-defined
or an implementation-defined signal is raised." (6.3.1.3p3).

Conversion of a real floating value to an integer type other than _Bool
that cannot represent the integer part of that value: "the behavior is
undefined." (6.3.1.4p1).

Conversion to a floating point type of an integer or floating real value
that is outside the range that can be represented by that type: "the
behavior is undefined" (6.3.1.4p2, 6.3.1.5p1).

If the implementation-defined result of converting a pointer to an
integer type cannot be represented in that type, "the behavior is
undefined" (6.3.2.3p6).

"If an integer constant cannot be represented by any type in
its list" (see 6.4.4.1p5) "and has no extended integer type, then the
integer constant has no type." (6.4.4.1p6).

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

#147995

On Thu, 14 Nov 2019 12:56:01 -0500, DFS <nospam@dfs.com> wrote:

>Since sizeof(seq)/sizeof(seq[0]) can only be >= 0 the compiler? decides 
>the result is unsigned, is that right?

No.  Since both operands of the divide operator have the same type, no
conversion is required and the result has the same type as the
operands.  The sizeof operator evaluates to type size_t which just
happens to be unsigned.  So both operands and result are size_t and
therefore unsigned but not for the reason you suggest.

There are free copies of the standard available for download which
would allow to answer these questions.  In this case, section 6.3.1.8.
If you want to seriously program in C you should get a copy.  It could
help you avoid many of the mistakes in your code.

>Comparing int i to the (unsigned int) number of elements in the array is 
>somehow worth a warning?  Not an egregious warning, but this is the kind 
>of thing that makes some people dislike C.  It's like you can't write 
>working, reasonable code without being smacked on the back of the hand 
>with a ruler.

On the other hand, if you made i unsigned you would not get the
warning at all.  Some even put the definition of i inside the for
statement as in
    for (unsigned int i = 0; ...
to insure the scope is limited to the loop.  This will work even if
there is an i defined before the for statement.  The i in the for
statement hides the i defined previously but only for the duration of
the loop.


-- 
Remove del for email

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

#148004

On 11/14/2019 2:03 PM, Barry Schwarz wrote:
> On Thu, 14 Nov 2019 12:56:01 -0500, DFS <nospam@dfs.com> wrote:
> 
>> Since sizeof(seq)/sizeof(seq[0]) can only be >= 0 the compiler? decides
>> the result is unsigned, is that right?
> 
> No.  Since both operands of the divide operator have the same type, no
> conversion is required and the result has the same type as the
> operands.  The sizeof operator evaluates to type size_t which just
> happens to be unsigned.  So both operands and result are size_t and
> therefore unsigned but not for the reason you suggest.
> 
> There are free copies of the standard available for download which
> would allow to answer these questions.  In this case, section 6.3.1.8.
> If you want to seriously program in C you should get a copy.  It could
> help you avoid many of the mistakes in your code.


Is this the latest draft before the costly standards doc from iso.org?


https://web.archive.org/web/20181230041359if_/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf



>> Comparing int i to the (unsigned int) number of elements in the array is
>> somehow worth a warning?  Not an egregious warning, but this is the kind
>> of thing that makes some people dislike C.  It's like you can't write
>> working, reasonable code without being smacked on the back of the hand
>> with a ruler.
> 
> On the other hand, if you made i unsigned you would not get the
> warning at all.  Some even put the definition of i inside the for
> statement as in
>      for (unsigned int i = 0; ...
> to insure the scope is limited to the loop.  This will work even if
> there is an i defined before the for statement.  The i in the for
> statement hides the i defined previously but only for the duration of
> the loop.


Interesting.  Works in nested for..loops too:


  int i = 100, j = 200;

   for(int i = 0; i < 3; i++) {
     for(int j = 0; j < 3; j++) {
       printf("(%d %d) ",i,j);
     }		
   }

   printf("\n%d %d\n",i,j);


(0 0) (0 1) (0 2) (1 0) (1 1) (1 2) (2 0) (2 1) (2 2)
100 200

But... I see danger ahead.  I'll probably not use that technique.

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

#148022

On 14/11/2019 22:08, DFS wrote:
> On 11/14/2019 2:03 PM, Barry Schwarz wrote:
>> On Thu, 14 Nov 2019 12:56:01 -0500, DFS <nospam@dfs.com> wrote:
>>
>>> Since sizeof(seq)/sizeof(seq[0]) can only be >= 0 the compiler? decides
>>> the result is unsigned, is that right?
>>
>> No.  Since both operands of the divide operator have the same type, no
>> conversion is required and the result has the same type as the
>> operands.  The sizeof operator evaluates to type size_t which just
>> happens to be unsigned.  So both operands and result are size_t and
>> therefore unsigned but not for the reason you suggest.
>>
>> There are free copies of the standard available for download which
>> would allow to answer these questions.  In this case, section 6.3.1.8.
>> If you want to seriously program in C you should get a copy.  It could
>> help you avoid many of the mistakes in your code.
> 
> 
> Is this the latest draft before the costly standards doc from iso.org?
> 
> 
> https://web.archive.org/web/20181230041359if_/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf
> 

Yes, I think so (certainly it is close enough for all practical
purposes).  Note that the C standard is not a tutorial or a beginners
document - it often takes a long time to get used to it, and to be
familiar with the different parts.  I personally would not recommend it
for most C programmers, except for very occasional reference.  But
you'll see references to parts of it in posts here, and then it can be
handy to look at.  (References are often made to other versions of the
standards, such as C11 or C99, but the section numbering is mostly
unchanged, as is most of the content - excluding the atomics, threading,
and a few other additions in C11.)

I think this website <https://en.cppreference.com/w/> is worth
bookmarking.  It aims to give accurate information about the language
and standard library, but is easier to navigate than the standards, has
some examples, and is clear about which C standards apply.  (It also
covers C++.)

> 
> 
> 
>>> Comparing int i to the (unsigned int) number of elements in the array is
>>> somehow worth a warning?  Not an egregious warning, but this is the kind
>>> of thing that makes some people dislike C.  It's like you can't write
>>> working, reasonable code without being smacked on the back of the hand
>>> with a ruler.
>>
>> On the other hand, if you made i unsigned you would not get the
>> warning at all.  Some even put the definition of i inside the for
>> statement as in
>>      for (unsigned int i = 0; ...
>> to insure the scope is limited to the loop.  This will work even if
>> there is an i defined before the for statement.  The i in the for
>> statement hides the i defined previously but only for the duration of
>> the loop.
> 
> 
> Interesting.  Works in nested for..loops too:
> 
> 
>  int i = 100, j = 200;
> 
>   for(int i = 0; i < 3; i++) {
>     for(int j = 0; j < 3; j++) {
>       printf("(%d %d) ",i,j);
>     }       
>   }
> 
>   printf("\n%d %d\n",i,j);
> 
> 
> (0 0) (0 1) (0 2) (1 0) (1 1) (1 2) (2 0) (2 1) (2 2)
> 100 200
> 
> But... I see danger ahead.  I'll probably not use that technique.
> 

Usually you want to avoid shadowing existing identifiers - it can lead
to confusion.  But the rules are consistent, and can be helpful.  It is
particularly useful to be able to hide global identifiers with local
ones - it means that if you have included glibc's maths headers, for
example, you can still use names like "y0", "y1", "j0" and "j1" in your
functions without fear of confusion with Bessel functions.

You can use "gcc -Wshadow" to warn you on identifier shadowing if you
are keen to avoid it.

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

#148024

David Brown <david.brown@hesbynett.no> writes:

> On 14/11/2019 22:08, DFS wrote:
>> On 11/14/2019 2:03 PM, Barry Schwarz wrote:
<cut>
>>> ...  Some even put the definition of i inside the for
>>> statement as in
>>>      for (unsigned int i = 0; ...
>>> to insure the scope is limited to the loop.  This will work even if
>>> there is an i defined before the for statement.  The i in the for
>>> statement hides the i defined previously but only for the duration of
>>> the loop.
>> 
>> 
>> Interesting.  Works in nested for..loops too:
>> 
>> 
>>  int i = 100, j = 200;
>> 
>>   for(int i = 0; i < 3; i++) {
>>     for(int j = 0; j < 3; j++) {
>>       printf("(%d %d) ",i,j);
>>     }       
>>   }
>> 
>>   printf("\n%d %d\n",i,j);

I though you were going to show this:

  #include <stdio.h>
   
  int main(void)
  {
       int i = 100, j = 100;
       for (int i = 0; i < 3; i++)
            for (int i = 0; i < 3; i++)
                 printf("x");
       printf(" %d %d\n", i, j);
  }

because it really /does/ work for nested loops!

>> But... I see danger ahead.  I'll probably not use that technique.

I see danger the other way.  Using a short variable name like i or j for
several different things can be confusing for the reader, and you can't
get any help from the compiler.  But if your for-loop-constrained
variable happens to shadow the same name in an outer scope, you can get
the compiler to tell you.

-- 
Ben.

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

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

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

csiph-web