HDTenEightyP/NetNews huggingface dataset:
From: ditolla@itnsg1.cineca.it (Francesco Di Tolla)
Subject: Re: Most difficult part of learning C?
Organization: Laboratorio di Fisica Computazionale, INFM. Trento Italia
Date: Wed, 26 Aug 1992 10:32:56 GMT

goldstei@cgi.com ("Morris Goldstein") writes:

>I am conducting research for a little project concerning difficulties in
>learning C and how to improve the teaching of C so as to circumvent these
>problems.

>When learning C, what things did you find the most confussing/difficult to
>understand?

>        -Morris

>(goldstein@cgi.com)

- the difference between statically defined multiple dimension
  arrays and dinamycally allocated, 
- the use of multiple array's pointers in function calls
- to program in a readeble way, the only way to get it is to
  read programs from expert programmers, no book is good
  enough!

Bye
Franz


-- 
 --------------------------------------------------------------------------
|  Francesco  D. Di Tolla            | Bitnet:    ditolla@itncisca.bitnet  |
|  Dip. di Fisica Univ. di Trento    | Internet:  ditolla@itnsg1.cineca.it |
|  I-38050 Povo (TN) - Italy         | Decnet:    itnvax::ditolla (37.65)  |
Date: Sat, 29 Aug 92 08:16:00 +0200
From: Gilles_Kohl@spam.fido.de (Gilles Kohl)
Subject: Most difficult part of learning C?
Newsgroups: comp.lang.c
X-Comment-To: (Tom Truscott)
Organization: To take arms against a C of troubles ... 

 > Some difficulties can be circumvented by avoiding them entirely.
 > In my opinion the following can be omitted:
 >     boolean operators
 >     goto
 >     enumerated types
 >     bit fields
 >     typedefs
 >     unions
 >     pointer arithmetic
 > Is the purpose of the course to explore every last corner of the C
 > language, or is it to teach some topic for which C happens to be
 > appropriate?
Tom,

The beauty of C consists in its smallness, IMHO. You can't leave much out 
without serious limitations. The topic of the course should be plain C, not one 
subset or the other. Teach them all, _and_ tell them about the potential 
problems. In real life, they will have to maintain programs containing elements 
that you consider superfluous, they should at least be able to identify and 
understand them.

Regards,
Gilles.

---
From: noesis@ucscb.UCSC.EDU (95016000)
Newsgroups: comp.lang.c
Subject: Re: Password encryption?
Keywords: password, encryption
Date: 3 Sep 92 14:23:25 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: ucscb.ucsc.edu


In article <julian.715516516@sun-1> julian@sun-1.cs.uct.ac.za (Julian Hansen) writes:
>Hi world,
>
>I need to do some password encryption and maybe data encryption to. Anyone
>out there like to help me. Some code would be nice and maybe a few pointers
>on what not to do (and what to do). Any help would be most appreciated.
>
here's what i use with some success:

long encrypt(char *s)
{
  long result=1;
  char *ptr;

  srand(0x1234);
  for (ptr=s; *ptr; ptr++)
    result+=(*ptr)*rand();
  return result;
}

the only change i've made to this is to use my own rand() algorhithm to
allow compilation on different machines which all return the same result
---kyle
Newsgroups: comp.lang.c
From: kendall@centerline.com (Sam Kendall)
Subject: Re: Why should POINTERS be so damn hard to understand ?
Organization: CenterLine Software, Inc.
	<1992Aug26.183054.14146@newshub.ccs.yorku.ca>
Date: Fri, 28 Aug 1992 20:28:48 GMT

tony@nexus.yorku.ca (Anthony Wallis) writes:

> Understand the MACHINE MODEL and you will understand POINTERS.

Au contraire.  Machine addresses point to bytes or words.  C pointers
point to objects.  There are countless books that introduce C pointers
by saying, more or less,

	Here is an array a of 10 ints.  Its address is 0x5000.  We
	assign a pointer to the array by executing `p = a;' and now p
	has the value 0x5000.  Execute `++p;'.  Now p has the value
	0x5004.  Why?  Because pointers step by the size of the thing
	they point to, and ints have size 4.

