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

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

Program to cipher a text, new thread, fresh one

Started byAlla _ <modelling.data@gmail.com>
First post2015-10-30 08:23 -0700
Last post2015-11-04 09:50 +0100
Articles 8 on this page of 68 — 15 participants

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

Contents

  Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-30 08:23 -0700
    Re: Program to cipher a text, new thread, fresh one Bartc <bc@freeuk.com> - 2015-10-30 15:39 +0000
      Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-30 09:33 -0700
      Re: Program to cipher a text, new thread, fresh one Richard Heathfield <rjh@cpax.org.uk> - 2015-11-01 09:33 +0000
    Re: Program to cipher a text, new thread, fresh one Mark Storkamp <mstorkamp@yahoo.com> - 2015-10-30 11:17 -0500
      Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-30 09:32 -0700
        Re: Program to cipher a text, new thread, fresh one Richard Heathfield <rjh@cpax.org.uk> - 2015-11-01 09:38 +0000
    Re: Program to cipher a text, new thread, fresh one "Osmium" <r124c4u102@comcast.net> - 2015-10-30 10:55 -0600
      Re: Program to cipher a text, new thread, fresh one Richard Heathfield <rjh@cpax.org.uk> - 2015-11-01 10:07 +0000
        Re: Program to cipher a text, new thread, fresh one Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-01 10:42 +0000
          Re: Program to cipher a text, new thread, fresh one Richard Heathfield <rjh@cpax.org.uk> - 2015-11-01 11:35 +0000
            Re: Program to cipher a text, new thread, fresh one James Kuyper <jameskuyper@verizon.net> - 2015-11-01 08:33 -0500
            Re: Program to cipher a text, new thread, fresh one Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-01 16:09 +0000
              Re: Program to cipher a text, new thread, fresh one Bartc <bc@freeuk.com> - 2015-11-02 12:43 +0000
                Re: Program to cipher a text, new thread, fresh one Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-02 13:25 +0000
                Re: Program to cipher a text, new thread, fresh one Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-02 06:13 -0800
            Re: Program to cipher a text, new thread, fresh one Keith Thompson <kst-u@mib.org> - 2015-11-01 12:26 -0800
        Re: Program to cipher a text, new thread, fresh one supercat@casperkitty.com - 2015-11-01 07:59 -0800
          Re: Program to cipher a text, new thread, fresh one Richard Heathfield <rjh@cpax.org.uk> - 2015-11-02 13:48 +0000
            Re: Program to cipher a text, new thread, fresh one Bartc <bc@freeuk.com> - 2015-11-02 14:06 +0000
              Re: Program to cipher a text, new thread, fresh one Richard Heathfield <rjh@cpax.org.uk> - 2015-11-02 14:51 +0000
                Re: Program to cipher a text, new thread, fresh one Bartc <bc@freeuk.com> - 2015-11-02 15:48 +0000
                  Re: Program to cipher a text, new thread, fresh one Richard Heathfield <rjh@cpax.org.uk> - 2015-11-02 16:00 +0000
                    Re: Program to cipher a text, new thread, fresh one asetofsymbols@gmail.com - 2015-11-03 01:40 -0800
                      Re: Program to cipher a text, new thread, fresh one Richard Heathfield <rjh@cpax.org.uk> - 2015-11-03 11:16 +0000
                      Re: Program to cipher a text, new thread, fresh one "Osmium" <r124c4u102@comcast.net> - 2015-11-03 05:21 -0600
                        Re: Program to cipher a text, new thread, fresh one asetofsymbols@gmail.com - 2015-11-03 03:41 -0800
                          Re: Program to cipher a text, new thread, fresh one Richard Heathfield <rjh@cpax.org.uk> - 2015-11-03 11:53 +0000
                            Re: Program to cipher a text, new thread, fresh one "Osmium" <r124c4u102@comcast.net> - 2015-11-03 05:57 -0600
                              Re: Program to cipher a text, new thread, fresh one Richard Heathfield <rjh@cpax.org.uk> - 2015-11-03 12:48 +0000
                                Re: Program to cipher a text, new thread, fresh one Rosario19 <Ros@invalid.invalid> - 2015-11-04 09:09 +0100
                                  Re: Program to cipher a text, new thread, fresh one Rosario19 <Ros@invalid.invalid> - 2015-11-04 09:37 +0100
                                Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-11-04 07:09 -0800
                          Re: Program to cipher a text, new thread, fresh one "Osmium" <r124c4u102@comcast.net> - 2015-11-03 05:53 -0600
                          Re: Program to cipher a text, new thread, fresh one asetofsymbols@gmail.com - 2015-11-03 04:29 -0800
                            Re: Program to cipher a text, new thread, fresh one "Osmium" <r124c4u102@comcast.net> - 2015-11-03 06:42 -0600
        Re: Program to cipher a text, new thread, fresh one Geoff <geoff@invalid.invalid> - 2015-11-01 08:07 -0800
        Re: Program to cipher a text, new thread, fresh one Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-02 02:26 -0800
          Re: Program to cipher a text, new thread, fresh one Rosario19 <Ros@invalid.invalid> - 2015-11-06 07:53 +0100
            Re: Program to cipher a text, new thread, fresh one Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-07 10:01 -0800
    Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-30 10:50 -0700
      Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-30 10:53 -0700
        Re: Program to cipher a text, new thread, fresh one Barry Schwarz <schwarzb@dqel.com> - 2015-10-30 11:52 -0700
          Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-30 12:12 -0700
            Re: Program to cipher a text, new thread, fresh one Barry Schwarz <schwarzb@dqel.com> - 2015-10-30 21:05 -0700
              Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-30 23:58 -0700
                Re: Program to cipher a text, new thread, fresh one Barry Schwarz <schwarzb@dqel.com> - 2015-10-31 03:09 -0700
                  Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-31 03:47 -0700
                    Re: Program to cipher a text, new thread, fresh one Barry Schwarz <schwarzb@dqel.com> - 2015-10-31 11:42 -0700
        Re: Program to cipher a text, new thread, fresh one Barry Schwarz <schwarzb@dqel.com> - 2015-10-30 12:04 -0700
        Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-30 12:10 -0700
    Re: Program to cipher a text, new thread, fresh one "Osmium" <r124c4u102@comcast.net> - 2015-10-30 13:17 -0600
      Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-31 00:04 -0700
        Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-31 00:25 -0700
    Re: Program to cipher a text, new thread, fresh one Keith Thompson <kst-u@mib.org> - 2015-10-30 12:34 -0700
      Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-30 21:49 -0700
        Re: Program to cipher a text, new thread, fresh one Keith Thompson <kst-u@mib.org> - 2015-10-31 13:18 -0700
    Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-31 00:29 -0700
    Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-31 01:12 -0700
      Re: Program to cipher a text, new thread, fresh one Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 12:24 +0000
        Re: Program to cipher a text, new thread, fresh one Alla _ <modelling.data@gmail.com> - 2015-10-31 06:11 -0700
        Re: Program to cipher a text, new thread, fresh one Bartc <bc@freeuk.com> - 2015-10-31 15:58 +0000
          Re: Program to cipher a text, new thread, fresh one Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 17:37 +0000
            Re: Program to cipher a text, new thread, fresh one Bartc <bc@freeuk.com> - 2015-10-31 18:14 +0000
              Re: Program to cipher a text, new thread, fresh one Keith Thompson <kst-u@mib.org> - 2015-10-31 13:29 -0700
                Re: Program to cipher a text, new thread, fresh one Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 20:35 +0000
              Re: Program to cipher a text, new thread, fresh one Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 20:32 +0000
    Re: Program to cipher a text, new thread, fresh one Rosario19 <Ros@invalid.invalid> - 2015-11-04 09:50 +0100

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

