Hallo allemaal,


During the conversion of my program from Pascal to C, I was more or
less able to find the C equivalent of most Pascal functions so far.
Only four gave me some real trouble. I solved them but it could be I
overlooked something.

1) In Pascal you can declare functions inside a function. AFAIK this
is not possible with C. Or am I wrong?

2) In Pascal there exists the "in" function. Example:

   if (c in ['A'..'F', '0'..'9']) then          { c is hexadecimal }

This can be translated like:

   if (   ((c >= 'A') && (c <= 'Z'))
       || ((c >= '0') && (c <= '9'))) ....      // c is hexadecimal

I just wonder if there is a more simpler solution.

3) In Pascal I can "add" lines:

  Line1 = 'File size:' + sSize + ' bytes.';

My solution:

  strcpy(Line1, "File size:");
  strcat(Line1, sSize);
  strcat(Line1, " bytes.);

Again, I just wonder if there is a more simpler solution.

4) In Pascal I can "add" just one character of another string:

  Str1 = Str2 + Str3[5];

Unfortunately  strcat(Str1, Str3[5]);  doesn't work, I get an error
message. My solution:

  Str4[0] = Str3[5];
  Str4[1] = 0;
  strcpy(Str1, Str2};
  strcat(Str1, Str4};

It works but in this case I'm certainly not happy with the solution.
Is there a better way?

Many thanks for any comment!


--
    ___
   / __|__
  / /  |_/     Groetjes, Ruud Baltissen
  \ \__|_\
   \___|       http://Ruud.C64.org

Ruud wrote:
> Hallo allemaal,
> 
> 
> During the conversion of my program from Pascal to C, I was more or
> less able to find the C equivalent of most Pascal functions so far.
> Only four gave me some real trouble. I solved them but it could be I
> overlooked something.
> 
> 1) In Pascal you can declare functions inside a function. AFAIK this
> is not possible with C. Or am I wrong?
> 
No, C does not have nested functions, although some compilers support
them as extensions.

> 2) In Pascal there exists the "in" function. Example:
> 
>    if (c in ['A'..'F', '0'..'9']) then          { c is hexadecimal }
> 
> This can be translated like:
> 
>    if (   ((c >= 'A') && (c <= 'Z'))
>        || ((c >= '0') && (c <= '9'))) ....      // c is hexadecimal
> 
> I just wonder if there is a more simpler solution.
> 
Sorry, no.  One alternative is to use a regular expression library if
you have a lot of these.

> 3) In Pascal I can "add" lines:
> 
>   Line1 = 'File size:' + sSize + ' bytes.';
> 
> My solution:
> 
>   strcpy(Line1, "File size:");
>   strcat(Line1, sSize);
>   strcat(Line1, " bytes.);
> 
> Again, I just wonder if there is a more simpler solution.
> 
Not in C.

> 4) In Pascal I can "add" just one character of another string:
> 
>   Str1 = Str2 + Str3[5];
> 
> Unfortunately  strcat(Str1, Str3[5]);  doesn't work, I get an error
> message. My solution:
> 
>   Str4[0] = Str3[5];
>   Str4[1] = 0;
>   strcpy(Str1, Str2};
>   strcat(Str1, Str4};
> 
> It works but in this case I'm certainly not happy with the solution.
> Is there a better way?
>
Don't use C.  C does not have string objects, of arrays of char and
library functions to manipulate then.

If you are doing a lot of string manipulation, C might not be your best
choice.  Scripting language like Perl are designed for string processing
and might be a better option.

-- 
Ian Collins

Ian Collins wrote:
> Ruud wrote:
>> Hallo allemaal,
>> 3) In Pascal I can "add" lines:
>>
>>   Line1 = 'File size:' + sSize + ' bytes.';
>>
>> My solution:
>>
>>   strcpy(Line1, "File size:");
>>   strcat(Line1, sSize);
>>   strcat(Line1, " bytes.);
>>
>> Again, I just wonder if there is a more simpler solution.
>>
> Not in C.

That is nonsense

sprintf(Line1,"File size: %s bytes",sSize);

And you can save yourself transforming Size into a string with

sprintf(Line1,"File size: %d bytes",Size);

> 
>> 4) In Pascal I can "add" just one character of another string:
>>
>>   Str1 = Str2 + Str3[5];
>>
>> Unfortunately  strcat(Str1, Str3[5]);  doesn't work, I get an error
>> message. My solution:
>>
>>   Str4[0] = Str3[5];
>>   Str4[1] = 0;
>>   strcpy(Str1, Str2};
>>   strcat(Str1, Str4};
>>
>> It works but in this case I'm certainly not happy with the solution.
>> Is there a better way?
>>
> Don't use C.  C does not have string objects, of arrays of char and
> library functions to manipulate then.
> 

If you do not know enough C please do not use this group.

The above can be done with

sprintf(str1,"%s%c",Str2,Str3[5]);


> If you are doing a lot of string manipulation, C might not be your best
> choice.  Scripting language like Perl are designed for string processing
> and might be a better option.
> 

C has problems with strings but it is usable. Other languages have other
(bigger) problems



-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Ruud wrote:
> Hallo allemaal,
> 
> 
> During the conversion of my program from Pascal to C, I was more or
> less able to find the C equivalent of most Pascal functions so far.
> Only four gave me some real trouble. I solved them but it could be I
> overlooked something.
> 
> 1) In Pascal you can declare functions inside a function. AFAIK this
> is not possible with C. Or am I wrong?
> 
> 2) In Pascal there exists the "in" function. Example:
> 
>    if (c in ['A'..'F', '0'..'9']) then          { c is hexadecimal }
> 
> This can be translated like:
> 
>    if (   ((c >= 'A') && (c <= 'Z'))
>        || ((c >= '0') && (c <= '9'))) ....      // c is hexadecimal
> 
> I just wonder if there is a more simpler solution.
> 

That one is simple enough

> 3) In Pascal I can "add" lines:
> 
>   Line1 = 'File size:' + sSize + ' bytes.';
> 
> My solution:
> 
>   strcpy(Line1, "File size:");
>   strcat(Line1, sSize);
>   strcat(Line1, " bytes.);
> 
> Again, I just wonder if there is a more simpler solution.

Yes:
sprintf(Line1,"File size: %s bytes",sSize);

And you can save yourself transforming Size into a string with

sprintf(Line1,"File size: %d bytes",Size);

> 
> 4) In Pascal I can "add" just one character of another string:
> 
>   Str1 = Str2 + Str3[5];
> 
> Unfortunately  strcat(Str1, Str3[5]);  doesn't work, I get an error
> message. My solution:
> 
>   Str4[0] = Str3[5];
>   Str4[1] = 0;
>   strcpy(Str1, Str2};
>   strcat(Str1, Str4};
> 
> It works but in this case I'm certainly not happy with the solution.
> Is there a better way?
> 

Yes.
The above can be done with

sprintf(str1,"%s%c",Str2,Str3[5]);


> Many thanks for any comment!
> 
> 
> --
>     ___
>    / __|__
>   / /  |_/     Groetjes, Ruud Baltissen
>   \ \__|_\
>    \___|       http://Ruud.C64.org
> 
> 


-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

On  1 Nov 2008 at 22:23, jacob navia wrote:
> Ian Collins wrote:
>> Not in C.
>
> That is nonsense
>
> sprintf(Line1,"File size: %s bytes",sSize);
>
> And you can save yourself transforming Size into a string with
>
> sprintf(Line1,"File size: %d bytes",Size);

Yes. In fact, many implementations also provide an asprintf() function
in their standard library, which allocates memory for Line1 with malloc,
saving you the trouble of working out the size of the buffer needed and
eliminating possible overflows if you miscalculate.

Antoninus Twink wrote:
> On  1 Nov 2008 at 22:23, jacob navia wrote:
>> Ian Collins wrote:
>>> Not in C.
>> That is nonsense
>>
>> sprintf(Line1,"File size: %s bytes",sSize);
>>
>> And you can save yourself transforming Size into a string with
>>
>> sprintf(Line1,"File size: %d bytes",Size);
> 
> Yes. In fact, many implementations also provide an asprintf() function
> in their standard library, which allocates memory for Line1 with malloc,
> saving you the trouble of working out the size of the buffer needed and
> eliminating possible overflows if you miscalculate.
> 

Yes, that would be an even better alternative.

I answered so quickly because I was astonished that somebody could answer

"Not in C"

to such elemntary question!


-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

jacob navia wrote:
> Ian Collins wrote:
>>>
>> Don't use C.  C does not have string objects, of arrays of char and
>> library functions to manipulate then.
>>
> 
> If you do not know enough C please do not use this group.
> 
Why do you have to insult everyone?

>> If you are doing a lot of string manipulation, C might not be your best
>> choice.  Scripting language like Perl are designed for string processing
>> and might be a better option.
>>
> 
> C has problems with strings but it is usable. Other languages have other
> (bigger) problems
> 
So what part of my statement do you disagree with?  A pair of pliers has
problems but is usable for undoing bolts, would you use them if you had
a spanner that fitted?

Your C tunnel vision appears to have blinded you the the existence of
other languages.

-- 
Ian Collins

Ian Collins wrote:
> jacob navia wrote:
>> Ian Collins wrote:
>>> Don't use C.  C does not have string objects, of arrays of char and
>>> library functions to manipulate then.
>>>
>> If you do not know enough C please do not use this group.
>>
> Why do you have to insult everyone?
> 

I am not insulting you. But failing to point
to sprintf as an obvious solution for that problem seems (to me)
a serious problem with the basics of the language.