It is much simpler to explain that p points to an object of type int, so
that when you increment it, it points to the next object.  You show a
diagram that contains no hex numbers.

People educated in this way have no trouble understanding, say, pointers
to arrays.  (Increment the pointer, and it points to the next array!)
On the other hand, people educated to think of pointers as hex addresses
-- even senior programmers -- often can't figure out the difference
between a pointer to an array and a pointer to the first element of that
array.

More significantly, people taught a machine model first have trouble
generalizing so that they can write portable code.  C implies a model
which is portable; that's the model to teach.

Check out Rabinowitz and Schaap, "Portable C", Prentice Hall, 1990.  It
presents pointers in a simple, abstract way.  Disclaimer: I am a friend
of the authors.

I do agree with you that a good programmer must understand the machine
model.  But not as a way of learning the language.

----
Sam Kendall
CenterLine Software, Inc. (formerly Saber Software)
Newsgroups: comp.lang.c
From: igrdb@informatik.tu-chemnitz.de (Ingo Gringer)
Subject: Combine c and c++?
Organization: tu-chemnitz
Date: Wed, 26 Aug 1992 13:58:57 GMT

Hi everywhere, 

Please be indulgent if that's just another nonsense question!
 
 I try to connect two applications which are programmed in c++
 and otherwise in c. Now I want to combine these programs, but
 there is an hump: they need their own libraries and the c-
 application is not compiled through the c++. It fails with the 
 error, that a function used in the special c-library is not
 declared. Thats correct but doesn't irritate the c-compiler.
 I dont know where he obtains his informations. One lib contains 
 finally the needed function. 

 Is it possible to link the object files produced by c++ or c 
 together? Trying this generates permamently an error that my
 function I wrote in the c-programm are not defined. But 
 I told the c++ - part everything with my headerfiles. 

What is wrong? Why doesn't it works?

Any hints would be very much appreciated.
  
Please responds by email. 
Ingo

Newsgroups: comp.lang.c
From: pinkas@caraway.intel.com (Israel Pinkas)
Subject: Re: strcpy implementation question
Followup-To: comp.lang.c
Organization: Software Technologies, INTeL Corporation, Santa Clara, CA
	<PINKAS.92Aug24183511@caraway.intel.com> <14173@goanna.cs.rmit.oz.au>
Date: Wed, 26 Aug 1992 00:30:06 GMT

In article <14173@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:

> There is a very basic problem which explains why strcpy() should touch
> only strlen(source)+1 chars:
>	 characters following the intended end of the source MAY NOT EXIST
>	 characters following the intended end of the destination MAY NOT EXIST
>	 characters following the intended end of the source may exist
>	 AND YET NOT BE INITIALISED.

I wish people would read my posting.  I specifically detailed the fact that
the strcpy routine in question only was used when the source AND
destination had been allocated by the compiler and were of a known size AT
COMPILE TIME.

The fact that the memory has not been initialized is irrelevant.  If the
source didn't care about it, neither will the destination..

> The traditional documentation for strcpy() said:
>	 strcpy copies string s2 to s1,
>     -->	stopping after the null character has been moved
> X3J11 weren't in the business of breaking anything they didn't _have_ to
> break, not if they could help it.

Man pages do not a spec make.

I specifically asked people for a spec that states that the optimization is
illegal or for pointers to code that is widely used that will be broken by
this code.

-Israel Pinkas
 pinkas@stps18.intel.com
--
Disclaimer: The above are my personal opinions, and in no way represent
the opinions of Intel Corporation.  In no way should the above be taken
to be a statement of Intel.
From: dave@cs.arizona.edu (Dave Schaumann)
Newsgroups: comp.lang.c
Subject: Re: How to handle __STDC__
Keywords: ANSI C, prototypes
Date: 30 Aug 92 16:37:57 GMT
Reply-To: dave@cs.arizona.edu (Dave Schaumann)
Organization: University of Arizona

