HDTenEightyP/NetNews huggingface dataset:
From: amid@bullet.ecf (AMID  Rudy)
Subject: C socket programming
Originator: amid@bullet.ecf.toronto.edu
Organization: University of Toronto, Engineering Computing Facility
Date: Thu, 9 Apr 1992 06:58:51 GMT

Hello,

   I have just one question (which is VITAL for my project):

   How can I mark accept(2) non-blocking?  The man pages suggest that it is
possible but don't have anything on how to do so.

   A quick reply will be greatly appreciated.  Thanks!

---
Rudy Amid  amid@ecf.toronto.edu                                            /\
   //      a378amid,a318amid,a209amid@cdf.toronto.edu                    (//\\)
  //
\X/     "This world needs its dreamers. May they never wake up." -Prefab Sprout
Newsgroups: comp.lang.c
From: andy@ian.stx.com (Andy Moore)
Subject: Re: Interpreting Escape Sequences
Summary: enough already!
Organization: STX, Lanham Maryland
Date: Wed, 15 Apr 1992 15:21:47 GMT

Sincere thanks to all who explained to me (often in gorey detail) that
escape sequences are interpreted at compile time and not by printf itself.
Special thanks to Jun Hamano (junio@tori.twinsun.com) and Robert Earl
(rearl@piggy.ucsb.edu) for actually including some code to interpret
escape sequences.

However... <flame mode on>

No thanks at all for the many unsolicited comments, critiques, and
advice on C programming and style in general.  I needed a specific
answer to a specific question/problem.  I did not ask for a tutorial
on C, nor for anyone's opinion on my code...  Some specifics:

}BTW, the one thing all style guides agree on is that identifiers in ALL CAPS
}should be reserved for #defines.

<biting tongue very hard>  Anyone interested in my suggestion for where
to put their 'style guides' may e-mail me...

}ptest with no argument will pass a NULL pointer into printf(), which
}is not a Good Thing (it could blow up).

}ptest "%s" (or any other printf format) can also cause your program to
}die messily.

}*Never* use printf(var) unless you have complete control and understanding
}of the possible contents of var.  Use fputs(var,stdout) or printf("%s",var)
}instead.

}(A bad thing to do, since calling this program with an argument
}containing "%s" or "%d" will cause it to go off into never-never
}land.)

}'nother problem: if your input string contains a percent sign ('%'),
}the code will fail, since printf receives no argument to go with the
}%.

}'nother problem: if you don't give the program any argument at all,
}it will fail, since printf will most probably get a NULL pointer.

Yes yes yes, I realize all that.  My example program wasn't a *real*
program; it was a short blurb to get to the specific problem.

}'main' should end with a
}	return 0;
}or
}	exit (0);
}to be fully correct, by the way.

Eat my shorts.  Believe it or not, some of us don't *like* C, and some
of us write real code in the Real World (tm) and don't give a rat's
about being 'fully correct'.

<flame mode off>  Just my opinions.  In spite of the previous tone used,
I do appreciate the help many of you have given me.

p.s. By the way, I did in fact check the FAQ carefully before posting...
-- 
_____________________________________________________________________________
Andy Moore         "I've given birth to eight babies; don't you talk to me
 andy@ian.stx.com   about gettin' hurt, you big ox!"  -- Fanny, "Robin Hood"
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: const Questions
Keywords: const pointers declarations
Date: 6 Apr 92 22:01:04 GMT
Article-I.D.: dog.22532
Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
NNTP-Posting-Host: 128.3.112.15

In article <22346@dog.ee.lbl.gov> I noted that
>>>... the `const'-ness of `a' is irrelevant in the prototype
>>>itself, so you could write, for instance:
>>>	void test(int *a[]);
>>>	void test(int **const a) { [...] }

In article <1992Apr1.044432.2616@druid.uucp> darcy@druid.uucp (D'Arcy
J.M. Cain) asks about:
>>void test(char *s);
>>void test(const char *s) { [...] }

In article <1992Apr2.143454.24447@klaava.Helsinki.FI>
wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) writes:
>This is a different case.

Right.