I do not see why stating "you do not know enough C"
is an insult!

Besides I would have never said that if you wouldn't have
started with that arrogant

"Don't use C"

stuff.

>>> If you are doing a lot of string manipulation, C might not be your best
>>> choice.  Scripting language like Perl are designed for string processing
>>> and might be a better option.
>>>
>> C has problems with strings but it is usable. Other languages have other
>> (bigger) problems
>>
> So what part of my statement do you disagree with?  

"Don't use C"



-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

jacob navia wrote:
> Ian Collins wrote:
>> jacob navia wrote:
>>> Ian Collins wrote:
> 
>>>> If you are doing a lot of string manipulation, C might not be your best
>>>> choice.  Scripting language like Perl are designed for string
>>>> processing
>>>> and might be a better option.
>>>>
>>> C has problems with strings but it is usable. Other languages have other
>>> (bigger) problems
>>>
>> So what part of my statement do you disagree with?  
> 
> "Don't use C"
> 
But why would you use C for string manipulation when there better
alternatives?

-- 
Ian Collins

Ruud <Ruud.Baltissen@apg.nl> writes:

> 2) In Pascal there exists the "in" function. Example:
>
>    if (c in ['A'..'F', '0'..'9']) then          { c is hexadecimal }
>
> This can be translated like:
>
>    if (   ((c >= 'A') && (c <= 'Z'))
>        || ((c >= '0') && (c <= '9'))) ....      // c is hexadecimal
>
> I just wonder if there is a more simpler solution.

In this case, yes.  There are macros in <ctype.h> for testing whether a
character is a member of various classes.  This has the added advantage
of being more portable, in case you should find yourself using a
character set where 'A','B','C','D','E','F' don't occur contiguously.
So a better way to write the above might be

#include <ctype.h>
/* ... */
if (isxdigit(c)) {
  /* c is hexadecimal */
}

There are others, such as isalpha(), isdigit(), isspace(), isupper(),
etc.  See your compiler's documentation or the C standard for a complete
list.

As a side note, some compilers (such as gcc) support an extension that
would let you do

switch (c) {
  case 'A' ... 'F':
  case '0' ... '9':
    /* c is hexadecimal */
}

but that suffers the same character-set dependency as what you wrote
above, and is non-standard, and isn't really much simpler to read or write.

Ian Collins wrote:
> jacob navia wrote:
>> Ian Collins wrote:
>>> jacob navia wrote:
>>>> Ian Collins wrote:
>>>>> If you are doing a lot of string manipulation, C might not be your best
>>>>> choice.  Scripting language like Perl are designed for string
>>>>> processing
>>>>> and might be a better option.
>>>>>
>>>> C has problems with strings but it is usable. Other languages have other
>>>> (bigger) problems
>>>>
>>> So what part of my statement do you disagree with?  
>> "Don't use C"
>>
> But why would you use C for string manipulation when there better
> alternatives?
> 

For many reasons:

1) C is a simple language easily available
2) Languages like perl/python have better string manipulation
    primitives but have other problems like performance,
    and availability.
3) If you use the pcre library (distributed with lcc-win) you have
    all the power of perl in C without the problems associated
    with perl.
4) Extensions to C like those proposed by lcc-win make the
    problems with raw C strings disappear.

jacob


-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

In article <ba5a4e47-f677-4e1c-b936-2621811c5534@f37g2000pri.googlegroups.com>,
 Ruud <Ruud.Baltissen@apg.nl> wrote:

> Hallo allemaal,
> 
> 
> During the conversion of my program from Pascal to C, I was more or
> less able to find the C equivalent of most Pascal functions so far.
> Only four gave me some real trouble. I solved them but it could be I
> overlooked something.
> 
> 1) In Pascal you can declare functions inside a function. AFAIK this
> is not possible with C. Or am I wrong?

Not in standard C. Some compilers have an extension to allow this.

> 2) In Pascal there exists the "in" function. Example:
> 
>    if (c in ['A'..'F', '0'..'9']) then          { c is hexadecimal }
> 
> This can be translated like:
> 
>    if (   ((c >= 'A') && (c <= 'Z'))
>        || ((c >= '0') && (c <= '9'))) ....      // c is hexadecimal
> 
> I just wonder if there is a more simpler solution.

    if (isxdigit(c)) ...

There are various ways to represent sets as bit arrays in C. None are officially 
sanctified as a set type.

> 3) In Pascal I can "add" lines:
> 
>   Line1 = 'File size:' + sSize + ' bytes.';
> 
> My solution:
> 
>   strcpy(Line1, "File size:");
>   strcat(Line1, sSize);
>   strcat(Line1, " bytes.);
> 
> Again, I just wonder if there is a more simpler solution.

The standard C library <string.h> is not really intended to deal with 
dynamickally resized strings. There are numerous libraries and implementation 
that do all this for you. For example, Tcl has its Tcl_DString. Other solutions 
are available.

> 4) In Pascal I can "add" just one character of another string:
> 
>   Str1 = Str2 + Str3[5];
> 
> Unfortunately  strcat(Str1, Str3[5]);  doesn't work, I get an error
> message. My solution:
> 
>   Str4[0] = Str3[5];
>   Str4[1] = 0;
>   strcpy(Str1, Str2};
>   strcat(Str1, Str4};
> 
> It works but in this case I'm certainly not happy with the solution.
> Is there a better way?

As above. You can layer on top of the standard library.

-- 
I'm not even supposed to be here today.

I ASSURE YOU WE'RE OPEN!

jacob navia wrote:
> Ian Collins wrote:
>>>
>> But why would you use C for string manipulation when there better
>> alternatives?
>>
> 
> For many reasons:
> 
> 1) C is a simple language easily available
> 2) Languages like perl/python have better string manipulation
>    primitives but have other problems like performance,
>    and availability.

I'll concede performance, although scripting language string
manipulation is well optimised.  Availability is debatable, requirements
for lots of string processing tend to be on platforms where other
languages are available.

> 3) If you use the pcre library (distributed with lcc-win) you have
>    all the power of perl in C without the problems associated
>    with perl.
> 4) Extensions to C like those proposed by lcc-win make the
>    problems with raw C strings disappear.
> 
lcc-win is way less portable than most, if not all, scripting languages.

-- 
Ian Collins

Ian Collins wrote:
> jacob navia wrote:
>> Ian Collins wrote:
>>> But why would you use C for string manipulation when there better
>>> alternatives?
>>>
>> For many reasons:
>>
>> 1) C is a simple language easily available
>> 2) Languages like perl/python have better string manipulation
>>    primitives but have other problems like performance,
>>    and availability.
> 
> I'll concede performance, although scripting language string
> manipulation is well optimised.  Availability is debatable, requirements
> for lots of string processing tend to be on platforms where other
> languages are available.
> 

Well the language choice is maybe not only for string manipulation.
Other reasons are probably more important, we do not know what
application the OP has. Note that he is translating from Pascal to
C. Pascal is even worst for string manipulation than C since
libraries like PCRE regular expressions are not easily available,
and regular expressions at all are not easy to find in Pascal.

C + the PCRE library is a very good choice for string manipulation,
combining performance and power.

>> 3) If you use the pcre library (distributed with lcc-win) you have
>>    all the power of perl in C without the problems associated
>>    with perl.
>> 4) Extensions to C like those proposed by lcc-win make the
>>    problems with raw C strings disappear.
>>
> lcc-win is way less portable than most, if not all, scripting languages.
> 

Maybe. But pcre is highly portable and can be used anywhere a
C compiler exists.


-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Ruud wrote:
> 4) In Pascal I can "add" just one character of another string:
> 
>   Str1 = Str2 + Str3[5];
> 
> Unfortunately  strcat(Str1, Str3[5]);  doesn't work, I get an error
> message. My solution:
> 
>   Str4[0] = Str3[5];
>   Str4[1] = 0;
>   strcpy(Str1, Str2};
>   strcat(Str1, Str4};

You can use strncat() to concatenate any number of characters from one 
string to another.  For this case you would use

     strcpy(Str1, Str2);
     strncat(Str1, &Str3[5], 1);

Observe that Str3[5] is a char, not a pointer to char, so you have to 
take the address of it with & to pass it to strncat.  This is the source 
of the error you mentioned.

jacob navia wrote:
> Ian Collins wrote:
>> Ruud wrote:
>>
.... snip ...
>>
>>> It works but in this case I'm certainly not happy with the
>>> solution.  Is there a better way?
>>
>> Don't use C.  C does not have string objects, of arrays of char
>> and library functions to manipulate then.
> 
> If you do not know enough C please do not use this group.

Of course, if you are as knowledgeable as Jacob, and similarly
adept at avoiding off-topic messages (sarcasm) you can make such
foolish requests.

Ruud, go ahead and ask questions.  It is one way to learn.  A good
book, such as K&R II, would be helpful.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

jacob navia wrote:
> Antoninus Twink wrote:
>
.... snip ...
>
>> Yes. In fact, many implementations also provide an asprintf()
>> function in their standard library, which allocates memory for
>> Line1 with malloc, saving you the trouble of working out the
>> size of the buffer needed and eliminating possible overflows
>> if you miscalculate.
> 
> Yes, that would be an even better alternative.

Hardly, bearing in mind the fact that there is no such function as
'asprintf()' in the C standard, and that no code to implement it
has been proposed here.  Twink is a known troll, whose primary
objective appears to be disruption of the newsgroup.  Navia also
tends to be off-topic, but that appears to be largely due to
ignorance of the language combined with his refusal to listen.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

Ian Collins said:

> Ruud wrote:
>> Hallo allemaal,
>> 
>> 
>> During the conversion of my program from Pascal to C, I was more or
>> less able to find the C equivalent of most Pascal functions so far.
>> Only four gave me some real trouble. I solved them but it could be I
>> overlooked something.
>> 
>> 1) In Pascal you can declare functions inside a function. AFAIK this
>> is not possible with C. Or am I wrong?
>> 
> No, C does not have nested functions, although some compilers support
> them as extensions.

Right so far.

> 
>> 2) In Pascal there exists the "in" function. Example:
>> 
>>    if (c in ['A'..'F', '0'..'9']) then          { c is hexadecimal }
>> 
>> This can be translated like:
>> 
>>    if (   ((c >= 'A') && (c <= 'Z'))
>>        || ((c >= '0') && (c <= '9'))) ....      // c is hexadecimal
>> 
>> I just wonder if there is a more simpler solution.
>> 
> Sorry, no.

Why not at least tell him about:

if(isupper(c) || isdigit(c))

and

if(strchr("ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789", c) != NULL)

neither of which is a precise match, but each of which might be used in 
similar situations.


> One alternative is to use a regular expression library if
> you have a lot of these.

That seems like overkill to me.

> 
>> 3) In Pascal I can "add" lines:
>> 
>>   Line1 = 'File size:' + sSize + ' bytes.';
>> 
>> My solution:
>> 
>>   strcpy(Line1, "File size:");
>>   strcat(Line1, sSize);
>>   strcat(Line1, " bytes.);
>> 
>> Again, I just wonder if there is a more simpler solution.
>> 
> Not in C.

Um, of course there is.

sprintf(Line1, "File size: %d byte%s", sSize, bytes == 1 ? "" : "s");

Note the extra flexibility that C gives you.

> 
>> 4) In Pascal I can "add" just one character of another string:
>> 
>>   Str1 = Str2 + Str3[5];
>> 
>> Unfortunately  strcat(Str1, Str3[5]);  doesn't work, I get an error
>> message. My solution:
>> 
>>   Str4[0] = Str3[5];
>>   Str4[1] = 0;
>>   strcpy(Str1, Str2};
>>   strcat(Str1, Str4};
>> 
>> It works but in this case I'm certainly not happy with the solution.
>> Is there a better way?

Yes - sprintf can do this easily enough.

sprintf(Str1, "%s%c", Str2, Str3[5]);

>>
> Don't use C.

Um, he asked for a better way to do this in C. Not using C doesn't count.

> C does not have string objects,

True, but it has a string format which works just fine.

> of arrays of char and library functions to manipulate then.

I'm not sure what you mean here (unless "of" is a typo for "just" or "only" 
or "merely", but yes, C has arrays of char and library functions to 
manipulate them. Good!

> If you are doing a lot of string manipulation, C might not be your best
> choice.  Scripting language like Perl are designed for string processing
> and might be a better option.

ROTFL! If you are doing a shedload of string manipulation, C is a far 
better choice than Perl. That is, if you want it to finish some time.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Richard Heathfield wrote:
> 
> Why not at least tell him about:
> 
> if(isupper(c) || isdigit(c))
> 
> and
> 
> if(strchr("ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789", c) != NULL)
> 
I don't know, must have been a bad hair day.  Too many kids making too
much noise too early after too little caffeine.

-- 
Ian Collins

On Sat, 01 Nov 2008 23:26:37 +0100, jacob navia <jacob@nospam.com>
wrote:

>Ruud wrote:
>> Hallo allemaal,
>> 
>> 
>> During the conversion of my program from Pascal to C, I was more or
>> less able to find the C equivalent of most Pascal functions so far.
>> Only four gave me some real trouble. I solved them but it could be I
>> overlooked something.
>> 
>> 1) In Pascal you can declare functions inside a function. AFAIK this
>> is not possible with C. Or am I wrong?
>> 
>> 2) In Pascal there exists the "in" function. Example:
>> 
>>    if (c in ['A'..'F', '0'..'9']) then          { c is hexadecimal }
>> 
>> This can be translated like:
>> 
>>    if (   ((c >= 'A') && (c <= 'Z'))
>>        || ((c >= '0') && (c <= '9'))) ....      // c is hexadecimal
>> 
>> I just wonder if there is a more simpler solution.
>> 
>
>That one is simple enough

Except for the fact that it doesn't work on an EBCDIC system.


-- 
Remove del for email

Richard Heathfield <rjh@see.sig.invalid> writes:
> Ian Collins said:
>
>> Ruud wrote:
>>> Hallo allemaal,
>>> 
>>> 
>>> During the conversion of my program from Pascal to C, I was more or
>>> less able to find the C equivalent of most Pascal functions so far.
>>> Only four gave me some real trouble. I solved them but it could be I
>>> overlooked something.
>>> 
>>> 1) In Pascal you can declare functions inside a function. AFAIK this
>>> is not possible with C. Or am I wrong?
>>> 
>> No, C does not have nested functions, although some compilers support
>> them as extensions.
>
> Right so far.
>
>> 
>>> 2) In Pascal there exists the "in" function. Example:
>>> 
>>>    if (c in ['A'..'F', '0'..'9']) then          { c is hexadecimal }
>>> 
>>> This can be translated like:
>>> 
>>>    if (   ((c >= 'A') && (c <= 'Z'))
>>>        || ((c >= '0') && (c <= '9'))) ....      // c is hexadecimal
>>> 
>>> I just wonder if there is a more simpler solution.
>>> 
>> Sorry, no.
>
> Why not at least tell him about:
>
> if(isupper(c) || isdigit(c))
>
> and
>
> if(strchr("ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789", c) != NULL)

Or, even better, isxdigit().  "(c >= 'A') && (c <= 'Z')" was a typo;
the original Pascal was looking for hexadecimal digits, not
alphanumerics.  If you want to reject lowercase hex digits, you'll
need to write something like (isxdigit(c) && !islower(c)).  If c is of
type char and there's any chance its value could be negative, you'll
need to convert it to unsigned char before passing it to one of the
is*() functions.

[...]

> sprintf(Line1, "File size: %d byte%s", sSize, bytes == 1 ? "" : "s");
>
> Note the extra flexibility that C gives you.

Yes, but you have to work a bit harder (than in, say, Perl) to manage
the memory.

[...]

>> If you are doing a lot of string manipulation, C might not be your best
>> choice.  Scripting language like Perl are designed for string processing
>> and might be a better option.
>
> ROTFL! If you are doing a shedload of string manipulation, C is a far 
> better choice than Perl. That is, if you want it to finish some time.

That hasn't been my experience, but this is off-topic.

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

On  1 Nov 2008 at 23:07, jacob navia wrote:
> Antoninus Twink wrote:
>> Yes. In fact, many implementations also provide an asprintf() function
>> in their standard library, which allocates memory for Line1 with malloc,
>> saving you the trouble of working out the size of the buffer needed and
>> eliminating possible overflows if you miscalculate.
>
> Yes, that would be an even better alternative.
>
> I answered so quickly because I was astonished that somebody could answer
>
> "Not in C"
>
> to such elemntary question!

Yes, it's simply amazing what nonsense they talk.

Barry Schwarz wrote:
> On Sat, 01 Nov 2008 23:26:37 +0100, jacob navia <jacob@nospam.com>
> wrote:
> 
>> Ruud wrote:
>>> Hallo allemaal,
>>>
>>>
>>> During the conversion of my program from Pascal to C, I was more or
>>> less able to find the C equivalent of most Pascal functions so far.
>>> Only four gave me some real trouble. I solved them but it could be I
>>> overlooked something.
>>>
>>> 1) In Pascal you can declare functions inside a function. AFAIK this
>>> is not possible with C. Or am I wrong?
>>>
>>> 2) In Pascal there exists the "in" function. Example:
>>>
>>>    if (c in ['A'..'F', '0'..'9']) then          { c is hexadecimal }
>>>
>>> This can be translated like:
>>>
>>>    if (   ((c >= 'A') && (c <= 'Z'))
>>>        || ((c >= '0') && (c <= '9'))) ....      // c is hexadecimal
>>>
>>> I just wonder if there is a more simpler solution.
>>>
>> That one is simple enough
> 
> Except for the fact that it doesn't work on an EBCDIC system.
> 
> 

yes. A better solution is ishexdigit()...


-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

On Sun, 02 Nov 2008 06:54:51 +0000, Richard Heathfield wrote:

>> If you are doing a lot of string manipulation, C might not be your best
>> choice.  Scripting language like Perl are designed for string processing
>> and might be a better option.
> 
> ROTFL! If you are doing a shedload of string manipulation, C is a far 
> better choice than Perl. That is, if you want it to finish some time.

I remember what Leroy said about pascal. Now that Leroy is a big and rich
star, his criticism remains.

I think the dealbreaker is whether one plays fast and loose with data.

That's been popular.  There has, however, been the anti-phenomenon of data
mining, which plays fast and loose with data until the *right one* comes
up.
-- 
George

Freedom itself was attacked this morning by a faceless coward, and freedom
will be defended.
George W. Bush

Picture of the Day http://apod.nasa.gov/apod/