In article <hawkeye.715165677@glia>, hawkeye@glia (Ken Keys - TF Dude) writes:
[question deleted]
>The ANSI/ISO standard does say that __STDC__ must be defined as 1 in
>any standard-conforming compiler.

The obvious conclusion is that the right way to check if you are compiling
under a standard-conforming compiler is to use "#if __STDC__".

>However, since a non-standard
>compiler is, by definition, not bound by the standard, it can do
>whatever it wants, including defining __STDC__ as 1.

Well, if you want to worry about this, you could do this:

	/* If this breaks because your non-standard compiler */
	/* #define's __STDC__ to 1, complain to you vendor,  */
	/* and not to the author of the code.		     */
	#if __STDC__

	. . .

>I agree, however,
>defining __STDC__ as 0 was a bad choice on the part of Mark Willams,

Agreed (assuming ANSI gave no meaning to "#define __STDC__ 0").

>a lot of existing code does use the "#ifdef __STDC__" check.

Well, as I indicated above, my reading of the quote you gave is that
"#if __STDC__" is clearly the right choice for checking for a compliant
compiler.  Using "#ifdef __STDC__" is IMHO sloppy work.

-- 
Dave Schaumann			dave@cs.arizona.edu
From: throop@aurs01.UUCP (Wayne Throop)
Newsgroups: comp.lang.c
Subject: Re: Most difficult part of learning C?
Date: 27 Aug 92 15:17:49 GMT

> From: ark@alice.att.com (Andrew Koenig)
> The most difficult part of learning C is getting the mechanical
> skills to be such a matter of routine that you don't have to think
> about them any more.

"When I first encountered C, things were simple.  A number was
 a number, and a pointer was a pointer.  When I had studied it a
 while, it became much more complex, with many rules to memorize.  A
 number was no longer just a number, a pointer was no longer just a
 pointer.  Now that I understand C, it is simple again.  A number is a
 number.  A pointer is a pointer."
                                    --- paraphrased Zen aphorism

Wayne Throop       ...!mcnc!aurgate!throop
Newsgroups: comp.lang.c
From: msb@sq.sq.com (Mark Brader)
Subject: Re: Order of execution...
Organization: SoftQuad Inc., Toronto, Canada
Distribution: usa
Date: Sun, 30 Aug 92 20:40:56 GMT

>   while ((textline[index++] = tolower(textLine[index])) != '\0');
> 
> The question is will it always work? Or will sometimes work depending
> on which side of the assignment gets evaluated first...?

It will never work until you spell your variables consistently, or use
a macro to alias the two spellings!

Ignoring that... the code will indeed only "sometimes work", but not
because the compiler may evaluate one or the other side of the assignment
first.  It can actually interlace the evaluation of the two parts!
Thus it can choose to begin by evaluating the index++ on the left and
by storing the incremented result in the variable, and then continue
by evaluating the right side, and then finish off the left side.

> Is there a better way to do this (and still keep it a one liner).

Actually, most people feel that writing it on one line as it is is a
bad idea; the single semicolon that is the loop body is hard to see.
There are various other styles; I like the next tersest, which is to put
the semicolon alone on the next line.

You want to get the increment out of the assignment, and the neatest
way to do this is to use a for loop.  I have also separated the test
from the assignment, which in this case seems clearer to me and also
avoids calling tolower() on the final null.

	for ( ; textLine[index] != '\0'; ++index)
		textLine[index] = tolower (textLine[index]);

You may of course write this on one line if you wish.  I'd probably
eliminate the needless variable "index" and write it like this:

	for ( ; *s; ++s) *s = tolower (*s);

or, some days, slightly more verbosely:

	for ( ; *s != '\0'; ++s)
		*s = tolower (*s);

where "char *s;" replaces your "char textLine[];", on the grounds that
(opinions follow) stereotypical uses of variables do not need long names,
and that formal parameters should be declared with their true types.

