HDTenEightyP/NetNews huggingface dataset:
From: lwv26@cas.org (Larry W. Virden)
Subject: Re: sscanf?  What am I doing wrong?
Followup-To: comp.lang.c
Reply-To: lvirden@cas.org (Larry W. Virden)
Organization: Nedriv Software and Shoe Shiners, Uninc.
Date: Wed, 2 Sep 1992 19:11:45 GMT

In article <1992Aug31.154655.15737@magnus.acs.ohio-state.edu> kpearce@magnus.acs.ohio-state.edu (BULLDAWG) writes:
:Hi:
:
:	Forgive me if this is a stupid question:
:
:I am using Borland C++ and am compiling as default C file.
:
:Why doesn't this work?
:
:char command[80]  \* This is data from a file read off of the disk 'r' type.*\
:char partA[20];   \* and is for example "transmit data" *\
:char partB[60];
:char tran[] = "transmit"
:sscanf(command,"%s %s",partA, partB);
:
:void main(void)
:{
:  if (partA==tran)
:  {
:  	printf("We have a match\n");
:  }
:  else
:  {
:  	printf("failed again  :(  \n");
:  }
:}
:
:This always fails.  I have tried putting \r\0 and various other control
:characters at the end of the ttest string tran[] to no avail.
:
:Putting a printf("%s\n %s\n %s\n",command,partA,partB) yields the correct output
:e.g.
:    transmit data
:    transmit
:    data
:
:So what am I doing wrong?  As far as the program goes they don't match.  But I
:say they do.
:
:Please e-mail to me.  Thanks.
:
:Ken Pearce

After making numberous fixes, we have:

 /* This is data from a file read off of the disk 'r' type.*/
char command[80] = "transmit data";
char partA[20];   /* and is for example "transmit data" */
char partB[60];
char tran[] = "transmit";

int main(void)
{
 sscanf(command,"%s %s",partA, partB);
  if (strcmp(partA,tran) == 0)
  {
  	printf("We have a match\n");
  }
  else
  {
  	printf("failed again  :(  \n");
  }
}

$ cc tstsscanf.c -o tstsc
$ ./tstsc
We have a match


-- 
Larry W. Virden                 UUCP: osu-cis!chemabs!lvirden
Same Mbox: BITNET: lvirden@cas  INET: lvirden@cas.org
Personal: 674 Falls Place,   Reynoldsburg, OH 43068-1614
America Online: lvirden@aol.com
Newsgroups: comp.lang.c
From: behrenss@Informatik.TU-Muenchen.DE (Soenke Behrens)
Subject: Re: Most difficult part of learning C?
Organization: Technische Universitaet Muenchen, Germany
Date: Tue, 25 Aug 1992 20:49:52 GMT

Hmm ... most difficult ... the various semantic pittraps in the language.
For one, the confusion between arrays and pointers (made worse by that
icky first German translation of K&R .. yuck :).
Syntactic pitfills, like the operator precedence (do I have to bracket that?
Yes? No?), "else"s that are assigned to the wrong "if" because I forgot to
use braces _everywhere_.
Ah, before I forget it: (*(void(*)())0)(); This is a piece of ROMable C
for starting the machine on RESET. These and similar constructs are
a pain :)

Soenke

-- 
===========================================================================
More than silver, more than gold, I need   !    behrenss@informatik.
electricity. I need it for my dreams.      !    tu-muenchen.de
(RACTER)                                   !  FIDO: 2:246/13 Soenke Behrens
From: linden@positive.Eng.Sun.COM (Peter van der Linden)
Newsgroups: comp.lang.c
Subject: Re: Novice Questions
Date: 31 Aug 1992 22:49:11 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: positive


Matthias mentions monotonically:
>  An array is not a lvalue! 

Actually, an array *is* an lvalue in ANSI C.

An array is not a *modifiable* lvalue however.

The Rationale gives some details about the
terminology battles that took place over this.