More specifically, though, here neither `s' is `const'.  In this case
you are dealing with the const-ness (constance?) of *s, not s itself.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
From: alpha@wyvern.twuug.com (Joe Wright)
Newsgroups: comp.lang.c
Subject: Re: C SRC FOR DBASE ACCESS?
Date: 9 Apr 92 04:02:57 GMT
Organization: Tidewater UNIX Users Group

C580503@umcvmb.missouri.edu (Albert Foo) writes:
: Has anybody written some routines in 'c' accessing dbase .dbf files?
: Or is there a public domain source available at a ftp site?
: 
: I'll appreciate anyone who can help. Thanks|
: Please send your replies to: c580503@umcvmb.missouri.edu
: 
I'd be interested too.  Please e-mail me..
-- 
Joe Wright  alpha@wyvern.twuug.com    
Newsgroups: comp.lang.c
From: thor@arrakis.denver.co.us (Robert B. Hood)
Subject: sscanf and floating point
Summary: a strange error message
Reply-To: thor@arrakis.denver.co.us
Organization: Bob's Programming Paradise, Lakewood, CO, USA
Date: Wed, 8 Apr 1992 04:08:51 GMT

Can anybody tell me why the following code produces the
following run-time error message?

------------------ le code snippet -----------------
    int      x,y,z;
    double   number;
    long     long_number;
    char     format[25];

    ...

    y = ...num_size.digits - 1;
    Grab(buff,buff+y,text);   // places "    234.34" in text 

    buff += y;
    ++buff;

    z = ...num_size.decimal_places;
    if(z > 0)
    {
        // the following sprintf produces "%07.02f"
        sprintf(format,"%%%02d.%02df",y - z,z);
        sscanf(text,format,&number);
        printf("\t");
        // this printf produces the error message below
        printf(format,number);
        printf(" [F]\n");
    }
    else
        long_number = atol(text);

...
---------------- le error --------------------------
(tab)printf: floating point formats not linked
Abnormal program termination
----------------------------------------------------

This was written using BC++ 2.0, and I use the command
line version (bcc).

My link file looks like:

d:\bcc\lib\c0l main initdb getstruc opendb listinfo+
setarea closedb getrec putrec goto getrecl getalias+
addblank delete recall f2b b2f grab
test
test
d:\bcc\lib\cl+
d:\bcc\lib\mathl+
d:\bcc\lib\fp87

I have a '486, so I used 'fp87'.  I have tried variations
(mathl and emu, mathl alone), and added and removed 'math.h'
and 'float.h' from the source.

Is this one of the bugs in version 2.0?  I have my code
exactly as it shows in TFM, but I get this enigmatic
error.

Thanks in advance for any advice.

Bob
-- 
Bob Hood    thor@arrakis.denver.co.us     H: 303-980-8392  W: 303-236-8959
---------------------------------------------------------------------------
           If a program is useful, it will have to be changed.
         If a program is useless, it will have to be documented.
Xref: sparky comp.lang.c:7671 comp.windows.ms.programmer:5488
From: abeals@autodesk.com (Andrew Scott Beals, KC6SSS)
Newsgroups: comp.lang.c,comp.windows.ms.programmer
Subject: Re: Please. (Was Re: I Hope the BC++ IDE Editor Supports OLE Soon)
Date: 15 Apr 92 23:07:10 GMT
Article-I.D.: melange.abeals.703379230
Followup-To: comp.lang.c

tjr@cbnewsc.cb.att.com (thomas.j.roberts) writes:


>Well, I used to agree with you. Then I started using Borland's Turbo C
>Integrated Development Environment (IDE). This IDE has evolved into a
>truly useful environment that puts emacs to shame. I now find that working
>on UNIX is a real pain (the IDE automatically positions the
>editor to the character where the complier detected an error - ~90% of
>the time that is precisely where I need to edit). And the error messages
>even contain a (usually) comprehensible description of the error (boy,
>MS-DOS/BC++ sure isn't UNIX!! (:-).

Gee, now let's see.  Lightspeed C [now "Think C"] did that for me back in '87..

BSD 4.1 Unix did that for me with cc||make+error+vi back in '81.


Yes, I would say that MS-DOS/BC++ sure isn't Unix!


Those who do not remember history are doomed to reinvent the wheel over
and over again.
--
Andrew Scott Beals	abeals@autodesk.com, kc6sss@n6eeg.#nocal.ca.usa.na
147.300MHz+, 440.900MHz+ [ctcss 114.8Hz]
Vivu libere a>u mortu!
Newsgroups: comp.lang.c
From: mcook@mrc.dev.cdx.mot.com (Michael Cook)
Subject: Re: passing structure to a function
Organization: Motorola Codex, Canton, Massachusetts
Date: Sat, 11 Apr 1992 13:29:02 GMT

volpe@bart.crd.ge.com (Christopher R Volpe) writes:

>In article <mcook.702843388@mrc.dev.cdx.mot.com>,
>mcook@mrc.dev.cdx.mot.com (Michael Cook) writes:
>|>volpe@bart.crd.ge.com (Christopher R Volpe) writes:
>|>
>|>>C, whether it be ANSI or pre-ANSI, has always required that all parameters,
>|>>structures or otherwise, be passed by value.
>|>
>|>Except arrays.  They're passed by reference.

>Wrong. Arrays aren't passed at all. Pointers are passed. And they're passed
>by value.

What's the difference between call-by-reference and passing a pointer?
-- 
 ==========================================================
 Michael.Cook@merlin.dev.cdx.mot.com          (617)821-7590
 Motorola/Codex, 20 Cabot Blvd, C2-135, Mansfield, MA 02048
 ==========================================================
From: darcy@druid.uucp (D'Arcy J.M. Cain)
Newsgroups: comp.lang.c
Subject: Re: Redirecting output
Date: 16 Apr 92 12:26:14 GMT
Organization: D'Arcy Cain Consulting

nestorak@eregion.endor.cs.psu.edu (John  Nestoriak) writes:
>I have a program which at various points spits stuff out using printf.  Of
>course when we got the second part of the project we were told that we need
>to spit it out to a file.  Is there a way that I can redirect stdout to a 

I Haven't seen this suggested yet.  In a common header file for the project
add the following #define:

#define printf my_printf

And create a varargs function to do anything you want with the arguments.
You might want to change those printfs manually anyway so that future
maintainers see that there is something special going on but this gives
you a quick fix to your problem.

-- 
D'Arcy J.M. Cain (darcy@druid)     |
D'Arcy Cain Consulting             |   There's no government
Toronto, Ontario, Canada           |   like no government!
+1 416 424 2871          DoD#0082  |
Newsgroups: comp.lang.c
From: barak@robcad.uucp (Barak Pridor)
Subject: Need a tool for converting C code to ANSI-C
Organization: ROBCAD Ltd. Herzelia - Israel
Distribution: comp.lang.c
Date: Mon, 13 Apr 1992 18:12:50 GMT


I'm looking for a tool that creates ANSI-C function declarations from 

traditional C code (that is -  puts the parameter declarations inside the 

parenthesis ).

I know about the GNU "protoize", but it exists as a patch for gcc, and 

I'm encountering ( usual ) problems with installing gcc on my IRIX.


replies via e-mail would be appreciated.

Thanks,
--


	Barak Pridor		      \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
	Robcad Ltd.		      \\    \\	  \\    \\    \\    \\    \\
	Delta House                   \\    \\	  \\    \\    \\    \\    \\
	16 Hagalim Ave.               \\    \\	  \\    \\    \\    \\    \\
        Hertzlia  46733               \\    \\	  \\    \\    \\    \\    \\
	Israel                        \\    \\	  \\    \\    \\    \\    \\
	e-mail : uunet!robcad!barak   \\    \\    \\    \\    \\    \\    \\
	Phone  : 972-52-556543        \\    \\    \\    \\    \\    \\    \\
	Fax    : 972-52-544402        \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
From: jamesh@cs.umr.edu (James Hartley)
Newsgroups: comp.lang.c
Subject: maximum malloc() allocation size?
Date: 9 Apr 92 03:18:31 GMT
Organization: University of Missouri - Rolla
Originator: jamesh@mcs213f.cs.umr.edu

In fooling around with porting code to and from an Amiga to a Sun, I
have run into some allocation quirks.  I also can't seem to locate where
ANSI states this *if* they do, but is there a maximum size in which
malloc(), calloc(), etc. can allocate?  Inquiring minds want to know...
I sincerely appreciate any pointers (no pun intended) and anyone can
give me.
-- 
James J. Hartley               _   /| Internet: jamesh@cs.umr.edu
Department of Computer Science \'o.O'   Bitnet: jamesh@cs.umr.edu@umrvmb.bitnet
University of Missouri - Rolla =(___)=    UUCP: ...!uunet!cs.umr.edu!jamesh
"If at first you don't succeed,   U   compile, compile, again..."
Newsgroups: comp.lang.c,comp.os.msdos.programmer
From: thor@arrakis.denver.co.us (Robert B. Hood)
Subject: Re: scanf and floating point
Followup-To: comp.os.msdos.programmer
Summary:  BC++ is not behaving predictably
Reply-To: thor@arrakis.denver.co.us
Organization: Bob's Programming Paradise, Lakewood, CO, USA
Date: Thu, 9 Apr 1992 15:55:56 GMT

[ For those of you joining us late, this article is in
regards to a "printf: floating point formats not linked"
error message that Borland C++ 2.0 generates when working
with floating point numbers. ]

Thanks to all who replied.  The general concensus is to
include a floating point number or operation in your
code for the compiler to see.  This should cause BC++
to link in the floating point support.  However, when
I tried including the statement:

           float      f = 1.0;

in my main module, _it still didn't link in the
floating point libraries_!  I began to wonder if my
compiler had become corrupted.

When I typed in this short program, compiled it
with the 'bcc' command, *it worked*!  You'll note
that there is *no* reference made anywhere to an constant
FP number, only a character string:

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

void main(void)
{
    char     *text = "    34.43";
    float    number;

    sscanf(text,"%f",&number);
    printf("%9.02f\n",number);
}
-------------------------------------------------

Since my program used the same functions but generated
an error message, I concluded that it had to be
something *external* that wasn't set right.

What I did then was re-compiled the above program,
and when it entered the link phase, I killed its
window (DESQview).  I was then able to examine the
contents of the compiler-generated "turboc.$ln" file.

This "invisible" link file and mine were almost
identical except for the *library search order*.
Where my link file had:

      d:\bcc\lib\cl+
      d:\bcc\lib\mathl+
      d:\bcc\lib\emu

the `turboc.$ln' file had:

      d:\bcc\lib\EMU+
      d:\bcc\lib\MATHL+
      d:\bcc\lib\CL

After re-arranging my link file to match, my program
worked perfectly -- without *any* reference to a
constant FP value.

Do you suppose the link-it-only-if-we-see-the-need
attitude has changed?

Bob
-- 
Bob Hood    thor@arrakis.denver.co.us     H: 303-980-8392  W: 303-236-8959
---------------------------------------------------------------------------
           If a program is useful, it will have to be changed.
         If a program is useless, it will have to be documented.
Xref: sparky comp.lang.c:7442 comp.std.c:1781
From: grieb@girtab.usc.edu (Charles Grieb)
Newsgroups: comp.lang.c,comp.std.c
Subject: Re: long long long long long madness
Date: 10 Apr 1992 03:02:18 -0700
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: girtab.usc.edu

How about:

int:n	At least n bits (n must be a constant int expression)
int:n:m	At least n bits and not more than m bits
int:n:n	Exactly n bits
float:n
float:n:m
enum:n (xxx...)

All scaler types are defined by four settings:
unsigned, minimum size, maximum size, and float.

A minimum size means at least 2^n different values may be stored there.
The compiler can have maximum minimum sizes and produce errors if
too large of a value is requested.

A maximum size means that the item occupies no more than that many
bits *rounded up to the next efficient addressing boundary*.  What is
an efficient addressing boundary can *vary* depending on whether a
type is in a structure or not or even it's location in the structure.
A maximum width does *not* imply modulo 2^m arithmetic!  Most
implementations ignore maximum widths of floats.

unsigned means that the values are interpreted as positive numbers.
Unsigned may be ignored on floats.

Float means the values represent floating point numbers.

A typedef carries the min and max with it.  If it is used but followed
with new sizes, these take precedence.

You may typedef the reserved words float, double, long, int, short,
and char.  If not then built-in defaults occur.  Typedefs follow
scope.  Typical default settings:

typedef int:8 char;
typedef int:16 short;
typedef int:32 int; /* not recursive because sizes take precedence */
typedef int:32 long;
typedef float:32 float;
typedef float:64 double;

Bill Spitzak
Newsgroups: comp.lang.c
From: rbs@cyclops.micr.Virginia.EDU (Robert B. Sisk)
Subject: Re: Help!Graphics screen print routine needed!
Organization: University of Virginia
Date: Wed, 15 Apr 1992 16:03:56 GMT

In article <1992Apr14.151638.5321@proto.com> joe@proto.com (Joe Huffman) writes:
>rcs76179@zach.fit.edu (Adnan Zejnilovic / ADVISOR M. Schneider) writes:
>
>>I have developed a program that displays different graphs on the screen using
>>Turbo C v2.0. I would like to be able to print these graphs on a dot matrix
>>printer.
>
>Try the product 'Baby Driver' from Autumn Hill Software.  It supports
>hundreds of printers and works with Turbo C...
>
>Autumn Hill Software
>1145 Ithaca Drive
>Boulder, Colorado 80303
>
>Voice: 303-494-8865
>FAX:   303-494-7802
>BBS:   303-494-8868
>
>
>-- 
>uunet!proto!joe
>joe@proto.com

Seems like I remember someone posting a message that drivers like that
mentioned above are in the public domain.  Are these drivers available?
Are they on compuserve and/or some FTP reachable server?  

Bob

-- 

Robert B. Sisk
NAR #53448				Internet: rbs@virginia.edu
TRIPOLI #1583				UUCP:     uunet!virginia!rbs
Newsgroups: comp.lang.c
From: andrews@sp1.csrd.uiuc.edu (John Andrews)
Subject: Re: Looking for C style/coding standards info
Organization: UIUC Center for Supercomputing Research and Development
Date: Wed, 8 Apr 92 17:03:37 GMT

craven@kira.msu.edu (Dean Craven) writes:

>Hi,

>I am looking for C programming style/coding conventions.  I found a few
> [ more explanation]

There is a good book available on the subject.  I have a copy in my office,
so this is from memory:

Title:  C Style (?)
Author: David Straker (?)
Publisher: Prentice Hall, 1992

Highly recommended.

--
John Andrews (andrews@csrd.uiuc.edu) "He who dies with the shortest .sig, wins"
Graduate Research Assistant, Center for Supercomputing R&D, Urbana, IL
From: moconnor@pms704.pms.ford.com (Mike O'Connor)
Newsgroups: comp.lang.c
Subject: Converting flock() to lockf()
Date: 13 Apr 92 20:05:10 GMT
Article-I.D.: fmsrl7.1992Apr13.200510.10515
Reply-To: Mike O'Connor <mjo@fmsrl7.srl.ford.com>
Organization: "Fordz"
X-Disclaimer: Not an official spokesperson for Ford Motor Co.

Anyone have a nice set of routines for converting flock() calls to
lockf() calls for a system which doesn't have flock()?

-- 
 Mike O'Connor                     |  Ford Motor Company, USA
 Applications Systems Analyst      |  CPD P&MS ECC Core Software
 Phone #:  +1 (313) 390-4008       |  P.O. Box 2053, ECC MD-7
 Fax #:    +1 (313) 845-0576       |  Dearborn, MI  48121-2053
From: v101q4ct@ubvmsb.cc.buffalo.edu (Brendon M McNamara)
Newsgroups: comp.lang.c
Subject: using #define
Date: 13 Apr 92 22:21:00 GMT
Organization: University at Buffalo
News-Software: VAX/VMS VNEWS 1.41

How can I do this:

#define FILE(n)   "FILE.F"(somehow stick n in here)

func() {
    int x;
    for (x=0;x<10;x++) printf("\n%s",FILE(x));
}

to create the following output:

FILE.F0
FILE.F1
FILE.F2
FILE.F3
FILE.F4
FILE.F5
FILE.F6
FILE.F7
FILE.F8
FILE.F9

I think that completely defines the question without
really asking a thing.


BMc
Newsgroups: comp.lang.c,comp.sys.sun.misc
From: scs@adam.mit.edu (Steve Summit)
Subject: Re: Why aren't my floats passing as doubles?
Followup-To: comp.lang.c
Reply-To: scs@adam.mit.edu
Organization: none, at the moment
Date: Sun, 12 Apr 1992 17:38:42 GMT

In article <mdrj_k=.lmb@netcom.com> lmb@netcom.com (Larry Blair) writes:
> I'm using Sun's ANSI C compiler on a SS2 under SunOS 4.1.1.
> What's happening is that in some of the files, for no apparent reason, if
> there is a formal parameter of "float" the generated code is looking for a
> 4-byte float to be passed in.  Since all floats are actually passed as
> doubles, occupying two registers, this is causing an argument mismatch.
>
> Does anyone know what can be causing this?

Why, yes: "Sun's ANSI C Compiler."  As Kenneth Herron has already
pointed out, the ANSI C Standard explicitly allows implementations
to pass floats as floats (as long as "new style" function
declarations and definitions are in use), obsoleting the pre-ANSI
rule that all floats were promoted to double.

Why are the floats only being passed/accepted as floats some of
the time, and not all of the time?  Perhaps some modules were
compiled with a non-ANSI compiler (such as Sun's earlier ones*).
Perhaps some modules are coming out of libraries which were so
compiled, perhaps deliberately (to allow the use of Sun's
non-ANSI compiler).  Perhaps (this is the most likely cause) some
of the functions-that-are-supposed-to-accept-float are defined
using old-style syntax (in which case the compiler rewrites the
parameter declarations to say that they accept doubles), and some
using new-style (in which case the compiler leaves "narrow"
parameters alone).  Or, perhaps some modules, which include calls
to the functions-that-are-supposed-to-accept-float, do not have
(new-style) function prototypes in scope: in this case, the
behavior defaults to "old style," and the arguments (whether
float or double) would be promoted to double.

For now, I recommend not declaring any function formal arguments
as float, short int, or char, especially when portability to
pre-ANSI compilers is desired, or when it may be necessary to
link together heterogeneous object files (some compiled with
pre-ANSI compilers and some with ANSI).  It's just too easy to
have these argument type incompatibility problems, especially
since the ANSI new-style vs. old-style rules are (necessarily)
complicated.  (My recommendation is "especially when it may be
necessary" rather than "only when it may be necessary" because
even if you don't think it's necessary to allow interim and/or
simultaneous use of pre-ANSI compilers, accidental use by your
colleagues of the wrong compiler and/or accidental omission of
prototypes in certain modules is likely to have the analogous
effect.)

[Followups to comp.lang.c, unless they have to do only with
something Sun-specific.]

					Steve Summit
					scs@adam.mit.edu

* My references here to "Sun's ANSI compiler" and "Sun's earlier
compilers" are based on my imperfect memories of descriptions
I've read in passing about the Sun C compiler situation, and may
not accurately reflect reality.
Xref: sparky comp.lang.c:7549 comp.sys.amiga.programmer:7641
From: ta00mmc@unccvax.uncc.edu (Michael McKnight)
Newsgroups: comp.lang.c,comp.sys.amiga.programmer
Subject: Integer to String in C
Date: 13 Apr 92 20:59:03 GMT
Followup-To: poster
Organization: University of NC at Charlotte

I need a function in C to convert an integer into a string.  For example:
Integer = 123
String  = "123"

Any help will be appreciated... source code or a standard function name
would be great!  I am trying to learn C on my own and I'm stuck!  I
guess it would be the functional opposite of atoi().

Please reply via Email only!
-Michael McKnight
ta00mmc@unccvax.uncc.edu