Incidentally, note that applying tolower() to characters which may not
be upper case letters is NOT portable to pre-ANSI C implementations.
For this article I am assuming that either the implementation is ANSI C
or that the string has been verified to contain only upper case letters.
-- 
Mark Brader		    At any rate, C++ != C.  Actually, the value of the
SoftQuad Inc., Toronto	    expression "C++ != C" is implementation-defined.
utzoo!sq!msb, msb@sq.com				-- Peter da Silva

Actually that value is undefined.  This article is in the public domain.
From: dave@cs.arizona.edu (Dave Schaumann)
Newsgroups: comp.lang.c
Subject: Re: HELP !! Converting non printable characters to HEX
Date: 2 Sep 92 00:02:27 GMT
Reply-To: dave@cs.arizona.edu (Dave Schaumann)
Organization: University of Arizona

In article <1992Sep1.152149.1905@cs.uow.edu.au>, u8705957@cs (Hitesh Sanghvi) writes:
>Hi there;
>	Any suggestion or 'c' code on how to convert non printable 
>characters to hex.
>My function works for printable ascii characters but does not work
>on non printable characters.
>
>My code is as follows:
>
>void
>dec_to_hex(sin,sout)
>unsigned char sin[],sout[];
>{
>	int loop,i;
>
>	for (loop = 0;loop<4;loop++)
>	{
>		i = (int)sin[loop];
>		sprintf(&(sout[2*loop]),"%02x",i);
>	}
>}
>so it takes 4 ch and gives me 8 hex ch onlly when ascii ch is entered.

Well, I don't know why your code doesn't work for you.  I tried it out,
and it seems to work fine for me.  However, there are a several things
I would change about your code:

>dec_to_hex(sin,sout)
            ^^^
sin is the name of a function defined by the math library.  Although you can
do it, it's poor form to have variables (or functions) with the same name as
library functions.

>unsigned char sin[],sout[];
                  ^^     ^^
>	for (loop = 0;loop<4;loop++)
                           ^
Hard coding magic numbers is a big mistake.  Get in the habit of using #define.

Also, IMHO, this function would be much simpler and ultimately more practical
if it only worked on one character at a time, and if it returned its value.
you can pass an array for the result if you want, but I find it tends to be
useful to return values as well (it also costs very little to do so).

With these comments in mind, I would write this code thusly:

unsigned char *char2hex( unsigned char c, unsigned char *buff ) {

  sprintf( buf, "%02x", (int)c ) ;
  return buf ;
  }

Really, this is so simple, you might as well make it a macro:

/* note the use of the comma operator so that buf is still "returned" */
#define CHAR2HEX( c, buf )  ((buf), sprintf( (buf), "%02x", (int)(c) ))

Now, your original loop could be written as

  #define N 4

  int i ;
  
  for( i = 0 ; i < N ; i++ )
    CHAR2HEX( s_in[i], s_out[i*2] ) ;

-- 
Caught an internal error--.brainrc restored
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.lang.c
Subject: Re: Novice Questions
Date: 30 Aug 92 10:11:21 GMT
Organization: University of Helsinki

maven@eskimo.celestial.com (Norman Hamer) writes:
> 1. Given a char array, say char foo[256];, is *foo the same as foo[0]
>and is foo+x the same as foo[x] in all implementations?

*foo and foo[0] are identical, and *(foo+x) and foo[x] are identical. 
The latter is by definition: the language is defined that way.  The
former follows directly from the latter: foo[0] <=> *(foo+0) <=> *(foo)
<=> *foo.

> 2. What's the best way to read in a text configuration file? I've seen
>code like this:

> fgets(line, 80, fd);
> while(!feof(fd))
> {
>   /* Muck with the data */
>   fgets(line, 80, fd);
> }

Works, but is ugly, since it duplicates the read statement, and makes it
easy to miss one of them when changing the other one.  Doesn't check for
ferror.

> while(fgets(line, 80, fd) != NULL)
> {
>   /*Muck with the data */
> }

Preferred, and the way that practically everybody does it.  An idiom in
C.  Concentrates all the line reading logic into one place and has only
the data mucking inside the loop, and nothing else there, so the data
mucking is nicely isolated.