#74428

FromAlla _ <modelling.data@gmail.com>
Date2015-10-31 06:11 -0700
Message-ID<b81f1560-e6d5-402c-b69e-dcb327895ec7@googlegroups.com>
In reply to#74426
Ben, thank you so much! This is wonderful! I will study it,
I will need some time to make sure I understand every line
of your code. 
Thank you! And I am happy that you wanted to do your version :)

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

#74444

FromBartc <bc@freeuk.com>
Date2015-10-31 15:58 +0000
Message-ID<n12oak$mom$1@dont-email.me>
In reply to#74426
On 31/10/2015 12:24, Ben Bacarisse wrote:

> As you were writing it I thought it looked fun so I had a go too.  For
> what it's worth, here's my version.  I make it read input rather than
> process a string and it's not intended to use only the features you've
> learned about so far because I don't know what they are.

Your code is character-based so I had a go at a line-based version.

I tried to make it do the same encoding as yours, but there is a 
difference which might be a bug in your code, or a lack of understanding 
on my part: lower case strings are encoded differently from the same 
upper case input.

So with key "ABC", then your program encodes "AAA" to "ABC", but "aaa" 
to "acb" (after restarting). (I assume that key "AAA..." having no 
effect is intentional.)

Anyway, in mine other differences are:

* Requires ASCII (this is checked for)

