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

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

Improving the program, issues with logical operators, incorrect output

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

Contents

  Improving the program, issues with logical operators, incorrect output Alla _ <modelling.data@gmail.com> - 2015-09-08 06:47 -0700
    Re: Improving the program, issues with logical operators, incorrect output fir <profesor.fir@gmail.com> - 2015-09-08 07:23 -0700
      Re: Improving the program, issues with logical operators, incorrect output Alla _ <modelling.data@gmail.com> - 2015-09-08 07:25 -0700
        Re: Improving the program, issues with logical operators, incorrect output fir <profesor.fir@gmail.com> - 2015-09-08 07:44 -0700
        Re: Improving the program, issues with logical operators, incorrect output Richard Heathfield <rjh@cpax.org.uk> - 2015-09-08 17:04 +0100
        Re: Improving the program, issues with logical operators, incorrect output Keith Thompson <kst-u@mib.org> - 2015-09-08 09:21 -0700
    Re: Improving the program, issues with logical operators, incorrect output Richard Heathfield <rjh@cpax.org.uk> - 2015-09-08 18:32 +0100
    Re: Improving the program, issues with logical operators, incorrect output Barry Schwarz <schwarzb@dqel.com> - 2015-09-08 15:53 -0700
    Re: Improving the program, issues with logical operators, incorrect output bartekltg <bartekltg@gmail.com> - 2015-09-09 15:42 +0200
    Re: Improving the program, issues with logical operators, incorrect output David Brown <david.brown@hesbynett.no> - 2015-09-09 16:11 +0200
      Re: Improving the program, issues with logical operators, incorrect output Richard Heathfield <rjh@cpax.org.uk> - 2015-09-09 16:01 +0100
        Re: Improving the program, issues with logical operators, incorrect output David Brown <david.brown@hesbynett.no> - 2015-09-09 21:11 +0200
          Re: Improving the program, issues with logical operators, incorrect output Richard Heathfield <rjh@cpax.org.uk> - 2015-09-09 20:42 +0100
            Re: Improving the program, issues with logical operators, incorrect output David Brown <david.brown@hesbynett.no> - 2015-09-09 22:23 +0200
            Re: Improving the program, issues with logical operators, incorrect output Keith Thompson <kst-u@mib.org> - 2015-09-09 13:41 -0700
              Re: Improving the program, issues with logical operators, incorrect output Richard Heathfield <rjh@cpax.org.uk> - 2015-09-09 22:21 +0100
              Re: Improving the program, issues with logical operators, incorrect output Les Cargill <lcargill99@comcast.com> - 2015-09-09 18:25 -0500
      Re: Improving the program, issues with logical operators, incorrect output Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-09 12:41 -0700
        Re: Improving the program, issues with logical operators, incorrect output David Brown <david.brown@hesbynett.no> - 2015-09-09 22:24 +0200
        Re: Improving the program, issues with logical operators, incorrect output Keith Thompson <kst-u@mib.org> - 2015-09-09 13:34 -0700
          Re: Improving the program, issues with logical operators, incorrect output Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-09 16:25 -0700
            Re: Improving the program, issues with logical operators, incorrect output Keith Thompson <kst-u@mib.org> - 2015-09-09 17:38 -0700
              Re: Improving the program, issues with logical operators, incorrect output fir <profesor.fir@gmail.com> - 2015-09-12 00:48 -0700
                Re: Improving the program, issues with logical operators, incorrect output fir <profesor.fir@gmail.com> - 2015-09-12 00:55 -0700
                Re: Improving the program, issues with logical operators, incorrect output David Brown <david.brown@hesbynett.no> - 2015-09-12 14:50 +0200
                  Re: Improving the program, issues with logical operators, incorrect output fir <profesor.fir@gmail.com> - 2015-09-12 07:12 -0700
          Re: Improving the program, issues with logical operators, incorrect output David Brown <david.brown@hesbynett.no> - 2015-09-10 09:56 +0200
    Re: Improving the program, issues with logical operators, incorrect output gordonb.papec@burditt.org (Gordon Burditt) - 2015-09-11 17:18 -0500
      Re: Improving the program, issues with logical operators, incorrect output Barry Schwarz <schwarzb@dqel.com> - 2015-09-13 01:08 -0700
      Re: Improving the program, issues with logical operators, incorrect output Stephen Sprunk <stephen@sprunk.org> - 2015-09-13 19:03 -0500