--
linden@eng.sun.com|| P. van der Linden and his uncustomary theories.
Go Giants!! Don't || When solving a "panic" you must first ask yourself what you
stop at Florida...|| were doing that could possibly frighten an operating system
Newsgroups: comp.lang.c
From: igrdb@informatik.tu-chemnitz.de (Ingo Gringer)
Subject: Thanks: Combine c and c++
Organization: tu-chemnitz
Date: Thu, 27 Aug 1992 09:34:38 GMT

Thanks for all hints! Extract: Don't forget the
extern "C" declaration for included c parts and
program main() in c++.

Ingo
From: mjn@pseudo.uucp (Murray Nesbitt)
Newsgroups: comp.lang.c
Subject: Re: How to handle __STDC__
Date: 31 Aug 92 10:11:41 GMT
Organization: Private system in Toronto, ON


albert@bsovax.UUCP (Albert van der Horst) writes:

>C) concerning __STDC__
>This built in #define is used most often to govern the use of
>prototypes.

The macro __STDC__ is intended to be used to conditionally translate
code which depends on the implementation being standard-conforming.
There are compilers which aren't standard-conforming but accept
function prototypes, so using __STDC__ for this purpose is not a great
idea.

>This would imply that you can have "#define __STDC__ 2"
>on a non standard system. Mark Williams is doing something
>substantially more reasonable : "#define __STDC__ 0" to convey that
>its c-compiler is not standard.

Since it doesn't claim ANSI conformance, it is free to do what it
wants with __STDC__.  But, I don't consider this reasonable - a
non-standard compiler should leave __STDC__ alone.  If the rogue
compiler wants to convey its non-conformance, it should simply not
define __STDC__.

>The result is that I cannot compile programs that use
>"#ifdef __STDC__". However this seems common practice in sources
>distributed via the net, but I have seen "#if __STDC__" as well.

If this "feature" of your compiler is problematic, you can always
#undef __STDC__.

On the other hand, if a programmer wants to conditionally translate
code which depends on the translator conforming to the *current* ANSI
Standard, the test should be:

#if __STDC__ == 1
[...]
#endif

-- 
Murray
Newsgroups: comp.lang.c
From: robert@triton.jpl.nasa.gov (Robert Angelino)
Subject: Successful use of /G_FLOAT option to VMS CC...
Reply-To: robert@triton.Jpl.Nasa.Gov
Organization: Jet Propulsion Laboratory, Pasadena CA
Date: Wed, 26 Aug 1992 22:19:23 GMT

Has anyone out there had any success with the /G_FLOAT with CC???
I keep getting multiply defined linker errors in the sharable image vaxcrtlg.

I'm running VMS O/S- V. 5.4-3 and C- V. 3.2 on a VAX 6400-10.

Any help is appreciated...

-robert
Newsgroups: comp.lang.c
From: kpearce@magnus.acs.ohio-state.edu (BULLDAWG)
Subject: sscanf, thanks for the answers. : )
Organization: The Ohio State University
Date: Mon, 31 Aug 1992 17:53:05 GMT

Many thanks to those who responded.

I have found the answer to my question.

Thanks.
Newsgroups: comp.lang.c
From: michael@nuchat.sccsi.com (Michael Bentley)
Subject: Re: New Comer - Please Help !
Keywords: Help NewComer
Organization: /etc/organization
Date: Tue, 25 Aug 1992 23:50:44 GMT

In article <1992Aug25.171317.8124@samba.oit.unc.edu> Ketan.Deshpande@bbs.oit.unc.edu (Ketan Deshpande) writes:
>In article <1992Aug25.000613.3610@geovision.gvc.com> pt@geovision.gvc.com writes:
	[> question about library functions deleted for brevity <]
>>I would suggest you actually _buy_ TurboC instead of pirating it, and then
>>RTFM.  There is a huge library of functions already there, and FileExists
>>As for mouse libraries, sorry - my TurboC manual doesn't mention it.
>
>I don't see how Doug's letter leads to Paul's statement about _buying_ TurboC.
>Can you help me out?
>Ketan.

