HDTenEightyP/NetNews huggingface dataset:
From: misar@rbg.informatik.th-darmstadt.de (Walter Misar)
Subject: Re: extern: interesting case...
Date: Wed, 6 Jan 1993 19:03:59 GMT
Organization: TH Darmstadt
Keywords: extern

In article <bibhas.726341439@femto.engr.mun.ca>, bibhas@pico.engr.mun.ca (Bibhas Bhattacharya) writes:
> When I declare:
> extern char line[];
> for the variable "line" which was defined in another file as:
> char line[80];
> everything works fine. But when I do:
> extern char *line;
> the program dumps core. I can't figure out the difference, especially when
> extern declaration is not supposed to reserve any memory or anything. When
> I looked up K&R, the correct declaration would be: extern char line[];.

A pointer isn't the same as an array. (Try compiling extern char *line;
extern char line[80]; => conflicting types for `line')
Given extern char line[], the compiler knows, that line is an constant adress,
where chars are stored. Given  extern char *line, the compiler looks at line
as a variable (=constant adress) where a pointer is stored, which points to
chars.

In assembler this would look like this:

line: dc.b "text",0	; char line[]="text";
+--------------------------------------------
text: dc.b "text",0
line: dc.l text		; char *line="text";	
 
-- 
Walter Misar                                | It is impossible to enjoy
misar@rbg.informatik.th-darmstadt.de        | idling thoroughly unless
                                            | one has plenty of work to do.
From: steve@dbaccess.com (Steve Suttles)
Newsgroups: comp.lang.c
Subject: Re: Unsolveable bug
Date: 8 Jan 93 04:14:20 GMT
Organization: Cross Access Corp., Santa Clara, CA
X-Newsreader: Tin 1.1 PL4

A somewhat less drastic approach might be to install printfs every
so often and see which ones run.  Narrow down the failure to one line
of code, and examine all values carefully.

I've experienced your symptoms several times, and each time it boiled
down to a variable that did not get initialized, and inherited
whatever value that memory cell had in it.  When I ran with the
debugger, it inherited a different value, which altered the behavior.
You may find that modifications to your program of any kind alter the
behavior, but this is consistent (putting in printfs does change the
runtime stack, after all...)

Forget about bugs in malloc implementation.  They would have been
found.  While your mistake might be in the area of malloc'ed memory,
it is a mistake in the requests that were made, rather than the
fulfillment of those requests.  But if you honestly believe you
haven't messed up with malloc, don't give up; keep looking until you
find it.  Computers only do what they are told, after all...

When one is discovered that doesn't, it gets sent out to be fixed.

sas
-- 
Steve Suttles                Internet:  steve@dbaccess.com      Dr. DCL is IN!
CROSS ACCESS Corporation     UUCP: {uunet,sgiblab}!troi!steve  Yo speako TECO!
2900 Gordon Ave, Suite 100   fax: (408) 735-0328              Talk data to me!
Santa Clara, CA 95051-0718   vox: (408) 735-7545   HA! It's under 4 lines NOW!
Newsgroups: comp.lang.c
From: misar@rbg.informatik.th-darmstadt.de (Walter Misar)
Subject: Re: Fopening a text file
Date: Tue, 5 Jan 1993 08:25:46 GMT
Organization: TH Darmstadt

In article <1993Jan5.015937.19270@vpnet.chi.il.us>, mox@vpnet.chi.il.us (William Moxley) writes:
> I'm having some problems with a program that I wrote for this computer
> which is running a sys V unix operating system.  My problem is with
> fopen.  When I try do a fopen("filename", "rt"); it opens the file as a
> binary.  If I drop the t, is still creates a binary file.  So how do I
> make fopen create a straight text file?
> 
> As you can guess, I normally don't write programs for machines other
> than dos.  Thanks in advance...

Oops, "rt" is new to me. In my understanding "r" specifies a text read,
"rb" a binary read. Further under Unix there isn't any difference between
this two modes - under both modes you will exactly read what was written.

-- 
Walter Misar                        It is impossible to enjoy idling thoroughly
misar@rbg.informatik.th-darmstadt.de       unless one has plenty of work to do.
Newsgroups: comp.lang.c
From: keith@torme.sharebase.com (Keith Chambless)
Subject: Re: NH-- > NH
Reply-To: keith@torme.sharebase.com (Keith Chambless)
Organization: NCR/ShareBase Corporation
Date: Fri, 8 Jan 93 21:03:35 GMT

In article <C0JMw6.680@netnews.jhuapl.edu> bandy@netnews.jhuapl.edu (Mike Bandy) writes:
>
>So what you're saying is that NH > NH.  I don't believe it.  Your 
>compiler (or your logic) has some serious problems.


Weird. Mine (Solbourne w/OS/MP 4.0) works the same:

	if (nh-- > nh)
	  printf("nh-- > nh = true\n");

prints true. I don't understand.
From: herring@netcom.com (John Herring)
Newsgroups: comp.lang.c
Subject: HELP!  using SDIO to talk to a SCSI device
Date: 8 Jan 93 15:44:22 GMT
Distribution: usa
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

Does anyone know of any sample code that will show me how to use
SDIO routines to talk using SCSI commands to a SCSI device in UNIX sys5 r3?

Or any other way to talk SCSI to a device in UNIX sys5.

TIA

john
Newsgroups: local.unix.help,comp.lang.c,comp.os.vms
From: kaarts@ccu.umanitoba.ca (Kenneth John Aarts)
Subject: Re: Using C to read Fortran Files
Organization: University of Manitoba, Winnipeg, Canada
Date: Wed, 6 Jan 1993 17:55:06 GMT

In <C0Fyo3.70D@ccu.umanitoba.ca> kaarts@ccu.umanitoba.ca (Kenneth John Aarts) writes:


>I have a fortran program that does essentially

>	open(unit=1,"test",status='new')
>	write(1,10) 'cArt'
>10	format(a4)
>	end

>and then a C program that reads it:

>	int d1,d2,d3,d4,d5;
>	FILE *fp;
>	fp=fopen("test","r");
>	fscanf(fp,"%c%c%c%c%c",&d1,&d2,&d3,&d4,&d5);
>	printf("%d %d %d %d %d\n",d1,d2,d3,d4,d5);

>The output of the C program is:

>  10  65  114  116   13

>  LF  A    r   t    CR

>However, a fortran program reading the test program does see cArt.

>How do I get C to find the c in cArt?

A little more information:

This is all done on VMS.  The fortran created file has a 'fortran carriage
control' record attribute.
Newsgroups: comp.lang.c
From: raph@panache.demon.co.uk (Raphael mankin)
Subject: Re: Moving from Pascal to C, Help please!!!!!! 
Distribution: world
Organization: Solvfield Ltd.
Reply-To: raph@panache.demon.co.uk
X-Mailer: Simple NEWS 1.90 (ka9q DIS 1.19)
Date: Sun, 10 Jan 1993 21:59:27 +0000

Just for the record. I've been programming now for 30 years, writing
compilers operating systems, network management, modem firmware, and name
and address label printing programs. Over that time I've learnt the virtues
of virtue.

On the topic of pointers; if you regard a pointer purely as an object reference
and not as a machine address ('object' here has nothing to do with OOP) then you
will not go far wrong. My experience is that a vast proportion of programming
errors (not design errors) are pointer faults of some sort -- and I'm not
referring just to my own code. I would class pointer modification as a kind
of dynamic unstructuredness, just as uncontrolled GOTOs are a static 
unstructuredness.

The remarks in K&R about using pointer modification to obtain a 'more 
efficient' subscripting predate the advent of optimising C compilers. You can
now get compilers that will do strength reduction on you subscripts, so let
the compiler do the hard work so keep your code clear and simple for the
human reader.
--------------
Raphael Mankin			Nil taurus excretum
Newsgroups: comp.lang.c
From: gm08@fg30.rz.uni-karlsruhe.de (Steffani)
Newsgroups: comp.lang.c
Subject: Re: C code Layout
Date: 6 Jan 1993 13:36:05 GMT
Organization: University of Karlsruhe, Germany
Reply-To: gm08@rz.uni-karlsruhe.de
NNTP-Posting-Host: fg30.rz.uni-karlsruhe.de

In article <13714@optilink.COM> brad@optilink.COM (Brad Yearwood) writes:
>In article <771@ulogic.UUCP>, hartman@ulogic.UUCP (Richard M. Hartman) writes:
># 
># ... am I in the minority here by preferring style C:
># 
># 	keyword (condition) 
># 		{
># 		statement1;
># 		statement2;
># 		statement3;
># 		}
I still prefer
	keyword(condition)
	 {
	  statement1;
	  .
	  .
	  statementX;
         }
Why? I like brackets wich belong together in ONE column. 
We use long (too long) names for functions and variables,
so the statements become very long. For better readablity(?)
i prefer lines not longer than 70 columns. So I do not like
more than 2 columns indent.
hans friedrich steffani
.
From: jos@and.nl (Jos Horsmeier)
Newsgroups: comp.lang.c
Subject: Re: NH-- > NH
Date: 9 Jan 93 14:16:08 GMT
Organization: AND Software BV Rotterdam

In article <1993Jan8.210335.28340@sharebase.com> keith@torme.sharebase.com (Keith Chambless) writes:
|In article <C0JMw6.680@netnews.jhuapl.edu> bandy@netnews.jhuapl.edu (Mike Bandy) writes:
|>
|>So what you're saying is that NH > NH.  I don't believe it.  Your 
|>compiler (or your logic) has some serious problems.
|
|
|Weird. Mine (Solbourne w/OS/MP 4.0) works the same:
|
|	if (nh-- > nh)
|	  printf("nh-- > nh = true\n");
|
|prints true. I don't understand.

Welcome to the wonderful world of undefined behavior. The postfix `--'
operator is guaranteed to be completed at the first sequence point.
The sequence point in a controlling expression of an if statement
is at the right parenthesis. Before that point, nobody knows when
the value 1 is subtracted from identifier `nh'. And even more: there
is no left to right evaluation guaranteed for a comparison operator.
Anything can be expected here ...

kind regards,

Jos aka jos@and.nl
Newsgroups: comp.lang.c
From: mueller@DG1.CHEMIE.UNI-KONSTANZ.DE (Christian M"uller)
Subject: struct / union / function declaration
Reply-To: mueller@DG1.CHEMIE.UNI-KONSTANZ.DE (Christian M"uller)
Organization: Fakultaet fuer Chemie, Universitaet Konstanz
Date: Tue, 12 Jan 1993 11:55:27 GMT


I have a problem defining a union like this:
  
struct s {
        union node *arg;
        union node (*func)(union node);
};

union node {
        struct s fun;
        int n;
};

Use gcc -Wall for compiling. Exists there *ANY* solution for defining
this without getting compiler warnings?

Note that struct s must be defined before the union definition.
Note also that we need a prototype definition for func here, otherwise
ge get an error somethere later.

A similar problem is the following:

struct x {
	int (*func)(struct x);
};

Any hints would be appreciated

Christian W. M"uller
From: roy%cybrspc@cs.umn.edu (Roy M. Silvernail)
Newsgroups: comp.lang.c
Subject: Re: Problem with string processing.
Date: Tue, 05 Jan 93 21:23:04 CST
Organization: Villa CyberSpace, Minneapolis, MN

mcglk@cpac.washington.edu (Ken McGlothlen) writes:

> Roy M. Silvernail (roy%cybrspc@cs.umn.edu) writes:
>
> | Assuming a large enough string for the append, and low-high byte ordering,
> | would this work?
> |
> | strcat(str,(char *)&ch);
> +----------
> 
> Well, it would work *sometimes*.  Remember that strcat() expects two pointers
> to ZERO-TERMINATED strings.  If what was stored in ch was immediately followe
> by a zero byte ('\0'), then it *would* work.

OK, I was feeling a bit silly that evening, but I'm really asking a
sideways pointer question.

The reasoning is:

The original example declared ch as int.  I assumed Intel ordering, so
the character 'A', value 0x41, would actually be stored as an int, and
so be at least 0x0041 (or longer).  The little-endian factor means this
looks like 0x41, 0x00 in memory.  So, cast the pointer to ch as a
(char *), and it seems like *(((char *)&ch)+1) == 0x00, and that ch could
be briefly considered as a zero-terminated string of length 1.

Maybe that should be ((char *)&ch)[1] == 0x00, perhaps?  And naturally
it fails on a big-endian machine, but I never said it was portable.

> But ch is stored wherever the
> compiler wants to store it, and it could be followed by *anything*,
> which means  that you could get a heck of a lot more characters on
> the end of str than you bargained for.

Of course.  Let's just say I'm sharpening up my obfuscatory technique. :-}
--
Roy M. Silvernail --  roy%cybrspc@cs.umn.edu - OR-  cybrspc!roy@cs.umn.edu
#! /usr/bin/perl
         open(I,"$0");@a=(<I>);shift(@a) until $a[0] =~ /^#!/;
         open(I,">>$ENV{'HOME'}/.signature");print I @a;__END__
         <perl signature virus V2.0 - do 'perl -x articlename'>
Newsgroups: comp.lang.c
From: dkeisen@leland.Stanford.EDU (Dave Eisen)
Subject: Re: Problem with string processing.
Organization: Sequoia Peripherals, Inc.
Date: Tue, 5 Jan 93 16:11:20 GMT

In article <MCGLK.93Jan5005833@yang.cpac.washington.edu> mcglk@cpac.washington.edu (Ken McGlothlen) writes:
>Roy M. Silvernail (roy%cybrspc@cs.umn.edu) writes:
>| [regarding the C statment:  while (*ptr++ = *str++);  ]
>|
>| (nice touch, BTW) How does this differ from 'strcpy(ptr, str)' besides the
>| function call overhead?
>It doesn't.  In fact, that's often how strcpy() is implemented.

In the example that Roy took this from, there is a big difference.
After the loop above, ptr points to the character one past the
trailing '\0' of the string. This is convenient because the function
it was taken from appended a character to the end of the string
and used this pointer to do so.

The loop is equivalent to:

   strcpy (ptr, str);
   ptr += strlen (str) + 1;

>| Assuming a large enough string for the append, and low-high byte ordering,
>| would this work?
>|
>| strcat(str,(char *)&ch);

>Well, it would work *sometimes*.  Remember that strcat() expects two pointers
>to ZERO-TERMINATED strings.  If what was stored in ch was immediately followed
>by a zero byte ('\0'), then it *would* work.  But ch is stored wherever the
>compiler wants to store it, and it could be followed by *anything*, which means
>that you could get a heck of a lot more characters on the end of str than you
>bargained for.

I think Roy was being cute here. I can never keep track of what 
low-high byte order means or what different endianness means,
but I think what he is saying is that if ch is an int formed
by widening the character chr, ch is say 4 bytes that look
like:

   chr  '\0'   '\0'   '\0'

so the strcat would work because the byte containing the value
of ch *is* followed by '\0'.

It takes more than a byte order assumption to get this to work.
First of all, there is no rule that states an int is bigger
than a char; if they are the same size, your objection is
completely valid. And if chars happen to be the same as signed
chars, the widening from char to int must preserve value (using
ANSI semantics) so if the char happens to be negative (on a two's
complement system), the int ch looks like:

   chr   FFFF    FFFF   FFFF

and the strcat doesn't work either.

So Roy's trick, if I am understanding him correctly, will work
fine on a system where a number of assumptions are correct. I'll
let Roy defend the usage of his trick from those who would 
argue it is not good style.


-- 
Dave Eisen                               Sequoia Peripherals: (415) 967-5644
dkeisen@leland.Stanford.EDU              Home:                (415) 321-5154
       There's something in my library to offend everybody. 
          --- Washington Coalition Against Censorship
Xref: sparky comp.lang.c:19527 comp.lang.c++:18926
Newsgroups: comp.lang.c,comp.lang.c++
Subject: Re:  Dynamic Mem Help
From: alien@acheron.amigans.gen.nz (Ross Smith)
Date: 10 Jan 93 12:12:06 GMT+12
Distribution: world
Organization: Muppet Labs

In article <rfries.164@sceng.ub.com> rfries@sceng.ub.com (Robert Fries) writes:
>In article <1993Jan8.205809.7661@klaava.Helsinki.FI> wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) writes:
>
>>rfries@sceng.ub.com (Robert Fries) writes:
>>>You'll have to use an explicit cast of this value to
>>>assign it to a variable of type 'char *', e.g.:
>>>
>>>      str = (char *)calloc(10, sizeof(char));
>
>>This is required in C++ only, not in ANSI C.
>
>>In ANSI C no casts are needed when assigning a "void *" to a pointer
>>to any data type (not including pointers to functions), or the other
>>way around.
>
>>--
>>Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
>>   MS-DOS, you can't live with it, you can live without it.
>
>Oops, you're absolutely right.

About what? C or MS-DOS?

:-)

--
...... Ross Smith (Wanganui, NZ) ...... alien@acheron.amigans.gen.nz ......

"I blame you for the moonlit sky and the dream that died with the Eagle's flight
I blame you for the moonlit nights when I wonder why are the seas still dry
Don't blame me, sleeping satellite"                              (Tasmin Archer)

--

Newsgroups: comp.lang.c,comp.lang.c++
From: suresh@papaya.iss.nus.sg (Suresh Thennarangam - Research Scholar)
Subject: Re: C/C++ Speed
Reply-To: suresh@iss.nus.sg (Suresh Thennarangam - Research Scholar)
Organization: Institute Of Systems Science, NUS
Distribution: usa
Date: Tue, 12 Jan 1993 02:51:24 GMT

In article <1993Jan11.161017.16545@taumet.com> mike@taumet.com (Mike Ball) writes:
>vpham@cs.ulowell.edu (vinh) writes:
>
>>to me, the most complex piece of software is an OS; and so far
>>i haven't seen a  successful commercial OS written in C++.
>
>Most of which just shows inexperience.  Operating systems are far from
>the most complex software out there.

I concur .. a a full-fledged RDBMS program like Oracle V6.0+ is far more
complex than an OS like DOS( the world's most commercially successful and
popular OS :->).  
>
>Also, all successful commercial OS's were written decades ago, since it
>takes that long to become a success.
>-- 
>Michael S. Ball (mike@taumet.com)
>TauMetric Corporation


***************************************************************************
* Suresh Thennarangam               *  EMail: suresh@iss.nus.sg(Internet) *
* Research Scholar                  *         ISSST@NUSVM.BITNET          *
* Institute Of Systems Science      *  Tel:  (065) 772 2588.              *
* National University Of Singapore  *  Facs.: (065) 778 2571              *
* Heng Mui Keng Terrace             *  Telex: ISSNUS RS 39988             *
* Singapore 0511.                   *                                     *
***************************************************************************
Newsgroups: comp.lang.c
From: eager@eagercon.com (Michael J. Eager)
Subject: Re: Problem with string processing.
Reply-To: eager@eagercon.com
Organization: Eager Consulting
Date: Mon, 4 Jan 1993 19:17:16 GMT

In article 20833@iitmax.iit.edu, matujos@elof.iit.edu (Joe Matusiewicz) writes:
>
>
>         void add_char_to_str(char ch, char *str)
>         {
>1.           char *tmp;
>2.           tmp = (char *) calloc (2*sizeof(char));
                             ^^^^^^^^^^^^^^^^^^^^^^^
Calloc takes two parameters:  calloc (2,1)
You should always include <stdlib.h> in your program when you use calloc; it
would have allowed the compiler to flag the incompatibility.

>3.           *tmp = ch;
>4.           *(tmp+1) = '\0';
>5.           strcat(str, tmp);
>             free (tmp);
>         }
>


This is also a very awkward way to do a very simple task.  Here is another
way:


void add_char_to_str(char ch, char *str)
{
    while (*str++);		/* Skip to end of string */
    *str++ = ch;		/* Add character */
    *str = '\0';		/* Terminate string */
}


I'd also suggest that the argument ordering be reversed to make the function
resemble strcat.

---
Michael J. Eager		Michael.Eager@eagercon.com
Eager Consulting		(415) 325-8077 
1960 Park Boulevard, Palo Alto, CA 94306-1141

Xref: sparky comp.lang.c:19356 comp.lang.pascal:7938 comp.lang.prolog:2329
From: jos@and.nl (Jos Horsmeier)
Newsgroups: comp.lang.c,comp.lang.pascal,comp.lang.prolog
Subject: Re: Assessing a language
Date: 7 Jan 93 09:39:17 GMT
Followup-To: comp.lang.c
Organization: AND Software BV Rotterdam

In article <nharvey.726285484@probitas> nharvey@probitas.cs.utas.edu.au (Nicole Harvey) writes:
|hi,
|   I am involved in assessing a language. Does anyone know of a standard
|set of problems that I could use to judge the languages compabilities?
|   Can anyone think of a problem that represents a real need in a language?
|For example, we have tested it for the eight queens problem to show that 
|it can do state space searches. We have also made sure it can generate the 
|Fibonacci numbers. Can you think of any other well known problems?
|   What things do you expect to be able to write relatively simply using any
|language? I would like to here from people working in all areas. 

All programming languages are Turing Machine equivalent. Given two languages
L1 and L2, one can write a compiler (or interpreter) in language L1 for 
language L2 and vice versa. IMHO the only classification one can make for
programming languages is: general purpose vs. special purpose languages.

Languages that pretend to be general purpose should not be biased towards
any particular topic such as symbolic data processing (LISP), vector mani-
pulation (APL) etc. etc. But it must not be too difficult to construct those
facilities yourself in such a language. If it were too difficult to do so,
this language would simply be a silly language: it would miss the `expressi-
veness' one needs to work with this language in a comfortable way.

Again IMHO, I think that any language assessing ends up in a religious war
between FORTRAN fans, LISP lawyers, C celebrities and APL addicts. ;-)

kind regards,

Jos aka jos@and.nl
Newsgroups: comp.lang.c
From: atbowler@thinkage.on.ca (Alan Bowler)
Subject: Re: upper/lower case with VMS C
Organization: /etc/organization
Date: Wed, 13 Jan 1993 00:58:41 GMT

In article <Bzs20s.FBM@rex.uokhsc.edu> david@rex.uokhsc.edu (David W. Bourne) writes:
>I am trying to compile a 'c' program I obtained from a colleague under
>VAX VMS. With other module I had no real problems but one module
>apparently has variables with the 'same' names, that is only case
>different.
>
>One line reads
>
>  double *Ao, *Ak, .... , *ao
>
>I then get an error message CONFLICTDECL indicating that the ao is
>a redeclaration of the Ao variable.

For maximum portability, a program should made sure that external names
are unique in first 6 characters ignoring case.  This is violated by
the names "Ao" and "ao".  I don't believe that VMS has the six
character part of the restriction, but I do believe it does not respect
case on external names.  You really need to rename one the these two
variables.  It will keep the loader happy, and probably make debugging
and other maintenance easier.