> while(!feof(fd))
> {
>    fgets(line, 80, fd);
>    if(feof(fd))
>        break;
>    /* Muck with the data */
> }

Even uglier than the first one, although more similar to Pascal (that is
not a virtue, although not necessarily a bad thing either).  Includes an
unnecessary goto (spelled break here), which confuses the logic of the
loop.  Also, this doesn't check for errors, you'd need to check for
ferror as well, but then it gets uglier and uglier.

> Which one is best and why?  Which is the least likely to provide
>erroneous results (the last one if you forget the second feof() will
>sometimes leave you with a portion of the last line... not all of it and
>not a null string)

The second one is best, 'cause it's the simplest and most common way of
doing it, and the most difficult to get wrong.

--
Lars.Wirzenius@helsinki.fi
Newsgroups: comp.lang.c
From: bo@bluemoon.rn.com (Tim dunfee)
Subject: Re: Most difficult part of learning C?
Organization: Blue Moon BBS ((614) 868-998[024])
Distribution: usa
Date: Sun, 30 Aug 92 23:33:24 EDT

sullivan@alw.nih.gov (Jim Sullivan) writes:

> In article <9208251159.AA04122@ult4>, goldstei@cgi.com ("Morris Goldstein") w
> |> I am conducting research for a little project concerning difficulties in
> |> learning C and how to improve the teaching of C so as to circumvent these
> |> problems.
> |> 
> |> When learning C, what things did you find the most confussing/difficult to
> |> understand?
> 
> What else?... POINTERS!
> -- 
> Jim Sullivan 		[ The future ain't what it used to be ]
> National Institutes of Health
> Bethesda, MD 20892
> Phone: (301) 496-5362
> FAX: (301) 402-2867
> Internet: sullivan@alw.nih.gov

I'm working on learning C _right now_ and I must agree that those pointer  
_thingies_ are the biggies.  Oh, I get the concept alright, but at compile 
time the darn thing tells me that I don't know what I'm doing! 8-)
Trial and error with massive references is the best solution I've found.
(Of course we haven't officially started working with structures and I'm 
just trying to forget about type-casting for a while.)
- Tim.

 ____________________________________________________________________
| ____    o          | e-mail:  bo@bluemoon.rn.com                   |
| ___/   /   /~~/~~/ |                                               |
|____________________|_______________________________________________|
|               Cheer me, Jeer me, or Beg for More!                  |
|A government is only so great as its officers...                    |
|                           ...a society only so great as its people.|
|____________________________________________________________________|
From: jerry@synopsys.com (Jerry Huth)
Newsgroups: comp.lang.c
Subject: Re: pointer to araay of structs
Keywords: pointers
Date: 2 Sep 92 00:33:55 GMT
Organization: Synopsys Inc.

eric@orfeo.radig.de (Eric Tuerlings) writes:

>> struct aaa {
>>     char y;
>>     char z;
>> } ;
>> 
>> void func (struct aaa (*bbb)[])
>> {
>>     char z;
>> 
>>     z = bbb[3]->z;
>> }
>> 
>> in which bbb is a pointer to an array of aaa structures. The compiler
>> complains about an unknown size.

Your parameter declaration "struct aaa (*bbb)[]" is indeed a pointer
to an array of aaa structures, but your use of it "z = bbb[3]->z;"
tries to access it as if bbb is an array of pointers to aaa
structures.  So, the compiler is correct in complaining.

You can do any of the following:

  1) bbb is a pointer to an array of aaa structures

     decl:  struct aaa (*bbb)[]
     use:   z = (*bbb)[3].z ;        <- new use

  2) bbb is an array of pointers to aaa structures

     decl:  struct aaa *(bbb[])      <- new decl
     use:   z = bbb[3]->z ;

But, it may be that BOTH your use and your decl are wrong, and
what you really want is:

  3) bbb is an array of aaa structures

     decl:  struct aaa bbb[]	     <- new decl
     use:   z = bbb[3].z             <- new use