jacob navia wrote, On 02/11/08 09:56:
> Barry Schwarz wrote:
>> On Sat, 01 Nov 2008 23:26:37 +0100, jacob navia <jacob@nospam.com>
>> wrote:
>>
>>> Ruud wrote:
>>>> Hallo allemaal,
>>>>
>>>>
>>>> During the conversion of my program from Pascal to C, I was more or
>>>> less able to find the C equivalent of most Pascal functions so far.
>>>> Only four gave me some real trouble. I solved them but it could be I
>>>> overlooked something.
>>>>
>>>> 1) In Pascal you can declare functions inside a function. AFAIK this
>>>> is not possible with C. Or am I wrong?
>>>>
>>>> 2) In Pascal there exists the "in" function. Example:
>>>>
>>>>    if (c in ['A'..'F', '0'..'9']) then          { c is hexadecimal }
>>>>
>>>> This can be translated like:
>>>>
>>>>    if (   ((c >= 'A') && (c <= 'Z'))
>>>>        || ((c >= '0') && (c <= '9'))) ....      // c is hexadecimal
>>>>
>>>> I just wonder if there is a more simpler solution.
>>>>
>>> That one is simple enough
>>
>> Except for the fact that it doesn't work on an EBCDIC system.
> 
> yes. A better solution is ishexdigit()...

You means isxdigit(). This, in my opinion, is simpler than the Pascal
solution.

The OP should note that whilst '0' to '9' are guaranteed to be in
sequence (allowing "c - '0'" to work as expected) there is no such
guarantee with letters in C. Since I'm guessing there will be a
conversion from character to number for a fully portable solution strchr
could well be useful.
   static const char *xdigits = "0123456789ABCDEF";
   char *pos = strchr("0123456789ABCDEF",toupper((unsigned char)c));
   if (pos) { /* character found so was a hex digit */
      digit = pos - xdigits;
   }
   else { /* not a hex digit */
   }

In my opinion, for characters strchr is very close to "in" in Pascal.
-- 
Flash Gordon
If spamming me sent it to smap@spam.causeway.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/

Hallo allemaal,


Many thanks for the massive response!


jacob navia wrote:
> If you do not know enough C please do not use this group.

Then please be a good man and tell me what level I should have before
I can attend this group?


Chuck wrote:
> Ruud, go ahead and ask questions.

Thank you very much for your support, Chuck!


> A good book, such as K&R II, would be helpful.

The book isn't the problem, see next.


Richard wrote:
> Why not at least tell him about:
>
> if(isupper(c) || isdigit(c))
>
> and
>
> if(strchr("ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789", c) != NULL)

The problem is not knowing all those available functions. And knowing
another language is a disavantage as well: instead of reading the book
line by line, one tends to look just at "how is this done in C".
And even reading the book line by line isn't a guarantee for success:
I justed searched the book "C in 21 days" for 'isdigit' and only found
one source file using this function. OTOH, this source file also
mentioned the function 'isspace' and this function does exactly what
one of my own made function does; detecting white space.


> sprintf

Not mentioned at all "C in 21 days" :( Because 'printf' was well
explained, I never used the help function of Borland C to give it a
better look. I wish I had because I just did: I learned nothing new
about 'printf' but the page also mentioned 'sprintf' and many more
other functions.


Trent wrote:
> strncat(Str1, &Str3[5], 1);

Here I have no excuse, it is mentioned very clearly in the book.


--
    ___
   / __|__
  / /  |_/     Groetjes, Ruud Baltissen
  \ \__|_\
   \___|      http://Ruud.C64.org

Ruud wrote:
> Hallo allemaal,
> 
> 
> Many thanks for the massive response!
> 
> 
> jacob navia wrote:
>> If you do not know enough C please do not use this group.
> 

> Then please be a good man and tell me what level I should have before
> I can attend this group?
> 

As you can see from my quotes, I do not told YOU that but to Ian
Collins. Please try to understand how quoting works.



-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

On Sun, 02 Nov 2008 01:28:00 -0700, Barry Schwarz wrote:
> On Sat, 01 Nov 2008 23:26:37 +0100, jacob navia <jacob@nospam.com>
> wrote:
>>Ruud wrote:
>>> 2) In Pascal there exists the "in" function. Example:
>>> 
>>>    if (c in ['A'..'F', '0'..'9']) then          { c is hexadecimal }
>>> 
>>> This can be translated like:
>>> 
>>>    if (   ((c >= 'A') && (c <= 'Z'))
>>>        || ((c >= '0') && (c <= '9'))) ....      // c is hexadecimal
>>> 
>>> I just wonder if there is a more simpler solution.
>>
>>That one is simple enough
> 
> Except for the fact that it doesn't work on an EBCDIC system.

It will (after fixing 'Z' so that it reads 'F') work on ASCII end EBCDIC 
systems. In theory, there could be other systems where it will fail. I 
doubt there are any such systems in practise, though.

Ruud wrote:
> Hallo allemaal,
> 
> 
> During the conversion of my program from Pascal to C, I was more or
> less able to find the C equivalent of most Pascal functions so far.
> Only four gave me some real trouble. I solved them but it could be I
> overlooked something.
> 
> 1) In Pascal you can declare functions inside a function. AFAIK this
> is not possible with C. Or am I wrong?

     Inside a C function you can *declare* another function
but you cannot *define* one.

> 2) In Pascal there exists the "in" function. Example:
> 
>    if (c in ['A'..'F', '0'..'9']) then          { c is hexadecimal }
> 
> This can be translated like:
> 
>    if (   ((c >= 'A') && (c <= 'Z'))
>        || ((c >= '0') && (c <= '9'))) ....      // c is hexadecimal
> 
> I just wonder if there is a more simpler solution.

     There are no built-in "set membership" facilities in C.
It's assumed that different kinds of sets call for different
kinds of representations -- bit mask, array of elements, array
of ranges, whatever -- and that you will code according to the
representation chosen rather than to the set abstraction.

     For classifying characters, though, the Standard library
offers some functions you may find useful.  In particular, the
<ctype.h> header declares two functions you can combine to make
the test shown in your example:

	#include <ctype.h>
	...
	int ch = (unsigned char)(...);
	if (isxdigit(ch) && !islower(ch)) ...

> 3) In Pascal I can "add" lines:
> 
>   Line1 = 'File size:' + sSize + ' bytes.';
> 
> My solution:
> 
>   strcpy(Line1, "File size:");
>   strcat(Line1, sSize);
>   strcat(Line1, " bytes.);
> 
> Again, I just wonder if there is a more simpler solution.

     That works, assuming sSize is a string and Line1 is a
char[] array of sufficient size.  An alternative that can be
convenient (especially if some of the data are not already
in string form) is to use sprintf().

> 4) In Pascal I can "add" just one character of another string:
> 
>   Str1 = Str2 + Str3[5];
> 
> Unfortunately  strcat(Str1, Str3[5]);  doesn't work, I get an error
> message. My solution:
> 
>   Str4[0] = Str3[5];
>   Str4[1] = 0;
>   strcpy(Str1, Str2};
>   strcat(Str1, Str4};
> 
> It works but in this case I'm certainly not happy with the solution.
> Is there a better way?

     "Better" is a slippery word.  There are certainly "other"
ways, such as

	strcpy(Str1, Str2);
	Str1[ strlen(Str2) ] = Str3[5];
	Str1[ strlen(Str2) ] = '\0';

or

	sprintf (Str1, "%s%c", Str2, Str3[5]);

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

Ruud wrote, On 02/11/08 12:11:
> Hallo allemaal,

<snip>

>> A good book, such as K&R II, would be helpful.
> 
> The book isn't the problem, see next.

Ah, but it could be! You would be well advised to get K&R2.


<snip>

> I justed searched the book "C in 21 days" for 'isdigit' and only found

<snip>

> Not mentioned at all "C in 21 days" :( Because 'printf' was well

<snip>

"C in 21 days" is *a* book, but what makes you think it is a *good*
book? K&R2 is an excellent (but not perfect) book and there are a few
others that generally get recommended here, but the book you have is not
one of them.
-- 
Flash Gordon
If spamming me sent it to smap@spam.causeway.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/

On Sun, 2 Nov 2008 12:50:11 +0000 (UTC), Harald van D?k
<truedfx@gmail.com> wrote:

>On Sun, 02 Nov 2008 01:28:00 -0700, Barry Schwarz wrote:
>> On Sat, 01 Nov 2008 23:26:37 +0100, jacob navia <jacob@nospam.com>
>> wrote:
>>>Ruud wrote:
>>>> 2) In Pascal there exists the "in" function. Example:
>>>> 
>>>>    if (c in ['A'..'F', '0'..'9']) then          { c is hexadecimal }
>>>> 
>>>> This can be translated like:
>>>> 
>>>>    if (   ((c >= 'A') && (c <= 'Z'))
>>>>        || ((c >= '0') && (c <= '9'))) ....      // c is hexadecimal
>>>> 
>>>> I just wonder if there is a more simpler solution.
>>>
>>>That one is simple enough
>> 
>> Except for the fact that it doesn't work on an EBCDIC system.
>
>It will (after fixing 'Z' so that it reads 'F') work on ASCII end EBCDIC 
>systems. In theory, there could be other systems where it will fail. I 
>doubt there are any such systems in practise, though.

On EBCDIC systems, a-f are also valid hex digits.  The same is true on
Solaris systems.  Even in standard C, the conversion specification "x"
produces a-f while"X" produces A-F.  Surely each of the characters
produced either way is a valid hex character.

-- 
Remove del for email

jacob navia <jacob@nospam.com> writes:
> Ruud wrote:
>> Hallo allemaal,
>> Many thanks for the massive response!
>> jacob navia wrote:
>>> If you do not know enough C please do not use this group.
>
>> Then please be a good man and tell me what level I should have before
>> I can attend this group?
>
> As you can see from my quotes, I do not told YOU that but to Ian
> Collins. Please try to understand how quoting works.