Page 2 of 2 — ← Prev page 1 [2]

#70089

On Wednesday, September 9, 2015 at 9:34:48 PM UTC+1, Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> > As far as a I can ascertain, that style {one true] was used in 
> > printed books to save vertical space. Printing is a different 
> > technology to screen scrolling, and paper costs money.
> 
> Do you have any evidence that that was the actual reason?  I use the
> 1TBS myself, and saving vertical space is not my motivation.
> 
I've heard that that was the case. I can't remember where, and it's
not the sort of thing that's easy to prove unless there's a written
statement by K and R to that effect.
If you've ever published a book containing computer code, you
understand these issues and it makes perfect sense. 

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

#70103

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Wednesday, September 9, 2015 at 9:34:48 PM UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> > As far as a I can ascertain, that style {one true] was used in 
>> > printed books to save vertical space. Printing is a different 
>> > technology to screen scrolling, and paper costs money.
>> 
>> Do you have any evidence that that was the actual reason?  I use the
>> 1TBS myself, and saving vertical space is not my motivation.
>> 
> I've heard that that was the case. I can't remember where, and it's
> not the sort of thing that's easy to prove unless there's a written
> statement by K and R to that effect.
> If you've ever published a book containing computer code, you
> understand these issues and it makes perfect sense. 

It would also make perfect sense if Kernighan and Ritchie happened to
use the 1TBS because they preferred it, and used it in their book for
that reason.

One B manual, <http://cm.bell-labs.com/cm/cs/who/dmr/kbman.pdf>,
uses the 1TBS ("{" and the end of a line, "}" aligned under the
keyword).

Another B manual, <https://www.bell-labs.com/usr/dmr/www/bref.pdf>,
uses a variant in which the closing "}" is indented:

    min(a,b) {
        if( a<b ) return(a);
        else return(b);
        }

So apparently the 1TBS predates C.

The BCPL manual <http://cm.bell-labs.com/cm/cs/who/dmr/bcpl.pdf>
doesn't have enough examples to show a consistent style.

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

#70324

W dniu czwartek, 10 września 2015 02:38:32 UTC+2 użytkownik Keith Thompson napisał:
> 
>     min(a,b) {
>         if( a<b ) return(a);
>         else return(b);
>         }
> 
> So apparently the 1TBS predates C.

imo the { } blocking seems overal bad,

this is mostly probably becouse imo it 'suggest' (as a side effect) that empty space (empty lines etc) are  'part'
of the function body (and this is imo quite unintended and bad)

      min(a,b) 
         if( a<b ) return(a) ;
         else return(b);