I believe that Paul is assuming (not totally without reason - *I* thought
the same thing) that if Doug had actually bought the product, he would
have noticed that there were several manuals included....  One of them
has "RUN-TIME LIBRARY * GLOBAL VARIABLES" (borland's caps lock, not mine)
written down the spine...


-- 
+============================================================+
|  Michael S. Bentley (Looking for a way back to California) |
|  VoiceNet : (713) 558-2349                                 |
|  E-mail   : michael@nuchat.sccsi.com                       |
Newsgroups: comp.lang.c
From: mswanke@cip.informatik.uni-erlangen.de (Matthias Wanke)
Subject: Decent DOS-C-Compilers
Summary: decent c-compilers for DOS sought.
Organization: CSD., University of Erlangen
Date: Thu, 3 Sep 1992 18:40:03 GMT
Keywords: Compiler C Dos

Fellow netters,

as i'm a little out of date when it comes to C-Compilers, i just wondered
what would be the fastest for my DOS-machine (486 DX-2) and is compatible with
the libraries of Borland-C 2.0? I`m trying to get my boss to purchase 
updates or something new so it`d be great if someone could suggest something. 
Btw, the compiler should produce at least '386-code that is able to
use Expanded/Extended Memory. (I have djg++, but i need compatibility
with Borland C++ and its libraries). Also, if someone knew how to (in some
way) convert Borland-Libraries of the .lib form into .obj or even into
UNIX-style ar-Archives, that`d be just great.

Help by e-mail would be really great.


Greets, Matt.
---
Matthias Wanke (IRC: Goose, Goosie)        * "Base 8 is just like base 10 - 
mswanke@cip.informatik.uni-erlangen.de     *  if you're missing two fingers..."
wanke@faps.uni-erlangen.de                 *  (Tom Lehrer)
From: mike@pacsoft.com (Mike Stefanik)
Newsgroups: comp.lang.c
Subject: Re: Why should POINTERS be so damn hard to understand ?
Date: 29 Aug 92 21:07:32 GMT
Organization: Pacific Software Group, Riverside, Ca.

In an article, henders@infonode.ingr.com (Greg Henderson) writes:
>[...] if you are worried about low-level efficiency the second
>version [using a pointer] is a little tighter, as each reference
>to the array value in the pointer version requires less work to
>come up w/ that address.

This depends on which machine and what compiler you're using... I've
seen code using array indices run faster than the flavor using pointers.
Efficiency is a subjective thing after all, and it doesn't necessarily
mean just making the program run faster.
-- 
Mike Stefanik  mike@pacsoft.com  ...!uunet!pacsoft!mike
Pacific Software Group, Riverside, CA
Newsgroups: comp.lang.c
From: sasghm@theseus.unx.sas.com (Gary Merrill)
Subject: Re: Why should POINTERS be so damn hard to understand ?
Originator: sasghm@theseus.unx.sas.com
Date: Thu, 27 Aug 1992 13:38:41 GMT
Organization: SAS Institute Inc.


In article <25233@castle.ed.ac.uk>, chas@castle.ed.ac.uk (C Spencer) writes:
|> 
|> Why does a pointer need to know what it's pointing to? Surely it's just
|> an address - if there was only one kind of pointer, there wouldn't be so
|> much to learn, and be confused by.

Yeah, sure.  And then we wouldn't have to worry about incrementing
or decrementing them (by how much?), or using 'sizeof' on them to
allocate dynamic storage for arrays of them, or calling functions
indirectly via function pointers, or using them to step through
arrays, or ...  In fact, what *would* we use them for?  Better
to just get rid of them.
-- 
Gary H. Merrill  [Principal Systems Developer, C Compiler Development]
SAS Institute Inc. / SAS Campus Dr. / Cary, NC  27513 / (919) 677-8000
sasghm@theseus.unx.sas.com ... !mcnc!sas!sasghm
From: adrian@milton.u.washington.edu (Adrian Mariano)
Newsgroups: comp.lang.c
Subject: scanf portability (?) problem
Keywords: scanf
Date: 26 Aug 92 22:56:56 GMT
Organization: University of Washington


I'm trying to parse lines which look like the ones below.  Most lines
will look like the top one, but in a few cases, the text in the second
and or third set of brackets will be 5 characters instead of 3
characters (like the second line below).

[ 0]      nimmox [ 6k] vs.          cd [ 9k] ( 99   19    0    5.5)
[ 5]         joe [IGS92] vs.     xxxyyyz [???] ( 33   11    3    4.5) 


In order to do this, I wrote the following scanf pattern:

            "[%2d]%12s [%[^]]] vs.%12s [%[^]]] (%3d %d %d %f)\n"

                          ^               ^
                          |               |
                          -----------------
                                  |
				  |
                          These are the troublemakers

Earlier, the program whose output I am parsing would only generate
lines which look like the first one above.  I assumed that the text in
brackets was always three characters, and parsed it with %3c.  This
worked correctly everywhere I tried it.

With the change, everything works fine on all machines I've tried but
one machine running Dynix.  Is there something I can do to make this
scanf pattern work everywhere?

Please email responses.
From: bob@kc2wz.bubble.org (Bob Billson)
Newsgroups: comp.lang.c
Subject: calloc() confusion -- help?
Summary: sorry if this a repeat newsfeed may be broke :-(
Keywords: calloc help not_homework
Date: 2 Sep 92 01:12:00 GMT
Distribution: na
Organization: Color Computer 3: Tandy's 'game' machine

Hi all,

I tried posting this the other day.  I doubt it got out as my news feed
seems to be broke (at least news has gone down to a trickle for the past few
days.)  If this is a repeat, I apologize.  I would appreciate any answers be
sent email.  Thanks.

I hope someone can unblock my mental block.  I am trying to figure out how to
properly use calloc() to create an array of structures.  Here is an example of
my test program.  It won't compile properly and I seem to have a mental block
figuring out why it won't compile and work correctly..  I need this to compile
under the "old style" K&R not ANSI.

"test.list" is a text file with < 80 chars per line of various info.  As
each line is read, the appropriate pieces need to be placed each struct member.
Because the number of lines in "test.list" will vary, I want to dynamically
allocate an array of structures mbox at runtime.


#include <stdio.h>


struct mbox  {
        char status,
             envelop[14],
             from[19],
             subj[37];
    };


 
main()
{
     FILE *fp;
     int i, limit;
     register struct mbox *ltr;
     char line[81];


     if ((fp = fopen ("test.list", "r")) == NULL)
             fatal ("can't open test.list");

/*   limit = numlines (fp);  */

     limit = 35;                    /* for test purposes right now */

     /* create an array of structs mbox, one for each line in test.file */

     ltr = (struct mbox *) calloc (limit, sizeof (struct mbox));

     if (ltr == NULL)
             fatal ("calloc() can't get enough memory");

     for (i = 0; i < limit; ++i)
       {     fgets (line, sizeof (line), fp);

             ltr[i]->status = line[0];
             strncpy (ltr[i]->envelop, &line[5], 12);
             strncpy (ltr[i]->from, &line[14], 18);
             strncpy (ltr[i]->subj, &line[32], 26);
       }

     fclose (fp);

     /* see if we got what we think we got */

     for (i = 0; i < limit; ++i);
       {      printf ("ltr[%d]->status  = %c\n", i, ltr[i]->status);
              printf ("ltr[%d]->envelop = %s\n", i, ltr[i]->envelop);
              printf ("ltr[%d]->from    = %s\n", i, ltr[i]->from);
              printf ("ltr[%d]->subj    = %s\n\n", i, ltr[i]->sb);
       }
}



int fatal (msg)
char *msg;
{
      fprintf (stderr, "foo: %s\n", msg);
      exit (0);
}


I'm sure the answer is simple, I just can't see it.  The C books I do have, do
not help much with calloc(). :-(

Thanks for the help!
 
      Bob
-- 
  Bob Billson, KC2WZ                          | internet: bob@kc2wz.bubble.org
                                              |           kc2wz@amsat.org
  $nail:  21 Bates Way,  Westfield, NJ 07090  | uucp:     ...!uunet!kc2wz!bob
                  C code.  C code run.  Run code run...<please!>
Newsgroups: comp.lang.c
From: dat@thinkage.on.ca (David Adrien Tanguay)
Subject: Re: string concatenation (was: Re: printf question)
Organization: Thinkage, Ltd.
Date: Wed, 2 Sep 1992 18:05:05 GMT

jos@and.nl (Jos Horsmeier) writes:
>In article <1SEP199221241770@eql.caltech.edu> rankin@eql.caltech.edu (Pat Rankin) writes:
>|     Minor quibble:  string concatentation is performed by the compiler,
>|not the preprocessor.
[...]
>Phase 6 reads:
>Adjacent character string literal tokens are concatenated and adjacent
>wide string literal tokens are concatenated.
>
>Phase 7 reads:
>[ ... ] The resulting tokens are syntactically and semantically
>analyzed and translated.
>
>So, phase 7 is the phase where the grammar comes in. On of the first
>grammar rules reads:
>
>primary-expression:
>	[ ... ]
>	string-literal
>
>Where string literal is defined as:
>
>string-literal:
>	"s-char sequence_opt"
>	L"s-char sequence_opt"
>
>See? A string literal is not defined as a concatenation of one or more
>string literals. That's why I thought that the process of concatenating
>these things was done in the preprocessor. Well, it does so in mine ...
>
>Section 3.3.1 (Primary expressions) says nothing about a concatenation
>of string literals either, so that made my believe that I was right
>even stronger, but I've tried some other preprocessors just now and
>none of them does the concatenation, so, again, you're probably right.

The standard does not define a "preprocessor" entity, only phases of
translation. As has been often mentioned, there does not even have to be
a separate preprocessor, or a compiler switch to only preprocess.
If the implemetation decides to draw a boundary between pre-processor and
parser, it is up to the implementation to decide which does the
catenation (it could do it in both). Of the two compilers I regularly use,
one does phase 6 in the parser and the other in the preprocessor.
-- 
David Tanguay       dat@Thinkage.on.ca  dat@Thinkage.com  uunet!thinkage!dat
Thinkage, Ltd.           Kitchener, Ontario, Canada          [43.40N 80.47W]
Newsgroups: comp.lang.c
From: ditolla@itnsg1.cineca.it (Francesco Di Tolla)
Subject: Re: C vs. FORTRAN
Organization: Laboratorio di Fisica Computazionale, INFM. Trento Italia
Date: Fri, 4 Sep 1992 07:53:53 GMT

dwiseman@spsd630a.erim.org (Dave Wiseman) writes:


>Help!

>I have a (two) simple programs, one in fortran, and one in C.  I have compiled
>them both optimized, and timed the results.  The fortran version takes .1 s
>to run, and the C version takes 12.5s to run.  I know (hope) that there is a
>simple remedy for this.  The project that I am working on has to do many 
>sines and cosines, and I'd prefer to keep the entire program in C, and not
>mix the languages.  What can I do to improve the speed of the C version?

>	Dave Wiseman
>	dwiseman@erim.org

>-------------------------------------------------------------------------------
>#include <stdio.h>
>#include <math.h>

>main (argc,argv)
>     int argc;
>     char **argv;
>{
>  double angle,delta,the_sin,the_cos;
>  int i;
>  
>  angle = 0.0;
>  delta = 0.01;
>  
>  for (i=0; i<1000000; i++)
>  {
>    the_sin = sin(angle);
>    the_cos = cos(angle);
>    angle += delta; 
>  }
>}
>-------------------------------------------------------------------------------
>      program test

>      real*8 angle,delta,the_sin,the_cos
>      integer*4 i

>      angle = 0.0
>      delta = 0.01

>      do I=1,1000000
>         the_sin = dsin(angle)
>         the_cos = dcos(angle)
>         angle = angle + delta
>      enddo

>      end
>-------------------------------------------------------------------------------
>--
>David Wiseman              dwiseman@erim.org
>Environmental Research Institute of Michigan

Are you shure your fortran program is performing any computation?

By
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)  |
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.c
Subject: Re: Why should POINTERS be so damn hard to understand ?
Date: 27 Aug 1992 15:34:19 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <1992Aug27.135946.6622@infonode.ingr.com> henders@infonode.ingr.com (Greg Henderson) writes:
>    int a[1000], *_i;
>    for (_i=a;  _i<a+1000; _i++ )
>	*_i = get_some_arbitrary_value();
>[This] version would not be possible unless you had pointers that
>knew what type they were supposed to point to, and thus know how many
>bytes to increment the address to get to next guy.

That's not true.  If pointers didn't scale automatically, the programmer
would do it himself:

int a[1000];
char *_i;

for (_i=(char *)a; _i<a+1000*sizeof(int); _i+=sizeof(int))
    *(int *)_i = whatever();

I would epect this to produce almost identical code.  And in a language
where pointers weren't typed, you wouldn't need all the casting.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: lam@saifr00.cfsat.honeywell.com (Josh Lam)
Newsgroups: comp.lang.c
Subject: Re: Combine c and c++?
Date: 26 Aug 92 16:12:13 GMT
Organization: Honeywell Air Transport Systems Division


In article <langlois.714840171@ro> langlois@doe.carleton.ca (Francis Langlois) writes:
Francis> Sender: news@cunews.carleton.ca (News Administrator)

Francis> In <igrdb.714837537@hrz.tu-chemnitz.de> igrdb@informatik.tu-chemnitz.de (Ingo Gringer) writes:


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

Francis> when you include the c protoype in C++ did you use the

Francis>   extern "C" prefix.

Francis>   I believe this is you only problem.  You see C++ uses name mangling
Francis> and C does not.  By using the extern "C" prefix you tell the compile
Francis> this function or data type or what ever is to be compiled so it looks
Francis> like C not C++.

Francis> eg.

Francis>  extern "C" int* foo(void); // is a prototype to C function which may
Francis> 			    // or may not have been compiled with C++


Also, make sure that the main() is in the C++ application.

-- 
Josh Lam
Honeywell Inc
lam@saifr00.cfsat.honeywell.com
Newsgroups: comp.lang.c
From: bernie@metapro.DIALix.oz.au (Bernd Felsche)
Subject: Re: Why should POINTERS be so damn hard to understand ?
Organization: MetaPro Systems, Perth, Western Australia
Date: Fri, 28 Aug 92 01:34:49 GMT

In <25233@castle.ed.ac.uk> chas@castle.ed.ac.uk (C Spencer) writes:

>Why does a pointer need to know what it's pointing to? Surely it's just
>an address - if there was only one kind of pointer, there wouldn't be so
>much to learn, and be confused by.

Obviously, so that when you add or subtract from it, it is
in multiples of the object size.

You will also find that some machine architectures only
support even addresses, or worse (??) multiple of 4. With
the advent of 64-bit architectures, I guess that it won't be
long before they'll be multiples of 8.
-- 
+-----+ Bernd Felsche                     _--_|\  #include <std/disclaimer.h>
| | | | MetaPro Systems Pty Ltd          /      \ bernie@metapro.DIALix.oz.au
| | | | 328 Albany Highway,              X_.--._/         Fax: +61 9 472 3337
|m|p|s| Victoria Park, Western Australia 6100  v        Phone: +61 9 362 9355
Newsgroups: comp.lang.c