I think he understood that.  If your remark was intended only for Ian
Collins, you could have sent him e-mail.  You seemed to be mandating
some minimum level of knowledge as a requirement for posting here;
surely such a rule would not apply only to Ian Collins.  Ruud just
wanted to you clarify the rules.

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

Barry Schwarz <schwarzb@dqel.com> writes:
> On Sun, 2 Nov 2008 12:50:11 +0000 (UTC), Harald van D?k
> <truedfx@gmail.com> wrote:
>
>>On Sun, 02 Nov 2008 01:28:00 -0700, Barry Schwarz wrote:
>>> On Sat, 01 Nov 2008 23:26:37 +0100, jacob navia <jacob@nospam.com>
>>> wrote:
>>>>Ruud wrote:
>>>>> 2) In Pascal there exists the "in" function. Example:
>>>>> 
>>>>>    if (c in ['A'..'F', '0'..'9']) then          { c is hexadecimal }
>>>>> 
>>>>> This can be translated like:
>>>>> 
>>>>>    if (   ((c >= 'A') && (c <= 'Z'))
>>>>>        || ((c >= '0') && (c <= '9'))) ....      // c is hexadecimal
>>>>> 
>>>>> I just wonder if there is a more simpler solution.
>>>>
>>>>That one is simple enough
>>> 
>>> Except for the fact that it doesn't work on an EBCDIC system.
>>
>>It will (after fixing 'Z' so that it reads 'F') work on ASCII end EBCDIC 
>>systems. In theory, there could be other systems where it will fail. I 
>>doubt there are any such systems in practise, though.
>
> On EBCDIC systems, a-f are also valid hex digits.  The same is true on
> Solaris systems.  Even in standard C, the conversion specification "x"
> produces a-f while"X" produces A-F.  Surely each of the characters
> produced either way is a valid hex character.

Maybe the OP has some specific reason to accept only uppercase
letters.  (Or maybe he just forgot about lowercase letters.)

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

In article <gek9ce$uv0$1@registered.motzarella.org>,
Eric Sosman  <esosman@ieee-dot-org.invalid> wrote:

[Copying a single character into a string]

>     "Better" is a slippery word.  There are certainly "other"
>ways, such as
>
>	strcpy(Str1, Str2);
>	Str1[ strlen(Str2) ] = Str3[5];
>	Str1[ strlen(Str2) ] = '\0';

That last line looks wrong to me; I think you want to add 1 to
strlen(Str2) before you use it as an index into Str1.

If I were writing that code, I would probably use something like this
instead:
    strcpy(Str1,Str2);
    len=strlen(Str1);
    Str1[len++]=Str3[5];
    Str1[len++]='\0';

This is also a case where strncat's (generally confusing)
interpretation of its count argument turns out to be useful:
    strcpy(Str1,Str2);
    strncat(Str1,Str3+5,1);
(But be careful using this one in code that has to be maintained.)


dave

-- 
Dave Vandervies                     dj3vande at eskimo dot com
> You are determined to martyr yourself on a nonexistent altar
An altar could be arranged.
         --Mark McIntyre and Richard Heathfield in comp.lang.c

On November 1, 2008 17:43, in comp.lang.c, Ruud (Ruud.Baltissen@apg.nl)
wrote:

> Hallo allemaal,
[snip]
> 2) In Pascal there exists the "in" function. Example:
> 
>    if (c in ['A'..'F', '0'..'9']) then          { c is hexadecimal }
> 
> This can be translated like:
> 
>    if (   ((c >= 'A') && (c <= 'Z'))
>        || ((c >= '0') && (c <= '9'))) ....      // c is hexadecimal

Actually, no it can't.

First off, your Pascal original only validates the
characters 'A', 'B', 'C', 'D', 'E', 'F', '0', '1', '2', '3', '4', '5',
'6', '7', '8', and '9', while your C "translation" (if it did what you
intended) would validate all the uppercase characters from 'A' to 'Z'
(exceeding your original requirement by 20 character values) along with the
digits '0' through '9'.

*But*, your C "translation" of the Pascal code is incorrect. In C, the
only "target characterset" characters required to be in ascending,
sequential order are the values from '0' to '9'. The target characterset
is /not/ obliged to support ascending sequential 'A' to 'Z', and indeed,
some target charactersets (notably all the EBCDIC variants) insert
additional characters /between/ various alphabetics. On an EBCDIC-US
machine, your code would accept as alphabetic about a dozen unprintable
characters, along with '}' and '\', between 'A' and 'Z' inclusive.

[snip]

HTH
-- 
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/   | GPG public key available by request
----------      Slackware - Because I know what I'm doing.          ------

dj3vande@csclub.uwaterloo.ca.invalid wrote:
> In article <gek9ce$uv0$1@registered.motzarella.org>,
> Eric Sosman  <esosman@ieee-dot-org.invalid> wrote:
> 
> [Copying a single character into a string]
> 
>>     "Better" is a slippery word.  There are certainly "other"
>> ways, such as
>>
>> 	strcpy(Str1, Str2);
>> 	Str1[ strlen(Str2) ] = Str3[5];
>> 	Str1[ strlen(Str2) ] = '\0';
> 
> That last line looks wrong to me; I think you want to add 1 to
> strlen(Str2) before you use it as an index into Str1.

     Right you are.  Thanks.

> If I were writing that code, I would probably use something like this
> instead:
>     strcpy(Str1,Str2);
>     len=strlen(Str1);
>     Str1[len++]=Str3[5];
>     Str1[len++]='\0';
> 
> This is also a case where strncat's (generally confusing)
> interpretation of its count argument turns out to be useful:
>     strcpy(Str1,Str2);
>     strncat(Str1,Str3+5,1);
> (But be careful using this one in code that has to be maintained.)

     ... and now you need to tack on the terminating '\0'
that strncat() didn't give you.  (We're both obviously
suffering from the effects of a 25-hour day, and besides:
Turnabout is fair play.)

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

jacob navia wrote:
> Ruud wrote:
>> jacob navia wrote:
>>
>>> If you do not know enough C please do not use this group.
>> 
>> Then please be a good man and tell me what level I should have
>> before I can attend this group?
> 
> As you can see from my quotes, I do not told YOU that but to
> Ian Collins. Please try to understand how quoting works.

Jacob (and others), Usenet is NOT for private communications.  Any
such should be done via email, if possible.  All Usenet messages
are totally public, and addressed to the general readership.  They
are delivered to the readership, barring plonking etc.

You have been told this before, but you persist in the same error.

The following is primarily for Ruuds benefit, but all are invited
to examine the referances.  The C99 items (n869_txt.bz2 is bzip2
compressed) describe the standard, and all functions in the
standard library.  The dinkumware reference is also an excellent
introduction the the standard library.

Some useful references about C:
 <http://www.ungerhu.com/jxh/clc.welcome.txt>
 <http://c-faq.com/>                                       (C-faq)
 <http://benpfaff.org/writings/clc/off-topic.html>
 <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf> (C99)
 <http://cbfalconer.home.att.net/download/n869_txt.bz2>  (pre-C99)
 <http://www.dinkumware.com/c99.aspx>                  (C-library}
 <http://gcc.gnu.org/onlinedocs/>                       (GNU docs)
 <http://clc-wiki.net/wiki/C_community:comp.lang.c:Introduction>

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

CBFalconer wrote:
> jacob navia wrote:
>> Ruud wrote:
>>> jacob navia wrote:
>>>
>>>> If you do not know enough C please do not use this group.
>>> Then please be a good man and tell me what level I should have
>>> before I can attend this group?
>> As you can see from my quotes, I do not told YOU that but to
>> Ian Collins. Please try to understand how quoting works.
> 
> Jacob (and others), Usenet is NOT for private communications. 

Hey you, can't you read? My answer was public.

This is a typical facloner post.

he doesn't knopw wnything of what's going on, and goes around
by "keywords". He sees "jacobn" then, of course it must be wrong!


  Any
> such should be done via email, if possible.  All Usenet messages
> are totally public, and addressed to the general readership.  They
> are delivered to the readership, barring plonking etc.
> 
> You have been told this before, but you persist in the same error.
> 

Yes falconer. You have been told this but you persist:
Read the messages and the context before spewing nonsense.


1) The OP asked a question
2) Ian collins said it wasn't possible to do that in C and that C
wasn't appropiate language for string processing.
I answered that post with a refultal and an example of how the OP
question could be answered. My answer was to Ian Collin's reply.

Look at the attributions now and follow the posts. It is not that
difficult.

Then, the OP misunderstood my quoting and thought I answered to him

Then you saw that wrong reply and without looking you take your
"professor chuck" hat and start spewing nonsense.

-- 
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

In article <gekuc2$atn$1@registered.motzarella.org>,
Eric Sosman  <esosman@ieee-dot-org.invalid> wrote:
>dj3vande@csclub.uwaterloo.ca.invalid wrote:

>> [Copying a single character into a string]

>> This is also a case where strncat's (generally confusing)
>> interpretation of its count argument turns out to be useful:
>>     strcpy(Str1,Str2);
>>     strncat(Str1,Str3+5,1);
>> (But be careful using this one in code that has to be maintained.)
>
>     ... and now you need to tack on the terminating '\0'
>that strncat() didn't give you.

It's strncpy that doesn't give a terminating '\0'; strncat copies at
most count characters from the source string to the end of the dest
string and then adds a '\0'.  (I *did* say that it was confusing.  I
had to check the man page to see which strncat was.  I just checked
N1124, and it agrees with the man page (7.21.3.2).)


dave

