HDTenEightyP/NetNews huggingface dataset:
From: spacefox@acs.bu.edu (Godfrey Degamo)
Newsgroups: comp.lang.c
Subject: Re: Most difficult part of learning C?
Date: 28 Aug 92 01:50:17 GMT
Organization: Boston University, Boston, MA, USA
Originator: spacefox@acs.bu.edu



I agree totally with John F. Woods.  Learning C was easy.  Mastering C,
just like mastering any computer language, will take a lifetime pursuit.
This reminds me of a funny, but full of wisdom quote from my C bible :)  :


     A substantial part of designing good modules and good functions is
perhaps best described as "common sense."  This includes a healthy respect
for human frailty and a willingness to leave well enough alone.  For example,
C is designed to implement the int data type efficiently.  If you don't
have a particular need for a long int or unsigned int, don't use them.  Don't
use an isolated char simply to save an atom of space.  Avoid fiddling with
data types just for some aesthetic pleasure or sense of orderliness.  Don't
use typedef symbols when keywords will do.  Don't #define constants when
what you mean is zero or nonzero; just use zero and one.  Resists casts;
they're for broken bones.  Don't create data structures if there's nothing
inherently structured about your data.  Use short names when they say what
you mean.

[But, heres where it gets pretty funny....]

     Eliminate the ornaments of programs and instead focus on the clarity
of your code and the ingenuity of your methods.  You will program rings around
Fancy Dan, who never learned to leave well enough alone.  While Fancy Dan
is becoming an expert on the faults of compilers, because his program stress
their limitations, you are getting your work done.

                                                -Craig Bolan,
                                                 Mastering C
                                                 III:12:221

:)


Well, I'll admit this is just a waste of newsgroup space!  I suggest that
you introduce the concepts of software engineering early.  but, then
software engineering is not specific to the C language!  Ah well...
I find that with me, most of the things people have listed as the hardest
part of learning C, is really just a lack of discipline.  No insult intended!
If you're having problems with pointers, draw a diagram; if you're having,
problems with operator precedence memorize them or use alot of '()'

