HDTenEightyP/NetNews huggingface dataset:
From: jamshid@ut-emx.uucp (Jamshid Afshar)
Newsgroups: comp.lang.c
Subject: Re: printf() questions
Summary: read printf() docs wrt `*' and `precision'
Date: 6 Apr 92 09:38:37 GMT
Organization: The University of Texas at Austin; Austin, Texas

In article <22918.29da2dd0@amherst.edu> pfcouvares@amherst.edu writes:
>I want to print this string out [...] in a field of length
>NAME_SIZE. (i.e. printf("%-25s",name) ... except with NAME_SIZE where 25 is)
>Is this possible with printf or one of its relatives, or must I write the code
>out myself to do it? It seems like something that should be possible...
>
>2) If you indicate a field, and the string turns out to be longer, printf will
>print the entire string anyway. Is there any way to make printf truncate the
>string so that the field is absolute even if the string is longer?

If you don't have an ANSI C compiler and library, you could be out of
luck as they might not implement these features.  If you do have an
ANSI C compiler, read the documentation on printf() for more info (and
there's lots).  To specify a minimum (left-padded) string width of
`NAME_SIZE':

	#define NAME_SIZE 25
	char* name = "Jamshid";
	printf("%-*s", NAME_SIZE, name);  /* `*' means the value is passed */
or
	#define X_STR(x) #x
	#define STR(x) X_STR(x) /* 2 macros needed for some cpp subtleties */
	   /* an ANSI C compiler merges "%-" "25" s" into "%-25s" */
	printf("%-" STR(NAME_SIZE) "s", name); /* printf("%-25s", name); */

Use the `precision' specifier to specify the maximum width of a string:
	printf("%-25.25s", name);  /* value after `.' is `precision' */

and then just put all together in a macro so you don't have to type it
in each time:
	#define NAME_FMT "%-" STR(NAME_SIZE) "." STR(NAME_SIZE) "s"
	printf("Hello, " NAME_FMT ", you may already have won $%.2f.",
	       name, cash_jackpot);

Jamshid Afshar
jamshid@emx.utexas.edu
Xref: sparky comp.lang.c:7399 comp.programming:791
From: andreww@suite.sw.oz.au (Andrew White)
Newsgroups: comp.lang.c,comp.programming
Subject: Re: 1-800-SPELL-IT
Date: 10 Apr 92 06:47:30 GMT
Organization: Softway Pty Ltd

>In article <1992Apr6.214828.15228@dsg.tandem.com> narayan@aravali.everest.tandem.com (Pankaj Narayan) writes:

>	   Does anyone have any programs that will take a string of digits
>	   and convert them to something meaningful by matching them
>	   against the telephone digit-to-alphabet table.

>	   e.g. if I had the number 773 5548, I could better remember it as
>		  SPELL-IT.

>	   This is a problem in looking up many  combinations (3**7 )in /usr/dict
>	   or something, but if someone has a solution, or would like to write
>	   one, please post or mail it.
> -- 
> ------------------------------------------------------------------------
> Pankaj Narayan			Email: narayan_pankaj@tandem.com
> Tandem Computers			Voice: 408 285 6047 (work)  
> 19333 Vallco Pkwy, Loc 3-06		
> Cupertino, CA 95014-2599		Fax:   408 285 7079


Each number maps to, what, 3 or 4 letters?, so why don't you just convert
the string of numbers into a grep string of characters.

e.g.	2 -> [afhj]  (I mad these up because I don't know the real mappings.)
	3 -> [qrn]

Then to find 222 3333 for example, just use:

	"grep '[afhj][afhj][afhj][qrn][qrn][qrn][qrn]' /usr/dict/words"

Seems simple to me, am I missing something?

Obviously grepping for a sequence of words is slightly more complicated
by not by much.

-- 
 _--_|\      Softway Pty Ltd        Phone:           Computer:
/      \     P.O. Box 305            +61 2 698 2322   andreww@softway.sw.oz.au
\_.--._/<--  Strawberry Hills 2012  Fax:             Telex:
      v      Australia               +61 2 699 9174    AA27987
Newsgroups: comp.lang.c,comp.sys.mac.programmer
From: atbowler@thinkage.on.ca (Alan Bowler)
Subject: Re: Problem De-allocating Memory in variable sized arrays
Organization: /etc/organization
Date: Wed, 15 Apr 1992 17:10:13 GMT

In article <1992Apr14.153034.18214@hobbes.kzoo.edu> k044477@hobbes.kzoo.edu (Jamie R. McCarthy) writes:
>erh0362@tesla.njit.edu writes:
>>
>>	It's not only possible. It's a standard thing to do in certain 
>>circumstances...
>>
>>	int *temp, *myarray;
>>	temp = (int ) malloc(N * sizeof(int));
>>	myarray = temp - 1;
>>
>>This is all quite well documented in Numerical Recipes in C,
>>along with routines to do similar things for multi-dimensional matrices.
>
>This will work on the Mac (currently), because pointers are always 32
>bits, memory is contiguous, there's no memory protection, and everything
>is generally clean and tidy.  But don't assume it's portable.  

It is true that this use of pointers is not sanctioned by the the
standard.  As the FAQ points out there may exist architectures and
implementations where
    p = &array[0] - 1;
might not give a useable pointer, so p[1] will not address array[0].

However, these machines are not all that common, and it may be
legitimate to say that you are not interested in porting to them.
"portability" is NOT an absolute value.  It is a measure of how
much effort it is to reuse the existing code versus how much effort
to reimplement from scratch.  It is affected by features of the new
environment.  No program is absolutely portable to all environments.
(As a trivial example, by choosing a language, you restrict the code
to environments that support that language.)  Any program has a set of
enviroments that it is easily ported to, and as a rule of thumb you
should strive to make that set as large as possible.  However, there
are tradeoffs, and the larger the set of environments, the more time
and effort goes into the programming and maintenance.  It may well be
a smart decision to decide that you are not interested in porting to
certain environments.  As an extreme case, if you are writing a
compiler to produce code for a sewing machine, you probably are not
worried about making the compiler itself run on the sewing machine,
and so don't need to worry about the fact that there is no file system.
A harder choice would be a compiler for a 36/72 bit machine.  Is it
worth worrying about making it run as a cross compiler from a 32 bit
workstation.  There would be would be a lot of overhead in writing
routines to simulate the target machine arithmetic, and using routines
instead of inline operators would have a performance penalty when
running the compiler on the 36/72 bit machine.  The tradeoffs are not
clear.

Certainly there are a number of coding practices that cost very little
and widen the set of target machines.  These should be used routinely.
However, portability is not the only goal, and you need to consider the
tradeoffs of wider portability versus the costs in extra code poorer
performance etc.
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.lang.c
Subject: Re: Is the address of a global a constant?
Date: 7 Apr 92 18:14:20 EDT

eric@pencom.com writes:
>In article <chupchup.702626670@piggy> chupchup@ferkel.ucsb.edu (Robert Earl)  
>writes:
>> eric@pencom.com writes:
>> | Is the address of a global supposed to be considered a valid constant?
>> No.  The address-of operator (&) is just an operator and does not
>> yield a constant value.

This, of course, is false, as anyone who BOTHERS TO READ THE STANDARD will
know.

>The C compiler treats the address of an external variable as a constant
>sometimes, but not in others.  Why?

The address of an object with static duration is ALWAYS a constant.
It is NEVER an integral constant expression.

OK?
From: jfw@ksr.com (John F. Woods)
Newsgroups: comp.lang.c
Subject: Re: Is the address of a global a constant?
Date: 8 Apr 92 13:09:23 EDT

chupchup@ferkel.ucsb.edu (Robert Earl) writes:
>jfw@ksr.com (John F. Woods) writes:
>OK.  I quote K&R II:
>"Constant expressions may not contain assignments, increment or
>decrement operators, function calls, or comma operators, except in an
>operand of sizeof.  If the constant expression is required to be
>integral, its operands must consist of integer, enumeration,
>character, and floating constants; ...  This necessarily rules out
>arrays, indirection, address-of, and structure member operations."

That is another way of looking at what the standard says.  Quoting the
Standard:

"More latitude is permitted for constant expressions in initializers.
Such a constant expression shall evaluate to one of the following:
* an arithmetic constant expression,
* a null pointer constant,
* an address constant, or
* an address constant for an object type plus or minus an integral
  constant expression.
...
   An address constant is a pointer to an lvalue designating an object of
static storage duration, or to a function designator."

I think, then, that I was wrong to assert that "The address of an object
with static duration is ALWAYS a constant" since that appears to be
conditional upon being in the context of an initializer; however, the only
place I can find in the syntax where "constant-expression" is not constrained
to be an "integral constant expression" is in initializers and expressions.

>Unless the standard turned around and did something completely
>different from what is in K&R, I highly doubt that "the address of an
>object with static duration is ALWAYS a constant.".  I agree that it
>is not an integral constant expression; but what is this?
>case &y - &z:

&y - &z is undefined, if y and z are not macros designating members of
the same array.  If they are, it certainly isn't an integral constant
expression.  Note that

	case 3.14159265358979323:

is also illegal (though (int)3.14159265358979323 would be OK) and, if
the standard is to be taken literally,

	case (int)(1.0 - 1.0):

is also illegal (the standard says that "An integral constant expression
shall ... have only operands that are ... floating constants that are the
immediate operands of casts."  I assume that leaves out floating arithmetic
constant expressions that are the immediate operands of casts.

So, the Standard defines several classes of constant expressions, and sort
of leaves it up to the careful reader to realize that only one class
(integral constant expression) is valid in nearly every context where a
constant expression is required.
Newsgroups: comp.lang.c
From: chupchup@ferkel.ucsb.edu (Robert Earl)
Subject: Re: Is the address of a global a constant?
Organization: (EVIL!)
Date: Tue, 7 Apr 1992 06:04:30 GMT

eric@pencom.com writes:

| Is the address of a global supposed to be considered a valid constant?

No.  The address-of operator (&) is just an operator and does not
yield a constant value.

| int foo(int *p)
| {
|         switch(p)
| 	{
| 		case &a :
| 		    return 1 ;

[ deleted... ]

| gcc first complains that p is not an integer.
| It then complains that the switch labels are not constant.
| Are these valid compiler gripes?

Yes.
-- 
robert earl		rearl@piggy.ucsb.edu

"eenie, meenie, chili beanie, your lucky number is... C!" ---Kelly Bundy
Newsgroups: comp.lang.c
From: comptec91055@camins.camosun.bc.ca
Subject: network id soft.
Organization: Camosun College
Date: Wed, 15 Apr 1992 00:28:35 GMT



		Hello Hardware gurus and hackers:

			I am attempting to write a small routine which can be
executed on any pc that returns information on the resident network card (type
mem. cap. etc.)  (assembly/c routine).. My problem is that I am unsure of which
interrupts the card takes over when it is installed, whether or not these inter-
rupts are from the dos vector table or directly from the cpu, and how they can
be used to access card info.  If anyone has the time I would very much appreciate
 any information that could be provided.  I will send anyone that responds a copy
of the final program which does a series of hardware checks and verifications
on the pc, including nice output (not that anyone responding would need this,
but what the heck..)   If there are any ideas could you please e-mail them.
 			Thanks in advance,
	
			D. Rozee
From: l.d..bricker@ehbbs.hou.tx.us (L.D. Bricker) 
Newsgroups: comp.lang.c
Subject: C COMPILER REVIEWS NEEDED
Date: 6 Apr 92 22:34:00 GMT
Distribution: world
Organization: Ed Hopper's BBS - Houston, TX - 713-997-7575
Reply-To: l.d..bricker@ehbbs.hou.tx.us (L.D. Bricker) 

I just got the Zortech compiler v3.0r4.  I will compile both c and c++.
I am just starting out but so far am very pleased.  If you have access
to fidonet or ilink (I think that is it but just found it tonite) you
can look for either Bob Stout or Roy Browning, both local to Houston and
both fully qualified to author texts, teach courses/seminars etc.
Either/both can give you much information
                                                                                                                      
Xref: sparky comp.lang.c:7365 comp.unix.misc:1993 comp.unix.programmer:2279 comp.benchmarks:680
From: lwall@netlabs.com (Larry Wall)
Newsgroups: comp.lang.c,comp.unix.misc,comp.unix.programmer,comp.benchmarks
Subject: Re: Buffered file reads, and speeds of C prog vs. wc vs. awk vs. perl
Date: 8 Apr 92 17:19:45 GMT
Organization: NetLabs, Inc.

In article <CKD.92Apr1124623@loiosh.eff.org> ckd@eff.org (Christopher Davis) writes:
: I would ignore the perl numbers in this thread because they're based on
: a2p-written code, not actual perl code.
: 
: Try this instead:
: 
: perl -e 'while(<>) {}; print "$.\n";'

Well, that's actually what a2p spits out, to the first approximation...

: Or would you test C with code written in FORTRAN and run through f2c?
: 
: (An unscientific test on a SPARC ELC, SunOS 4.1.2, perl 4.0.19:
: > time perl -e 'while(<>) {}; print "$.\n";' < /etc/termcap > /dev/null
: 0.150u 0.370s 0:00.48 108.3% 0+238k 0+0io 0pf+0w
: > time awk 'END {print NR}' < /etc/termcap > /dev/null
: 0.200u 0.070s 0:00.27 100.0% 0+122k 3+0io 2pf+0w
: )

Note that there's a perturbing factor here (in more ways than one).
Where's all that system time going for the perl test?  It turns out
that it's mostly calls to signal routines, caused by supersafe
implementations of setjmp()/longjmp(), used to enter and exit the null
block.  Ick.  We're also probably getting hammered by saving and
restoring larger register windows.  Life used to be simpler...

To get around the longjmp() overhead (until I scrap those calls), you
can say

	perl -le '1 while <>; print $.;'

That'll run faster than sed.  But to get on towards egrep speeds, you
want something like

	perl -le '$sum += tr/\n// while sysread(STDIN,$_,8192); print $sum'

Larry Wall
lwall@netlabs.com
Newsgroups: comp.lang.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: Is the address of a global a constant?
Organization: TauMetric Corporation
Date: Wed, 8 Apr 1992 15:32:04 GMT

chupchup@ferkel.ucsb.edu (Robert Earl) writes:

>jfw@ksr.com (John F. Woods) writes:

>| The address of an object with static duration is ALWAYS a constant.
>| It is NEVER an integral constant expression.

>I quote K&R II:

>"Constant expressions may not contain assignments, increment or
>decrement operators, function calls, or comma operators, except in an
>operand of sizeof.  If the constant expression is required to be
>integral, its operands must consist of integer, enumeration,
>character, and floating constants; ...  This necessarily rules out
>arrays, indirection, address-of, and structure member operations."

>Later it goes on to *specificially* *permit* the use of address-of for
>*initializers*.

>Unless the standard turned around and did something completely
>different from what is in K&R, I highly doubt that "the address of an
>object with static duration is ALWAYS a constant.".

We have to remember that K&R2 is not the official ISO/ANSI C Standard.

First, that book was published before work on the Standard was complete,
and some things did change between the two publication dates.

Second, K&R sometimes paraphrase the Standard.  The C Committee often
argued for long periods of time about the precise wording of sections,
and even about the placement of commas.  It is likely that in many
cases a paraphrase will not have the identical meaning.  This is not
intended as criticism of K&R; their book is a tutorial, not a Standard.
The Standard is a horrible tutorial; it wasn't meant to be one.

Section 3.4 of the Standard discusses several different kinds of
constant expressions.  One kind is an "address constant", which may
contain an address-of operator.  In discussing constant expressions in
general, there is no prohibition against the address-of operator.  The
quoted paragraph above collapses the discussion of different kinds of
constants into one, and is a little misleading, at least as quoted here.

Woods is entirely correct.  The address of a static object is a
constant expression.  In particular, it is an "address constant".
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Xref: sparky comp.lang.c:7557 comp.windows.ms.programmer:5399
From: twbrown@PE-Nelson.COM (Tom W. Brown)
Newsgroups: comp.lang.c,comp.windows.ms.programmer
Subject: Re: Please.  (Was Re: I Hope the BC++ IDE Editor Supports OLE Soon)
Date: 14 Apr 92 00:26:33 GMT
Followup-To: comp.lang.c
Organization: PE-Nelson

In article <1992Apr13.192943.28164@cbnewsc.cb.att.com>, tjr@cbnewsc.cb.att.com (thomas.j.roberts) writes:
|> From article <kuede7INN40h@alhena.usc.edu>, by ajayshah@alhena.usc.edu (Ajay Shah):
|> > ebergman@isis.cs.du.edu (Eric Bergman-Terrell) writes:
|> > 
|> >>I'm excited about the potential for using OLE in a compiler's text editor.
|> >>In addition to leaving voice annotations, etc., documentation could be inserted
|> >>in-line.  The documentation could be diagrams, word processor text, voice 
|> >>samples, even animated video.
|> > 
|> 
|> However, I, too, do not believe that animation/audio objects in source code
|> will help developers. As alluded to above, nothing can take the place
|> of an intelligent, well though out design - that takes thought, experience,
|> time, and effort.
|> 

I'll second this; consider:

  1) Not only does the original request call for a fairly significant
     modification of the program editor, but it calls for a _major_ modification
     of the preprocessor and compiler which currently handle only "flat text".
     Perhaps if you use a pre-preprocessor that takes an annotated source file
     and generates flat ASCII this concern goes away at the expense of another
     step in the compilation process.

     I haven't tried, but if you do this now in something like Word for Windows
     and "Save As" a text file, is the result compilable?  If so, then maybe
     that's all you need.

  2) This would seem to have a major impact on source code portability which,
     to the extent it currently exists, is based on ASCII portability.  It will
     be some time before OLE is a truly portable convention for embedded
     files.

  3) IMHO it takes less time to write a standard C comment that adequately
     explains a data structure or algorithm than it would take to create some
     graph or animation.


----------------------------------------------------------------------------
Tom Brown               |  "Strange women, laying in ponds, distributing
PE Nelson Systems       |   swords is no basis for a system of government."
twbrown@pe-nelson.com   |                    Monty Python and the Holy Grail
----------------------------------------------------------------------------
Xref: sparky comp.lang.c:7305 comp.unix.questions:5936 comp.unix.programmer:2266 comp.unix.shell:1995 comp.databases.oracle:450
From: geir@fdmetd.uucp (Geir Engebakken)
Newsgroups: comp.lang.c,comp.unix.questions,comp.unix.programmer,comp.unix.shell,comp.databases.oracle
Subject: Writing portable C, bourne sh, PRO*C.
Keywords: Portability, V.4/V.3, c, sh, PRO*C
Date: 7 Apr 92 16:21:21 GMT
Followup-To: poster
Organization: Fellesdata a.s, Oslo, Norway


We are about to init a project of writing (new release) an application
involving :
	
	pure C-code
	Bourne shell scripts 
	ORACLE embedded sql (PRO*C)
	ORACLE SQL*FORMS

Presently there is no unique std for portability considerations.

What ideas do you have (e.g. #ifdefs in the c-code)?
What is the most readable way of doing it?
What is the best '#ifdef' in a sh-script?

Tusen takk,
Geir

-- 
Geir Engebakken, Fellesdata a.s, P.O. Box 248, 0212 OSLO 2, NORWAY
Phone : +47 2 52 80 44                            Fax   : +47 2 52 85 10
E-mail : ...!mcsun!nuug!fdmetd!geir  or           geir@fdmetd.uucp
<The opinions expressed, if any, do not represent Fellesdata a.s>
From: volpe@bart.crd.ge.com (Christopher R Volpe)
Newsgroups: comp.lang.c
Subject: Re: passing structure to a function
Date: 9 Apr 92 13:34:54 GMT
Reply-To: volpe@bart.crd.ge.com (Christopher R Volpe)
Organization: GE Corporate R&D Center

In article <ku66poINN5kp@early-bird.think.com>, barmar@think.com (Barry
Margolin) writes:
|>I believe ANSI C requires that structures be passed by value, and I also
|>think that most pre-ANSI C compiler that support structure passing also do
|>so. 

C, whether it be ANSI or pre-ANSI, has always required that all parameters,
structures or otherwise, be passed by value.

(This in no way prohibits an implementation from copying the structure 
argument, and placing an address of the copy on the stack. That's an
implementation detail, not a semantically different mechanism.)

|>Barry Margolin
|>System Manager, Thinking Machines Corp.
|>
|>barmar@think.com          {uunet,harvard}!think!barmar
                            
==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com
From: daves@hpopd.pwd.hp.com (Dave Straker)
Newsgroups: comp.lang.c
Subject: Re: Looking for C style/coding standards info
Date: 9 Apr 92 12:20:08 GMT
Article-I.D.: hpopd.36770005
Organization: Hewlett-Packard NSG-PWD, UK.

>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

Glad you like it John (and thanks for the recommendation!).

The full title is `C Style: Standards and Guidelines'
ISBN: 0-13-116898-3

Dave Straker            Pinewood Information Systems Division (PWD not PISD)
(}-8]                   HPDESK: David Straker/HP1600/01
#define opinions mine   Unix:   daves@hpopd.pwd.hp.com
Xref: sparky comp.lang.c:7401 comp.std.c:1772 comp.arch:4844
From: amf@amfent.Gwinnett.COM (Andy Feibus)
Newsgroups: comp.lang.c,comp.std.c,comp.arch
Subject: Re: PLEASE don't use "long long" for 64 bits + answer to letter
Date: 9 Apr 92 01:59:09 GMT

diamond@jit533.jit.dec.com (Norman Diamond) writes:
> In article <aFeoiB1w164w@amfent.Gwinnett.COM> amf@amfent.Gwinnett.COM (Andy F
> us) writes:
> >Without having "long long" in strict ANSI mode, is "long" 32 bits or 64 bits
> Regardless, in strict ANSI mode:  maybe yes, "long" is 32 bits or 64 bits,
> or maybe no, "long" isn't 32 bits or 64 bits.  It might be 36 bits or 60 bits
> or 128 bits or anything else that's at least 32 bits.
Actually, Norman, I was mostly asking about the particular compiler
(Mips, I believe) in question.  I wasn't planning to code to the answer;
just a curiousity, since the other modes had "long long" being 64 bits.
I just wondered that in absence of "long long", what size did they
decide to make "long".

Thanks, tho, for looking out for someone possibly creating non-portable code.
-- Andy.
andyfe@utoday.com
Newsgroups: comp.lang.c
From: meyer@dbsun.uucp (Don Meyer)
Subject: Re: CFront
Organization: BioMerieux-Vitek, St. Louis Mo.
Date: Wed, 15 Apr 1992 22:11:14 GMT


True, cfront emits regular old K&R 'C' code.  As such, you can indeed
"do anything" in 'C' that can be done is C++.  This principal can obviously
be extended to encompass assembly language or straight machine code.
Since 'C' compiles into those.

What people mean is that you can't do some things in 'C' in a way that
is maintainable.  Or even fit to be looked upon without screaming.
C++ can take nice clean simple C++ code and implement it in what humans
would consider _really ugly_ 'C' code.

In brief, that's the situation.

Don Meyer

-- 
-------------------------------------------------------------------------
meyer%dbsun.uucp@wupost.wustl.edu        |||     I am at two with nature.
Opinions expressed are personal.         |||       -- Woody Allen