-- 
Dave Vandervies                                    dj3vande at eskimo dot com
A lot of comp.lang.c people are traditionalists. For a very long time, the
*only* date of celebration recognised all over Usenet was 1st April. In
comp.lang.c that is still more or less the case.  --Richard Heathfield in CLC

Lew Pitcher <lpitcher@teksavvy.com> writes:
> On November 1, 2008 17:43, in comp.lang.c, Ruud (Ruud.Baltissen@apg.nl)
> wrote:
[...]
>> 2) In Pascal there exists the "in" function. Example:
>> 
>>    if (c in ['A'..'F', '0'..'9']) then          { c is hexadecimal }
>> 
>> This can be translated like:
>> 
>>    if (   ((c >= 'A') && (c <= 'Z'))
>>        || ((c >= '0') && (c <= '9'))) ....      // c is hexadecimal
>
> Actually, no it can't.
>
[...]
> 
> *But*, your C "translation" of the Pascal code is incorrect. In C, the
> only "target characterset" characters required to be in ascending,
> sequential order are the values from '0' to '9'. The target characterset
> is /not/ obliged to support ascending sequential 'A' to 'Z', and indeed,
> some target charactersets (notably all the EBCDIC variants) insert
> additional characters /between/ various alphabetics. On an EBCDIC-US
> machine, your code would accept as alphabetic about a dozen unprintable
> characters, along with '}' and '\', between 'A' and 'Z' inclusive.

You're assuming that Pascal does require the letters 'A'-'Z' to have
sequential codes.  I don't know whether it does or not, but my guess
is that it doesn't, any more than C does.  I'm sure there have been
Pascal implementations for EBCDIC-based systems.

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

dj3vande@csclub.uwaterloo.ca.invalid wrote:
> In article <gekuc2$atn$1@registered.motzarella.org>,
> Eric Sosman  <esosman@ieee-dot-org.invalid> wrote:
>> dj3vande@csclub.uwaterloo.ca.invalid wrote:
> 
>>> [Copying a single character into a string]
> 
>>> This is also a case where strncat's (generally confusing)
>>> interpretation of its count argument turns out to be useful:
>>>     strcpy(Str1,Str2);
>>>     strncat(Str1,Str3+5,1);
>>> (But be careful using this one in code that has to be maintained.)
>>     ... and now you need to tack on the terminating '\0'
>> that strncat() didn't give you.
> 
> It's strncpy that doesn't give a terminating '\0'; strncat copies at
> most count characters from the source string to the end of the dest
> string and then adds a '\0'.  (I *did* say that it was confusing.  I
> had to check the man page to see which strncat was.  I just checked
> N1124, and it agrees with the man page (7.21.3.2).)

     (Sigh.)  Not my day, is it?  I must have forgotten not
to take my stupid pills ...

     Thanks again.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

dj3vande@csclub.uwaterloo.ca.invalid writes:
[...]
> It's strncpy that doesn't give a terminating '\0'; strncat copies at
> most count characters from the source string to the end of the dest
> string and then adds a '\0'.  (I *did* say that it was confusing.  I
> had to check the man page to see which strncat was.  I just checked
> N1124, and it agrees with the man page (7.21.3.2).)

N1256 is more up to date.

http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf

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

dj3vande@csclub.uwaterloo.ca.invalid wrote:
> Eric Sosman  <esosman@ieee-dot-org.invalid> wrote:
>
.... snip ...
>
>> ... and now you need to tack on the terminating '\0'
>> that strncat() didn't give you.
> 
> It's strncpy that doesn't give a terminating '\0'; strncat copies
> at most count characters from the source string to the end of the
> dest string and then adds a '\0'.  (I *did* say that it was
> confusing.  I had to check the man page to see which strncat was. 
> I just checked N1124, and it agrees with the man page (7.21.3.2).)

I suggest ignoring strncpy and its nuisances, and using strlcpy and
strlcat.  These names are reserved, but you can change them. 
Source code in standard C, and full documentation, are all
available at:

  <http://cbfalconer.home.att.net/download/strlcpy.zip>

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

Oops. My apologies to Keith Thompson and the rest of comp.lang.c

I meant to post my reply, but I hit "mail to" instead.
Here's my reply, posted.


On November 2, 2008 17:07, in comp.lang.c, Keith Thompson (kst-u@mib.org)
wrote:

> Lew Pitcher <lpitcher@teksavvy.com> writes:
>> On November 1, 2008 17:43, in comp.lang.c, Ruud (Ruud.Baltissen@apg.nl)
>> wrote:
> [...]
>>> 2) In Pascal there exists the "in" function. Example:
>>> 
>>>    if (c in ['A'..'F', '0'..'9']) then          { c is hexadecimal }
>>> 
>>> This can be translated like:
>>> 
>>>    if (   ((c >= 'A') && (c <= 'Z'))
>>>        || ((c >= '0') && (c <= '9'))) ....      // c is hexadecimal
>>
>> Actually, no it can't.
>>
> [...]
>> 
>> *But*, your C "translation" of the Pascal code is incorrect. In C, the
>> only "target characterset" characters required to be in ascending,
>> sequential order are the values from '0' to '9'. The target characterset
>> is /not/ obliged to support ascending sequential 'A' to 'Z', and indeed,
>> some target charactersets (notably all the EBCDIC variants) insert
>> additional characters /between/ various alphabetics. On an EBCDIC-US
>> machine, your code would accept as alphabetic about a dozen unprintable
>> characters, along with '}' and '\', between 'A' and 'Z' inclusive.
> 
> You're assuming that Pascal does require the letters 'A'-'Z' to have
> sequential codes. 

Not really. I know (with support from a couple of my old PASCAL
books: "Algorithms + Data Structures = Programs" by Nicklaus Wirth,
and "Microcomputer Problem Solving using PASCAL" by Kenneth L. Bowles) that
the PASCAL set ['A'..'F'] enumerates out to 'A', 'B', 'C', 'D', 'E', 'F'.
Similarly, the PASCAL set ['A'..'Z'] enumerates out to all the uppercase
characters from 'A' to 'Z' inclusive, and nothing else.

In any case, I was talking C, not PASCAL.

Can we agree that the C expression
  ((c >= 'A') && (c <= 'Z'))
(for a char c) is platform and characterset specific, and that in some
target charactersets, the expression /will not/ result in a "false" value
for some non-alphabetic characters?

> I don't know whether it does or not, but my guess 
> is that it doesn't,

It doesn't matter. We're not talking about PASCAL handling a range of
characters. Instead we're talking about the equivalence of a PASCAL "set"
to a /C/ range of characters. And, there are some times when the
PASCAL "set" and the C range do not match.

> any more than C does.  I'm sure there have been 
> Pascal implementations for EBCDIC-based systems.

True, but beside the point.
-- 
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/   | GPG public key available by request
----------      Slackware - Because I know what I'm doing.          ------

In article <490E2A52.C79786D8@yahoo.com>,
CBFalconer  <cbfalconer@maineline.net> wrote:

>I suggest ignoring strncpy and its nuisances, and using strlcpy and
>strlcat.

The case I was commenting on was one of the (admittedly few) cases
where strncat makes it *easier* to do The Right Thing than strlcat
would.


dave

-- 
Dave Vandervies                                     dj3vande at eskimo dot com
Actually, I'm toying with approaching a mug-printing outfit to see if they can
do me an Emacs reference quart-sized mug although I fear that the text might
still be too small to read.       --Peter Corlett in the scary devil monastery

On Sun, 02 Nov 2008 10:59:20 +1300, Ian Collins <ian-news@hotmail.com>
wrote:

>Ruud wrote:
>Sorry, no.  One alternative is to use a regular expression library if
>you have a lot of these.

Please.  Point me to a regular expression library for C.  Please.
-- 
I cum frum Brooklyn an if y'want me tuh, 
I'll loin yuh tuh tawk right. Hell, I'll 
loin all of yez.

Lew Pitcher <lpitcher@teksavvy.com> writes:
[...]
> On November 2, 2008 17:07, in comp.lang.c, Keith Thompson (kst-u@mib.org)
> wrote:
>
>> Lew Pitcher <lpitcher@teksavvy.com> writes:
>>> On November 1, 2008 17:43, in comp.lang.c, Ruud (Ruud.Baltissen@apg.nl)
>>> wrote:
>> [...]
>>>> 2) In Pascal there exists the "in" function. Example:
>>>> 
>>>>    if (c in ['A'..'F', '0'..'9']) then          { c is hexadecimal }
>>>> 
>>>> This can be translated like:
>>>> 
>>>>    if (   ((c >= 'A') && (c <= 'Z'))
>>>>        || ((c >= '0') && (c <= '9'))) ....      // c is hexadecimal
>>>
>>> Actually, no it can't.
>>>
>> [...]
>>> 
>>> *But*, your C "translation" of the Pascal code is incorrect. In C, the
>>> only "target characterset" characters required to be in ascending,
>>> sequential order are the values from '0' to '9'. The target characterset
>>> is /not/ obliged to support ascending sequential 'A' to 'Z', and indeed,
>>> some target charactersets (notably all the EBCDIC variants) insert
>>> additional characters /between/ various alphabetics. On an EBCDIC-US
>>> machine, your code would accept as alphabetic about a dozen unprintable
>>> characters, along with '}' and '\', between 'A' and 'Z' inclusive.
>> 
>> You're assuming that Pascal does require the letters 'A'-'Z' to have
>> sequential codes. 
>
> Not really. I know (with support from a couple of my old PASCAL
> books: "Algorithms + Data Structures = Programs" by Nicklaus Wirth,
> and "Microcomputer Problem Solving using PASCAL" by Kenneth L. Bowles) that
> the PASCAL set ['A'..'F'] enumerates out to 'A', 'B', 'C', 'D', 'E', 'F'.
> Similarly, the PASCAL set ['A'..'Z'] enumerates out to all the uppercase
> characters from 'A' to 'Z' inclusive, and nothing else.
>
> In any case, I was talking C, not PASCAL.