(Note to goldstei@cgi.com ("Morris Goldstein"): This is definitely
an example of one of the most confusing things about C!)
Xref: sparky comp.lang.c:12810 comp.unix.questions:10405
From: tim@shovel.Prime.COM (Tim Cantin)
Newsgroups: comp.lang.c,comp.unix.questions
Subject: Re: cursor input on curses (new prob.)
Date: 26 Aug 92 18:43:52 GMT
Organization: Prime Computer R&D

Try typing 'man keypad'... should show you the man page for curses. I did this 
on a Sun system and it is there...

#include <curses.h>
keypad (win, bf)
WINDOW *win; /* window pointer or stdwin */
int bf; /* TRUE or FALSE */

-- 
#include "stddisclaimer.h"
/* Tim Cantin          {uunet, csnet-relay}!primerd!tim || tim@s35.prime.com
   Prime Computer Inc. 10-21, 500 Old Conn. Path, Framingham, MA 01701 (USA) */
flames > /dev/null 2>&1
From: jos@and.nl (Jos Horsmeier)
Newsgroups: comp.lang.c
Subject: Re: strstr and ANSI-c
Keywords: strstr ANSI
Date: 30 Aug 92 13:19:45 GMT
Organization: AND Software BV Rotterdam

In article <1992Aug29.215550.11490@daimi.aau.dk> pjunold@daimi.aau.dk (Peter Joachim Unold) writes:
|Hello
|
|I've for some time been coding on a program, that must be compiled and run
|on many diff. unix platforms. Apart from the usual portability problems one 
|encounter in unix-programming, I have had problems with users reporting, that
|their ANSI-c compiler reports the 'strstr' string-function unknown. How is 
|that? strstr IS according to my K&C 2. edition part of the standard-library.
|I could ofcause just code my own strstr function, but if one can't expect the
|ANSI-c-compilers to fullfill the ANSI-standard, what can one expect?

I assume you're distributing the _source code_ of your program to your
users. Are you sure they're using an ANSI-C conformant compiler? The
strstr() function is definitely part of the standard (paragraph 4.11.5.7)
so ask your users to complain about it to their vendors. 

Did you check the `#include <string.h>' line in your source files?
I think you probably did ...

Maybe you could include some additional checkpoint sin your code. I've
read about _non_ fonformant compilers that _do_ define __STDC__, but
they define it as a non 1 value. Maybe some paranoic checks like

#ifdef __STDC__
#if __STDC__ != 1
/* Include the same file here, just to cause the pre-processor
 * to start complaining, so you'll know something is wrong.
 * You can't use the #error statement here, 'cause the compiler
 * is cheating you ...
 */
#endif
#endif

could help you out here ...

kind regards,

Jos aka jos@and.nl
From: Monroe.Thomas@ttlg.UUCP (Monroe Thomas)
Sender: postmaster@ttlg.UUCP
Newsgroups: comp.lang.c
Subject: Strange error in C compi
Date: 28 Aug 92  02:12:00 mst

> Hello all!

>Consider the following code:

>/*
> _DYNAMIC is linker-defined and may be either 0 or non-zero,
> depending on link mode.
>*/

>extern _DYNAMIC[];

>main() {
> if (_DYNAMIC)
>  puts("Dynamic");
> else
>  puts("Static");
>}

> The above code doesn't work, but with if-statement rewritten
> as follows does:

> if (_DYNAMIC != (int*) 0)

> Could anyone explain why?

> Note: in the first case compiler treats else-clause as dead
> code, but in the second one everything is compiled as
> expected.

Obviously your compiler as treating _DYNAMIC as never being a null
pointer.  Your first construct is testing the address of the variable,
your second example is testing the value at that address.

Try dereferencing _DYNAMIC to get a construct similar to your first:

main() {
 if (*_DYNAMIC)
   // note use of *
   puts("Dynamic");
 else
   puts("Static");
}

 * OLX 2.2 * "The little demon was deceitful," Tom implied.

 * Origin: Through the Looking Glass (42:100/14)