Well, to stop making you think that I'm an arrogant C programmer, I don't know
the correct syntax to the switch statement, in fact, I don't know more than 60%
of the specifics to any of the stdio.h or stdlib.h modules!  But, that's why
I have a trusty C manual!  (maybe that's why Microsoft turned me down?  hmmm...)

                                       -scherzo,
                                        G. Degamo,
                                         spacefox@acs.bu.edu
Xref: sparky comp.lang.c:13040 comp.lang.pascal:5132
From: tsv@dbrus.Unify.Com (Tim Vannaman)
Newsgroups: comp.lang.c,comp.lang.pascal
Subject: Pascall Typed Files
Date: 31 Aug 92 20:16:24 GMT
Organization: unify

OK, since I can't put pascal obj's into my c code, how can I read a typed file
created by pascal into my C program?  (Turbo C & Pascal)

ex.
  In pascal :

  Type
     scuz = record
	      Player string[25];
	      Age    integer;
	      Money   float;
	    end;
     
  Var 
    fil : File of Scuz;


If I load the file full of data, how would I go about reading and re-writing it
in C?  I tried getting a hex dump of the file, but it didn't make any sense.

Tim.


--
Tim Vannaman, Premium Technical Support Engineer   Phone: (916) 928-6433
Unify Corporation, Sacramento, California    Fax: (916) 928-6403
tsv@unify.Com  or  {{ucdavis,csun,lll-crg}!csusac,pyramid,sequent}!unify!tsv
Newsgroups: comp.lang.c
From: tching@target.water.ca.gov (Tracy Ching <SysAdmin>)
Subject: Need help with serial routine - how to get a byte from COM1
Organization: California State University, Sacramento
Distribution: usa
Date: Thu, 27 Aug 1992 22:27:55 GMT

	I'm using Quick C to write a very simple program to read and
write to the serial port.  My program is shown below.  What do I
need to be able to read from the port without getting nasty DOS error
messages like "COM1 not ready ... Abort Retry Ignore Fail..." or
something like that every time I try to read a byte from the port?
I can write to it fine and the data comes out.  (I see it on my dumb
term connected to COM1).  Please e-mail to
tching@water.ca.gov

#include <stdio.h>
FILE *fp_ser;	/* serial port */
int ch;

main()
{
int result;

fp_ser = fopen("com1", "w+b");  /* opens com1 for read write binary */
result = fputs ("Hello world \n", fp_ser);  /* print it to serial port */

/* How do I get a serial char back from the com1 and echo it
   onto my screen????
   I used fgetc() with disasterous results			*/

fclose (fp_ser);
}

Newsgroups: comp.lang.c
From: pinkas@skywalker.intel.com (Israel Pinkas)
Subject: Re: strcpy implementation question
Organization: Software Technologies, INTeL Corporation, Santa Clara, CA
	<PINKAS.92Aug25163006@caraway.intel.com> <14213@goanna.cs.rmit.oz.au>
Date: Fri, 4 Sep 1992 01:36:43 GMT

I wrote:

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

ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:

RK> I wish people would read charitably and not assume that the answer is
RK> irrelevant to their question without thinking.

The post I was referencing was irrelevant to my question.  I speficifally
stated that the size of boththe source and the destination were known by
the compiler at compile time, and that the compiler would never access
memory byond the end of either.  The post I was refering to talked about
malloc'ed memory and accessing uninitialized memory and going into areas
that were not mapped in to my process.

RK> The point is _uniformity_.  Since strcpy() *can't* go too far in the
RK> great majority of cases, it will only be confusing if it does something
RK> different in this case.

So what?  My question was whether the compiler was allowed to modify past
the end of the destination string, not on whether it is confusing.

RK> When is the size of the source known at compile time?  Two cases:
RK> (a) the source is a string literal (or is a pointer whose value is known
RK>     by constant propagation to be a specific string literal)
RK> (b) the code looks something like
RK>  if (strlen(x) == 27) { /* don't change x */; strcpy(d, x); ...}

Not quite.  I said that the size of the source and destination are known,
not the length of the string.  If the length of the string is known, and it
can be guaranteed to be inviolate, we only have to copy enough bytes to
move the string.  However, strings are not inviolate, as the middle of the
string can be modified in ways that the compiler cannot control, such as
signal handlers.

The only way a compiler can know the size of a char array is:
    (a) It is a string literal.
    (b) It is an array declared at compile time, with dimension(s).

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

RK> This is wrong.  It isn' the source or the destination that cares, it is
RK> strcpy() that cares.  strcpy() MUST NOT READ any uninitialised memory
RK> locations.

Why not.  There is a difference betwenn uninitialized and unallocated.  For
example, with the declaration:

	int a[5];

inside a block.  a[0] is uninitialized, but a[5] may be unallocated.
Uninitialized memory belongs to the process, it just doesn't have a known
or predictable value.  It is still legal to access it.  Unallocated memory
doesn't belong to the process, and will probably cause an execution error
if accessed.

-Israel
From: jaorans@pbhyg.PacBell.COM (Jeff Oransky)
Subject: Re: main()
Reply-To: jaorans@PacBell.COM (Jeff Oransky)
Organization: Pacific * Bell, San Ramon, CA
Date: Wed, 2 Sep 1992 19:08:09 GMT

In article <1992Sep2.162015.11561@lclark.edu> harrison@lclark.edu (Mark Harrison) writes:
>
>In my programs, I use 'void main()' and never had any problems doing so. 
>These are written with Turbo C/C++ 3.0, so I don't know about any others,
>but it sounds like you are using BC, so there shouldn't be any difference.
>If you just use 'main()' the compiler will assume that it is an int function.

I would have to guess that the custom of making the main function an int
type and returning 0 at the end is more of a necessity in UNIX C 
programming since a program return to the operating system of 0
indicates a successful execution or a non zero for an unsuccessful one.

------------------------------------------------------------------------------
! Jeff Oransky             !   "Hope is the thing with feathers ......"      !
! Pacific Bell             !         Woody Allen                             !
------------------------------------------------------------------------------
Newsgroups: comp.lang.c
From: drd@siia.mv.com (David Dick)
Subject: Re: True Portability?
Organization: Software Innovations, Inc., Nashua, NH
Date: Wed, 2 Sep 92 22:40:55 GMT

In article <Aug31.145702.60242@yuma.ACNS.ColoState.EDU> shafer@CS.ColoState.EDU (spencer shafer) writes:
>With 'C's touted portability, is it unreasonable for a user to expect
>a vendor to offer "source code compatibility" across multiple hardware
>platforms?  

In our business of migrating software to UNIX, we have sometimes
been contractually required to provide converted software that will
run identically on more than one machine.  I don't think it's 
unreasonable at all -- I thought support for portable software
was supposed to be one of the great advantages of UNIX.

Unfortunately, it has become harder, not easier, since we started
in this business (1981).

David Dick
Software Innovations, Inc. [the Software Moving Company]
Newsgroups: comp.lang.c
From: osymg@Ercvx1.erc.montana.edu (Marcus Giese)
Newsgroups: comp.lang.c
Subject: Re: vax floating point bit structure
Date: 30 Aug 92 03:02:07 GMT
Reply-To: osymg@Ercvx1.erc.montana.edu (Marcus Giese)
Organization: NEWSRDR-testing

In article <1992Aug28.121613.592@hou.amoco.com>, 
zrwb14@hou.amoco.com (Randy Byrne) writes:
>Since this is just about the largest "comp" user group I thought I'd try 
>posting this question here:  Does anyone know what the bit structure of a 
>VAX floating point number is?  The only information 
[...]
>
>Randy
>
I *think* the following is correct, but if I were you, I'd a get a VAX
architecture handbook...

h_floating:
        0 - 14    exponent
        15        sign
        16 - 127  fraction

        Sinificance increases from 112-127, 96-111, 80-95, etc., normalized
        all fractions are "broken up" into 16bit word sizes

g_floating:
        0 - 3     fraction
        4 - 14    exponent
        15        sign
        16 - 63   fraction

        Significance increases from 48-63, 32-47, 16-31, 0-3, normalized
        all fractions are "broken up" into 16bit word sizes

d_floating (don't quote me on this one):
        0 - 6     fraction
        7 - 14    exponent
        15        sign
        16 - 63   fraction

        Significance increases from 48-63, 32-47, 16-31, 0-6
        all fractions are "broken up" into 16bit word sizes

f_floating:
        0 - 6     fraction
        7 - 14    exponent
        15        sign
        16 - 31   fraction

        Significance increases from 16-31, 0-6, normalized


The f and g floating are also supported on the ALPHA, the other two are
not (I think).
                                Marcus

ps: I think values of 1-255 for the exponent are true binary -127->+127

|Marcus Giese|osymg@cs.montana.edu|osymg@terra.oscs.montana.edu|(406)994-3932|
------------------------------------------------------------------------------
"If they're selling elephants two for a quarter, that's a great bargain.
 But only if you have a quarter - and only if you need elephants." (D.Dinkins)
Xref: sparky comp.lang.c:12685 comp.sys.sun.misc:3859
From: Thomas.Tornblom@nexus.comm.se (Thomas Tornblom)
Newsgroups: comp.lang.c,comp.sys.sun.misc
Subject: Re: How to use the same file of structs on PC and Sun?
Date: 24 Aug 92 00:30:32 GMT
Organization: Communicator Nexus AB

In article <71527@apple.Apple.COM> may@Apple.COM (Patrick May) writes:

   Hi,

	I'm porting an application from an MS-DOS environment to the Sun
   (SunOS 4.1.1).  The app makes heavy use of files opened in binary mode
   to store various structs.  When I tried to use these same files on the
   Sun I found that the Sun compiler came up with a different size for
   these structs than did the MS-DOS compiler (uSoft).  I'd half expected
   something like this, and had intended to do a one-time conversion of
   the affected files.

	Unfortunately, these files may be accessed by the both the Sun
   and MS-DOS versions of the application over, for example, PC/NFS.
   Is there a way to tell the Sun compiler not to do any alignment (if
   in fact that's what's happening) or, alternatively, to tell the
   Microsoft compiler to act the same as the Sun compiler?

   Thanks,

   Patrick May
   may@apple.com     (posting from, but not working or speaking for, Apple)
   ------------------------------------------------------------------------
				 "A contract programmer is always intense."

You are facing more severe problems than you think. Not only is the
alignment different, the byte order is also different. The intel goo
is little endian which means that the least significant bytes of a
word are at lower addresses. All suns, except the sun386i, are big
endian where the most significant bytes of a word are stored at low
addresses.

Thomas
--
Real life:      Thomas Tornblom           Email:  Thomas.Tornblom@nexus.comm.se
Snail mail:     Communicator Nexus AB     Phone:  +46 18 171814
                Box 857                   Fax:    +46 18 696516
                S - 751 08 Uppsala, Sweden
From: jcoxhead@acorn.co.uk (Jonathan Coxhead)
Newsgroups: comp.lang.c
Subject: Re: printf question
Date: 2 Sep 92 11:07:05 GMT
Organization: Acorn Computers Ltd, Cambridge, England


   In article "Re: printf question" karl@ima.isc.com (Karl Heuer) writes
parenthetically

         The C preprocessor has no way to evaluate-and-stringise a constant
      expression.

but it does!

      #define STR_(s) #s
      #define STR(s)  STR_ (s)

      #define WIDTH 8

      printf ("%" STR (WIDTH) "x", n);

   Easy. I keep the first two lines in a central place for whenever I need
them, along with other useful stuff.

   /|
  (_|/
   /|
  (_/
Newsgroups: comp.lang.c
From: silvia@rcf.rsmas.miami.edu
Subject: avatar
Reply-To: silvia@rcf.rsmas.miami.edu
Organization: RSMAS
Date: Mon, 31 Aug 92 19:23:36 GMT

Does anyone know how one could make a BBS avatar compatable? I would liek to incorpoarte into my C program but can't seem to find anything on the subject. If you can please e-mail i have a hard time getting to the sub.
Newsgroups: comp.lang.c
From: jlnance@eos.ncsu.edu (JAMES LEWIS NANCE)
Subject: Re: True Portability?
Originator: jlnance@kelley.ece.ncsu.edu
Reply-To: jlnance@eos.ncsu.edu (JAMES LEWIS NANCE)
Organization: North Carolina State University, Project Eos
Date: Mon, 31 Aug 1992 17:36:24 GMT


In article <Aug31.145702.60242@yuma.ACNS.ColoState.EDU>, shafer@CS.ColoState.EDU (spencer shafer) writes:
|> 
|> With 'C's touted portability, is it unreasonable for a user to expect
|> a vendor to offer "source code compatibility" across multiple hardware
|> platforms?  In other words, I would like to take the same program and
|> compile it on different machines and obtain the EXACT same results.
|> Keep in mind this includes POSIX, any API's for communications stacks
|> and for process to process communications.  Is it too much to expect?
|> Could the API's be different - parameter order, encoding, etc.?  Could
|> the runtime libraries be different?
|> How can a user require a vondor to provide this? (and then verify it?)
|> 
|> I'm interested in any opinions or experiences.

It is easy to write nonportable code in C or in any other language, but it you
stick to the standard libraries, and do not use anything that the ansi standard
says is implementatin specific, your programs should be fairly portable.

If you do graphics, then things get tricker.  If you manipulate the graphics 
hardware directly from C, then you will not be protable at all.  If you use
something like an X windows server to provide your graphics interface, then you
will be portable.

If you write binary files and expect to share these between machines, or if you
use network connections between machines, then you have to wory about wheather
a machine is big or little endian, but if you explicitly take this into account,
you can still be portable.

I have a circuit simulator that I am writing for my PhD thesis.  It will run on
a variety of different machines (PCs, Vax, Sun, Mac), and the only portability
problem I have found is the lack of a standard way to clear the screen.  I take
care of this with a #ifdef statement in one of the header files.

Hope this helps,

Jim Nance
From: thompson@atlas.socsci.umn.edu (T. Scott Thompson)
Newsgroups: comp.lang.c
Subject: Re: POWER OF LARGE NUMBERS
Date: 25 Aug 92 16:47:22 GMT
Reply-To: thompson@atlas.socsci.umn.edu
Organization: Economics Department, University of Minnesota

jlnance@eos.ncsu.edu (JAMES LEWIS NANCE) writes:

>As I said before, you will have to define a type that can hold the numbers of
                                    ^^^^^^^^^^^^^
>the size you need before this will work (ints only for example).  If you use
>C++ then you can overload the *= and >>= operators to help you, but this is
>really not necessary.

If you look back over the history of this thread you will see that the
whole point of the initial discussion (not counting the statement of
the problem itself) is that it is impossible to do this.  The number
of bits needed to store the result is so large that no computer will
ever be able to do it (at least not in this galaxy).
--
T. Scott Thompson              email:  thompson@atlas.socsci.umn.edu
Department of Economics        phone:  (612) 625-0119
University of Minnesota        fax:    (612) 624-0209
From: doug@tisdec.tis.tandy.com
Date: 02 Sep 92 13:07 CDT
Newsgroups: comp.lang.c
Subject: Re: main()
Message-ID: <6700001@tisdec.tis.tandy.com>
Nf-ID: #R:Isis.MsState.Edu:715416182:tisdec.tis.tandy.com:6700001:000:2883
Nf-From: tisdec.tis.tandy.com!doug    Sep  2 13:07:00 1992


>/* ---------- "main()" ---------- */
>Ok, I thought supposadly in ANSI C/C++ one was to declare main() as such:
>either:

>int main(void)
 >or
>void main(void)

>BC++ books say int main(void) but what is the benefit of 'return 0' at the
>end.. seems like wasted space.

>Now in VERY new C++ books or VERY new C books, they usually have either

>int main()
>or void main()

>so what is wrong with 'main()' .. ANSI i suppose

>so what should i use

>void main(void) looks best (to me)?

>any htoughts?

Actually main() is defined as

  int main(int argc, char **argv, char *envp);

Argc is the number of arguments on the command line, with the program
name counting as one, argv is a pointer to an array of pointers to the
arguments (program name is argv[0]), and envp is a pointer to array of
pointers to the program's environment variables.  This last is very
rarely used so you will usually see it prototyped with only 2 parameters.

If you define it as main() all that will happen is that there will be
no prototyping for main.  This means the compiler will not be able to
spot an error if you call it with the wrong parameters, not a very
serious problem in this case.  Also without the declarations you won't
be able to access any command line arguments that might have been
passed to the program.

Declaring it as "void main(void)" is dead wrong.  But you can still do
it because the compiler has no idea how main() is defined.  You tell
it.  It's just another function.

The return value of main() is importatant if not always used.  Programs
under UNIX or DOS can return a value to the caller reporting information,
usually the outcome of running the program.  This value is set by calling
the exit() or by returning a value from main().  Also some compilers may
give a warning message if you don't have a return value in a function that
has been defined as returning a value.  So you can either put a return
value in or define main() as void to suppress it.

Now have said all that I should point out that I currently work on a
non-Unix system (it's not DOS either, it's much worse) where the system
does know what main() looks like.  If I don't declare main() with exactly
the return value and parameters it expects then the linker will spit out
some warning messages.  To avoid these I declare everything, including
envp, at which point the compiler spits out it's own warning messages
telling me that I declared but didn't use some parameters.

========================================================================
     Doug Scott                             doug@tisdec.tis.tandy.com
     Tandy Information Services             Phone: (817) 878-0367
========================================================================
All answers are guaranteed to be true, unless they happen to be wrong.
========================================================================
From: richard@aiai.ed.ac.uk (Richard Tobin)
Newsgroups: comp.lang.c
Subject: Re: strcpy implementation question
Date: 26 Aug 92 12:26:02 GMT
Organization: AIAI, University of Edinburgh, Scotland

In article <14173@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>Another example is
>	char *dst = malloc(strlen(src)+1);
>	assert(dst != NULL);
>	(void) strcpy(dst, src);
>Imagine a machine in which sizeof (long) = 4 but where the strictest
>alignment requirement is 2, and suppose that src is "".  Then malloc()
>might allocate 2 bytes at the top of memory.  (This is not an unrealistic
>example, by the way.  I have used such a machine, and I have used such a
>malloc().)  If strcpy() tries to move 4 bytes, it will run off the end of
>memory.  (For a modern example, think about OS/2 segments on a 286.)

All this means is that a library whose strcpy() copied extra bytes would have
to make sure that malloc() left adequate padding.

Of course, such a strcpy() would be broken for the other reasons given.

-- Richard
-- 
Richard Tobin,
AI Applications Institute,                                R.Tobin@ed.ac.uk
Edinburgh University.
Xref: sparky comp.lang.c:13188 comp.sys.sun.misc:4076