When I learned Pascal (<NAMEDROP>from Ken Bowles</NAMEDROP>), that was
the assumption, but then we were using ASCII-based systems.

I just grabbed a copy of iso7185.pdf, ISO 7185:1990.  My reading is
that ['A'..'Z'] specifies the set of all char values >='A' and <='Z';
on a system where the representation of type char is EBCDIC, it would
include all the uppercase letters *plus* several other characters.

> Can we agree that the C expression
>   ((c >= 'A') && (c <= 'Z'))
> (for a char c) is platform and characterset specific, and that in some
> target charactersets, the expression /will not/ result in a "false" value
> for some non-alphabetic characters?

Certainly.

>> I don't know whether it does or not, but my guess 
>> is that it doesn't,
>
> It doesn't matter. We're not talking about PASCAL handling a range of
> characters. Instead we're talking about the equivalence of a PASCAL "set"
> to a /C/ range of characters. And, there are some times when the
> PASCAL "set" and the C range do not match.
>
>> any more than C does.  I'm sure there have been 
>> Pascal implementations for EBCDIC-based systems.
>
> True, but beside the point.

See above.

Yes, Pascal is off-topic, but the original question was how to write C
equivalent to a certain chunk of Pascal code, so we need to understand
what the Pascal means; we could (and do) as easily discuss nuances of
English grammar when the problem is described in English.

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

Pilcrow <Pilcrow6@gmail.com> writes:
> On Sun, 02 Nov 2008 10:59:20 +1300, Ian Collins <ian-news@hotmail.com>
> wrote:
>>Ruud wrote:
>>Sorry, no.  One alternative is to use a regular expression library if
>>you have a lot of these.
>
> Please.  Point me to a regular expression library for C.  Please.

A Google search for "C regular expression library" gets about 441,000
hits; many of the first few appear to be quite relevant.

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

On Nov 2, 5:31=A0pm, CBFalconer <cbfalconer@yahoo.com> wrote:
> dj3vande@csclub.uwaterloo.ca.invalid wrote:
> > Eric Sosman =A0<esosman@ieee-dot-org.invalid> wrote:
>
> ... snip ...
>
> >> ... and now you need to tack on the terminating '\0'
> >> that strncat() didn't give you.
>
> > It's strncpy that doesn't give a terminating '\0'; strncat copies
> > at most count characters from the source string to the end of the
> > dest string and then adds a '\0'. =A0(I *did* say that it was
> > confusing. =A0I had to check the man page to see which strncat was.
> > I just checked N1124, and it agrees with the man page (7.21.3.2).)
>
> I suggest ignoring strncpy and its nuisances, and using strlcpy and
> strlcat. =A0These names are reserved, but you can change them.
> Source code in standard C, and full documentation, are all
> available at:
>
> =A0 <http://cbfalconer.home.att.net/download/strlcpy.zip>

So you bash powerful functions like asprintf(), but advocate trivial,
ten-liner functions like strlcpy() and strlcat()?

Sebastian

On 2 Nov, 12:11, Ruud <Ruud.Baltis...@apg.nl> wrote:
> jacob navia wrote:

> > If you do not know enough C please do not use this group.
>
> Then please be a good man and tell me what level I should have before
> I can attend this group?

Jacob was talking rubbish


> Chuck wrote:

<snip>

> > A good book, such as K&R II, would be helpful.
>
> The book isn't the problem, see next.
>
> Richard wrote:

Ruud, you use an odd quoting convention doesn't your
news software support the more usual conventions
(all the attributions at the top)?

> > Why not at least tell him about:
>
> > if(isupper(c) || isdigit(c))
>
> > and
>
> > if(strchr("ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789", c) != NULL)
>
> The problem is not knowing all those available functions.

yes, I remember all those functions and headers looked pretty
forbidding when I started learning C (also from pascal).
It didn't help that my implementation didn't distinguish
non-standard from standard headers.

> And knowing
> another language is a disavantage as well: instead of reading the book
> line by line, one tends to look just at "how is this done in C".

K&R is pretty good for getting C idioms over. It really is
worth ploughing through K&R and doing the exercises. It's
not a big book (though information dense).


> And even reading the book line by line isn't a guarantee for success:

there are no guarantees!

> I justed searched the book "C in 21 days"

"xyz in small number days" isn't usually a promising title.
Really, give K&R a try.

I've got a book that promises to teach me to ride a horse in
a weekend...

> for 'isdigit' and only found
> one source file using this function. OTOH, this source file also
> mentioned the function 'isspace' and this function does exactly what
> one of my own made function does; detecting white space.
>
> > sprintf
>
> Not mentioned at all "C in 21 days"

oh dear. sprintf() is *really* useful.

> :( Because 'printf' was well
> explained, I never used the help function of Borland C to give it a
> better look. I wish I had because I just did: I learned nothing new
> about 'printf' but the page also mentioned 'sprintf' and many more
> other functions.
>
> Trent wrote:
> > strncat(Str1, &Str3[5], 1);
>
> Here I have no excuse, it is mentioned very clearly in the book.


--
Nick Keighley

"ALGOL 60 was a language so far ahead of its time that it
was not only an improvement on its predecessors but also
on nearly all its successors".
		--C.A.R. Hoare

On 2 Nov, 22:08, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> dj3va...@csclub.uwaterloo.ca.invalid wrote:
> > In article <gekuc2$at...@registered.motzarella.org>,
> > Eric Sosman =A0<esos...@ieee-dot-org.invalid> wrote:
> >> dj3va...@csclub.uwaterloo.ca.invalid wrote:

> >>> [Copying a single character into a string]
>
> >>> This is also a case where strncat's (generally confusing)
> >>> interpretation of its count argument turns out to be useful:
> >>> =A0 =A0 strcpy(Str1,Str2);
> >>> =A0 =A0 strncat(Str1,Str3+5,1);
> >>> (But be careful using this one in code that has to be maintained.)
>
> >> =A0 =A0 ... and now you need to tack on the terminating '\0'
> >> that strncat() didn't give you.
>
> > It's strncpy that doesn't give a terminating '\0'; strncat copies at
> > most count characters from the source string to the end of the dest
> > string and then adds a '\0'. =A0(I *did* say that it was confusing. =A0=
I
> > had to check the man page to see which strncat was. =A0I just checked
> > N1124, and it agrees with the man page (7.21.3.2).)
>
> =A0 =A0 =A0(Sigh.) =A0Not my day, is it? =A0I must have forgotten not
> to take my stupid pills ...

I have a reflex, as soon as I see a string of the form strn* in a post
I start to post my standard "strncpy() may not do what you expect"
reply. I had it all composed and ready to send when I noticed he
was using strncat(). So I pressed Discard instead of Send.
But it was close  :-)


--
Nick Keighley

"Resistance is futile.  Read the C-faq."
		-- James Hu (c.l.c.)

On  3 Nov 2008 at  7:36, s0suk3@gmail.com wrote:
> On Nov 2, 5:31 pm, CBFalconer <cbfalconer@yahoo.com> wrote:
>> I suggest ignoring strncpy and its nuisances, and using strlcpy and
>> strlcat.  These names are reserved, but you can change them.
>> Source code in standard C, and full documentation, are all
>> available at:
>>
>>   <http://[spam snipped]>
>
> So you bash powerful functions like asprintf(), but advocate trivial,
> ten-liner functions like strlcpy() and strlcat()?

Yes, funny how that works, isn't it?

I often wonder what motivates CBF to post his spamming crap about
strlcpy, ggets, etc. time and time again. Maybe he makes ad revenue from
his site, or maybe it's just the ego trip of looking at his logs and
counting the number of people he manages to gull into making the mistake
of downloading his unreadable garbage.

On  3 Nov 2008 at  8:31, Nick Keighley wrote:
> On 2 Nov, 12:11, Ruud <Ruud.Baltis...@apg.nl> wrote:
>> jacob navia wrote:
>> > If you do not know enough C please do not use this group.
>>
>> Then please be a good man and tell me what level I should have before
>> I can attend this group?
>
> Jacob was talking rubbish

No, he wasn't.

He was clearly addressing Collins' arrogance in wading into a
conversation with an air of authority and spouting nonsense. Jacob was
clearly criticizing people who pretend to be C experts while in fact
talking nonsense, not newbies with genuine questions.

s0suk3@gmail.com wrote:
> CBFalconer <cbfalconer@yahoo.com> wrote:
>
.... snip ...
>
>> I suggest ignoring strncpy and its nuisances, and using strlcpy
>> and strlcat.  These names are reserved, but you can change them.
>> Source code in standard C, and full documentation, are all
>> available at:
>>
>>   <http://cbfalconer.home.att.net/download/strlcpy.zip>
> 
> So you bash powerful functions like asprintf(), but advocate
> trivial, ten-liner functions like strlcpy() and strlcat()?

Definitely.  Especially functions whose complete action is easily
described.  Above all when they replace variadic (and thus error
prone) functions.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