* Is line-based, with lines limited to 500 characters. (Yours also 
seemed to be line based, in that after pressing Enter, you got the 
encoded string, then it waited for another line, but that was an 
illusion. Strange though because after entering what you thought was the 
same line of input, you got a different encoding!

--------------------------------------------------------

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <ctype.h>

static void quit(char *message);
static void processkey(char *key);
static int readline(char *prompt,char *buffer,int size);
static int shiftchar(int c,int offset);
static void encodestring(char *str,char *key);
static void decodestring(char *str,char *key);

static void quit(char *message)
{
     printf("%s %s\n","Error:",message);
     exit(EXIT_FAILURE);
}

static void processkey(char *key)
{
     while (*key)
     {
         if (!isalpha(*key))
         {
             quit("key not alphabetical");
         }
         *key=toupper(*key);
         ++key;
     }
}

static int readline(char *prompt,char *buffer,int size)
{
int n;
int c;
     n=0;
     printf("%s",prompt);
     while ((c=getchar())!='\n' && c!=EOF)
     {
         if (++n>=size)
         {
             quit("Input too long");
         }
         *buffer=c;
         ++buffer;
     }
     *buffer=0;
     return n;
}

static int shiftchar(int c,int offset)
{
     if (isupper(c))
     {
         c+=offset;
         if (c>'Z')
         {
             c-=26;
         }
         else if (c<'A')
         {
             c+=26;
         }
     }
     else if (islower(c))
     {
         c+=offset;
         if (c>'z')
         {
             c-=26;
         }
         else if (c<'a')
         {
             c+=26;
         }
     }
     return c;
}

static void encodestring(char *str, char *key)
{
char *k;
int c;
     k=key;
     while (c=*str)
     {
         if (isalpha(c))
         {
             *str=shiftchar(*str,*k-'A');
             ++k;
         }
         ++str;
         if (*k==0)
         {
             k=key;
         }
     }
}

static void decodestring(char* str, char *key)
{
char *k;
int c;
     k=key;
     while (c=*str)
     {
         if (isalpha(c))
         {
             *str=shiftchar(*str,'A'-*k);
             ++k;
         }
         ++str;
         if (*k==0)
         {
             k=key;
         }
     }
}

int main (void)
{
#define maxstrlen 500
char str[maxstrlen];
char key[maxstrlen];
     if ('A' != 65)
     {
         quit("Not ASCII");
     }
     readline("Enter a keystring: ",key,maxstrlen);
     if (strlen(key)==0)
     {
         quit("Empty key");
     }
     processkey(key);
     printf("%s %s\n","Using key:",key);
     printf("\nPress Enter to quit:\n");

     while (readline("Next line: ",str,maxstrlen))
     {
         encodestring(str,key);
         printf("%s%s%s\n","Encoded:  \"",str,"\"");
         decodestring(str,key);
         printf("%s%s%s\n","Decoded:  \"",str,"\"");
     }
}


-- 
Bartc

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

#74453

FromBen Bacarisse <ben.usenet@bsb.me.uk>
Date2015-10-31 17:37 +0000
Message-ID<8737wraqhw.fsf@bsb.me.uk>
In reply to#74444
Bartc <bc@freeuk.com> writes:

> On 31/10/2015 12:24, Ben Bacarisse wrote:
>
>> As you were writing it I thought it looked fun so I had a go too.  For
>> what it's worth, here's my version.  I make it read input rather than
>> process a string and it's not intended to use only the features you've
>> learned about so far because I don't know what they are.
>
> Your code is character-based so I had a go at a line-based version.
>
> I tried to make it do the same encoding as yours, but there is a
> difference which might be a bug in your code, or a lack of
> understanding on my part: lower case strings are encoded differently
> from the same upper case input.
>
> So with key "ABC", then your program encodes "AAA" to "ABC", but "aaa"
> to "acb" (after restarting). (I assume that key "AAA..." having no
> effect is intentional.)

That would be a bug, but I can't reproduce it.  I've checked with the
code I posted (in case I posted something other that the last version),
and it seems to work as expected:

$ ./vigenère ABC <<<aaa
abc
$ ./vigenère ABC <<<AAA
ABC

As to the actual meaning of the key shifts, I think a being "no shift"
was as specified by Alla.  I'm not sure if that's "right", it just
seemed to be what was wanted.

> Anyway, in mine other differences are:
>
> * Requires ASCII (this is checked for)

It's not entirely clear what ASCII means.  You assume some things about
the letters (they they are contiguous) and you assume that no char
values are negative.  Is that what you mean?  Some encodings that some
people would call ASCII have negative characters.

> * Is line-based, with lines limited to 500 characters.

Why?  It seems to complicate the program.

> (Yours also
> seemed to be line based, in that after pressing Enter, you got the
> encoded string, then it waited for another line, but that was an
> illusion. Strange though because after entering what you thought was
> the same line of input, you got a different encoding!

I don't know what this means but my program is not line-oriented at all.
It sounds like you had some trouble running it.  It's the simplest form
of filter, if that helps you work out how to test it.

<snip code>
-- 
Ben.

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

#74465

FromBartc <bc@freeuk.com>
Date2015-10-31 18:14 +0000
Message-ID<n130a5$ob3$1@dont-email.me>
In reply to#74453
On 31/10/2015 17:37, Ben Bacarisse wrote:
> Bartc <bc@freeuk.com> writes:
>
>> On 31/10/2015 12:24, Ben Bacarisse wrote:

>> I tried to make it do the same encoding as yours, but there is a
>> difference which might be a bug in your code, or a lack of
>> understanding on my part: lower case strings are encoded differently
>> from the same upper case input.
>>
>> So with key "ABC", then your program encodes "AAA" to "ABC", but "aaa"
>> to "acb" (after restarting). (I assume that key "AAA..." having no
>> effect is intentional.)
>
> That would be a bug, but I can't reproduce it.  I've checked with the
> code I posted (in case I posted something other that the last version),
> and it seems to work as expected:

OK, it's to do with the isalpha() function; some libraries in Windows 
return 1 or 2 for an alpha character (for upper or lower case 
presumably), and you use that to step along the key string. (So in 
Windows, it steps twice along the keystring for a lower case input. In 
Linux it stepped just once.)

The specs for isalpha() just say it returns non-zero if test is true.

>
>> Anyway, in mine other differences are:
>>
>> * Requires ASCII (this is checked for)
>
> It's not entirely clear what ASCII means.  You assume some things about
> the letters (they they are contiguous) and you assume that no char
> values are negative.  Is that what you mean?  Some encodings that some
> people would call ASCII have negative characters.

ASCII codes go up to 127. But the values of interest are 65 to 90, and 
97 to 122, which are always going to be positive.

>> * Is line-based, with lines limited to 500 characters.
>
> Why?  It seems to complicate the program.

To give an idea of what it looks like. A bit more complicated, but far 
more flexible. So I can grab an input string (from the console, file, 
data in a program or just construct it), and then do whatever I want 
with it including encoding or decoding, or reverse the string first and 
then encode.

That's a lot harder if the input is trickled in a character at a time.

>> (Yours also
>> seemed to be line based, in that after pressing Enter, you got the
>> encoded string, then it waited for another line, but that was an
>> illusion. Strange though because after entering what you thought was
>> the same line of input, you got a different encoding!
>
> I don't know what this means but my program is not line-oriented at all.
> It sounds like you had some trouble running it.  It's the simplest form
> of filter, if that helps you work out how to test it.

I ran it on Windows and Linux and they were the same (apart from the 
isalpha thing). Transcribed manually:

...$ ./a.out ABC
LINE1
LJPE1
LINE2
MKNF2
LINE3
NIOG3
^Z
... Stopped

The input was LINE1 Enter, LINE2 Enter, LINE3 Enter. The characters are 
shown as I type, then as I press Enter, the encoded line is displayed, 
then it sits waiting for more input.

It does look remarkably like it's reading a line at a time, outputting 
the encoding, then waiting for the next. Except the keystring is not 
reset and that gives confusing results.

(Actually that was why I put a line-reading loop into my version!)

-- 
Bartc

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

#74486

FromKeith Thompson <kst-u@mib.org>
Date2015-10-31 13:29 -0700
Message-ID<lnfv0q93z2.fsf@kst-u.example.com>
In reply to#74465
Bartc <bc@freeuk.com> writes:
> On 31/10/2015 17:37, Ben Bacarisse wrote:
>> Bartc <bc@freeuk.com> writes:
>>
>>> On 31/10/2015 12:24, Ben Bacarisse wrote:
>
>>> I tried to make it do the same encoding as yours, but there is a
>>> difference which might be a bug in your code, or a lack of
>>> understanding on my part: lower case strings are encoded differently
>>> from the same upper case input.
>>>
>>> So with key "ABC", then your program encodes "AAA" to "ABC", but "aaa"
>>> to "acb" (after restarting). (I assume that key "AAA..." having no
>>> effect is intentional.)
>>
>> That would be a bug, but I can't reproduce it.  I've checked with the
>> code I posted (in case I posted something other that the last version),
>> and it seems to work as expected:
>
> OK, it's to do with the isalpha() function; some libraries in Windows 
> return 1 or 2 for an alpha character (for upper or lower case 
> presumably), and you use that to step along the key string. (So in 
> Windows, it steps twice along the keystring for a lower case input. In 
> Linux it stepped just once.)

Do they really?  The MSDN documentation for isalpha():
    https://msdn.microsoft.com/en-us/library/xt82b8z8.aspx
doesn't mention this; it merely says that isalpha() returns zero or
non-zero.

Even if it were documented, I wouldn't write code that depends on it.

Unless you're referring to some function other than isalpha()?

(There's also a C++specific isalpha() function declared in the <locale>
header, but it returns a bool, and it's not being used here.)

> The specs for isalpha() just say it returns non-zero if test is true.

That's all I'd consider depending on.  And in fact I don't think I've
seen any code in this thread that makes any assumptions about which
non-zero value isalpha() returns.

>>> Anyway, in mine other differences are:
>>>
>>> * Requires ASCII (this is checked for)
>>
>> It's not entirely clear what ASCII means.  You assume some things about
>> the letters (they they are contiguous) and you assume that no char
>> values are negative.  Is that what you mean?  Some encodings that some
>> people would call ASCII have negative characters.
>
> ASCII codes go up to 127. But the values of interest are 65 to 90, and 
> 97 to 122, which are always going to be positive.

Regardless of the character set, the values of the 52 letters are
guaranteed to be positive.  But the characters that aren't letters are
also "of interest", since you're handling user input.  If the input
contains, for example, an accented letter in a Latin-1 locale, it's
going to have a negative value as a plain char (assuming CHAR_BIT==8 and
CHAR_MIN<0), which means that passing it to isalpha(), isupper(), or
islower() has undefined behavior (both ISO C and MSDN say so).

[...]

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

#74489

FromBen Bacarisse <ben.usenet@bsb.me.uk>
Date2015-10-31 20:35 +0000
Message-ID<87y4ei93pc.fsf@bsb.me.uk>
In reply to#74486
Keith Thompson <kst-u@mib.org> writes:

> Bartc <bc@freeuk.com> writes:
<snip>
>> The specs for isalpha() just say it returns non-zero if test is true.
>
> That's all I'd consider depending on.  And in fact I don't think I've
> seen any code in this thread that makes any assumptions about which
> non-zero value isalpha() returns.

Mine did.  I wrote n += isalpha(c); rather than n += !!isalpha(c) (or
any of the many variations that would also have worked).

<snip>
-- 
Ben.

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

#74487

FromBen Bacarisse <ben.usenet@bsb.me.uk>
Date2015-10-31 20:32 +0000
Message-ID<874mh6aiew.fsf@bsb.me.uk>
In reply to#74465
Bartc <bc@freeuk.com> writes:

> On 31/10/2015 17:37, Ben Bacarisse wrote:
>> Bartc <bc@freeuk.com> writes:
>>
>>> On 31/10/2015 12:24, Ben Bacarisse wrote:
>
>>> I tried to make it do the same encoding as yours, but there is a
>>> difference which might be a bug in your code, or a lack of
>>> understanding on my part: lower case strings are encoded differently
>>> from the same upper case input.
>>>
>>> So with key "ABC", then your program encodes "AAA" to "ABC", but "aaa"
>>> to "acb" (after restarting). (I assume that key "AAA..." having no
>>> effect is intentional.)
>>
>> That would be a bug, but I can't reproduce it.  I've checked with the
>> code I posted (in case I posted something other that the last version),
>> and it seems to work as expected:
>
> OK, it's to do with the isalpha() function; some libraries in Windows
> return 1 or 2 for an alpha character (for upper or lower case
> presumably), and you use that to step along the key string.

Good spot.  That should have been !!isalpha() (or similar).  Thanks.

<snip>
>>> Anyway, in mine other differences are:
>>>
>>> * Requires ASCII (this is checked for)
>>
>> It's not entirely clear what ASCII means.  You assume some things about
>> the letters (they they are contiguous) and you assume that no char
>> values are negative.  Is that what you mean?  Some encodings that some
>> people would call ASCII have negative characters.
>
> ASCII codes go up to 127. But the values of interest are 65 to 90, and
> 97 to 122, which are always going to be positive.
>
>>> * Is line-based, with lines limited to 500 characters.
>>
>> Why?  It seems to complicate the program.
>
> To give an idea of what it looks like.

Fair enough.

> A bit more complicated, but far
> more flexible. So I can grab an input string (from the console, file,
> data in a program or just construct it), and then do whatever I want
> with it including encoding or decoding, or reverse the string first
> and then encode.
>
> That's a lot harder if the input is trickled in a character at a time.

That depends on your computing environment.  In mine I can do what you
describe using my version.  But I can't easily use your version in a
pipeline, for example.  I'd say that wit the right execution environment
(i.e. a good shell), a plain filter like mine is the more flexible.

>>> (Yours also
>>> seemed to be line based, in that after pressing Enter, you got the
>>> encoded string, then it waited for another line, but that was an
>>> illusion. Strange though because after entering what you thought was
>>> the same line of input, you got a different encoding!
>>
>> I don't know what this means but my program is not line-oriented at all.
>> It sounds like you had some trouble running it.  It's the simplest form
>> of filter, if that helps you work out how to test it.
>
> I ran it on Windows and Linux and they were the same (apart from the
> isalpha thing). Transcribed manually:
>
> ...$ ./a.out ABC
> LINE1
> LJPE1
> LINE2
> MKNF2
> LINE3
> NIOG3
> ^Z
> ... Stopped
>
> The input was LINE1 Enter, LINE2 Enter, LINE3 Enter. The characters
> are shown as I type, then as I press Enter, the encoded line is
> displayed, then it sits waiting for more input.
>
> It does look remarkably like it's reading a line at a time, outputting
> the encoding, then waiting for the next. Except the keystring is not
> reset and that gives confusing results.

Yes, the key string is not reset.  That's because it's not line
oriented.  And it seems odd that don't know that your shell's input is
line buffered (you can turn that off if you like).  That does not mean
the program is line-oriented.

-- 
Ben.

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

#74807

FromRosario19 <Ros@invalid.invalid>
Date2015-11-04 09:50 +0100
Message-ID<g9hj3bd6adf13nipu0kpepn5bs3k3js8a7@4ax.com>
In reply to#74314
On Fri, 30 Oct 2015 08:23:15 -0700 (PDT), Alla _ wrote:

>Therefore the program should have two arguments to work with:
>1) text message
>2) key word

for me all the problem would reduce to write 2 function:

int  Crpt(char*  key, unsigned indexNow, int charToConvert)

and the inverse

int  deCrpt(char*  key, unsigned indexNow, int charToConvert)

these are both one char at time

even if the return type had to be a char 
and the arg charToConvert had to be a char
i use int or unsigned

because chars and unsigned chars 
not fit well the return and call C sys for me

[toc] | [prev] | [standalone]

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

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

csiph-web