imo it would be probably better to use ony one enclosing mark (as the opening one after if, for and function header is obvious, Or maybe even detect end of the function by the begining of another one;
(yet other option is to use two part named
control structures (like do-while for example) [probably one mark blocks are better than two-marked, but probably no mark blocks are yet better)

also this ; operators imo in todays times should be optional (and in maybe most better cases almost (if not totally) no present in code [on this i was already writing one year ago]

      min(a,b) 
         if( a<b ) 
            return a 
         else 
            return b


this looks bare but it shows that such code is really simple witout the coat of
gothic syntax

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

#70325

W dniu sobota, 12 września 2015 09:48:46 UTC+2 użytkownik fir napisał:
> W dniu czwartek, 10 września 2015 02:38:32 UTC+2 użytkownik Keith Thompson napisał:
> > 
> >     min(a,b) {
> >         if( a<b ) return(a);
> >         else return(b);
> >         }
> > 
> > So apparently the 1TBS predates C.
> 
> imo the { } blocking seems overal bad,
> 
> this is mostly probably becouse imo it 'suggest' (as a side effect) that empty space (empty lines etc) are  'part'
> of the function body (and this is imo quite unintended and bad)
> 
>       min(a,b) 
>          if( a<b ) return(a) ;
>          else return(b);
> 
> imo it would be probably better to use ony one enclosing mark (as the opening one after if, for and function header is obvious, Or maybe even detect end of the function by the begining of another one;
> (yet other option is to use two part named
> control structures (like do-while for example) [probably one mark blocks are better than two-marked, but probably no mark blocks are yet better)
> 
> also this ; operators imo in todays times should be optional (and in maybe most better cases almost (if not totally) no present in code [on this i was already writing one year ago]
> 
>       min(a,b) 
>          if( a<b ) 
>             return a 
>          else 
>             return b
> 
> 
> this looks bare but it shows that such code is really simple witout the coat of
> gothic syntax

making some of this delimiters optional seem to be a good way.. maybe ading some
other (this one mark family) delimiter 
as an option could help too

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

#70338

On 12/09/15 09:48, fir wrote:
> W dniu czwartek, 10 września 2015 02:38:32 UTC+2 użytkownik Keith Thompson napisał:
>>
>>      min(a,b) {
>>          if( a<b ) return(a);
>>          else return(b);
>>          }
>>
>> So apparently the 1TBS predates C.
>
> imo the { } blocking seems overal bad,
>
> this is mostly probably becouse imo it 'suggest' (as a side effect) that empty space (empty lines etc) are  'part'
> of the function body (and this is imo quite unintended and bad)
>
>        min(a,b)
>           if( a<b ) return(a) ;
>           else return(b);
>
> imo it would be probably better to use ony one enclosing mark (as the opening one after if, for and function header is obvious, Or maybe even detect end of the function by the begining of another one;
> (yet other option is to use two part named
> control structures (like do-while for example) [probably one mark blocks are better than two-marked, but probably no mark blocks are yet better)
>
> also this ; operators imo in todays times should be optional (and in maybe most better cases almost (if not totally) no present in code [on this i was already writing one year ago]
>
>        min(a,b)
>           if( a<b )
>              return a
>           else
>              return b
>
>
> this looks bare but it shows that such code is really simple witout the coat of
> gothic syntax
>

There are a few languages that use whitespace for structuring.  Occam 
and Python come to mind.  In Python, your function would be:

def min(a, b) :
	if a < b :
		return a
	else :
		return b

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

#70349

W dniu sobota, 12 września 2015 14:50:41 UTC+2 użytkownik David Brown napisał:
> On 12/09/15 09:48, fir wrote:
> > W dniu czwartek, 10 września 2015 02:38:32 UTC+2 użytkownik Keith Thompson napisał:
> >>
> >>      min(a,b) {
> >>          if( a<b ) return(a);
> >>          else return(b);
> >>          }
> >>
> >> So apparently the 1TBS predates C.
> >
> > imo the { } blocking seems overal bad,
> >
> > this is mostly probably becouse imo it 'suggest' (as a side effect) that empty space (empty lines etc) are  'part'
> > of the function body (and this is imo quite unintended and bad)
> >
> >        min(a,b)
> >           if( a<b ) return(a) ;
> >           else return(b);
> >
> > imo it would be probably better to use ony one enclosing mark (as the opening one after if, for and function header is obvious, Or maybe even detect end of the function by the begining of another one;
> > (yet other option is to use two part named
> > control structures (like do-while for example) [probably one mark blocks are better than two-marked, but probably no mark blocks are yet better)
> >
> > also this ; operators imo in todays times should be optional (and in maybe most better cases almost (if not totally) no present in code [on this i was already writing one year ago]
> >
> >        min(a,b)
> >           if( a<b )
> >              return a
> >           else
> >              return b
> >
> >
> > this looks bare but it shows that such code is really simple witout the coat of
> > gothic syntax
> >
> 
> There are a few languages that use whitespace for structuring.  Occam 
> and Python come to mind.  In Python, your function would be:
> 
> def min(a, b) :
> 	if a < b :
> 		return a
> 	else :
> 		return b

Im not saying about whitespaces /whitespace delimiting - which i also dislike - im saing about 'syntactic delimiting' (+ ev. optional delimiters)

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

#70129

On 09/09/15 22:34, Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> On Wednesday, September 9, 2015 at 3:11:44 PM UTC+1, David Brown wrote:
>>> What I am going to recommend here is basically what is known as "the one
>>> true brace style".  I believe it is a style that makes code structure
>>> clear, and minimises the risk of differences between the visual
>>> structure (what the code looks like to the programmer) and the syntactic
>>> structure (how it is actually structured, as seen by the compiler which
>>> ignores spacing, newlines, indentation, etc.).
>>>
>> As far as a I can ascertain, that style was used in printed books to
>> save vertical space. Printing is a different technology to screen
>> scrolling, and paper costs money.
> 
> Do you have any evidence that that was the actual reason?  I use the
> 1TBS myself, and saving vertical space is not my motivation.
> 

Saving vertical space is not my motivation for preferring 1TBS either -
though it is a convenient side-effect.  I don't often print out my code,
but it's nice to be able to see more of a file's code on the screen at a
time.

I like 1TBS because I find it consistent, easy to see the structure of
the code, and because it minimises the risk of getting out of
synchronisation between the visual and logical blocking.  But I fully
appreciate that familiarity and habit plays a big part in this.

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

#70284

> 1) Get the card number from the user.

Bank card numbers can go up to 19 digits.  (Look up "bank card
number" on Wikipedia.)  Don't forget about space for the trailing
'\0'.

Also, someone malicious will try entering something vastly overlong
(gigabytes?) with the hope of getting free money or free merchandise
or getting a fake credit card number accepted for real.

scanf() used with a %s format makes it impossible to protect
against overlong input.

> 2) Multiply every other digit by 2,
> starting with the number's second-to-last digit,
> and then add those products' digits together.
> 
> 3) Add the sum to the sum of the digits that
> weren't multiplied by 2.
> 
> 4) If the total's last digit is 0 (or, put more
> formally, if the total modulo 10 is congruent to
> 0), the number is valid.

This is commonly known as the Luhn algorithm or Luhn checksum.  It's
good as a quick check for mistyping a digit or swapping two digits
(catches most such errors) but is no substitute for checking online
that the credit card account is active and in good standing and not
reported stolen.  This, of course, requires a merchant account and
each query is likely to cost money (possibly only a few cents).
This can add up if you are teaching a large class and let your students
use the merchant account for testing their programs.  It can also
add up if you connect this to a web site and let any credit card
number thief to validate credit cards using your web site.

> 5) If the card is valid, print that it's a valid
> card and the name of the issuer. 

Define valid card!  "Passes the Luhn checksum", "Has a valid issuer
(from a list of accepted issuers)", "Has the correct number of
digits for the issuer", "Is a credit card", "is not reported stolen",
and "all of the above" are all different criteria.

> The name of issuer depends on the following:
> 
> American Express uses 15-digit numbers, 
> MasterCard uses 16-digit numbers, and
> Visa uses 13- and 16-digit numbers.

You have left off many issuers.  And, this is important, many
issuers issue cards that are NOT credit cards!

Kroger loyalty cards have a prefix of 6032 and use 15 digits.
Lowe's loyalty cards have a prefix of 6006 and use 19 digits.
A Texas driver's license doesn't seem to have any number on it that
isn't part of the address.  (There may be other information on
tracks the keyboard-with-card-reader I'm using doesn't read.)


> American Express numbers all start with 34 or 37; 
> MasterCard numbers all start with 51, 52, 53, 54, or 55; 
> and Visa numbers all start with 4.

Discover starts with 6011, 62, 64, or 65, although they don't necessarily
own all the numbers in those blocks, and uses 16-digit numbers.

Mastercard has announced it's going to start using numbers in a block
that begins with 2 starting sometime in 2016.

So, what should the program do if the Luhn checksum passes but:
	(a) The number matches no known issuer (e.g. begins with 0, 1,
	    2, 6, 7, 8, or 9, or 3 or 5 but the number is outside the
	    indicated blocks above)
	(b) The number matches an issuer but the number of digits is wrong.
	(c) The "number" contains non-numeric characters (recently one
	    payee complained that my credit card number read as random 
	    letters.  It read correctly the next try and nobody else
	    has a problem with it.  Apparently it's possible for a
	    card to be misread.

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

#70401

On Fri, 11 Sep 2015 17:18:51 -0500, gordonb.papec@burditt.org (Gordon
Burditt) wrote:

>scanf() used with a %s format makes it impossible to protect
>against overlong input.

%s can be controlled with the optional maximum field width (%16s in
the OP's case).

-- 
Remove del for email

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

#70438

On 11-Sep-15 17:18, Gordon Burditt wrote:
> A Texas driver's license doesn't seem to have any number on it that 
> isn't part of the address.  (There may be other information on
> tracks the keyboard-with-card-reader I'm using doesn't read.)

That is true of Track 1.  Track 2 contains several numeric fields:

ISO Issuer Identification Number
License Number
Date of Expiry (YYMM)
Date of Birth (YYYYMMDD)

And Track 3 contains a few more:

Zip+4 Code
Height (FtIn)
Weight (Lbs)

The face and 2D barcode contain all of the information on all 3 magnetic
strip tracks plus the Document Discriminator, and obviously the picture
and signature are on the face.

There are also non-numeric fields in each place, of course.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web