On Nov 2, 1:17=A0pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> dj3va...@csclub.uwaterloo.ca.invalid wrote:
> >> =A0 =A0 =A0 =A0strcpy(Str1, Str2);
> >> =A0 =A0 =A0 =A0Str1[ strlen(Str2) ] =3D Str3[5];
> >> =A0 =A0 =A0 =A0Str1[ strlen(Str2) ] =3D '\0';
>
> > That last line looks wrong to me; I think you want to add 1 to
> > strlen(Str2) before you use it as an index into Str1.
>
> =A0 =A0 =A0Right you are. =A0Thanks.


Actually you need to save the result of the strlen() in the second
line, since the assignment in the second line will eliminate the NUL
in Str1.

In article <72992c9d-66e7-4639-81d3-b7820cd2b713@r15g2000prh.googlegroups.com>,
robertwessel2@yahoo.com <robertwessel2@yahoo.com> wrote:
>On Nov 2, 1:17 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>> dj3va...@csclub.uwaterloo.ca.invalid wrote:
>> >>        strcpy(Str1, Str2);
>> >>        Str1[ strlen(Str2) ] = Str3[5];
>> >>        Str1[ strlen(Str2) ] = '\0';
>>
>> > That last line looks wrong to me; I think you want to add 1 to
>> > strlen(Str2) before you use it as an index into Str1.
>>
>>      Right you are.  Thanks.
>
>Actually you need to save the result of the strlen() in the second
>line, since the assignment in the second line will eliminate the NUL
>in Str1.

Look more closely.
He's giving strlen one string, and modifying a different one.


dave
(made the same mistake on the first reading)

-- 
Dave Vandervies                           dj3vande at eskimo dot com
You really don't want to see Dann in full flow (unless somebody else
is the victim, of course).
                                 --Richard Heathfield in comp.lang.c

robertwessel2@yahoo.com wrote:
> On Nov 2, 1:17 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>> dj3va...@csclub.uwaterloo.ca.invalid wrote:
>>>>        strcpy(Str1, Str2);
>>>>        Str1[ strlen(Str2) ] = Str3[5];
>>>>        Str1[ strlen(Str2) ] = '\0';
>>> That last line looks wrong to me; I think you want to add 1 to
>>> strlen(Str2) before you use it as an index into Str1.
>>      Right you are.  Thanks.
> 
> 
> Actually you need to save the result of the strlen() in the second
> line, since the assignment in the second line will eliminate the NUL
> in Str1.

     Having made two mistakes already in this thread, it is with
some trepidation that I maintain you're wrong here.  Look again
at the function argument ...

-- 
Eric.Sosman@sun.com

On Nov 3, 4:44=A0pm, Eric Sosman <Eric.Sos...@sun.com> wrote:
> robertwess...@yahoo.com wrote:
> > On Nov 2, 1:17 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> >> dj3va...@csclub.uwaterloo.ca.invalid wrote:
> >>>> =A0 =A0 =A0 =A0strcpy(Str1, Str2);
> >>>> =A0 =A0 =A0 =A0Str1[ strlen(Str2) ] =3D Str3[5];
> >>>> =A0 =A0 =A0 =A0Str1[ strlen(Str2) ] =3D '\0';
> >>> That last line looks wrong to me; I think you want to add 1 to
> >>> strlen(Str2) before you use it as an index into Str1.
> >> =A0 =A0 =A0Right you are. =A0Thanks.
>
> > Actually you need to save the result of the strlen() in the second
> > line, since the assignment in the second line will eliminate the NUL
> > in Str1.
>
> =A0 =A0 =A0Having made two mistakes already in this thread, it is with
> some trepidation that I maintain you're wrong here. =A0Look again
> at the function argument ...


Ugh.  My mistake.  Too much string copying going on in this thread!

On Nov 1, 1:43=A0pm, Ruud <Ruud.Baltis...@apg.nl> wrote:
> Hallo allemaal,
>
> During the conversion of my program from Pascal to C, I was more
> or less able to find the C equivalent of most Pascal functions so
> far. Only four gave me some real trouble. I solved them but it
> could be I overlooked something.
>
> 1) In Pascal you can declare functions inside a function. AFAIK
> this is not possible with C. Or am I wrong?

Correct.  C does not support the concept of locally scoped or
anonymous functions.  That said, locally scoped functions are rarely a
serious issue.

> 2) In Pascal there exists the "in" function. Example:
>
> =A0 =A0if (c in ['A'..'F', '0'..'9']) then { c is hexadecimal }
>
> This can be translated like:
>
> =A0 =A0if ( =A0 ((c >=3D 'A') && (c <=3D 'Z'))
> =A0 =A0 =A0 =A0|| ((c >=3D '0') && (c <=3D '9'))) .... // c is hexadecima=
l
>
> I just wonder if there is a more simpler solution.

The above C translates to:

    if (isalnum (c)) { ... }

The Pascal is doing something different, more like:

    if (isdigit (c) || (isalpha(c) && c =3D=3D toupper(c))) { ... }

Except of course none of this is strictly true since in C your program
may launch nuclear missiles towards Russia if the variable c is non-
ASCII.

> 3) In Pascal I can "add" lines:
>
> =A0 Line1 =3D 'File size:' + sSize + ' bytes.';
>
> My solution:
>
> =A0 strcpy(Line1, "File size:");
> =A0 strcat(Line1, sSize);
> =A0 strcat(Line1, " bytes.);
>
> Again, I just wonder if there is a more simpler solution.

C sucks for strings.  You can try something like sprintf (Line1, "File
size:" "%s" " bytes", sSize); and hope you don't buffer overflow, but
you really don't have Pascal's self managed string semantics in the
core language.

Have no fear, though.  You can use string libraries such as mine
http://bstring.sf.net/ to make life a whole lot better:

    bformata (Line1 =3D bfromcstr ("File size:"), "%s bytes", sSize);

This has almost exactly the same semantic behavior as Pascal.

> 4) In Pascal I can "add" just one character of another string:
>
> =A0 Str1 =3D Str2 + Str3[5];
>
> Unfortunately =A0strcat(Str1, Str3[5]); =A0doesn't work, I get an
> error message. My solution:
>
> =A0 Str4[0] =3D Str3[5];
> =A0 Str4[1] =3D 0;
> =A0 strcpy(Str1, Str2};
> =A0 strcat(Str1, Str4};
>
> It works but in this case I'm certainly not happy with the
> solution. Is there a better way?

Well using the Better String library its just:

    bconchar (Str1 =3D bfromcstr (bdata (Str2)), bchare (Str3, 5));

But your questions are well motivated.  Bare C is just really weak for
really simple fundamental things which is trivial in most programming
languages.  To learn how do this right in straight C correctly you
just have to learn all of C's weaknesses.  Libraries such as mine help
tremendously just for strings, but you still kind of have to learn the
C way of doing things.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

In article <3563a280-117b-4768-8d65-7947705ac57d@a3g2000prm.googlegroups.com>,
Nick Keighley  <nick_keighley_nospam@hotmail.com> wrote:

>I have a reflex, as soon as I see a string of the form strn* in a post
>I start to post my standard "strncpy() may not do what you expect"
>reply.

strncpy does exactly what I expect; it's just not usually what I want,
so I either use something else instead or use strncpy followed by some
fixup code.

>     I had it all composed and ready to send when I noticed he
>was using strncat(). So I pressed Discard instead of Send.
>But it was close  :-)

Yep.  strncat is the one I always have to look up; the way it
interprets its count argument is about as unlikely as it could possibly
be without looking like it was deliberately designed to be confusing.
(But writing that post did shed some light on what it might've been
designed for.)


dave

-- 
Dave Vandervies                             dj3vande at eskimo dot com
You might have the same problem that I do, though...  I've got a whole
bunch of square tuits but I can't find a file to take the corners off.
                           --Matt Roberds in the scary devil monastery

On Sun, 02 Nov 2008 14:07:04 -0800, Keith Thompson <kst-u@mib.org>
wrote:

> Lew Pitcher <lpitcher@teksavvy.com> writes:
> > On November 1, 2008 17:43, in comp.lang.c, Ruud (Ruud.Baltissen@apg.nl)
> > wrote:
> [...]
> >> 2) In Pascal there exists the "in" function. Example:
> >> 
> >>    if (c in ['A'..'F', '0'..'9']) then          { c is hexadecimal }
> >> 
> >> This can be translated like:
> >> 
> >>    if (   ((c >= 'A') && (c <= 'Z'))
> >>        || ((c >= '0') && (c <= '9'))) ....      // c is hexadecimal
> >
Corrected elsethread to 'F'.

> > Actually, no it can't.
> >
> [...]
> > 
> > *But*, your C "translation" of the Pascal code is incorrect. In C, the
> > only "target characterset" characters required to be in ascending,
> > sequential order are the values from '0' to '9'. The target characterset
> > is /not/ obliged to support ascending sequential 'A' to 'Z', <snip>
> 
> You're assuming that Pascal does require the letters 'A'-'Z' to have
> sequential codes.  I don't know whether it does or not, but my guess
> is that it doesn't, any more than C does.  I'm sure there have been
> Pascal implementations for EBCDIC-based systems.

<Spock> Indeed. </> ISO 7185-1990 6.4.2.2 d:
1) The subset of character values representing the digits 0 to 9 shall
be numerically ordered
and contiguous.
2) The subset of character values representing the upper case letters
A to Z, if available,
shall be alphabetically ordered but not necessarily contiguous.
3) The subset of character values representing the lower case letters
a to z, if available, shall
be alphabetically ordered but not necessarily contiguous.

For EBCDIC, A-F are contiguous, though A-Z aren't.
So the particular case wanted here would in fact work;
but other cases wouldn't, making it a poor habit.

- formerly david.thompson1 || achar(64) || worldnet.att.net